Do You Need a Pentest After PHP2Shell? AI Found the Bug, and a Patch Is Not a Security Test

Quick Answer: A pentest after PHP2Shell is worth doing once patching is verified. A patch proves only that two CVEs are closed on the runtimes you updated. It will not reveal forgotten hosts, origins reachable around your web application firewall (WAF), exposed database ports or flaws in your own code. Start with an external infrastructure assessment or a vulnerability assessment, then pentest the application if you hold sensitive data or face an audit.

For how the two bugs work and how to patch them, read our PHP2Shell patch guide. This article is about what the discovery says about the rest of your stack.

Wiz Research found the first flaw on 19 August 2026 with AI-assisted research tooling. It confirmed unauthenticated remote code execution (RCE) against Drupal the next day and WordPress on 21 August. It reported privately to PHP on 24 August. Researchers at Calif reached the same flaws through an AI-assisted source audit.

The telling detail: a PHP core developer had already noticed the out-of-memory error in a 2024 audit. It stayed unfixed because nobody could show an exploit path. The affected code goes back to PHP 5.4, released in 2012.

So the bug was seen, judged too costly to weaponise, and parked. In 2026, AI-assisted tooling made the costly part - finding an exploit path through a large, old C codebase - far cheaper. That change applies to every mature component you rely on, not only PHP.

Expect more. Beazley Security told the insurance market that businesses face a "new reality of vulnerabilities", with AI-assisted discovery picking up speed. Insurance supervisors see the knock-on effect: the Bank for International Settlements' FSI (Financial Stability Institute) and the global supervisors' body IAIS warn that one shared software dependency can hit many insured companies at once.

The defending side is thin. The PHP Foundation has 13 full- and part-time staff. Attackers were faster:

The lesson is not "panic about AI". The gap between a bug becoming known and someone using it is shrinking, and old, trusted code will keep yielding serious flaws. Plan as if the next one is already being studied.

Testing decisions should rest on what is known, not on headlines. As of today, the picture is:

Meanwhile the patch gap is wide. In Censys figures reported on 27 October, 32.5 million PHP services remained unpatched, and more than 60 million did not disclose a version at all.

A patch is necessary. It is also narrow. Here is the honest boundary:

The last row has its own guide: how to check you weren't hit first and which secrets to rotate.

The co-exposure row is real. Of the internet-facing PHP hosts in Recorded Future's data, around 394,000 had SSH open as well, some 233,000 had MySQL and about 68,000 had Remote Desktop Protocol (RDP). A web flaw on a host that also offers a database login is a short path to your data.

Unit 42's unconfirmed case shows how fast an intruder can move once a web application falls. Within two hours the attackers reached stored password hashes and multi-factor authentication (MFA) secrets. They then relayed Windows NTLM logins toward Active Directory and tried for Domain Admin rights. Read it as an illustration of lateral movement, not as proof of a PHP2Shell breach.

Buyers often ask for "a pentest" when they need a different answer. Start from the question, not the product name.

An assessment scans a defined surface for known weaknesses and misconfigurations, then confirms the important ones by hand. It answers "what is wrong, and how bad is it".

A penetration test goes further. A tester tries to exploit and chain issues, usually with test accounts, to show what an attacker could reach. It answers "how far can someone get".

All three penetration test tiers are described on our penetration testing services page. Two details decide whether the result is usable:

For most companies that have just patched PHP2Shell, one of these two fixed-price options is the useful first step. They find what a patch leaves behind before you pay for a deeper test.

After patching, never before. A tester on an unpatched server will report the one issue you already know about, and it may bury everything else. A server compromised before testing also produces confusing results.

A sensible order after a mass-exploited bug:

Time the application test to your calendar, not only to the news. Is an ISO 27001 or SOC 2 audit, insurance renewal or customer questionnaire due next quarter? Then test early enough to fix and retest. Auditors value a report with closed findings far more than an open list; our note on vulnerability assessment cadence covers the timing.

Whoever you hire, these questions separate a usable report from a PDF of scanner output:

PHP2Shell showed the cost of being unprepared, even before any confirmed breach. The UK government confirmed 32 digital services unavailable and 4 partly unavailable after organisations took systems offline. Dutch, Finnish, French, Danish and German public bodies did the same on 21 October.

Britain's National Cyber Security Centre (NCSC) and the EU institutions' CERT-EU set out a clear order: update, apply temporary fixes if you cannot, and consider going offline if neither can happen quickly. Many organisations ended up at the last step.

The cheap part of being ready is knowing your own surface: a current inventory, a documented patch process, and an outside view of what the internet can reach. That lets you patch in hours instead of switching services off. If auditors need the process written down, our Vulnerability Management Program (€359) documents patch service-level agreements (SLAs) and the evidence trail.

Facts in this article were verified on 28 October 2026 against these sources: