PHP2Shell Is Being Exploited: Patch, Then Check Your Logs

By Felipe Isaza, FUNCSHUN | Companion to CyberScope Weekly Vol 70

If you haven't updated PHP yet, do it today. Then keep reading, because patching isn't the whole job this time.

What happened

On Oct 21, 2026, the PHP project released 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two critical flaws, CVE-2026-109618 and CVE-2026-109619. Either one can let an attacker run code on a web server without logging in. PHP says any installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. mod_php is the highest risk.

The attackers didn't wait for the patch. Amazon's honeypot network saw the first attempt on Oct 17, four days before the fix. Since then, security firms have logged millions of attempts. Most of those failed.

That changed over the weekend. On Oct 24, attackers launched 35 shells on honeypots run by Perplexity researcher Adel Karimi. He called it confirmed remote code execution. Expel's Marcus Hutchins agreed. Karimi was careful about what it proves. His setup was deliberately favorable: Apache mod_php with a single worker, running an unpatched PHP 8.4.26. He says it doesn't measure how reliable the attack is on other setups. No one saw the attackers download anything afterward.

Here is where official sources stand as I write this on Oct 26. CISA's alert says it hasn't observed successful exploitation. Its Known Exploited Vulnerabilities catalog doesn't list either CVE yet. Palo Alto and Cisco both say they aren't aware of malicious use against their products. Treat that as "not confirmed yet," not "safe." Researchers are watching real attackers use these flaws, and patch gaps close fast.

A second PHP flaw has no patch yet

On Oct 23, PHP published an advisory for a separate flaw, CVE-2026-115560. There is no fix. It arrives with the next regular bugfix release, and the full advisory comes then.

PHP calls it an unlikely route to code execution, because three things have to line up. The application sets session.serialize_handler to php_binary or php_serialize, then switches it to php at runtime with ini_set() before session_start(), and session upload progress is still turned on. Most sites won't match that. You don't need to figure out whether yours does. Turn the feature off:

session.upload_progress.enabled=0

PHP's advice is to set it until the next release. If you already set it on Oct 21 as a stopgap for CVE-2026-109619, keep it.

It's not just your website

PHP sits inside products you don't think of as PHP. Vendors are still working out what's affected.

• Palo Alto Networks: PAN-OS and Panorama are affected through the management web interface. Fixes are out for three releases (10.2.18-h13, 11.1.16-h4 and 11.2.10-h16). More are due Oct 27 to 30. Palo Alto rates it 8.7 and recommends restricting access to the management interface.
• Cisco: Ultra-Reliable Wireless Backhaul, Expressway and Duo Access Gateway are affected. Duo Access Gateway is fixed in 3.2.0. Expressway's fix is 15.5.21, with a date still to come, and workarounds exist for it and for Backhaul. Eleven more products are still under investigation.
• Fortinet: four products are under review. FortiOS isn't affected.

That's from Help Net Security's running list, updated Oct 26, and the vendors' own advisories are the source of truth. The same rule applies to everything on that list: keep management interfaces off the internet.

Why this matters if you handle CUI

CMMC Phase II is suspended. Your obligations aren't. DoD's CIO page says Phase II, originally due Nov 10, remains suspended, and nothing has changed since Jul 13. Class Deviation 2026-O0025 Revision 3 keeps DFARS 252.204-7012 in place. If your contracts carry that clause, three things still apply:

• You must implement NIST SP 800-171 on systems that process, store or transmit covered defense information.
• You must report cyber incidents to DoD within 72 hours of discovery.
• You must preserve images of affected systems, plus relevant monitoring and packet capture data, for at least 90 days after you submit the report.

A web server that holds or reaches CUI is squarely in scope. In NIST SP 800-171 Rev 2, this week touches 3.4.1 (system inventory), 3.14.1 (finding and fixing flaws), 3.3.1 (audit logs), 3.14.6 (monitoring) and 3.6.1 (incident handling). An assessor or prime will ask the same question: show me the inventory, the patch date, and what you checked afterward.

What to do today

1. Find every system that runs PHP. Start with your own web servers. Then add WordPress sites, customer portals, vendor-hosted apps and appliances. Ask your IT team and each vendor directly, and write down the answers.
2. Update the internet-facing ones first. Use 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your Linux vendor's patched package. On Windows, PHP published rebuilt packages on Oct 26 (8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1), so take those. PHP 8.2 reaches end of life on Dec 31, 2026, so plan the move to a newer branch.
3. On PHP 8.1 or older? The PHP project no longer updates these. Get a backported fix from your distribution or support vendor, or upgrade. CISA's advice is to take those systems offline until they're fixed.
4. Can't patch today? PHP says these steps reduce exposure but don't make an installation safe. Set session.upload_progress.enabled=0 and a low post_max_size, and set memory_limit=-1 in a way applications can't override. Ask your developer or hosting company to apply them, and put a firm patch date on it.
5. Turn off session upload progress either way. Set session.upload_progress.enabled=0 in php.ini, your FPM pool or the server configuration. Don't use ini_set() or .user.ini, which can apply too late. Restart every PHP worker afterward.
6. Check your logs back to Oct 17. Amazon advises looking for POST requests that contain PHP_SESSION_UPLOAD_PROGRESS, and for web servers that suddenly run unexpected processes or change files. CISA says to watch for PHP workers launching shells or downloading tools, and it published a Sigma detection rule. Searchlight Cyber also released an open-source scanner. Use it only on systems you own.
7. Lock down management interfaces. Check your Palo Alto and Cisco gear, and any other device with a web admin page. Restrict it to an internal admin network, then watch for the vendor patches due this week.
8. If anything looks wrong, preserve first. Take images of the affected systems and keep the logs before you clean up or rebuild. That evidence is what the 90-day requirement is about.
9. Confirm your incident plan. Name who decides this is a reportable incident, who files the DoD report, and who holds the medium assurance certificate DoD requires for DIBNet.
10. Save your evidence. Keep the inventory, patch dates, config screenshots and what you searched for in the logs, and file it with your SSP.

The bottom line

A patch tells you the hole is closed. It doesn't tell you whether someone walked through it first. With PHP2Shell, attempts started four days before the fix, and now they're working on real servers. Patch today, close the stopgap for the second flaw, and spend an hour on the logs. If your team can't tell you which systems run PHP, start there.

Not sure what's running on your web servers, or whether you could meet the 72-hour clock? Book a Cyber Risk Strategy Call: [https://start.funcshun.com]

Felipe Isaza is the founder of FUNCSHUN Cybersecurity, which helps defense contractors meet CMMC and NIST SP 800-171 requirements.

---

Sources

• PHP, "Security advisory: Critical remote code execution vulnerabilities, update now" (Oct 21, 2026): https://www.php.net/archive/2026.php#2026-10-21-5
• PHP, "Informational advisory: Session upload progress" (CVE-2026-115560) (Oct 23, 2026): https://www.php.net/archive/2026.php#2026-10-23-1
• PHP, "Updated PHP Windows builds for Brotli security fix" (Oct 26, 2026): https://www.php.net/archive/2026.php#2026-10-26-1
• CISA, "Critical Vulnerabilities in PHP Require Immediate Patching" (Oct 21, 2026, updated Oct 23): https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
• AWS Security Blog, "Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot" (Oct 21, 2026): https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
• SecurityWeek, "PHP2Shell Exploitation Moves From Probes to Working Shells" (Oct 26, 2026): https://www.securityweek.com/php2shell-exploitation-moves-from-probes-to-working-shells/
• BleepingComputer, PHP2Shell flaws now exploited in the wild (Oct 26, 2026): https://www.bleepingcomputer.com/news/security/php2shell-security-flaws-now-sucessfully-exploited-in-the-wild/
• Help Net Security, PHP2Shell vendor impact tracker (Fortinet, Cisco, Palo Alto Networks) (updated Oct 26, 2026): https://www.helpnetsecurity.com/2026/10/22/php2shell-vulnerability-fortinet-cisco-palo-alto-networks/
• DoD CIO, CMMC program page (Phase II suspension): https://dodcio.defense.gov/CMMC/
• Dentons, client alert on CMMC Phase II and Class Deviation 2026-O0025 Rev 3 (Oct 2026): https://www.dentons.com/en/insights/alerts/2026/october/22/cmmc-phase-ii-follow-up
• DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting: https://www.acquisition.gov/dfars/252.204-7012-safeguarding-covered-defense-information-and-cyber-incident-reporting
• NIST SP 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations: https://csrc.nist.gov/pubs/sp/800/171/r2/upd1/final