We Don't Write PHP. PHP2Shell Still Made Us Audit Everything: A Runtime-Patching Playbook for Polyglot Teams

Our team primarily develops Django, React, and Flutter applications, so the initial response to the PHP2Shell advisories was a dismissive "not our problem." However, this reaction proved to be misguided. The crucial question isn't whether we write PHP, but rather whether we operate PHP in any form, anywhere. Taking this assessment seriously prompted an audit of every runtime we encounter, not just PHP.

This report serves as the playbook derived from that audit. It doesn't criticize PHP; rather, it focuses on how a polyglot team ensures a runtime-level fix is implemented correctly across all affected areas. The PHP2Shell incident is just one example of a broader issue highlighted during a month dubbed "Black October." In the same period, multiple AI developer platforms reported breaches involving attackers targeting stored environment variables and API keys.

The overarching lesson applies to both scenarios: swift identification of where runtimes are located and which secrets they manage is essential.

In essence, PHP2Shell is a runtime vulnerability, not an application flaw. Despite following best coding practices, the only safeguard was promptly knowing where the runtime existed and replacing it. The critical bugs within PHP, CVE-2026-109618 and CVE-2026-109619, are rated with a high CVSS v4.0 score of 9.2. These vulnerabilities can be exploited without authentication, before any application code is executed.

Notably, every web-facing PHP setup, including Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed, is vulnerable. The fixed versions include 8.5.12, 8.4.27, 8.3.36, and 8.2.35, all released on October 21, 2026.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) quickly acknowledged these vulnerabilities, adding them to its Known Exploited Vulnerabilities catalog on October 26, 2026. This alert serves as a concise summary for team leaders to disseminate. As of now, there are no additional claims regarding the timeline of the bug's existence or the extent of its exploitation. However, these details are unnecessary to initiate action.

The primary takeaway from PHP2Shell is that it underscores the necessity of knowing where runtimes are located and which secrets they hold. The incident was a runtime bug, not an application one, and its impact was amplified by exposure. To mitigate this, teams must conduct a comprehensive inventory of all runtimes, including those that are not directly developed by the team itself.

This inventory should include appliances, vendor boxes with web admin UIs, admin and database tools, vendor appliances, base images, client and legacy projects, and any other systems that may run PHP.

Practical steps to identify these runtimes include using commands like `command -v php`, `ps aux | grep -E 'php-fpm|httpd|apache2|lsphp|frankenphp'`, and scanning container images with tools such as Docker, SBOMs, or image scanners like Trivy, Grype, or Syft. It is also crucial to ensure that management interfaces, such as those for firewalls and VPN gateways, are not exposed to the public internet and are promptly patched.

Following the patching of the PHP vulnerability, teams should also address any underlying kernel vulnerabilities that could further exploit the system.