Every PHP installation that serves web requests has been open to unauthenticated remote code execution since 2004. On October 21, 2026, the PHP project shipped the fix, the NSA told organizations to take unpatchable systems offline, and four European governments pulled their own websites to patch. Your security team is handling the interpreter. This article is for the person who has to explain the response to an auditor.
php2shell is a security incident, and it’s also a live test of the vulnerability management, asset inventory, incident response and vendor management controls you attested to in your last audit. Every framework Axipro works with has a specific expectation for what you do in the next 72 hours and what evidence you keep. Below is the mapping, framework by framework: the control reference, what you need to do, and the artifact that satisfies it.
What php2shell Is, in One Minute
Two flaws in PHP core, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on CVSS v4.0, let an unauthenticated attacker run code on the server. The first is triggered through out-of-memory handling that interrupts PHP while request data is only partially initialized. The second exploits request-owned internal state that survives after its memory has been freed. According to the CISA alert, the flaws affect every PHP installation serving web requests, including PHP-FPM, Apache with mod_php, and embedded deployments.
The fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and earlier are end-of-life and get no official fix. Some Linux distributions and long-term support vendors are backporting patches, but the PHP project itself won’t. CERT-EU’s advisory notes that technical details are public and proofs of concept are circulating, so expect exploitation attempts now rather than later.
The discovery story matters for one section of this article. Researchers at Calif, working with OpenAI, reported the first flaw on August 11. Wiz reported the second on August 24. Both used frontier AI models to find bugs that had survived two decades of human review, and Wiz warned that the same models can now adapt an exploit across PHP versions, configurations and memory layouts. That changes the threat model your AI governance documentation describes. We come back to it below.
The Six Actions Every Framework Expects
The frameworks differ in control numbering and in how fast they want you to move, but they converge on the same six steps. Each step produces one artifact. If you do nothing else, produce these six and attach them to the controls listed in the mapping section.
Detect and log. Record when you became aware of the advisory, from which source, and who triaged it. A ticket with a timestamp is the minimum. If nobody logged the advisory, your continuous monitoring control is a sentence in a policy rather than something that operates.
Scope the exposure. Query your asset inventory for every host running PHP and record the version on each. That includes the marketing website, staging and QA environments, internal tools, customer portals and anything a contractor stood up two years ago. Every PHP installation serving web requests is in scope, not only the ones inside your SOC 2 system boundary.
Patch and restart. Update to the fixed version for your branch, then restart PHP-FPM or the web server. The old interpreter stays loaded in memory until the process restarts, so a package update without a restart leaves the host vulnerable. Capture the version output before and after, plus the restart log.
Decide on end-of-life hosts, in writing. Anything on PHP 8.1 or older gets one of three outcomes: upgraded to a supported branch, taken offline, or formally risk-accepted by someone with the authority to accept it. CISA’s guidance is to take unpatchable systems offline. If you choose otherwise, the risk register entry needs an owner, a compensating control and a review date.
Verify what your vendors did for you. Managed hosts and PaaS providers patched fleet-wide, but under the shared responsibility model you still own the verification. Collect the vendor’s status notice and run your own version check against the live host.
Close the loop. Write a short post-incident note covering when you learned, when you patched, what was out of scope, what broke and what changed. This one document is the difference between a scramble and audit evidence.
Important: A patch isn’t applied until the process restarts. We’ve seen the same pattern during this disclosure window: apt upgrade runs, the package manager reports the new version, php -v on the command line confirms it, and the long-running PHP-FPM workers serving traffic are still the old binary. Verify with the running process, not the installed package.
Framework-by-Framework Mapping
SOC 2 (AICPA Trust Services Criteria)
SOC 2 doesn’t prescribe a patch deadline. It asks whether your controls operated as designed during the period, and php2shell lands squarely inside the Common Criteria your auditor tests every year.
CC7.1 requires detection and monitoring procedures to identify susceptibilities to newly discovered vulnerabilities. Evidence: the advisory in your ticketing or GRC platform with a timestamp, and your vulnerability scanner’s detection of the affected version on each host.
CC3.2 and CC3.4 cover risk identification and the analysis of significant changes. Evidence: a risk register entry for php2shell with likelihood, impact and treatment, plus a note on any host where treatment deviates from the standard patch.
CC7.3 and CC7.4 cover the evaluation of security events and the response to incidents. Even without confirmed exploitation, php2shell meets the threshold for a security event that has to be assessed. Evidence: the triage record, the decision on whether to invoke the incident response plan, and the remediation ticket trail.
CC8.1 governs change management. Emergency patches are still changes. Evidence: the change record for each patch, with approval, testing notes (or the documented decision to skip pre-production testing under emergency change procedures), and a rollback plan.
CC9.2 addresses vendor and business partner risk. Evidence: the hosting provider’s status notice and your own verification output.
If the Availability category is in scope, taking systems offline to patch triggers A1.2 and A1.3. Document the outage decision and the recovery, and link both to your business continuity plan.
ISO 27001:2022
ISO 27001 gives you the most explicit control set for this event, and the certification body auditor will walk Annex A with you.
A.8.8 Management of technical vulnerabilities is the primary control. The standard expects you to obtain information about technical vulnerabilities, evaluate your exposure and act on it. Evidence: the advisory intake record, the exposure assessment across your asset inventory, and the patch records.
A.5.7 Threat intelligence covers how the advisory reached you. If the answer is “someone saw it on LinkedIn,” document the improvement action to subscribe to CERT, vendor and CISA feeds.
A.5.9 Inventory of information and other associated assets is where most organizations are exposed. If your inventory couldn’t answer “where do we run PHP?” within an hour, that’s a nonconformity under A.5.9 regardless of whether you patched. Record it as a corrective action under Clause 10.2 rather than hoping the auditor doesn’t ask.
A.8.9 Configuration management, A.8.19 Installation of software on operational systems and A.8.32 Change management govern the patch itself. Evidence: change records, configuration baselines updated with the new PHP version, and the restart confirmation.
A.5.24 through A.5.28 cover incident management: planning, assessment and decision, response, learning, and evidence collection. Evidence: the decision record on whether php2shell counted as an incident for your organization, the response log, and the post-incident review.
A.5.19 through A.5.22 cover supplier relationships. Evidence: vendor patch confirmations and your verification.
A.5.30 ICT readiness for business continuity applies if you took systems offline. Evidence: the continuity decision and the recovery timeline.
Finally, Clause 6.1.2 and 6.1.3 require the risk assessment and treatment plan to reflect this. Add AI-accelerated discovery of interpreter-level vulnerabilities as a threat source. It belongs in the Clause 9.3 management review input for your next cycle. Your Statement of Applicability doesn’t change, but the justification for A.8.8 now has a concrete example.
HIPAA (Security Rule, 45 CFR Part 164)
HIPAA frames the event as a risk management obligation and, potentially, a breach notification obligation.
§164.308(a)(1)(ii)(A) Risk analysis and (B) Risk management require you to assess the risk to ePHI and put measures in place to reduce it. Any PHP host that processes, stores or transmits ePHI, including patient portals, intake forms and billing integrations, needs a documented risk assessment update. Evidence: the updated risk analysis entry and the remediation record.
§164.308(a)(5)(ii)(B) Protection from malicious software is an addressable specification that covers patching as a defense against code execution. Evidence: patch records.
§164.308(a)(6) Security incident procedures require you to identify and respond to suspected or known security incidents and document the outcome. Evidence: the incident determination and response log.
§164.308(a)(8) Evaluation expects a technical and non-technical evaluation in response to environmental or operational changes. A critical interpreter-level vulnerability qualifies. Evidence: the evaluation record.
§164.308(b) and §164.314(a) Business associate contracts apply if a business associate hosts your PHP systems. Evidence: the BA’s patch confirmation.
Breach notification (§164.400 through §164.414) is the part that can hurt. If you find evidence of exploitation on a host with ePHI, HIPAA presumes a breach unless your four-factor risk assessment under §164.402 shows a low probability that the ePHI was compromised. You have 60 days from discovery to notify individuals and HHS. Evidence: forensic review of the affected host, the risk assessment, and the notification decision. The HHS Security Rule guidance is the authoritative reference for the specifications above.
Worth Knowing: HHS proposed an update to the Security Rule that would set explicit timeframes for patching critical vulnerabilities, with 15 calendar days cited in the proposal. Whatever the final rule’s status when you read this, OCR investigators already treat the gap between advisory and patch as a measure of whether risk management was reasonable and appropriate. Document your timeline even if no rule currently mandates one.
PCI DSS v4.0.1
PCI DSS is the one framework with a hard deadline, and it’s shorter than most organizations assume for a flaw this severe.
Requirement 6.3.1 requires you to identify security vulnerabilities using industry-recognized sources and rank them by risk. Evidence: the advisory intake and your criticality ranking, which at CVSS 9.2 isn’t a judgment call.
Requirement 6.3.3 requires critical and high-security patches to be installed within one month of release. For php2shell, one month is the outer boundary. Your own targeted risk analysis under 12.3.1 should justify a much shorter window for an unauthenticated RCE with public exploits. Evidence: patch records with dates, and the risk analysis supporting your timeline.
Requirement 6.4.1 and 6.4.2 require public-facing web applications to be protected by an automated technical solution that detects and prevents web-based attacks. Cloudflare and other WAF vendors deployed php2shell rules before the patch shipped. If you have a WAF, record the rule deployment as a compensating control that covered the window between disclosure and patch. If you don’t, this is the finding.
Requirement 11.3.1 and 11.3.2 require internal and external vulnerability scans quarterly and after any significant change. Rescan after patching and keep the clean result. The external ASV scan has to come from a PCI-approved scanning vendor.
Requirement 12.10 covers incident response. Evidence: the incident response plan invocation decision and the log.
Requirement 12.8 covers third-party service providers. Evidence: patch confirmations from any TPSP that touches the cardholder data environment.
The PCI Security Standards Council publishes the full requirement text. The references above are to v4.0.1.
GDPR and UK GDPR
GDPR has nothing to say about PHP. What it asks is whether personal data was affected and whether you can prove you met your security obligation.
Article 32 Security of processing requires technical and organizational measures appropriate to the risk, including a process for regularly testing and evaluating their effectiveness. Patching a critical interpreter vulnerability promptly is the plainest possible example. Evidence: the patch timeline.
Article 33 Notification to the supervisory authority applies if you find evidence of exploitation on a system holding personal data. The deadline is 72 hours from becoming aware of the breach, unless it’s unlikely to result in a risk to individuals. Article 33(5) requires you to document every personal data breach, including the ones you decide not to notify. Evidence: the breach assessment record, notified or not.
Article 34 Communication to the data subject applies if the breach is likely to result in a high risk to individuals.
Article 28 Processor obligations mean that if you’re a processor, you have to notify your controllers without undue delay once you become aware of a breach. If your hosting provider is your processor, their patch confirmation is part of your Article 28 evidence.
Article 5(2) Accountability ties it together. You have to be able to show compliance, which is why the six artifacts above matter more than the patch itself from a GDPR perspective.
ISO 42001 and the EU AI Act
Most coverage of php2shell will skip this section. It’s the one that changes your AI governance documentation.
php2shell was found by AI. The flaws sat in PHP for 22 years because they were too hard for humans to find and exploit. Wiz’s assessment, reported by TechCrunch, is that LLMs can now adapt exploits across versions and memory layouts, which removes the barrier that kept these bugs theoretical. The PHP Foundation said the same thing: AI will make this class of weakness easier to find.
Under ISO 42001 Clause 6.1.2 AI risk assessment, your assessment of threats to the AI systems you provide or use should reflect this. AI-accelerated vulnerability discovery and exploit adaptation is now a demonstrated threat source rather than a hypothetical one, and it affects the conventional web stack your AI systems run on. Evidence: an updated AI risk assessment that names the threat.
Clause 8.4 AI system impact assessment should consider the impact on individuals if the infrastructure hosting an AI system is compromised through an interpreter-level flaw. If your AI product has a PHP component anywhere in its serving path, the impact assessment needs a line about it.
Under the EU AI Act, Article 15 requires high-risk AI systems to achieve an appropriate level of accuracy, robustness and cybersecurity, and Article 9 requires a risk management system that’s updated throughout the lifecycle. A critical vulnerability in the hosting stack is a cybersecurity event under Article 15 whether or not it’s “AI-specific.” Evidence: the risk management system update and the cybersecurity measures record.
NCA ECC and SAMA CSF (Saudi Arabia and the GCC)
For organizations in scope of Saudi Arabia’s National Cybersecurity Authority Essential Cybersecurity Controls or the SAMA Cyber Security Framework, the expectations are explicit and the regulators are active.
NCA ECC 2-3 Vulnerability Management requires vulnerabilities to be identified, classified and remediated within defined timeframes, with critical vulnerabilities prioritized. ECC 2-13 Cybersecurity Incident and Threat Management covers the response and the threat intelligence intake. ECC 2-1 Asset Management covers the inventory question. Evidence: the same six artifacts, mapped to these control families.
SAMA CSF 3.3.17 Vulnerability Management requires a documented process for identifying and remediating vulnerabilities with defined timelines based on criticality. 3.3.15 Cybersecurity Incident Management and 3.3.16 Threat Management cover the response and intelligence functions. Member organizations should expect SAMA to ask about php2shell in the next compliance review.
The practical difference in the GCC is the expectation of regulator notification. If you find evidence of exploitation, check your sector regulator’s incident reporting requirements before the 24-hour mark. Several GCC regulators have reporting windows shorter than GDPR’s 72 hours.
The Master Mapping
| Action | SOC 2 | ISO 27001:2022 | HIPAA | PCI DSS v4.0.1 | GDPR | ISO 42001 / EU AI Act |
|---|---|---|---|---|---|---|
| Detect and log | CC7.1, CC7.3 | A.5.7, A.8.8, A.6.8 | 164.308(a)(6) | 6.3.1 | Art. 32 | Cl. 6.1.2 |
| Scope the exposure | CC3.2 | A.5.9, A.8.8 | 164.308(a)(1)(ii)(A) | 6.3.1, 12.3.1 | Art. 32 | Cl. 8.4 |
| Patch and restart | CC8.1, CC7.4 | A.8.8, A.8.19, A.8.32 | 164.308(a)(5)(ii)(B) | 6.3.3, 11.3.1, 11.3.2 | Art. 32 | AI Act Art. 15 |
| Decide on EOL hosts | CC3.2, CC3.4 | Cl. 6.1.3, A.5.24 | 164.308(a)(1)(ii)(B) | 12.3.1, 6.3.3 | Art. 32 | AI Act Art. 9 |
| Verify vendors | CC9.2 | A.5.19 to A.5.22 | 164.308(b), 164.314(a) | 12.8 | Art. 28 | ISO 42001 A.10 |
| Close the loop | CC7.4, CC7.5 | A.5.27, A.5.28, Cl. 10.2 | 164.308(a)(8), 164.316 | 12.10 | Art. 5(2), 33(5) | Cl. 10.2 |
The Evidence Pack
Whatever GRC platform you run, attach the php2shell evidence to the controls above this week, not in the month before your audit. A complete pack contains the advisory intake ticket, the asset inventory export filtered to PHP hosts with versions, the before-and-after version output per host, the restart confirmation, the change records, the risk register entry including any risk acceptance for EOL hosts, the vendor confirmations, the WAF rule deployment record if you have one, the post-patch scan results, and the post-incident note.
If you’re managing this in spreadsheets and email threads, you’ll spend more time assembling the pack than you spent patching. That’s a reasonable argument for moving to a platform before the next event, and there will be a next event.
Pro Tip: Attach the evidence to the control, not to a “php2shell” folder. Auditors test controls, and a control with a timestamped artifact from October 2026 is proof the control operated. A folder named after the vulnerability is proof that you remember the vulnerability.
The Hosts Nobody Budgets For
The exposure that will cause the most audit friction isn’t the production application. It’s the PHP running where nobody expects it: the WordPress marketing site managed by an agency, the staging server that was supposed to be decommissioned, the internal wiki, the customer portal on a legacy stack, the contractor-built integration that still answers on a subdomain.
In our experience with first-time SOC 2 and ISO 27001 clients, the marketing website gets excluded from scope by default. It holds no customer data, and the team that runs it reports to marketing rather than engineering. That exclusion is defensible for a SOC 2 system boundary. It doesn’t hold up for A.5.9 asset inventory, and a compromised marketing site is still your domain and your reputation. If it collects form submissions, it’s also your personal data under GDPR.
Inventory every PHP host, whether or not it sits inside your audit boundary. Then decide, in writing, which ones are in scope for which framework.
What This Means for the Next One
php2shell is the first critical vulnerability in a foundational web technology where the disclosure story is “AI found it before attackers did.” Both OpenAI and Wiz framed their findings as proof that AI-assisted research works, and the PHP Foundation’s response was to warn that the same capability will make vulnerabilities easier to find across the board. There will be more of these.
For compliance programs, the practical consequence is that the interval between “obscure flaw nobody can exploit” and “public PoC with WAF signatures” is collapsing. Vulnerability management controls that assume a monthly patch cycle, and asset inventories that get reconciled quarterly, were designed for a slower threat model. The frameworks haven’t changed. The expected speed of operating them has.
The organizations that handled php2shell well this week were the ones that could answer three questions within an hour: where do we run PHP, who owns each host, and who has the authority to take it offline. If you couldn’t answer those, the remediation plan for your next audit cycle writes itself.
Conclusion
php2shell requires the same six actions under every major framework: detect and log the advisory, scope every PHP host, patch and restart, decide formally on end-of-life systems, verify what vendors did on your behalf, and document the response. The control references differ, from SOC 2’s CC7.1 to ISO 27001’s A.8.8 to PCI DSS’s one-month deadline under 6.3.3 to GDPR’s 72-hour notification clock if exploitation touches personal data. The evidence is the same ten artifacts. Produce them this week, attach them to the controls, and the auditor’s question about October 2026 becomes a thirty-second answer rather than a finding.
Frequently Asked Questions
Does php2shell count as a security incident if we weren’t exploited?
It counts as a security event that has to be assessed under every framework covered here, and your incident response procedure should document the decision on whether to escalate it to an incident. For most organizations that patched before any exploitation, the correct record is an assessed event with a documented decision not to invoke the full incident plan, plus the patch trail. The decision itself is the evidence.
We run PHP 8.1 and can’t upgrade this week. What do we tell the auditor?
Document a formal risk acceptance signed by someone with the authority to accept it, name the compensating controls (WAF rules, network isolation, taking the host offline outside business hours), and set a dated upgrade plan. CISA’s guidance is to take unpatchable systems offline. If you choose not to, the risk register entry needs to show you understood that recommendation and picked a different treatment for stated reasons.
Our hosting provider says they patched. Is that enough?
Not on its own. Keep the provider’s status notice as vendor evidence, then verify on your own site by checking the running PHP version. Under the shared responsibility model the provider is accountable for the patch and you’re accountable for confirming it. Auditors working to SOC 2 CC9.2, ISO 27001 A.5.22 and PCI DSS 12.8 will expect both artifacts.
Does php2shell trigger GDPR or HIPAA breach notification?
Only if you find evidence that the vulnerability was exploited on a system holding personal data or ePHI. Patching a vulnerability isn’t a breach. If you do find indicators of compromise, GDPR gives you 72 hours from awareness to notify the supervisory authority, and HIPAA presumes a breach of ePHI unless your four-factor risk assessment shows a low probability of compromise, with a 60-day notification window. Document the assessment either way.
How fast do we actually need to patch?
PCI DSS sets the only hard deadline at one month for critical patches, and that’s the outer bound, not the target. Every other framework asks whether your response was reasonable given the risk. For an unauthenticated remote code execution flaw with public exploits, “reasonable” is measured in hours to days. Your own targeted risk analysis should set the window, and your evidence should show you met it.
