Compromised plugins and scripts: the way into Pix checkout fraud

In legitimate online stores, the Pix scam rarely starts with Pix. It starts with a plugin, a theme or a third-party script that runs on the payment page and falls under criminal control. Because everything the page loads has the same power over what the customer sees, a single compromised component is enough to swap the QR code, alter the copied payment code or capture card data. Reducing exposure means fewer components on the checkout, knowing exactly which ones are there, and noticing when something changes.

Why a third-party component has so much power

The payment page a customer sees is assembled in their browser from many pieces: the platform code, the theme, shipping, coupon and review plugins, the support chat, analytics and advertising tools, libraries fetched from outside servers. The browser does not distinguish what belongs to the store from what belongs to a third party. Any of those pieces can read and change any part of the page, including the Pix QR code, the copy button and the card fields.

That creates a long chain of trust. The store trusts the plugin vendor, who trusts their own publishing account, which depends on passwords, servers and domains the store never sees. One weak link is enough.

Three documented ways in

The domain that changed hands. In June 2024, Sansec warned that polyfill.io, a service used by more than 100,000 sites to load a compatibility library, had been bought by another company months earlier and had started injecting malicious code into the sites that used it. Those sites did not change a line: the script they already loaded changed at the source.

The tampered update. That same month, according to BleepingComputer, the Wordfence team found five plugins in the official WordPress directory that had received malicious code, together installed on more than 35,000 sites. The tampered versions created administrator accounts for the attackers and sent the details to an outside server. Stores that kept up to date got the problem.

The service embedded in the payment page. The ICO, the UK data protection authority, fined Ticketmaster UK in 2020 for failing to put appropriate measures in place to prevent an attack on a chatbot installed on its online payment page. According to the regulator's annual report, the breach affected 9.4 million customers across Europe.

The pattern is still active. In January 2026, Malwarebytes covered Silent Push research on a campaign active since early 2022 that inserted code into checkout pages to capture card data from six card networks, using a script able to remove itself from the page to hinder investigation.

From card theft to Pix swaps

The cases above involve cards, redirects or admin accounts, but the access behind each of them is the same: a script with power over the page. Whoever can read a typed card number can, with the same access, rewrite the Pix QR code and the copy-and-paste text.

With Pix, the outcome is especially harsh. The payment is instant, valid and for the right amount, just to someone else's account. There is no later stage where anyone reviews the transaction. The store is not paid, the customer thinks they paid, and recovery depends on a dispute, proof of fraud and funds left in the receiving account. That is why, for instant payments, payment page security stops being only a compliance topic and becomes a revenue topic.

What reduces exposure

In March 2025 the PCI Security Standards Council published guidance on PCI DSS requirements 6.4.3 and 11.6.1, which deal precisely with payment page scripts and unauthorised changes to the page. The logic applies to any payment method:

• An inventory with reasons. List every script loaded on the checkout, who supplies it and why it needs to be there. Anything without a reason goes.
• A lean checkout. Chat, pop-ups, review widgets and remarketing tools rarely need to be on the page where payment happens.
• Controlled sources. Avoid loading essential libraries from domains you do not control, and pin the versions you use. The polyfill.io case shows the risk of depending on an outside address.
• Careful updates. Apply security fixes, remove idle plugins and themes, and never use pirated versions, which arrive with code of unknown origin.
• Protected accounts. Require two-step verification on the store admin, use unique passwords and review the administrator list regularly.
• Watch what reaches the customer. Monitor the page as it is delivered to the browser, not just the files on the server, with alerts for any new or changed script.
• A response plan. Decide who switches Pix off, removes the suspicious component and notifies customers if something is detected.

See how this check works on the Pix protection and card protection pages.

No inventory stops a trusted vendor from being compromised tomorrow. Proteside works at the last possible point: in the shopper's browser, it checks that the QR code, the copy-and-paste code and the card form are exactly what the store issued, blocks any swap before payment and produces evidence for PCI DSS. You can try it free for 14 days.