> ## Content Index
> Fetch the complete content index at: https://www.cybrsecmedia.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# PHP2Shell Crisis: 10 AI Prompts That Cut Through the Chaos
- URL: https://www.cybrsecmedia.com/php2shell-crisis-10-ai-prompts-that-cut-through-the-chaos/
- Published: 2026-11-02T12:57:40.000Z
- Updated: 2026-11-02T12:58:38.000Z
- Description: Hacker David Maynor shares 10 AI prompts he used during the PHP2Shell crisis to verify exploit claims, correct assumptions and separate fact from hype.
- Author: David Maynor
- Tags: PHP2Shell, AI and Incident Response, CYBR.SEC.Community, blog

On October 21, 2026, [PHP released emergency security updates for two critical remote code execution vulnerabilities](https://www.cybrsecmedia.com/certificate-authorities-php-runtimes-and-the-limits-of-defense-in-depth-in-the-vulnpocolypse-era/), CVE-2026-109618 and CVE-2026-109619, both carrying CVSS scores of 9.2.

That sounds straightforward enough. [Two serious vulnerabilities](https://www.cybrsecmedia.com/critical-php-rce-flaws-5-steps-to-take-now/), four patched versions, and an [urgent message to update](https://www.cybrsecmedia.com/php2shell-patches-released-critical-rce-flaws-threaten-70-of-the-web/).

Except nothing about the preceding 36 hours was straightforward.

[Subscribe to the CYBR.SEC.Media newsletter](#/portal/signup/free)

CVE identifiers had circulated with the wrong release time and inflated severity scores. A security firm accidentally published a proof-of-concept video, deleted it, and watched copies spread anyway. Information intended for critical infrastructure providers may have leaked. Then Chainguard broke the coordinated disclosure embargo by publishing patched container images more than six hours ahead of the official release.

The PHP Foundation would later sum up the episode with a remarkable admission: "We couldn't write this kind of drama."

Meanwhile, security teams had to make decisions. Were attackers exploiting these vulnerabilities? Which PHP installations were actually exposed? Would configuration changes buy time? Was Windows vulnerable? And how much of the information flying around was independently verified?

I spent the day working through those questions, using AI-assisted research and a series of prompts designed to keep speculation from becoming fact.

The most important rule was simple:

**Confirmed, reported and claimed are three different states. Ten outlets repeating the same unverified claim don't make it ten times more credible.**

Here's how that played out.

**Morning: Don't believe the internet yet**

**1\. Read the source, not the headline**

The day began with links appearing in a chat. One social media post claimed a weaponized PHP exploit bundle was circulating. A news report sounded considerably less certain.

My first job wasn't to decide which one was right. It was to establish what each source actually said.

The prompt:

*Read this firsthand. Report only what it actually says: who is claiming what, which identifiers, versions and scores it names, and what it does not say. Separate vendor-confirmed, independently reproduced, third-party claimed and reshared with no new evidence.*

This matters because attribution drifts during emergencies. Someone makes a claim. Someone else reports the claim. A third person shares the report. Before long, the original assertion is being repeated as established fact.

Later, a Windows HTTP.sys kernel vulnerability surfaced in the middle of the PHP discussion. Reading the original material revealed that it wasn't about PHP at all.

Thirty seconds spent verifying the source prevented an afternoon of chasing somebody else's mistake.

**2\. Count evidence, not echoes**

By midmorning, the information was contradictory.

One source claimed a hosted, weaponized exploit bundle existed. watchTowr reported no known exploitation. Huntress said it had not reproduced a proof of concept as of October 20 and knew of no publicly available exploit code.

Those statements couldn't simply be averaged into a conclusion that exploitation was probably happening.

My next prompt forced the contradictions into the open:

*For each source, state its upstream: the vendor, its own lab work, or another outlet? List the tensions explicitly. End, per sub-claim, with CONFIRMED / REPORTED / CLAIMED-ONLY.*

This is especially important when AI is helping process information. An AI system can summarize a dozen articles in seconds, but if eleven repeat the twelfth, the summary may create an illusion of consensus.

The number of sources isn't the same thing as the number of independent observations.

**3\. Schedule the verdict instead of guessing**

One of the most useful decisions I made happened before the official advisory existed.

Rather than keep refreshing websites or speculate about what PHP would announce, I scheduled a check for 14:10 UTC, ten minutes after the expected release.

The instruction was specific:

*Fetch the official advisory for CVE-2026-109618 and CVE-2026-109619 from php.net. Reconcile it against what we have built and believed: affected branches and fixed versions, including end-of-life; the component PHP names versus the mechanism we framed; whether configuration does or does not mitigate; exploitation status per official sources only. Per point: CONFIRMED / REFUTED / STILL UNSTATED, and a verdict — ship as-is, or a named scoped edit first. Report only. Do not edit, merge, or promote.*

The last sentence matters as much as the rest.

The AI-assisted check was authorized to evaluate the evidence. It was not authorized to change the work or publish anything.

Those are different responsibilities.

There was also a practical advantage: I didn't have to make a decision before the evidence existed.

Sometimes the smartest automation is the one that tells you to wait.

**Midday: The official advisory changes the picture**

At 14:00 UTC, PHP published its advisory.

One sentence settled the biggest question:

**"There are no complete mitigations, updating is the only safe choice."**

That statement became the reference point for everything that followed.

**4\. Make the vendor's exact words the authority**

My next prompt focused on extracting what PHP actually said, rather than what the rest of the internet had inferred.

*Extract the fixed versions for every branch, the vendor's exact mitigation language, every stopgap and its stated limits, the highest-risk deployment mode, and any end-of-life backports. Note what the advisory does not claim.*

The patched releases were PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

But the advisory also revealed details that changed the guidance.

For example, end-of-life PHP installations weren't entirely without options. Minimal source backports existed for PHP 7.4, 8.0 and 8.1.

That's materially different from saying those installations had no fix available. Their problem was now getting those backports packaged, distributed and deployed.

The advisory also made no claim that exploitation was occurring in the wild.

That distinction matters. A security company reporting exploitation is one thing. PHP confirming exploitation is another.

Neither statement should be attributed to the other.

**5\. Stop calling partial workarounds mitigations**

This was the point where our own work needed correction.

Earlier that morning, we'd built material that credited anyone who disabled PHP's session upload progress feature with having mitigated 38 PHP pools.

The official advisory showed why that language was wrong.

Disabling session upload progress blocked the confirmed session path for CVE-2026-109619\. It did nothing to address CVE-2026-109618.

The second vulnerability required a different stopgap: setting memory\_limit=-1 administratively, restarting workers and verifying the change.

Both measures had limitations. Neither made the installation safe.

I used this prompt to force the distinction:

*For each workaround: which vulnerability does it cover, which exact path, how must it be set, does it require a restart, and what does it explicitly not cover? Call it a stopgap unless the vendor calls it a mitigation.*

The correction went all the way down to a variable name.

We changed mitigated\_pools to disabled\_pools.

That might sound trivial. It isn't.

If a variable says a system is mitigated when all you've done is disable one vulnerable feature, you've encoded a false security conclusion into the work itself.

Somebody will eventually trust that label. Somebody may build a dashboard around it. Somebody may use it to justify closing a ticket.

**A misleading variable name can become a misleading security decision.**

The lesson wasn't that configuration changes are useless. It was that their scope must be stated precisely.

**Afternoon: Exploit code appears, but what does it actually prove?**

**6\. Read exploit code for its requirements, not its reputation**

As the day progressed, a public reproduction repository appeared.

That raised the temperature immediately. But the existence of exploit code doesn't automatically mean every vulnerable installation can be compromised using that code.

I wanted to understand the exact conditions required.

The prompt:

*Documentation-only. Do not run it. Extract its exact preconditions: PHP version, server and SAPI, error settings, memory limit, worker model, operating system, binary offsets.*

The repository targeted a specific environment: PHP 8.4.26 on Debian 12, Apache prefork with mod\_php, a single worker, display\_errors enabled, a low memory limit and Linux-specific offsets.

That's useful information.

It tells defenders which environments most closely match the demonstrated exploit conditions.

It does not establish that other vulnerable configurations are safe. It also doesn't establish that attackers are actively exploiting the issue across the internet.

There's an enormous difference between asking whether exploit code exists and asking exactly what conditions that code requires.

The second question produces something defenders can act on.

**7\. Windows is vulnerable. That doesn't mean the Linux exploit works there.**

One of the best questions of the day was also one of the shortest:

"Does the php bug run on widows"

Typo and all, it got straight to the point.

But answering it properly required separating three questions that people routinely collapse into one:

Is Windows within the vendor's affected scope?

Does the publicly circulating exploit work on Windows?

Has anyone independently demonstrated a complete exploit chain on Windows?

The prompt made those distinctions explicit:

*Separate: (1) is the platform in vendor scope, with patched binaries published? (2) is the circulating exploit portable to it? (3) is there an independently verified end-to-end chain on it, or only detection coverage? Close with one classification line.*

The answer:

**Windows is vulnerable. Known public weaponization was Linux/mod\_php-specific. Do not treat Windows as safe.**

Remove the first sentence and Windows administrators might dismiss the threat.

Remove the second and you're implying that the demonstrated Linux exploit applies equally to Windows.

Remove the third and somebody may mistake the absence of a public Windows exploit for proof of safety.

Good security analysis has to accommodate several truths at once.

**8\. Don't let attack chains teleport across system layers**

Another thread attempted to connect the PHP vulnerabilities with the separate Windows HTTP.sys kernel bug.

The idea was to use one vulnerability to gain entry and the other to establish further control.

It's the sort of scenario worth thinking through, but only if the technical boundaries remain intact.

My prompt kept the exercise conceptual:

*Conceptually only, no exploit work. If the lower-layer bug is the entry, what could the first payload actually be? Where does PHP enter — as a later userland stage, not through the kernel bug itself? What protections still stand? Entry is not persistence, and persistence is not interaction.*

A kernel vulnerability might provide an entry point. That doesn't magically create a PHP execution environment or bypass every subsequent security boundary.

Protections such as PatchGuard, Hypervisor-Protected Code Integrity and virtualization-based security still have to be accounted for.

Attack chains are not collections of vulnerabilities that can be connected simply because they sound compatible.

You have to explain how control moves from one layer to another.

If you can't describe that transition, you don't have a demonstrated chain. You have a hypothesis.

**Evening: The disclosure disaster becomes part of the story**

**9\. Record what actually happened**

By evening, the PHP Foundation had published its account of the disclosure problems.

The instruction was short:

"Log it."

But the expanded task was more demanding:

*Reconcile it against this morning's reconciliation. What is upgraded? What is the full leak timeline, in UTC? What did monitoring actually identify at disclosure? File what it changes, and what it does not.*

The most consequential detail was Chainguard's decision to release patched container images ahead of the coordinated disclosure.

From Chainguard's perspective, getting fixes to its customers early was defensible.

But publicly available patched images also meant anyone could compare the fixed code with the vulnerable versions.

That potentially gave attackers a roadmap before the rest of the ecosystem had received the official updates.

It's a genuine supply-chain dilemma.

Do you publish fixes early to protect your own customers, knowing that others may become more exposed? Do you wait for the coordinated release while information is already leaking? Do defenders rely on temporary stopgaps during the gap?

There isn't a clean answer that satisfies everyone.

But there is value in documenting the precise sequence of events and the tradeoffs involved. The next coordinated disclosure failure may involve entirely different software, but the underlying decisions will look familiar.

**10\. Put guardrails on public claims before writing them**

The final prompt governed what could be said publicly:

*Never write "in the wild" unless an official source says it. Never call a stopgap a mitigation. Name the real fixed versions. Do not invent a detail the source does not specify.*

By the end of the day, researcher-demonstrated exploitation was real.

The PHP Foundation's monitoring, however, had identified no functional exploitation in the wild at the time of disclosure.

Both statements could be true.

Neither should be omitted simply because the other makes for a better headline.

The same applies to vulnerability scope, patched versions and temporary workarounds. Every adjective carries a burden of proof.

If the evidence supports "demonstrated," don't write "widespread." If the vendor says "stopgap," don't write "mitigation." If a report says "possible," don't turn it into "confirmed."

That's not being overly cautious. It's making sure the information people use to defend their systems is accurate.

**The real lesson: AI can accelerate the work, but it can't own the judgment**

By the end of October 21, I had ten prompts, a collection of corrected assumptions and a much clearer picture of what the PHP vulnerabilities meant.

The prompts weren't magic words designed to make an AI sound intelligent.

They were a way to encode decisions before fatigue, urgency and information overload made those decisions harder.

Some were long because the task required explicit boundaries. Others were as short as "Log it" because the underlying method had already been established.

That's the difference between a useful AI-assisted workflow and a chatbot confidently summarizing whatever happens to be circulating.

The value isn't in how quickly a model produces an answer. It's in whether the process forces that answer to survive contact with evidence.

And sometimes that process reveals that your own work is wrong.

We had to correct our assumptions about end-of-life PHP backports. We had to change how we described configuration workarounds. We had to distinguish vulnerable Windows installations from the Linux-specific exploit being demonstrated publicly.

Those corrections were the work.

The next emergency won't be PHP. The first headlines will still contain errors. Somebody will mistake repeated claims for independent confirmation. A partial workaround will be presented as a complete fix. And somebody will want to publish an answer before the authoritative evidence exists.

When that happens, I want a method that holds up under pressure.

Read firsthand. Preserve uncertainty. Verify against authoritative sources. Understand the technical preconditions. Keep automated research separate from automated action. And correct your own work when the evidence demands it.

**The goal isn't to be the first person with an answer. It's to be the person whose answer is still right when the dust settles.**

**Source material:* PHP security advisory and releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (October 21, 2026); GHSA-w8hw-w9fx-j79w (CVE-2026-109618); GHSA-6wmf-4rv5-p3rp (CVE-2026-109619); PHP Foundation, "Today's PHP security release and how we're strengthening PHP security" (October 21, 2026).*

[![](https://storage.ghost.io/c/ab/67/ab676516-71e3-473d-8f73-9e0692f5aaee/content/images/2026/11/2027-Events-Banner.png)](https://www.cybrsecmedia.com/conference/)