Last week’s PHP vulnerabilities sent IT teams, hosting providers, and software vendors into emergency patching mode. Calendars got rearranged, and other projects waited. Organizations had to figure out where they used PHP, who was responsible for updating it, and how quickly they could make changes without breaking something important.
If your team spent last week chasing updates and vendor responses, you probably don’t need another announcement about PHP2Shell. You need to know whether the work is complete and whether anything was missed.
Why the rush was warranted
On October 21, the PHP project released updates addressing CVE-2026-109618 and CVE-2026-109619. These vulnerabilities can, under certain conditions, allow an attacker to execute code on a server without authenticating. The PHP Foundation’s announcement made the urgency clear: organizations running PHP needed to update immediately.
That created a difficult balancing act. Teams needed to move quickly while checking application compatibility, coordinating downtime, and waiting for vendors to confirm whether their products were affected. The immediate concern was serious, but the practical challenge was familiar: finding every place a widely used technology was hiding.
Your public website was the starting point
Checking the company website and contacting its hosting provider made sense. However, PHP can also support internal applications, administrative portals, reporting tools, and software purchased from third parties.
CERT-EU’s advisory specifically notes that commercial and open-source products may be affected because they use PHP behind the scenes. An organization doesn’t have to develop its own applications to have vulnerable PHP in its environment.
Your follow-up review should therefore include internal servers, virtual machines, containers, test environments, and vendor applications. These are places to investigate, rather than assume are affected. An installed PHP component needs to be evaluated in context, including whether it serves web requests and what the vendor says about its exposure.
A system being accessible only from inside the network changes its exposure. It still deserves review. Internal applications may be reachable through VPN access, compromised workstations, or other systems an attacker has already accessed.
Verify what actually changed
“The website is updated” leaves several questions unanswered. Was the application updated, or was its underlying PHP runtime updated? Were all sites and environments included? Did the change reach every server supporting the service?
The October 21 fixes were released in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Distribution and support vendors may also provide backported fixes that retain an older upstream version number, so verification needs to account for the vendor’s package advisory. A label such as “PHP 8.4” doesn’t provide enough detail to close the issue.
Ask your IT team, MSP, hosting provider, or software vendor to document which systems were reviewed, what remediation was applied, and how it was verified. For vendor-managed software, obtain confirmation for the specific product and version you use.
Remediation guidance from Qualys also emphasizes checking both installed packages and running PHP instances. Updated files on disk don’t necessarily mean existing processes have loaded the corrected code. Required service restarts and follow-up scans are part of finishing the work.
Keep checking as guidance evolves
Emergency remediation often begins with incomplete information. Temporary protections, pending vendor updates, and systems awaiting testing can easily disappear into last week’s email threads.
Give each unresolved system an owner and a deadline. Record temporary mitigations and revisit them when a permanent fix becomes available. Continue checking current advisories, too. CERT-EU updated its guidance on October 23 to include a separate PHP vulnerability affecting an unusual application configuration, showing why the first advisory shouldn’t be the last one reviewed.
Use the scramble to improve the next response
Once the urgent work settles down, capture what slowed your team down. Perhaps nobody knew who managed an old portal. Perhaps your inventory identified an application but omitted its underlying components. Those gaps are useful findings.
At Asylas, we help organizations identify exposure, prioritize remediation, and verify that fixes address the risk. Last week demanded speed. The follow-through requires enough visibility to account for the systems that were easy to overlook and protect the people and data depending on them.
