The first move in our response to PHP2Shell was to isolate the environment. We then enabled Wiz in our infrastructure.
That sequence matters to me: first reduce exposure, then improve visibility. Neither step, by itself, proves that the underlying vulnerability is fixed. The work that follows needs to establish what is affected, what is actually running, and what evidence supports bringing a service back into normal operation.
I’m keeping our environment and implementation details private. This is an operational perspective, followed by the response strategy I would incorporate into a repeatable platform workflow—not a public incident postmortem or a claim that compromise occurred.
What PHP2Shell actually changes
PHP’s October 21 advisory covers CVE-2026-109618 and CVE-2026-109619: request-state memory corruption flaws that can allow unauthenticated remote code execution. Web-serving deployments are at risk, with Apache mod_php assessed highest; a demonstrated attack runs before application code. PHP security advisory.
The upstream fixes are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Distribution packages may carry backported fixes; validate against the vendor advisory. PHP 8.1 and older are outside upstream support. A supported backport and an unsupported installation are different situations. PHP release guidance.
As of this note, the Canadian Cyber Centre’s October 27 update reports exploitation in the wild and records CISA’s October 26 addition of both CVEs to its Known Exploited Vulnerabilities catalog. This is no longer a response to a hypothetical exploit alone. That does not establish whether any particular environment was compromised. Cyber Centre alert.
Why we isolated first
Isolation gave our response a clear starting point. I would keep the exact boundaries out of a public article; the useful lesson is the ordering of decisions, rather than a diagram of a private environment.
For a reusable runbook, define containment before an emergency: who can authorize it, which business owner accepts the availability impact, how responders retain access, and what permits reconnection. Otherwise, “isolate it” is an instruction that different teams can interpret very differently.
Containment should also preserve the ability to investigate. Record the action and its time, retain relevant evidence where feasible, and coordinate collection with incident responders. Urgent risk reduction and evidence preservation sometimes compete; the incident lead should make that tradeoff explicitly.
An isolated service still needs a remediation owner. I would give every containment exception an expiry and a next review time so temporary isolation cannot quietly become the permanent operating model.
Where Wiz fits—and where it doesn’t
We enabled Wiz in our infrastructure as the next step. I’m not publishing coverage figures, findings, or details of our configuration here.
The operational question I want a cloud security platform to help answer is specific: which affected workload can receive untrusted traffic, what can it access, and who owns the fix? The answer should connect a finding to a running resource and an accountable team. A list of CVEs without that context leaves most of the prioritization work unfinished.
After enabling a platform, I would validate its scope: included accounts and projects, scan freshness, required permissions, unsupported resources, and known gaps. Separate the claim “the integration is enabled” from “this workload was assessed.” Confirm which capabilities are actually deployed before depending on their signals.
Wiz is part of visibility and response. Enabling it does not patch PHP, establish that exploitation never happened, or replace the service owner’s verification of the running application.
A response with evidence at each handoff
I would organize the work around five handoffs. Each needs a named owner and a piece of evidence that the next person can inspect.
1. Establish scope. Inventory runtime packages, web-serving processes, container images, and third-party products that may bundle PHP. Include staging systems and administrative interfaces. Record “unknown” when an inventory source cannot establish a version; do not silently treat missing data as a clean result.
2. Prioritize exposure. Start with affected services reachable by untrusted requests. Add privilege, accessible secrets, sensitive data, and business criticality to the decision. A severity score helps start the queue; it cannot describe the whole environment. Keep unresolved exposure behind a documented containment decision.
3. Apply the appropriate fix. Follow the upstream or product vendor’s advisory for that exact deployment. For containers, rebuild from a corrected base and deploy a new immutable image. Check the image digest that reached production, rather than accepting a successful pipeline as proof. Test uploads, sessions, authentication, and the application’s normal request paths before restoring traffic.
4. Verify the running service. Confirm that the web-serving runtime uses the corrected package and that old workers or replicas are gone. Red Hat’s guidance specifically calls for restarting every worker after mitigation changes; a reload is insufficient, and containers should be replaced. Its advisory also warns that configuration mitigations can disrupt workloads and do not replace patching. Apply that guidance in the context of the relevant product. Red Hat response guidance.
5. Investigate independently of patch status. Patching closes a vulnerability; it does not reconstruct what happened before the fix. Have responders review the available evidence for unexpected execution, persistence, file changes, and credential access. If findings warrant it, use the incident process for trusted rebuilds and credential rotation. “Nothing found in the logs we retained” has a different meaning from “exploitation was impossible.”
A useful closure record could look like this. It is a proposed template, not a record from our environment:
Service / accountable owner:
Runtime and vendor advisory:
Exposure assessment / time checked:
Containment decision / review deadline:
Fixed package or image digest:
Running workload verification:
Application checks / result:
Investigation status / evidence location:
Residual risks / approver / next review:
Keep sensitive evidence in the incident system. The closure record can link to it without copying credentials, request payloads, or private infrastructure details into a broadly shared ticket.
Don’t let a clean deployment become a vulnerable rollback
One failure mode I would explicitly test is rollback. A release can deploy a corrected image while the previous, vulnerable image remains the easiest recovery option.
Mark affected artifacts as ineligible for ordinary deployment and rollback. Keep any evidence copies separately controlled. Prepare a recovery artifact with the security fix included, and require a documented exception if an emergency forces a different choice. Reliability planning needs to account for security state as well as application compatibility.
Also track advisory changes after patching. PHP’s October 23 notice describes CVE-2026-115560, a separate session-upload-progress issue requiring unusual configuration and runtime behavior. It recommends disabling that feature in the affected scenario. An initial patch ticket should not conceal a later advisory. PHP follow-up notice.
What I would change as AI accelerates security research
Wiz’s research account describes AI helping researchers develop and adapt exploits for longstanding PHP flaws, alongside coordinated patch verification. That is a concrete example of AI changing the practicality of research; it is not evidence that every attacker can instantly exploit every deployment. Wiz’s original research.
My response would be to shorten the path from an advisory to a verified decision. I would use AI for bounded work: extracting affected-version conditions from primary advisories, comparing them with an inventory export, drafting compatibility tests, and summarizing gaps in a remediation record. Every conclusion should retain its source and timestamp, and missing evidence should remain visibly missing.
I would keep production authority outside that reasoning loop. Deterministic policy should control deployment permissions, approved artifacts, and required approvals. A model-generated recommendation should not become permission to change a firewall, rotate credentials, or reconnect an isolated service. Repository text, logs, and advisory content should be treated as input data, including when they contain instructions aimed at an agent.
For sensitive analysis, use approved environments and minimize the data supplied. Let the assistant work from sanitized inventory fields or evidence references where possible. Avoid feeding secrets or private incident material into an unapproved service simply because summarization is convenient.
The recurring platform work is less glamorous, but more durable: supported runtimes with owners, continuously refreshed inventory, monitored vendor advisories, restricted workload permissions, tested recovery paths, and deployment gates that reject known affected artifacts unless an authorized exception exists.
I would measure whether that system works through time to identify an owner, time to contain exposed services, time to verify the running fix, and unresolved exceptions past their deadline. Those are proposed measures—not results from our response.
The standard I want to keep
Isolating the environment and enabling Wiz were the beginning of our response. The standard I want to carry forward is an evidence-backed path from exposure to recovery: an owner who understands the service, a fix appropriate to the runtime, verification of what is running, and an investigation whose limits are recorded honestly.
AI can help reduce the reading, comparison, and coordination work along that path. The platform still needs to make safe decisions repeatable. That is the work I would invest in before the next urgent advisory arrives.