PHP's security team shipped emergency fixes on October 21, 2026, for two critical flaws that let an attacker run their own code on a web server without logging in. If you run PHP, update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35; the PHP security advisory says updating is the only complete fix.
What happened
The flaws, CVE-2026-109618 and CVE-2026-109619, are known together as PHP2Shell. They sit in PHP itself, the programming language behind WordPress, Drupal, Joomla and 75% to 80% of all websites, according to BleepingComputer.
Both are remote code execution (RCE) flaws, meaning an outsider can send instructions over the internet and get your server to carry them out. They are also unauthenticated: the attacker doesn't need a username or password first.
Researchers at Calif, Wiz and OpenAI found and reported the flaws, which affect nearly every PHP version back to 5.4, The Hacker News reports. The underlying code had been in PHP for more than a decade.
How serious it is
PHP's security team rates both flaws 9.2 out of 10 on CVSS v4.0, the standard scale for scoring vulnerability severity. A score of 10.0 circulated after details leaked a day early, but that number didn't come from PHP and was wrong.
Your own application code doesn't protect you here. Because the bug lives in the PHP engine, The Hacker News reports that even a bare "Hello World" page on an unpatched version can be attacked.
Updating WordPress, Drupal or another application won't fix it either. The fix has to come from the server's PHP package, your host or your container image.
The flaws can also leak memory. An attacker can read data the server is holding for other users' requests, which may include passwords, login tokens, API keys and certificates, according to The Hacker News.
Is anyone exploiting it
As of October 21, 2026, at 4:30 p.m. PT, there are exploit attempts, with no confirmed breach.
- Cloudflare reported early attack attempts on October 21, before the patch was out, BleepingComputer reports.
- Later that day, security researchers reported attempts against both flaws, and no source had confirmed a successful break-in, per The Hacker News.
- CISA said it had not observed exploitation when it published its alert.
That picture can change fast. Technical details are now public and early proof-of-concept exploit code is circulating, CERT-EU warns.
Why it matters for healthcare
PHP often runs out of sight: CISA points out that it is frequently built into other software, so you may not know where it's running.
For a healthcare organization, places to check include the WordPress site where patients request appointments or fill out intake forms, a patient portal or plugin added to that site, and vendor appliances with a web admin page. Any of them may touch patient information or hold credentials for other systems.
The memory leak is the quieter risk, because a stolen password or API key can open systems far beyond the web server, including email.
What to do now
- Find every PHP install. CISA recommends an inventory of every system running PHP, including vendor products that bundle it. If someone else runs the server, ask your hosting provider and vendors whether they have patched.
- Patch internet-facing systems first. Then restart Apache, PHP-FPM and any other PHP workers, The Hacker News advises.
- Confirm the fix in the package changelog. Linux distributions got the fix in advance, so a patched package can show an older version number. Look for the two CVE numbers in its changelog instead.
- Plan for old versions. PHP 8.1 and older no longer get official releases, though PHP published source fixes for 7.4 through 8.1. CISA says systems that can't be updated should go offline until they are.
- Treat workarounds as stopgaps. PHP lists configuration changes that cut off some attack paths, and CISA says a web application firewall (a filter that blocks known attack traffic) may help. Neither makes a server safe.
- Check for signs of a past break-in. CISA recommends watching for PHP processes that launch shells or download tools. If you find signs of a break-in, rotate the passwords and API keys stored on that server.
If a web form or app on that server sends patient email through an API, its key belongs on the rotation list.
Go deeper: HIPAA compliant email
