Attacks that remove a hosted payment element and render a convincing copy in its place, so card details are typed into attacker-controlled markup on a page that still looks entirely correct.
Published 24 August 2026
An embedded payment element is supposed to make skimming impossible. The card fields sit in an iframe served by the payment provider, your page can't read them, and a skimmer running on your page has nothing to steal.
That only holds while the real element is the one on the page. An attacker who can run script in the parent document can remove it and draw their own markup in the same spot. The layout survives, the styling matches, and the customer types their card into the attacker's fields.
Asking whether a script came from an approved source doesn't help here, because it did. The question that tells the injected tag apart from the real ones is whether anybody signed off on this script running on this page, and can say why it needs to be there.
That's what PCI DSS 6.4.3 asks, and it asks it per script on the payment page rather than per source host. A tag manager sails through a source check and fails an inventory check the moment it starts serving something nobody approved.
It's worth being precise about what a hosted payment element actually guarantees, because this attack lives in the gap.
The guarantee is real, and it's narrow: script in your page can't read across the origin boundary into the provider's iframe. Card details typed into the real element genuinely are out of reach of anything running on your page.
What it doesn't do is guarantee the element is still there. Your page owns the layout, so script in your page can remove the iframe, hide it, shrink it to nothing, or draw its own fields next to it. None of that needs to read across the boundary, so the isolation doesn't stop any of it.
Your customer can't tell. A real hosted field and a good copy look identical, and the padlock, the domain and the certificate are all still correct, because they're yours and the site really is yours. Every check a customer has been taught to make still passes while their details go somewhere else.
Most of the discussion about tag managers stops at "a third party can change your pages". The bigger problem is that the change turns up already authorised.
A CSP that allows a tag manager allows arbitrary script from it, because that's the whole point of a tag manager. Narrow that allowance and you break the thing. So source-based control, which works well against an unfamiliar host, has nothing to offer here: the injection comes from a host you trust on purpose, at a point where script is meant to load, down a channel built to deliver exactly this.
That doesn't make tag managers unusable on a payment page, but it changes what the control has to be. Either the payment page runs no tag manager at all, which is the cleanest answer if you can afford it, or you inventory the tags it does run one by one and check against that inventory, so an extra one shows up even though its source was allowed.
The copy still has to send the data somewhere, so the destination turns up as a connection you never allowed. That's the half that's hard to hide. The fields can be copied convincingly, but the data still has to leave, and you can see it leaving.
Pair it with a script inventory of the payment page. A swapped element means a script running there that is not on your authorised list, and the two signals together identify both halves of the attack — what was added, and where it sent the data.
If your payment page uses a hosted element, it's worth building one specific check: confirm the provider's frame is actually there, and the size you expect, once the page has loaded. A missing or collapsed element on a page that should have one isn't a rendering quirk to look at next week.
These are the entries in our threat intelligence feed for this campaign, shown exactly as we match them. An entry starting *. covers that domain and everything under it, so an attacker cycling through subdomains doesn't get away from it. We only do that when the attacker registered the domain themselves.
The feed changes as we go. We add hosts when they show up and pull them out when the evidence no longer holds, so this is what we're matching today rather than a permanent record.
*.fontuse.com*.sallexyhub.comCorroborated by external research. We classify these on what we saw them doing, not on any claim about who runs them.
We flag these hosts in your own reports automatically, so you hear about it from us instead of from your customers.
← All threat intelligence research · Read this page as Markdown