On October 21, the PHP project released emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, now widely called PHP2Shell. Either flaw can let an attacker run code on a web server without logging in. Details leaked a day before the planned disclosure, and security firms reported exploitation attempts within hours of the patches.
Most bank leaders will never touch a line of PHP. This still belongs on your next risk committee agenda, for three reasons.
Your exposure probably sits with your vendors
PHP runs a large share of the web, including WordPress, Drupal, and many hosted portals. Every PHP installation that serves web requests is affected, across versions going back more than a decade. For most community banks, that means the public website, the marketing site, and possibly loan or account-opening portals, board portals, or HR tools hosted by third parties. The question is not whether your IT team patched a server. It is whether each vendor running PHP on your behalf has patched, and whether you can show it.
Logging in is not a defense
These flaws trigger while PHP is still setting up an incoming request, before the application's own code runs and before any login page appears. A system that requires authentication offers no protection. Only the patch, or interim configuration changes made by whoever runs the server, closes the gap.
Old software has no fix
The PHP project patched versions 8.2 through 8.5. It is not releasing fixes for 8.1 or earlier, which are past end of life. Any system still running an older version must be upgraded, isolated, or retired. There is no patch to apply.
What has changed
The flaws were found with the help of frontier AI models. The researchers noted that the underlying weaknesses had existed for years, but proving they could be exploited required a chain of steps that AI made practical. Attackers have access to the same tools. Expect more discoveries like this, in older and more widely deployed software, with less time between disclosure and attack.
What we recommend this week
- Ask each vendor that hosts a web-facing system for you to confirm in writing that it has applied PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or that it does not use PHP.
- Identify any system on PHP 8.1 or earlier and obtain a dated plan to upgrade or retire it.
- File the confirmations in your third-party risk records. An examiner reviewing your program will want to see how you tracked a critical vendor vulnerability, not only whether it was fixed.
- Brief your risk committee: what was affected, who confirmed remediation, and what remains open.
If you would like help building the vendor confirmation list or the board summary, contact us.