Installing a PHP patch can close a security flaw. It cannot tell administrators whether attackers got there first.
That is the challenge facing security teams after the PHP2Shell disclosures at the center of the “Black October” alarm. Amazon reported exploitation attempts before public disclosure, while a separate PHP advisory added configuration checks even for organizations that had already installed the emergency updates.
Security teams must now establish whether attackers gained access before patching, whether they left anything behind, and whether every exposed application is running the fixes.
The investigation window starts before the patch
The initial disruption included European government websites taken offline as a precaution. The follow-up question is whether exposed systems were targeted before their operators knew to act.
Amazon Threat Intelligence reported a PHP2Shell exploitation attempt against its MadPot honeypot infrastructure on Oct. 17, four days before public disclosure. More attempts followed around the release, but Amazon said it was unclear whether those attempts would have succeeded against real-world systems.
Amazon recommended investigating from at least Oct. 17 rather than using the advisory date as the starting point. That distinction matters for organizations whose initial checks covered only the period after patching began.
The evidence also requires care. In an Oct. 25 correction, Palo Alto Networks’ Unit 42 retracted its earlier attribution of an attack against a European government agency to PHP2Shell. Researchers observed a compromise involving a vulnerable PHP application but could not confirm that these specific CVEs provided initial access.
The correction does not reduce the need to patch. It does mean that the reported incident cannot establish successful PHP2Shell exploitation.
A separate advisory keeps configuration checks in focus
The original flaws, CVE-2026-109618 and CVE-2026-109619, received fixes in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on Oct. 21. Distribution and long-term-support vendors may supply backported fixes, so administrators should verify their vendor’s package status rather than rely solely on an upstream version comparison.
On Oct. 23, the PHP project issued an informational advisory for a separate issue, CVE-2026-115560, involving session upload progress. It requires an unusual combination of configuration and application behavior, and PHP said it would address it through the regular release cycle.
Specifically, an application must configure session.serialize_handler as php_binary or php_serialize, then switch it to php using ini_set() before calling session_start(). Session upload progress must also remain enabled.
PHP recommends setting session.upload_progress.enabled=0 until the next regular bugfix release. This disables PHP’s native session upload-progress reporting, so administrators should check whether their applications rely on it. For this separate issue, PHP says applications that never change the serialization handler at runtime can keep the feature enabled. They still need the updates addressing the original PHP2Shell vulnerabilities.
Administrators applying that mitigation must use configuration that takes effect before request parsing, such as php.ini, the PHP-FPM pool, or Apache server configuration. PHP warns against relying on application-level ini_set() or PHP-FPM .user.ini files for this change.
Red Hat’s deployment guidance also calls for restarting every affected worker; a reload is insufficient. In containerized deployments, replace the running container or pod. Verify that the application serving web requests uses the updated setting, rather than relying solely on the command-line PHP configuration.
Disabling session upload progress addresses the separate conditional issue but does not replace the original PHP2Shell updates. The later advisory does not mean those updates failed to fix the original vulnerabilities.
Updating the CMS does not close every gap
The vulnerable component sits beneath the website application. Wiz researchers demonstrated unauthenticated remote code execution against WordPress, Drupal, and Joomla deployments, but said the underlying weaknesses were in PHP itself.
For organizations accustomed to responding to WordPress plugin exploitation, that changes the verification task. Updating a plugin or content management system alone does not demonstrate that its PHP runtime received a fix.
Joseph Perry, cybersecurity researcher and advanced services lead at Arcova, described the response as a “critical update and monitoring window” for ecommerce and other API-driven web applications.
“For every person out there with a blog or website, it's a good reason to minimize complexity, update everything, and stay on top of best practices,” Perry said.
A practical follow-up is to ask hosting and application owners which runtime serves each exposed site, which vendor package fixes the flaws, and whether running workers and containers actually picked up the update.
The National Security Agency’s advisory also recommends enhanced logging and replacing end-of-life PHP services that cannot receive compatible patches. Where an immediate update is not feasible, it recommends taking the system offline until it can be fully mitigated. For administrators, that makes identifying unsupported systems part of the response—not simply confirming updates on supported deployments.
Temporary controls also need scrutiny. AWS’s mitigation guidance describes web application firewall rules as supporting protection and emphasizes that patching is the only complete fix. A blocked request should not become the evidence used to close a remediation ticket.
Cloudflare reported that attackers modified their payloads to try to bypass its protections, while its analysts continued updating detection rules. That activity gives defenders another reason to review temporary controls throughout remediation rather than treat their initial deployment as the end of the work.
AI changes which exploits are worth the effort
Perry’s broader concern is the economics of exploit development.
“This is also a curious case in which AI didn't make the exploit possible so much as practical,” he said. “The thing in the way of developing an exploit like this is the need for constant, exhaustive debugging from platform to platform, version to version.”
Wiz’s findings align with that assessment. The researchers described repeated testing and adaptation across PHP versions, configurations, and memory layouts, and said AI reduced the specialist effort required.
“Protecting against AI isn't about protecting against futuristic exploits no human could possibly imagine. It's about protecting against the kind of exploits no human would bother to use,” Perry said.
That does not establish that every observed attack used AI. It does challenge the assumption that complex memory corruption flaws will remain too costly to exploit across many targets.
“It means we should focus less on what AI makes possible and much, much more on what AI makes practical,” Perry said.
The potential downstream problem is familiar. Earlier reporting on WP-SHELLSTORM’s website backdooring operation showed how attackers used known vulnerabilities to establish persistent access. That was a separate campaign, but it illustrates why remediation must consider what an attacker could leave behind.
What security teams need to establish before closing the response
The most useful outcome after Black October is a documented answer to three questions: Which systems were exposed, when did their protection take effect, and what evidence supports confidence that they remain trustworthy?
Security teams should connect each public-facing application to its actual PHP runtime and an accountable owner. Hosted services need confirmation from the provider; containers need confirmation that updated images reached running workloads. A completed change request is weaker evidence than verification of the deployed fix.
Investigation should run alongside remediation. Review retained web, application, and endpoint telemetry from at least the earliest known targeting date, extending further where evidence warrants. Unexpected processes launched by web workers, unauthorized file changes, or suspicious outbound connections deserve investigation, although none alone proves PHP2Shell exploitation. Missing logs should be recorded as a limit on confidence.
Where evidence indicates compromise, treat patching as one part of incident response. Establish the scope, remove persistence, and assess whether accessible credentials or tokens need replacement before declaring recovery complete.