Cyber Security
AI Is Finding Software Vulnerabilities Faster. Is Your Business Security Keeping Up?
The PHP2Shell disclosure makes a practical point: fixing the application is not enough if the vulnerable runtime underneath it remains in service.
5 min read — Altitude IT
Your website can be maintained diligently and still depend on vulnerable software underneath it. The October 2026 PHP disclosure is a useful example: updating a content-management system or its plug-ins does not necessarily update the PHP runtime that executes the application. Businesses need to know who owns each layer and how a security fix reaches the systems actually serving customers.
What happened in the PHP research?
On 21 October, OpenAI described a coordinated response to critical PHP vulnerabilities. It reported AI-assisted research involving Calif and independent discoveries by Wiz, with PHP maintainers leading the fixes. The researchers' PHP2Shell advisory identifies CVE-2026-109618, involving out-of-memory corruption, and CVE-2026-109619, involving stale state across requests.
The researchers demonstrated unauthenticated code execution and memory disclosure in controlled tests. That establishes serious technical impact on affected configurations; it is not evidence that every PHP website has been attacked or that your business has suffered a breach. Discovery, a working demonstration and confirmed exploitation in a particular organisation are different claims.
Check the runtime, not only the website dashboard
PHP's first fixed releases for these issues were 8.2.35, 8.3.36, 8.4.27 and 8.5.12. These are historical minimums for the original disclosure, not a permanent recommendation to stop updating there. Follow the current PHP notices and your distribution's security guidance, including any later fixes or vendor backports.
Inventory every runtime: public sites, internal applications, scheduled jobs and separately hosted environments. Ask the hosting provider which package is installed and which fixed version is running. Security updates may be backported without changing the headline upstream version, so obtain the provider's advisory and package evidence rather than relying on a public version banner.
Apply the relevant update, restart affected PHP services and long-running workers, then verify the running version and test important business functions. A downloaded package or successful deployment job is not proof that every old worker has stopped.
Pay attention to follow-up guidance
PHP's 23 October response describes a further vector involving particular session-serialiser changes at runtime and enabled upload-progress tracking. It recommends disabling session upload progress until the relevant follow-up release. This is a configuration-specific warning, not proof that all patched deployments remain exploitable. Review the latest notice with your administrator before changing production configuration.
Temporary web application firewall rules or configuration mitigations may reduce particular attack paths, but do not replace the required runtime update. Some configuration changes affect uploads, memory handling or availability. Test them, document their limitations and remove or revise temporary measures when the permanent fix is established.
A patching programme reaches beyond PHP
The same ownership problem applies to operating systems, third-party applications, firmware, network appliances and embedded software. Keep an inventory with support status, patch responsibility and a route for urgent advisories. Unsupported software needs a replacement or explicitly managed exception; an unattended update tool cannot install a fix that no longer exists.
Use vulnerability scanning to identify exposure, then prioritise by internet accessibility, business impact, exploit information and available mitigations. Automated patching helps deliver routine fixes consistently, but failures, reboot requirements and incompatible applications still need an accountable person. Re-scan or inspect runtime evidence after remediation.
Why patching alone is not enough
A new vulnerability may have no available fix. Stolen credentials, phishing, malicious applications and misconfigurations do not disappear because Windows is up to date. The interval between discovery and deployment also remains a risk. Controls should complement one another:
- DNS and web filtering can restrict known harmful destinations; email protection can reduce malicious messages.
- Endpoint detection and response can identify suspicious behaviour; application allowlisting restricts unauthorised execution, subject to policy and coverage.
- Identity protection, MFA and least privilege reduce inappropriate access; network segmentation limits unnecessary connections.
- Monitoring connects alerts to investigation and containment; independent backups and tested restores support recovery.
Our earlier guide to AI-powered cyberattacks explains the wider threat. None of these layers guarantees prevention or substitutes for PHP remediation. Modern integrated security tools can combine several functions, but businesses must verify what is licensed, deployed and monitored. Altitude is evaluating integrated approaches, including Heimdal; that is not a claim that particular Heimdal products are deployed or independently validated.
Ask for evidence of continuous management
Request patch-compliance reports tied to an accurate asset list, overdue vulnerabilities with owners, unsupported-software exceptions, endpoint coverage and alert-handling records. Check recovery readiness through observed restore tests rather than backup success notifications alone. Our layered protection guide explains how these responsibilities fit together.
An independent security assurance review can identify gaps between the inventory, the installed controls and the evidence of delivery. Cyber Essentials can provide a useful baseline within its scope, not assurance that every application vulnerability has been eliminated. Faster discovery makes continuous management more important, not less.
Primary sources
OpenAI coordinated disclosure; PHP2Shell technical and upgrade guidance; PHP security announcements and follow-up notices. Checked 2 November 2026; administrators should check for newer guidance before acting.