2004487 - SVG filters can be applied to cross-origin iframes, enabling SVG clickjacking (and other SVG filter attacks)

Status: NEW

(Core :: SVG, defect)

Description

[Lyra Rebane]

I recently published a new attack technique called SVG clickjacking: https://lyra.horse/blog/2025/12/svg-clickjacking/ (tl;dr you can have complex interactive clickjacking attacks and data exfil through various means that enable attacks not possible with traditional clickjacking)

Writing the post I initially assumed that being able to apply SVG filters to cross-origin iframes was intended browser behavior, but the Chromium team let me know that they're currently discussing whether it is something that should instead be fixed on a browser level. They pointed out that Safari has already patched this back in 2017 (see https://crbug.com/40061989#comment55), so it might make sense for them to do it too.

It might make sense to implement a fix in Firefox too.

Please let me know if there's any additional information I should provide, the blog post goes over the technical details of the attack so please look at it first.

Comment 1

[Robert Longson [:longsonr]]

Presumably you can do this without filters just by positioning any html you like via position:absolute over the iframe to change it.

The way to stop this is to make sure that you set X-Frame-Options on pages that contain sensitive information you don't want 3rd parties to frame.

I.e. It seems to me that there is already a general solution to this problem.

Comment 2

[Lyra Rebane]

The difference between this technique and absolutely positioning html is that this technique can read individual pixels, process them with logic gates, and present it to the user in a completely different form.

For example, the filter can read individual letters from the source page text, and then turn that into a QR code link for the user to scan for data exfiltration. Extracting multiple bytes of data like this is not possible with just absolute positioning.

Or you could show different attack overlays depending on the individual pixels inside the iframe, also something not possible with absolute positioning.

Unlike absolute positioning, you can use this technique actually read cross-origin data and run logic on it.

Comment 3

[Tom Ritter [:tjr] (OOTO until April)]

I concur, I wished I had pushed harder on blocking this back when Safari blocked them. https://ritter.vg/misc/ff/svg-filters.html was an attempt from back then to enumerate the filters and how they applied cross-origin in different browsers. (Surely needs updating.). We landed some telemetry in Bug 1480695 but it never got followed up on...

The probe is still in the tree but the probe seems to be inactive for some reason? I will ask in #telemetry ...

Comment 4

[Tom Ritter [:tjr] (OOTO until April)]

Not sure if this telemetry link will work

For 145 Release in the last 30 days:

jq '
  group_by(.Platform, .Metric) |
  map({
      Product: .[0].Platform,
      Metric: .[0].Metric,
      avg_rate: (map(."Usage Rate" | tonumber) | add / length)
  })
' svgfilters.json

[
  {
    "Product": "Fenix",
    "Metric": "use.counter.doc.filtered_cross_origin_iframe",
    "avg_rate": 4.355162571701723e-05
  },
  {
    "Product": "Fenix",
    "Metric": "use.counter.page.filtered_cross_origin_iframe",
    "avg_rate": 0.00037627872801147236
  },
  {
    "Product": "Firefox",
    "Metric": "use.counter.doc.filtered_cross_origin_iframe",
    "avg_rate": 5.375039584503091e-06
  },
  {
    "Product": "Firefox",
    "Metric": "use.counter.page.filtered_cross_origin_iframe",
    "avg_rate": 5.574613732097723e-05
  }
]

I'm attaching per-country graphs.

Comment 5

[Tom Ritter [:tjr] (OOTO until April)]

Attachment: use.counter.doc.filtered_cross_origin_iframe - avg_rate vs. Country.png

Comment 6

[Tom Ritter [:tjr] (OOTO until April)]

Attachment: use.counter.page.filtered_cross_origin_iframe - avg_rate vs. Country.png

Comment 7

[Lyra Rebane]

Fyi the Chromium team decided that on their side, the responsibility lays with the website developer. They'd still like to mitigate it in the browser too as defense-in-depth, but it seems like a fix for this will not be prioritized atm.

Comment 8

[Lyra Rebane]

Chromium bumped the priority of the bug on their side to S2 (medium) now, so they probably plan on fixing it.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:TYLin, could you have a look please?

For more information, please visit BugBot documentation.