How Tabiri's AI agent triaged PHP2Shell safely in less than 20 minutes

A new vulnerability advisory can arrive before every security tool in an organization is ready to recognize it. When that happens, defenders still need a quick way to identify which systems might be affected. In one authorized assessment, our AI-assisted penetration-testing workflow helped us turn a new PHP advisory into targeted, non-exploit checks and identify a likely PHP-backed application in about twenty minutes.

The important result was an early lead for human review, not an automatic declaration that a server was exploitable. That distinction matters whenever speed and uncertainty arrive together.

We started with the advisory, not an exploit

In October 2026, the PHP security team disclosed two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively discussed as PHP2Shell. They affect PHP's handling of request memory and internal state. An unauthenticated attacker may be able to reach remote code execution on affected PHP installations, so the PHP team issued fixed releases for supported branches and recommended updating promptly.

We had a small, authorized environment to assess, with several systems exposing web interfaces. The rules did not permit exploitation, brute force or post-exploitation. Our goal was narrower: identify likely PHP services quickly, gather safe evidence and tell the responsible engineers where to verify and remediate.

The boundary that mattered

The agent could translate advisory details into repeatable probes and collect evidence. It could not declare a system vulnerable. Version verification, risk judgment and remediation remained human responsibilities.

Turning a new bug into a practical check

Ordinary network discovery gave us the first map of open web services. But a web server banner is not the same thing as a PHP version. One service advertised Apache while its responses did not disclose a PHP version. A scanner looking only for a visible version string could therefore lack enough information to make a confident version-based match.

Our agent-assisted workflow combined service discovery with checks derived from the advisory's request-handling details. It looked for PHP-style paths and application behavior, examined session-related response signals and sent a carefully scoped multipart request containing the upload-progress field discussed in the advisory. It repeated the candidate check across the other web-facing systems to separate likely PHP surfaces from unrelated applications.

policy

Scope

The authorized rules excluded exploitation and kept every probe focused on identifying likely PHP-backed services.

manage_search

Correlate

The agent combined discovery, application behavior and advisory-specific signals instead of relying on a single banner.

fact_check

Validate

Engineers received a focused lead, then retained responsibility for confirming the PHP build, patch status and actual risk.

A probe is evidence, not proof

The multipart request returned an application-level response, including a CSRF rejection in one test. That helped show that the request reached the application and informed our fingerprinting. It did not prove that a vulnerable PHP runtime was installed, that the relevant internal condition was present or that code execution was possible.

The saved evidence identified one likely PHP-backed application among ten targets in roughly twenty minutes. We escalated the candidate and took it out of service while its PHP build and patch status could be checked. For a fast triage exercise, that was the right outcome: a broad advisory became a specific, reviewable lead without any attempt to weaponize the issue.

"The value was not an automatic verdict. It was a fast, evidence-backed path to the next human decision."

What the agent contributed

Conventional vulnerability scanners are valuable when their checks cover the software and versions in an environment, and when the right feeds, credentials and scan settings are in place. On a newly disclosed issue, however, defenders can face a gap between an advisory and the checks available in their own scanner workflow. The agent helped us bridge that gap by converting technical clues into small web-level tests and applying them consistently across candidate services.

This does not mean AI replaces OpenVAS, Nessus or other established scanners. Greenbone reported that its Enterprise Feed included PHP version checks beginning October 21, with further agent-based checks described on October 22. Whether those checks are present and active in any deployment depends on its feed, configuration and scan method. The narrower lesson is that a locally available agent can help investigate an emerging issue while a team verifies what its existing tools can detect.

What remains human

People authorize the scope, interpret incomplete signals, confirm the installed software, assess business risk and decide how to remediate. Agentic testing accelerates the evidence-gathering loop; it does not remove accountability from it.

The takeaway

To me, the practical value of an AI penetration-testing agent is not that it knows every vulnerability in advance. It is that, when given an authorized scope and a credible advisory, it can help translate technical details into repeatable safe checks, run them across relevant systems and organize the evidence for people to validate.

Established scanners remain essential, and their feeds should stay current. Agentic testing adds another capability: when a new risk is not yet producing an actionable result in a local scanning workflow, it helps engineers ask targeted questions of systems they are responsible for, then leaves final judgment and remediation where they belong - with humans.