If your website, online store, or internal tool runs on PHP, here is the short version: the fix is a PHP update, and no setting or plugin fully replaces it. On October 21, 2026, the PHP project released versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to close two PHP vulnerabilities, nicknamed PHP2Shell, that can let an attacker run code on a web server without logging in (PHP.net advisory).
The pressure has only grown since then. The federal Cybersecurity and Infrastructure Security Agency (CISA) urged organizations to patch immediately, and Amazon's threat intelligence team now reports the flaws are being broadly exploited. Below is what changed after the patch shipped, which stopgaps actually help, and how to figure out who on your team has to act.
What PHP2Shell is, in plain terms
PHP is the server-side language behind WordPress, Drupal, Joomla, Magento, and countless custom websites. PHP2Shell is not a bug in any of those platforms. It sits in the PHP engine itself, which is why a carefully maintained WordPress site can still be exposed.
The two PHP vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619, and the PHP security team rated both 9.2 on the CVSS v4.0 severity scale (PHP.net).
- CVE-2026-109618 (memory exhaustion): If PHP runs out of memory while setting up a web request, it can stop partway through. Its cleanup routine then treats that half-built data as valid, which can corrupt memory.
- CVE-2026-109619 (stale state): Data belonging to one request can outlive the memory behind it. A later request handled by the same worker process may use that leftover data before it is reset.
Two terms matter here. "Remote code execution" means an outsider can make your server run their commands. "Unauthenticated" means they don't need an account to try. According to PHP's advisory, every installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed, with the highest risk on mod_php.
These are not new mistakes. Researchers at Sansec trace the vulnerable code back to PHP 5.4.0, released in 2012.
Why warnings about the PHP vulnerabilities got louder after the patch
The disclosure did not go as planned. Here is the confirmed sequence:
- October 17: Amazon's honeypot network recorded a PHP2Shell exploitation attempt, four days before public disclosure (AWS Security Blog). Amazon says it is unclear how the attacker got the details early.
- October 20: Details leaked online. PHP posted an advance notice and reserved the right to release early.
- October 21: PHP shipped the fixes. CISA called for immediate updates the same day.
- After release: Amazon reported that new proof-of-concept exploits appeared within hours and that PHP2Shell is now being broadly exploited in the wild.
What remains uncertain matters too. Amazon says it is unclear whether some of the early attempts would have worked against real systems, and no public tally of compromised sites exists yet. Still, "attempts are widespread" is enough reason to treat these PHP vulnerabilities as an emergency rather than routine maintenance.
The problem also reaches beyond websites. Many commercial products bundle PHP inside them. Help Net Security reports that Palo Alto Networks confirmed its PAN-OS and Panorama products are affected, while the UK's National Cyber Security Centre advised organizations to consider taking offline any system that can't be fixed quickly.
Who has to act? A quick decision guide
The right next step depends on how your PHP is installed. Use this table to find the person responsible.
| How your site runs | Who installs the fix | What to do today |
|---|---|---|
| Managed WordPress or shared hosting | Your host | Check the host's status page or ask support which patched PHP build serves your site |
| VPS or dedicated server with a control panel | You or your managed-support plan | Update PHP packages through the OS or panel, then restart PHP |
| Docker or other containers | You | Rebuild images on a patched base image and redeploy every service |
| PHP 8.1 or older, or PHP built from source | You | Upgrade, get a vendor backport, or use the PHP team's minimal source backports for 7.4, 8.0, and 8.1 |
| Firewalls, appliances, or software that bundles PHP | The product vendor | Watch the vendor's security advisories and apply its update |
Coverage varies widely between providers. One example: InMotion Hosting's status table shows patched packages for every version on its shared plans, but none for servers still on CentOS 7. Older platforms are where gaps hide, so ask your provider directly.
Stopgap settings: what they block and what they cost
If you truly cannot update today, PHP's advisory lists settings that reduce exposure to these PHP vulnerabilities. The project is blunt that they do not make a server safe. Treat them as a bridge measured in hours, not weeks.
| Setting | What it targets | The trade-off |
|---|---|---|
memory_limit=-1, set at the server level |
The memory-exhaustion path (CVE-2026-109618) | One request can consume all available memory, so pair it with container limits |
A lower post_max_size (8M, or 32M if uploads are needed) |
Oversized requests that trigger memory failures | Large uploads may fail |
session.upload_progress.enabled=0 |
The confirmed session path for CVE-2026-109619 | Upload progress bars stop working |
fatal_error_backtraces=0 (PHP 8.5 only) |
The confirmed backtrace path | Fatal errors lose diagnostic detail |
Two details trip people up. These values must be set in php.ini, the FPM pool, or the web server configuration, not through ini_set() or a .user.ini file. And every PHP worker must be restarted before a change takes effect.
Web application firewall rules from companies such as Cloudflare add another layer, but they are also stopgaps. Attackers actively tweak payloads to slip past filters.
A worked example (hypothetical)
Imagine a small Ohio bakery that sells gift boxes through a WooCommerce store on shared hosting. The owner checks the host's status page and sees that PHP 8.3 was patched on October 21. Done? Not quite.
A closer look turns up a forgotten staging copy of the store on a separate legacy plan running PHP 7.4. That copy is just as reachable from the internet as the live shop. The practical fix is to ask the host about patched packages for that plan, or simply delete the staging site. The lesson: count every PHP installation you own, not just the one customers see.
Patched doesn't mean clean
Because exploitation attempts against these PHP vulnerabilities predate disclosure, Amazon recommends starting any investigation from at least October 17, not from the patch date. Its suggested checks include:
- Reviewing web server logs for POST requests containing the string
PHP_SESSION_UPLOAD_PROGRESS. - Looking for unexpected processes or file changes on web servers.
- Investigating, rather than automatically blocking, the IP addresses Amazon published, since many belong to shared anonymization services.
Sansec also notes that CVE-2026-109618 can leak server memory on its own. If you find signs of probing, consider rotating passwords, API keys, and other secrets the server handles. If anything looks wrong, bring in a qualified incident-response professional.
Common mistakes to avoid
- Checking the wrong PHP. Running
php -vshows the command-line version, which may differ from the build your web server actually uses. Confirm the version serving web requests. - Updating plugins instead of PHP. WordPress and plugin updates do not touch PHP vulnerabilities in the engine itself.
- Judging by version number alone. Linux distributions often backport fixes into older-looking version numbers. Check your vendor's advisory, such as Red Hat's CVE page, for the exact package.
- Hiding PHP version headers. Concealing your version from scanners does nothing to fix the underlying PHP vulnerabilities.
Quick answers
Is PHP 8.2 a safe place to stay?
It's patched in 8.2.35, but PHP says the 8.2 branch reaches end of life on December 31, 2026. After that, it receives no further security fixes, so plan an upgrade now.
Can I scan my own servers?
Yes. Searchlight Cyber released an open-source scanner, php2shell-scanner, that tests whether a host is exposed. Only scan systems you own or are authorized to test.
Do site visitors need to do anything?
Not directly. Our earlier explainer, PHP Security Vulnerability 2026: Why Websites Scrambled, covers what an outage does and doesn't mean for customers.
The takeaway
Most PHP vulnerabilities are fixed quietly in routine releases. PHP2Shell is different because it hits the engine under millions of sites and needs no login to attack. Your next step is concrete: identify every PHP installation you're responsible for, confirm each is running 8.5.12, 8.4.27, 8.3.36, 8.2.35, or a vendor-patched build, and check your logs back to October 17. If you rely on a host or vendor, get that confirmation in writing today.
