Internet-facing PHP servers face immediate compromise risk because attackers are broadly exploiting two critical code-execution weaknesses. Exploitation attempts appeared four days before public disclosure, followed by multiple proof-of-concept releases and more activity before the embargo ended on October 21. The weaknesses affect PHP request processing before application code runs. Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
What Happened
The PHP project released emergency fixes on October 21 for two critical weaknesses in the PHP core runtime. Both can allow an unauthenticated attacker to execute code on a vulnerable server, and both affect multipart request processing before an application’s own code runs. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
Evidence indicates that attackers were already testing the weaknesses before public disclosure. Amazon threat telemetry recorded an exploitation attempt on October 17, four days before disclosure, from an address associated with a commercial anonymization network. Because the vulnerability was still under embargo, the activity suggested threat-actor involvement, although it remains unclear how the actor obtained the information.
On October 21, proof-of-concept exploits appeared from around 02:00 UTC, hours before the embargo lifted at 14:00 UTC. Additional attempts came from different anonymized infrastructure between 02:00 UTC and 08:00 UTC. Variations in payloads and infrastructure suggested multiple actors. After the embargo ended and patches became available, further proofs of concept appeared within hours and were used against sensors almost immediately. The weaknesses are now being broadly exploited in the wild.
Technical analysis remains ongoing, and it is unclear whether every attempt observed before disclosure would have succeeded against a real system. That uncertainty does not reduce the need to patch because working attack information is public and broad exploitation has been observed.
Why It Matters
PHP is widely used across web applications and infrastructure products, so organizations may have exposure beyond systems labeled as traditional web servers. The weaknesses sit in PHP core request handling and can be reached before application code runs. Application-level checks therefore should not be treated as a complete barrier.
The timing changes the usual patching assumption. Exploitation activity appeared before disclosure, proof-of-concept code appeared before the embargo ended, and broader scanning followed quickly. Organizations that begin inventory only after a public announcement may already be behind the attacker timeline.
A web application firewall can narrow some attack paths, but one weakness includes server-side behavior that a firewall cannot see. Patching is the only complete fix.
What to Watch
Further analysis may clarify how pre-disclosure actors learned about the weaknesses and whether the earliest attempts succeeded in real environments. Those questions remain unresolved.
Organizations should also watch for updated packages from the operating-system distributions and vendors that supply their PHP installations. The relevant fix may arrive through a supported distribution package rather than a direct installation from the PHP project.
Continued variation in payloads and anonymization infrastructure would be consistent with multiple actors testing public exploit information. Observations involving reported infrastructure should be investigated in context rather than used as the sole basis for broad blocking, because some addresses belong to shared anonymization services.
What Defenders Should Do
Primary action: Inventory every place PHP runs and upgrade to PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35, or an appropriate vendor package containing the fix. Include products and appliances that embed PHP, not only directly managed websites.
Temporary edge controls: Use web application firewall rules to reduce exposure while upgrades are tested and deployed. Where an application does not accept file uploads, blocking multipart requests can remove important attack paths. Where uploads are required, broad blocking may disrupt legitimate traffic and will not close the weakness.
Safe deployment: Start new firewall rules in monitoring or count mode, confirm they do not match valid traffic, and then move them to blocking. Request-body limits and rate controls can reduce some conditions used by an attacker, but inspection limits and multipart header behavior leave gaps.
Server controls: Disabling session upload progress and applying relevant runtime changes can provide additional protection during the patch window. These measures support the upgrade; they do not replace it. After patching, review temporary controls and retain only those that provide useful defense without unnecessary operational impact.
The Larger Lesson
Coordinated disclosure does not guarantee a quiet period before a patch becomes public. In this case, suspicious exploitation preceded disclosure, and public attack material spread within hours.
The durable response is a process that can rapidly find an exposed runtime, identify the correct vendor package, apply temporary controls safely, and move to the complete fix. Edge filtering can buy time, but it cannot repair vulnerable server-side behavior. The lesson extends beyond PHP: organizations need patch workflows built for exploitation that starts before the normal announcement cycle.