Cloud Services
PHP Vulnerabilities: Your Guide to Acting on PHP2Shell
-
Macquarie Technology Group
- 7 min read
Summary
- Two critical PHP flaws, known as PHP2Shell, let attackers run code on web servers without logging in.
- Both are rated 9.2 (critical) and are being actively exploited.
- PHP released fixes on 22 October (AEDT), and ASD’s ACSC issued a Critical alert.
- Updating WordPress or Drupal won’t help, because the flaw sits in PHP itself.
- Patch, restart, check your logs and rotate your secrets.
How PHP2Shell Unfolded
On the night of 21 October, ASD pulled cyber.gov.au offline. Government sites in Europe and parts of Wikipedia followed1. The cause was PHP2Shell, a pair of critical flaws in PHP, the language behind WordPress, Drupal, Magento and GovCMS.
The bugs had sat in PHP for around 14 years before AI-assisted research found them. PHP received the first private reports on 11 August. Details leaked on 20 October, so PHP released fixes a day early. By then, attackers were already probing; Amazon logged an exploit attempt on 17 October2.
Timeline (AEDT) Date Event
| Date | Event |
|---|---|
| 27 October | CISA adds both flaws to its Known Exploited Vulnerabilities catalogue (26 October, US time) |
| 23–24 October | PHP discloses a third flaw, CVE-2026-115560, with no emergency fix |
| 22 October, 1am | PHP releases fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 |
| 22 October | ACSC follow-up alert confirms patches are available |
| 21 October | ASD’s ACSC issues a Critical alert; cyber.gov.au goes offline that night |
| 20–21 October | CVE numbers leak; PHP brings its release forward a day |
| 17–18 October | First exploit attempt logged by Amazon honeypots |
| 1 August | PHP receives the first private reports of the flaws to Sophos on the 11th but recommends the 1st as being the key date3. |
Where Things Stand
Both PHP2Shell flaws let an attacker run code with a single crafted web request. No login or vulnerable plugin is needed.
The Vulnerabilities at a Glance
| CVE | What it does | Severity | Status (28 October 2026) |
|---|---|---|---|
| CVE-2026-1096184 | Memory corruption when PHP hits its memory limit. Can also leak server memory, including passwords and API keys. | 9.2 critical (CVSS v4.0) | Fixed. Actively exploited. |
| CVE-2026-1096195 | A PHP worker reuses stale data from an earlier request after its memory is freed. | 9.2 critical (CVSS v4.0) | Fixed. Actively exploited. |
| CVE-2026-1155606 | Code execution through session upload progress, in unusual configurations only. | Not yet published | No fix yet. No exploitation reported. |
Who Is Affected
Any PHP installation that serves web requests is in scope. That includes Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed⁷. PHP rates mod_php as the highest risk. ASD’s ACSC advised that all versions from PHP 5 onwards may be affected⁸.
PHP 8.1 and older are end of life and get no official fix. PHP 8.2 follows on 31 December 2026⁹.
The exposure is huge. Unit 42 counted more than 22.6 million potentially vulnerable instances¹⁰.
What’s at Stake
Your Website Holds the Keys to Your Data
The flaw isn’t in your database, but PHP holds the database credentials in memory. An attacker with code running can usually reach customer records, orders and password hashes. They can also use the server as a stepping stone into your wider network.
Patching Your CMS Isn’t Enough
Updating WordPress, Drupal or Magento won’t fix this. You need to patch PHP itself on every server, container and image, then restart PHP workers.
Your Compliance Clock Is Already Running
Under the Essential Eight, ISM-1876 requires critical patches for online services within 48 hours¹¹. If personal information may be exposed, the Notifiable Data Breaches scheme gives you 30 days to assess it¹².
The Window Between Disclosure and Attack Has Collapsed
Here, exploitation began before the fix existed. AI now helps attackers move as fast as defenders. The real question is how quickly you can see and fix your exposure.
How We Responded
When PHP2Shell became public, our priority was to identify our exposure, assess how serious it was and act before we were hit.
We knew Where PHP Was Running with AppSec tooling
We run an application security tool where we have onboarded our source code repositories, and that identifies the languages and frameworks behind each application, including PHP. We then confirmed the PHP version running on each system, including vendor products. This gave us a list of affected applications, so remediation could start straight away instead of waiting for a manual inventory.
In addition to the source code identified internally, we leverage attack surface management tools and intelligence feeds to understand our exposure from an outside-in view. This shows which applications are visible from the internet, the same view an attacker has.
Reduced Exposure Before Patching
While we rolled out patches, we applied the interim protections as described below. The most important was turning off PHP’s session upload progress feature, which removes a known attack path. We treated these steps as a stopgap, not a fix.
Coordinated Across Teams
Security, infrastructure, application and operations teams worked together. Clear ownership and shared priorities let us move quickly without disrupting the services our customers rely on.
Beyond PHP2Shell: Getting Ready for AI-Speed Vulnerabilities
Coordinated Across Teams
Security, infrastructure, application and operations teams worked together. Clear ownership and shared priorities let us move quickly without disrupting the services our customers rely on.
The Old Patching Rhythm No Longer Works
Many vulnerability programs still run on monthly scans and quarterly reports. That rhythm assumes defenders have weeks. With PHP2Shell, exploitation attempts started before the fix was public. The question is no longer “when is our next patch cycle? But “how fast can we act today?”.
Use AI on Defence Too
If attackers use AI to find and exploit flaws faster, defenders need to keep pace. AI can help sort through advisories, match new vulnerabilities to your own systems, suggest fixes and spot unusual activity sooner.
Your Action Plan
Patching is the only complete fix.
This Week
- Find every PHP instance. Check websites, portals, containers, cloud images and vendor appliances. Ask suppliers to confirm in writing.
- Patch. Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or apply your Linux vendor’s update.
- Restart. Restart web servers, PHP-FPM pools and containers so the fix takes effect.
- Mitigate the rest. Turn off session upload progress and keep it off even after patching, until PHP’s next regular release, enable WAF rules, but only as a stopgap.
- Isolate the unpatchable. Take servers on PHP 8.1 or older offline until you can upgrade.
Then Check You Weren’t Hit
- Exploitation began before the fix, so look back to at least 11 August.
- Review logs for unusual POST requests, memory errors, worker crashes and unexpected processes.
- If you suspect compromise, isolate and rebuild the system, then rotate credentials and API keys.
- Start a Notifiable Data Breaches assessment if personal information may be involved.
Close the Gap for Next Time
PHP2Shell won’t be the last flaw like this. Ask your team: Can we list every internet-facing system within an hour? Can we patch critical flaws within 48 hours? Who decides to take a site offline?
Sources
1 iTWire, “PHP2Shell: the 14-year-old bugs that pulled cyber.gov.au and government sites worldwide offline,” 23 October 2026.
2 The Hacker News, “PHP Warns of Another Unpatched RCE Risk Two Days After Emergency PHP2Shell Patches,” 23 October 2026.
3 Sophos, “Advisory: PHP2Shell Vulnerabilities (CVE-2026-109618, CVE-2026-109619),” Security Advisory, October 2026.
4 watchTowr, “CVE-2026-109618: Exploited Remote Code Execution in PHP,” updated 26 October 2026.
5 CERT-EU, “Security Advisory 2026-018: Critical Vulnerabilities in PHP,” updated 23 October 2026.
6 serversideup, “docker-php v5.0.3: Security update,” 23 October 2026.
7 Cybersecurity and Infrastructure Security Agency (CISA), “Critical Vulnerabilities in PHP Require Immediate Patching,” updated 26 October 2026.
8 Australian Signals Directorate’s Australian Cyber Security Centre (ACSC), “Critical vulnerabilities in PHP,” 21 October 2026.
9 PHP, “PHP 8.2.35 release notes,” 21 October 2026.
10 Palo Alto Networks Unit 42, “Threat Brief: Critical Vulnerabilities in PHP,” updated 25 October 2026.
11 Australian Signals Directorate, “Essential Eight maturity model,” ISM-1876.
12 Clayton Utz, “Notifiable Data Breaches Scheme: draft guidance materials demonstrate that preparation is paramount,” October 2017.
Contact us
Talk to an expert.
Let’s talk about where you are and what better looks like for your business.
- 1800 004 943
- Level 15, 2 Market Street Sydney, NSW, Australia