If your business takes payments online, there’s a good chance PHP is running somewhere in that chain. This week, the PHP Foundation released emergency fixes for two critical flaws, nicknamed PHP2Shell, that can let an attacker take over a web server without logging in.
We want to be straight with you about what this means for payments, where the real risk sits, and the handful of things you should do this week. No panic, just what you need to know.
What happened
PHP is the programming language behind a huge share of the web, including WordPress, WooCommerce, Magento and countless custom portals. On October 21, 2026, the PHP team shipped an out-of-band security release for two flaws, CVE-2026-109618 and CVE-2026-109619. Both are rated critical (9.2 out of 10), and either one can let an unauthenticated attacker run their own code on a server that handles PHP requests.
In plain terms: under the right conditions, PHP can be tricked into using memory it shouldn’t trust. An attacker who gets that right can make the server do whatever they want.
Three things make this one worth your attention:
- It’s broad. Reported affected versions run from PHP 5.4 through 8.5. Old and new installs alike are in scope.
- Details leaked early. Technical information got out before the official release, and proof-of-concept exploit code has been circulating publicly.
- Attackers are already probing. Amazon’s threat intelligence team reported exploitation attempts as early as October 17, four days before the fix was public. Reports since then vary on how widespread actual attacks are, but we’d treat this as an ongoing security issue.
Where this touches payments
The biggest risk isn’t the card networks or the terminal on your counter. It’s the web-facing software around them: your website, your checkout page, and the portals you and your partners log into.
| Layer | Exposure | Why it matters |
| Your website and checkout | Highest | Many ecommerce platforms and plugins run on PHP. A compromised site can have its checkout page altered to skim card numbers or redirect customers. |
| Gateways and hosted payment pages | Moderate | Gateways themselves vary, but plugins, shopping cart connectors and admin dashboards are often PHP-based. A hacked site can still swap out the script that loads a hosted payment form. |
| Merchant, ISO and partner portals | Moderate | Reporting portals, CRMs and boarding tools across the industry are frequently built on PHP. A breach there exposes merchant data and account access, not just card numbers. |
| Processors | Lower, but not zero | Core authorization systems generally aren’t PHP, but the web portals and back-office tools around them can be. |
| Card terminals | Low | Countertop and handheld terminals don’t typically run PHP. The exception is a terminal managed through a web dashboard that is itself exposed. |
| Card networks | Indirect | The networks themselves aren’t the target. The impact shows up downstream as compromised cards, fraud, chargebacks and compliance reviews for affected merchants. |
One important point if you use a hosted payment page or tokenization: that keeps card data off your servers, which is exactly what you want. But it doesn’t make your website immune. If an attacker controls the page that loads your payment form, they can tamper with it. Patching your site still matters.
What to do this week
You don’t need to be technical to get this handled. You need to ask the right people the right questions.
- Find out where PHP lives in your business. Your website, online store, booking or invoicing tools, and any customer portal are the places to start. If you’re not sure, ask whoever built or hosts your site.
- Ask your web host and software vendors directly. “Are you affected by PHP2Shell (CVE-2026-109618 and CVE-2026-109619), and have you patched?” Get a yes, a no, or a date. If you’re on a managed platform, they may have already handled it.
- Update, don’t just plan to update. PHP issued fixes for its supported 8.2 through 8.5 branches. If you’re running an older version, talk to your host about a vendor-patched build or an upgrade. Check php.net or your Linux distribution’s security notice for the exact version that fixes your branch.
- Use the temporary mitigations if you can’t patch today. PHP published interim steps, such as turning off session upload progress, that shrink the attack surface. They help, but they’re a stopgap, not a fix.
- Update your plugins and themes too. While you’re in there, bring WordPress, WooCommerce, Magento or whatever you run up to the latest version.
- Keep card data off your servers. If your site still collects card numbers directly, this is a good moment to move to a hosted payment page or tokenized checkout. It shrinks your risk and your PCI scope. PayTech Trust can help you with this.
- Tighten access. Turn on multi-factor authentication for your website admin, hosting account and payment portals, and remove logins for anyone who no longer needs them.
For your IT person or developer: confirm the patch was installed by checking the package changelog for both CVE numbers, not just the version string. Some Linux distributions backport fixes without changing the headline version.
Warning signs to watch for
Patching closes the door. It doesn’t tell you whether someone already walked through it. Over the next few weeks, keep an eye out for:
- Checkout changes you didn’t make. New fields, a payment form that looks slightly off, or customers being sent to an unfamiliar page.
- Card testing. A burst of small transactions, a spike in declines, or orders with mismatched names and billing details.
- New admin accounts or files on your website that nobody on your team created.
- Customer complaints about fraud on cards they recently used with you.
- Unusual activity in your portals, such as logins from new locations, changed payout or banking details, or API keys you don’t recognize.
If you see any of these, don’t wait. Contact us and your web host right away. If there’s a chance your site was compromised, we can help rotate your gateway API keys and passwords as soon as it’s clean.
What we’re doing, and how we can help
You don’t have to sort through this alone. If you’re not sure whether your website or checkout is exposed, or you want to move to a hosted payment page or tokenized checkout to keep card data off your servers, reach out to your PayTech Trust representative or contact our team. We’ll help you figure out where you stand and what to do next.
Security issues like this one will keep coming. The merchants who come through them best aren’t the ones with the biggest IT budgets. They’re the ones who know what they’re running, keep it current, and keep sensitive data off systems that don’t need it.
Further reading
