One request. No login. Your PHP server. Patch today.
On October 21, 2026, PHP fixed two critical flaws in its core engine. Together they let an attacker run code on a PHP server with a single unauthenticated request. WordPress, Drupal, Joomla, Magento and most PHP apps are exposed until the server itself is updated.
PHP2Shell at a glance
- 9.2 CVSS v4.0 severity for both CVEs
- 0 logins or app bugs needed to attack
- 5.4+ affected PHP releases go back to 2012
- ~70% of websites run on PHP
Sources: PHP security advisory and Wiz Research, Oct 21, 2026.
Weeks of quiet work. Then one day to patch.
Researchers at Calif and Wiz found the bugs separately and reported them to the PHP security team. The fix and the public details landed the same day. CVE-2026-109618 and CVE-2026-109619 are both rated 9.2.
Aug 2026 — Found
Calif and Wiz Research independently find memory-safety bugs in how PHP handles fatal errors. Wiz confirms unauthenticated RCE on Drupal and WordPress within two days.
Aug 24, 2026 — Reported
Wiz reports its findings to the PHP security team, joining the coordinated disclosure Calif started on August 11.
Sep 21, 2026 — Fix in progress
PHP acknowledges the reports and begins a coordinated fix with Linux distributions and LTS vendors.
Oct 20, 2026 — Advance notice
PHP announces a critical release for the next day. Details start to leak.
Oct 21, 07:43 UTC — Attacks start
Cloudflare reports attack traffic against its customers, hours before the patch is public.
Oct 21, 14:00 UTC — Patched and public
PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Wiz, Calif and others publish their research.
Exploitation status on Oct 21: Cloudflare reported attack traffic. The PHP team said it had not identified functional exploits at release. CERT-EU says proofs of concept have begun to circulate. Neither CVE is in CISA's KEV catalog yet. Treat every internet-facing PHP server as urgent.
The bug is in PHP, not in your code.
You can run a clean, fully updated WordPress or Laravel app and still be exposed. The attack happens while PHP is setting up the request, before your application runs.
01 Send one request
An attacker sends a crafted file-upload request to any PHP page. No login, plugin or app bug needed.
Unpatched PHP runtime
02 Force a fatal error
The request pushes PHP past its memory limit while it is still building internal request data.
Out-of-memory handling
03 Leave stale state
PHP frees memory but keeps pointers to it. The next request on the same worker reuses that stale state.
Use-after-free
04 Leak memory
One path returns worker memory in a session cookie: passwords, tokens, API keys and TLS keys from other requests.
Secrets exposed
05 Run code
Chained, the bugs gave researchers unauthenticated code execution on WordPress, Drupal, Joomla, Magento and more.
Full server takeover
If it runs PHP and it is not on these versions, yes.
At risk: every PHP installation serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php as the highest risk.
| PHP branch | Fixed in | Notes |
|---|---|---|
| 8.5 | 8.5.12 | Also set fatal_error_backtraces=0 if you cannot patch yet. |
| 8.4 | 8.4.27 | |
| 8.3 | 8.3.36 | |
| 8.2 | 8.2.35 | Branch ends support on Dec 31, 2026. Plan the upgrade. |
| 8.1 and older | No official fix | PHP published minimal source backports for 7.4, 8.0 and 8.1. Ask your vendor or upgrade. |
Check what the web server runs, not the CLI.
The php -v command shows the command-line build. Your site may run a different PHP-FPM version. Check the FPM binary, or a version check served by the web server, on every host.
Updating WordPress, plugins or your framework does not fix this. Maintenance mode does not help either, because PHP parses the request before your app checks the flag.
Patch, restart, then verify.
In this order. Internet-facing servers first.
Patch every PHP runtime
Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Include versions your sites do not use, containers, appliances and control panels. On managed hosting, ask your host for the version and patch date.
Restart everything
PHP-FPM, Apache and long-running workers such as queues keep the old runtime in memory until they restart.
Verify what is running
Confirm the version served by the web server on each host, not just the CLI.
Cannot patch today? Reduce exposure
PHP's interim steps: memory_limit=-1 with a low post_max_size, and session.upload_progress.enabled=0 in php.ini or the FPM pool, then restart workers. Turn on your CDN or WAF vendor's PHP2Shell rule. This lowers risk. It does not make you safe.
Look for signs of compromise
PHP processes spawning shells, curl or wget. New files in the web root, new cron jobs or accounts. Repeated 500 errors, memory-limit errors after upload requests, oversized PHPSESSID cookies.
Rotate secrets on exposed servers
The memory leak can expose passwords, API keys, session tokens and TLS private keys. If a server was reachable before you patched, rotate them.
Only an update is a complete solution.PHP security team, Oct 21, 2026
We find every PHP server, patch it, and check nobody got in first.
Our engineers work with your team, with your permission and inside an agreed scope. You get a list of every exposed system, what was patched or mitigated, and a clear answer on compromise.
PHP inventory
Every server, container, appliance and hosted site running PHP, including the ones nobody remembers.
Version and restart check
The version the web server actually runs, compared with the fixed releases.
Patch or mitigate
We patch with your team, or apply PHP's interim mitigations and edge rules where patching has to wait.
Compromise check
Web roots, cron jobs, accounts and process history reviewed for webshells and persistence.
Secret rotation plan
Which passwords, API keys, tokens and certificates to rotate, and in what order.
End-of-life plan
A path off PHP 8.1 and older, and off 8.2 before support ends on Dec 31, 2026.
How it starts
30-minute call
A security engineer reviews your PHP footprint and hosting.
Scope
We agree on systems, access and timing.
Patch and report
Patched or mitigated systems, compromise findings and next steps.
Five questions. Be honest.
Answer for your company today. Nothing is sent anywhere.
- We know every server, container and hosted site that runs PHP, including WordPress sites and appliances.
- Every one of them runs PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later.
- We restarted PHP-FPM, Apache and long-running PHP workers after updating.
- None of our sites runs PHP 8.1 or older.
- We would notice a PHP process spawning a shell, or a new file in a web root, within hours.
0 of 5 answered.
Common questions.
Is WordPress, Drupal, Joomla or Magento affected?
Yes, when it runs on an unpatched PHP. The flaw is in PHP itself, so the CMS version does not matter. Researchers confirmed unauthenticated code execution on all four.
Will updating WordPress or our plugins fix it?
No. The PHP runtime on the server must be updated and restarted. On managed hosting, ask your host to confirm the PHP version and when it was patched.
Is it being exploited?
Cloudflare reported attack traffic on October 21, hours before the patch was public. CERT-EU says proofs of concept are circulating. Treat internet-facing PHP servers as a priority.
We run PHP 7.4 or 8.1. What now?
There is no official release. PHP published minimal source backports for 7.4, 8.0 and 8.1, and some Linux vendors ship backported packages. The real fix is a supported version. Until then, apply the interim mitigations and limit exposure.
Does our WAF or CDN protect us?
Partly. Cloudflare, AWS, Google, Microsoft, Akamai, Fastly and others published guidance or mitigations. They reduce risk while you patch. The update is the only complete fix.
Do you work in Mexico and the US?
Yes. iNBest has engineers in Mexico and the United States and works in Spanish and English.
Sources
- Wiz Research: PHP2Shell, critical RCE in PHP (Oct 21, 2026)
- PHP: Security advisory, critical remote code execution vulnerabilities (Oct 21, 2026)
- Sansec: PHP2Shell (CVE-2026-109618, CVE-2026-109619)
- Laravel Forge: PHP security advisory, patching steps
- Rescana: fixed versions, mitigations and exploitation status
- SOCRadar: PHP2Shell exposure and detection
Patch today. Then make sure nobody got in first.
Book 30 minutes with a security engineer. We will help you find every PHP server, patch or mitigate it, and check for signs of compromise.
Send us your context.
A security engineer will reply with a practical next step.