Summary
- Nilson publishes its worldwide card fraud losses for 2025 in the coming weeks, and 22 Security expects the number to be a shock. We project about $35 billion in global losses for 2025 and about $40 billion for 2026. That pace would reach Nilson’s 2030 projection of $41.06 billion about four years early.
- Verizon’s 2026 Data Breach Investigations Report shows attackers getting in through unpatched software more often than ever while defenders patch less of it. Once attackers are in the server behind an online store, they add a few lines of code to the checkout page that copy every card number typed into it in a method called skimming. PHP2Shell, disclosed in October, lets an outsider run code on a server without logging in to potentially execute a skimming attack.
- The fixes include asking if you really need to host payment processing yourself. PCI DSS now requires you to know every script on your payment page and to detect changes to it. OWASP describes practical ways to do both, from a Content Security Policy to a locked-down tag manager.
The Trend
Nilson publishes its Card Fraud Losses Worldwide figures in the coming weeks, and 22 Security believes we are in for a shock. The trade publication reports each year’s losses the following December or January, so its numbers for 2025 will be available soon.
22 Security projects that global losses for 2025 will come in at about $35 billion, and that 2026 is on track for about $40 billion. Our analysis is based on Consumer Financial Protection Bureau (CFPB) complaints about unauthorized card charges, which are available a year ahead of Nilson’s figures and have tracked the US component closely since 2019. Google searches for “fraudulent charge” have risen alongside them since 2022. If fraud outside the US stays near the $19 to $20 billion it has held since 2021, and US losses rise with complaints as they did from 2019 to 2024, the 2025 total could exceed $35 billion.
That is well ahead of the pace in Nilson’s last report, which projected $41.06 billion by 2030. We will have to wait until December 2027 to see what Nilson says about 2026, but if the current trend holds, 2026 lands near $40 billion, close to that 2030 figure four years early.
How this could be happening
Verizon’s 2026 Data Breach Investigations Report shows attackers getting in through unpatched software more often than at any point in its records. Exploited vulnerabilities were the first step in 31% of breaches, up from about 20% last year and about 6% in 2022. Stolen logins still appear somewhere in 39% of breaches. Servers were involved in 84% of breaches, and web applications were the single most common asset hit at 54%. Meanwhile defenders are falling behind. Across more than 13,000 organizations, only 26% of known-exploited vulnerabilities were fully patched, down from 38% a year earlier. The median time to finish patching was 43 days. Verizon’s recommended fixes are unglamorous: multi-factor login on anything exposed to the internet, an inventory of accounts with dormant ones disabled, and automated patching for operating systems and applications.
Card skimming is one of the things attackers do once they are in. After gaining access to the server behind an online store, through an unpatched flaw or a stolen login, they add a few lines of code to the checkout page. The page keeps working and the order goes through, but a copy of every card number typed into it is sent to the attacker.
A recent example shows how wide that door can be. In October, researchers disclosed PHP2Shell, a pair of flaws in PHP, the language behind roughly 70% of websites. The flaws let an outsider run their own code on a server without logging in. CISA issued an alert and has since added both flaws to its Known Exploited Vulnerabilities catalog. Because the problem is in PHP itself, a store running fully updated software is still exposed until PHP is patched. No one has publicly reported a skimmer planted this way yet, but running code on the server is exactly the access a skimmer needs.
What to do about it
Start by asking if you need to handle card numbers on your own site at all. Risk avoidance is a real strategy. Most payment processors offer a hosted payment page or an embedded payment form that they serve and secure. The page that sends customers to the processor is still yours to secure, but shifting to a hosted page means the card number is typed into their page, not yours. This is usually the cheapest fix available to small or mid-sized companies.
Since March 31, 2025, the PCI Data Security Standard has carried two rules written specifically to stop skimming.
- Know every script on your payment page (Requirement 6.4.3). Keep a list of every script that loads at checkout, with a written reason each one is needed, and a way to confirm each is authorized. Record a fingerprint (a hash) of each approved script, and have the browser or a scheduled check confirm it has not changed.
- Detect changes to your payment page (Requirement 11.6.1). Run a check, at least weekly, that alerts you when the scripts or security headers on the page your customers actually receive have changed.
OWASP, the nonprofit that publishes free security guidance for developers, describes practical ways to meet both:
- Set a Content Security Policy. This is an instruction your site sends to the browser saying which scripts may run and where the page may send data. A skimmer that is not on the list is blocked from running, or blocked from sending card numbers out. Start in report-only mode to see what would break before enforcing it.
- Fingerprint third-party scripts. Subresource Integrity lets the browser refuse a script whose contents have changed since you approved it.
- Host scripts yourself where you can. A copy on your own server cannot be altered by a break-in at the vendor.
- Isolate what you cannot host. Third-party code loaded in a sandboxed frame cannot read the checkout form.
- Lock down your tag manager. Restrict custom code tags and require two-factor login, since a tag manager is a way to add scripts without touching the site.
None of this replaces fixing the server. OWASP is explicit that a Content Security Policy is a second layer of protection, and a skimmer planted by someone who controls the server can change the policy too. Patch the platform and what it runs on, PHP included, and require multi-factor login for every admin account.
How 22 Security can help
22 Security can help with all of the above. We can review your checkout and move it to a payment page your processor hosts, build the script inventory and weekly change detection behind Requirements 6.4.3 and 11.6.1, and roll out a Content Security Policy in report-only mode before enforcing it. An external compliance assessment checks what anyone on the internet can see about your store, including end-of-life software and missing security headers, and maps what it finds to PCI DSS. A penetration test shows whether an outsider can reach the server behind your store through unpatched software or a stolen login. Book a call and we will scope it out.