The vulnerability is in PHP. The real failure may be in your IT operations.

On October 21, 2026, security researchers disclosed two critical vulnerabilities in PHP that can allow an unauthenticated attacker to execute code remotely. Within days, exploitation reports emerged, and CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalog.

The vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, are collectively known as PHP2Shell. Both received a CVSS 4.0 severity score of 9.2. PHP is widely deployed, making the potential attack surface enormous.

This isn’t a theoretical risk to put on next quarter’s security roadmap.
It’s an operational problem that needs attention now.

Why PHP2Shell is different

Most people hear about a vulnerability and immediately ask: Which application is affected?

PHP2Shell changes the conversation because the flaw sits in the PHP runtime itself, below application-level defenses.

The vulnerabilities involve memory-management errors that can leave PHP in an unsafe state when handling requests. Under the right conditions, an attacker can exploit that behavior to execute arbitrary code or expose sensitive process memory.

An attacker doesn’t necessarily need a valid account or a compromised employee laptop. A vulnerable, internet-facing PHP service may be enough.

And the implications go beyond the web application itself. Successful remote code execution can give an attacker a foothold to steal credentials, access sensitive files, establish persistence, or move toward other systems.

The critical detail: an application-level security check cannot reliably protect against a vulnerability that can be triggered before application code runs.

That is why PHP2Shell requires infrastructure-level remediation, not simply a code change in your application.

The uncomfortable question: Do you know where you’re running PHP?

PHP is not limited to the application your engineering team actively maintains.

It may be running in a WordPress installation, a legacy internal tool, a customer portal, a third-party application, a container, or a server that nobody remembers deploying.

The affected environments include PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The PHP team has identified Apache mod_php as particularly concerning.

For a 50- or 200-person company without a large security team, the difficult part may not be understanding the vulnerability. It may be answering five basic questions:

• Which internet-facing systems run PHP?
• Which versions are installed, including bundled and containerized versions?
• Who owns each system, and who can patch it?
• Have the vulnerable systems actually been updated and restarted?
• Has anything suspicious happened since the vulnerability became exploitable?

If those answers require days of Slack messages and spreadsheet archaeology, your company has an operational security gap.

What companies should do now

1. Find every affected PHP installation

Inventory production servers, development environments, containers, hosted applications, and third-party software that bundles PHP.

Don’t rely on the engineering team’s memory or a list of approved assets. Verify the running versions and configurations.

2. Patch to a fixed release

The PHP security releases addressing the two PHP2Shell vulnerabilities are:

• PHP 8.5.12 or later
• PHP 8.4.27 or later
• PHP 8.3.36 or later
• PHP 8.2.35 or later

These are the minimum fixed releases for the respective branches; use the latest supported security release available. PHP 8.1 and older branches are end-of-life and require migration to a supported version.

Verify the actual runtime, deploy the appropriate update, restart affected services where necessary, and confirm that the fix is active. Updating a development dependency doesn’t patch a production server. If you cannot patch immediately, restrict exposure and apply the PHP team’s recommended temporary mitigations. Disabling session upload-progress tracking can reduce risk, but it is not a substitute for installing the security update.

Important: A separate PHP issue, CVE-2026-115560, was disclosed shortly afterward. It involves a specific combination of session configuration and application behavior and is not fixed by the PHP2Shell releases above. Check the latest PHP security advisories rather than assuming one update resolves every newly disclosed PHP vulnerability.

3. Look for signs of compromise

Patching closes the known vulnerability. It does not prove that nobody exploited it before the update.
Review web-server, application, authentication, and endpoint telemetry for suspicious activity. Pay particular attention to unexpected child processes launched by PHP workers, unfamiliar files, new accounts, unusual outbound connections, and unexplained changes to services.

Don’t rely exclusively on matching a known malicious request. Exploitation can be difficult to identify from application logs alone, especially when the vulnerable behavior occurs before application code executes. If you find evidence of compromise, treat it as an incident: investigate the host, contain the threat, assess credential exposure, and follow an appropriate recovery process.

4. Turn the response into a repeatable process

PHP2Shell is one example of a recurring problem: a critical vulnerability is disclosed, and every organization must quickly discover its exposure, assign ownership, remediate affected systems, and document the outcome.
The companies that handle this well aren’t necessarily the ones with the largest security budgets. They are the ones that can answer those questions quickly and consistently.

Where EspressoLabs fits

EspressoLabs is building an AI-native IT, security, and compliance platform for small and midsize businesses. The goal is to make security operations more accessible without requiring every company to assemble an enterprise-sized IT and security team.

An incident like PHP2Shell illustrates why that matters.

1. Better visibility into your environment.
You cannot protect an asset you don’t know exists. An effective IT operations process starts with discovering systems, understanding their software and configuration, and identifying who owns them.

2. Faster remediation and verification.
Security teams need more than a vulnerability alert. They need a clear path from identifying an affected system to assigning remediation, tracking progress, and verifying that the change was completed. EspressoLabs can help streamline the IT operations and follow-through around that process.

3. Security that doesn’t stop at the endpoint.
Endpoint protection is important, but it cannot replace patching a vulnerable server-side runtime. Companies need complementary controls across infrastructure, identity, endpoint security, and application operations.

4. Evidence that security work actually happened.
For companies preparing for SOC 2 or maintaining an existing program, asset inventories, remediation records, assigned ownership, and documented follow-up can support a stronger vulnerability-management process. Those records do not, by themselves, establish SOC 2 compliance; controls must also be appropriately designed, implemented, and tested.

One important distinction: an IT management platform does not automatically patch every PHP installation, detect every exploit, or replace specialist incident response. Coverage depends on the systems integrated, permissions granted, and controls deployed. Internet-facing applications and runtimes still need explicit assessment and remediation.

The broader objective is to make these tasks part of routine operations rather than a fire drill every time a critical CVE hits the news.

The CTO’s PHP2Shell checklist

If I were responsible for technology at a 100-person company today, this would be my immediate checklist:

• Inventory all PHP runtimes and internet-facing applications.
• Identify affected versions, including bundled and containerized installations.
• Assign an owner and deadline to every affected asset.
• Patch to a fixed, supported PHP release and verify the running version.
• Review exposure during the pre-patch window for signs of compromise.
• Investigate suspicious processes, files, credentials, and outbound traffic.
• Review the latest PHP advisories for additional vulnerabilities, including CVE-2026-115560.
• Document remediation and improve the process for the next critical vulnerability.

The bottom line

PHP2Shell is a reminder that security isn’t just about buying the right tools. It’s about knowing what you operate, understanding where you’re exposed, and being able to act before a vulnerability becomes a breach.
If your team needs a spreadsheet, three meetings, and a week of investigation to discover which systems are affected by a critical vulnerability, the problem is bigger than PHP.

You need a better way to run IT and security.

EspressoLabs helps SMBs build a more manageable approach to IT, security, and compliance, without the cost and complexity of traditional enterprise operations.
If you’re also working toward SOC 2, explore our EspressoLabs SOC 2 offer to see how we can help make the journey more accessible.

---

Misc

• Sources: Wiz Research
• Canadian Centre for Cyber Security