After PHP2Shell: What a Web Application Pentest Finds

On 26 October 2026, CISA added two unauthenticated PHP remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, together nicknamed PHP2Shell, to the Known Exploited Vulnerabilities catalog with a three-day federal remediation deadline. For CTDefense clients running Laravel, Drupal, Symfony, or WordPress stacks, the patch window closed on 29 October. What should have come next is harder to buy from a scanner: a web application pentest beyond vulnerability scan, confirming whether the CVE is actually reachable in the client’s deployment and what an attacker can do from the moment the shell lands.

That gap is where the engagement earns its fee. A scanner confirms a CVE is present on a host. A pentest proves whether that CVE is exploitable in the specific configuration in front of it, and maps the chain an attacker can run from the initial foothold onward.

What PHP2Shell Enables Beyond the CVE

CISA’s advisory names Apache mod_php as the highest-risk configuration, with PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed also affected. In practice, that catches almost every production PHP serving mode the team sees on client engagements. The CVE pair allows unauthenticated remote code execution; unauthenticated is the operative word, because it collapses the usual initial-access cost to zero.

The urgency is not academic. ENISA’s 2025 Threat Landscape, drawn from 4,875 incidents between July 2024 and June 2025, places vulnerability exploitation at 21.3% of all intrusion vectors, and notes that newly disclosed web flaws are frequently weaponised within hours of disclosure. Three days of federal grace is not three days of market grace.

The patch stops future exploitation. It does not answer the question CTDefense gets on every post-KEV call: whether anyone had already walked through this door before the patch, and if they had, how far they would have reached.

Shell to Credential: The Post-Exploitation Chain

Once a tester has shell on a PHP-serving host, the real work starts. The team runs a PHP RCE post-exploitation methodology that mirrors what a motivated attacker would do in the first hour after foothold.

The first step is almost never further exploitation. It is stabilisation and quiet enumeration:

• Shell stabilisation. The team upgrades the raw RCE primitive into an interactive shell with proper terminal handling, so tooling behaves and operator visibility stays clean. Noisy shells get noticed.
• Local service account inventory. The pentester enumerates the uid the PHP worker is running under, the sudo surface available to it, and the writable paths inside the application root.
• Secrets on disk. .env files, wp-config.php, config/database.yml, mounted secret volumes, and .git/config are checked in order. On a recent engagement the team found an AWS access key pair in a staging .env that had been deployed to production by accident.
• Credential cache harvest. Browser-cached session cookies for admin SaaS tools, SSH keys in the webserver user’s home directory, and locally stored API tokens for the organisation’s own back-office systems.

Every item on that list is invisible to a vulnerability scanner. A scanner cannot know that the .env on this host contains a credential that unlocks a different host, because the scanner has no concept of chain.

SSRF Pivots and ORM Injection Paths

With shell and local credentials in hand, the test moves outward. This is where the technique set PortSwigger’s 2025 research tracks becomes relevant. PortSwigger’s annual community vote processed 63 nominations in 2025, and ORM leaks, novel SSRF chains, and new SSTI exploitation modes landed in the top three.

A SSRF post-exploitation chain from an unauthenticated PHP RCE typically takes one of three shapes:

• Cloud metadata to IAM role. On AWS, Azure, or GCP, the compromised PHP worker is often running on an instance with an attached role. A direct call to the instance metadata service surfaces temporary credentials that unlock whatever that role was allowed to touch, usually S3 buckets, DynamoDB tables, or SQS queues.
• Internal admin interfaces. PHP hosts frequently sit on the same VPC as internal admin dashboards, Redis instances, Elasticsearch clusters, and CI runners. The team probes localhost and the host’s /16 subnet from the inside, looking for the kind of unauthenticated internal services that no edge scanner can see.
• Service-to-service authentication re-use. Where the PHP app signs service-to-service calls with a shared secret, that secret becomes a lateral-movement primitive against every service that trusts it.

The next layer is ORM injection web application testing against adjacent back-office APIs. Modern PHP applications rarely stop at raw SQL; they ride on Eloquent, Doctrine, or custom query builders, and PortSwigger’s 2025 vote shows researchers have published generalisable methodologies for leaking data and bypassing scope filters through ORM constructs. CTDefense pentesters probe adjacent APIs for mass-assignment on nested relations, filter bypass through NULL and type-juggling tricks, and model-level authorisation gaps that look clean in code review but break under test.

Where a client wants depth on this part of the surface, the engagement extends into secure code review on the ORM boundary, so the finding is tied to a specific line of code and a specific remediation.

Scanner Report vs Pentest Report

By this point the deliverable is already different in kind, not degree. A scanner report confirms CVE-2026-109618 and CVE-2026-109619 were present on the asset. A pentest report describes what a standard web pentest methodology covers plus the specific attack narrative the team ran, step by step, from the first unauthenticated request to the last credential pulled out of the environment.

That narrative gives a CISO four things a CVE scan cannot:

• Proof of exploitability in context. Not “this CVE applies to your software version”, but “here is the exact request that returned a shell, and here is the data that was reachable from that shell.”
• A map of the post-exploitation chain. Which internal services were reachable, which credentials were cached, which cloud resources an attached IAM role could have accessed.
• Business-logic and ORM findings adjacent to the headline CVE. CTDefense has yet to run a web engagement where the KEV CVE was the only issue of consequence. For a sense of how those adjacent findings cluster, how OWASP Top 10 2025 categories translate to actual findings walks through the real-world breakdown the team sees.
• Remediation that goes past the patch. Patching PHP closes the one hole. Rotating the AWS credentials sitting in the staging .env, locking down the SSRF-reachable metadata endpoint, and tightening ORM scope filters closes the paths that would have been reused against the next CVE.

What This Means for an Upcoming Audit

Boards and auditors have become noticeably more precise about what counts as evidence. “We patched within the KEV window” is a control statement. “We commissioned a web app pentest after the KEV notification, confirmed the fix was effective, and surfaced the adjacent risks” is penetration testing evidence for ISO 27001 control A.8.29, for NIS2 Article 21 technical measures, and for PCI DSS Requirement 11.4.

Scoping for that evidence is where many engagements get thin. The team recommends tying the pentest to a specific application boundary, a specific authentication model, and a specific set of integrations, so the resulting report answers auditor questions directly rather than describing capability. A CISO sitting across from an auditor needs a report that names the application, the dates, the methodology, the findings, and the retest result; not a brochure.

Where CTDefense Fits

CTDefense delivers Web Application Pentest engagements against exactly this scope: human-led, methodology-driven, with the post-exploitation chain mapped as explicitly as the client’s environment allows. Where the headline is a KEV like PHP2Shell, the engagement starts with CVE verification and finishes with the adjacent SSRF, ORM, and credential-cache findings that the scanner never raises.

Other mid-market SaaS, fintech, healthcare, and retail organisations running PHP-heavy stacks are encouraged to treat a KEV notification as a trigger for scoped pentest work, not a trigger for a patch ticket in isolation. Addressing the chain, and not just the patch, is what closes the risk that a KEV like PHP2Shell actually represented.