Elias Taylor argues that the public PHP2Shell exploit frenzy is outrunning the evidence. He points to proof-of-concept repositories that, in his account, require an additional application vulnerability or a deliberately weakened test server.

That is a criticism of particular demonstrations and claims of easy exploitation. PHP’s maintainers separately document working remote-code-execution paths. Both facts belong in the same discussion.

What Taylor is challenging

  • A proof of concept, or PoC, should show the reported flaw under stated conditions. Taylor argues that several circulating examples quietly change those conditions.
  • His main example is local file inclusion: an application already lets a request select a file for the server to load. Requiring that separate weakness changes what an alleged general-purpose PHP exploit demonstrates.
  • Taylor attributes the repeated pattern to developers trusting model-generated exploit claims without checking the test environment. His essay does not measure how often that happens across all published repositories.

A crash, stale memory write, and attacker-controlled code execution are different results. A convincing-looking transcript does not establish which one occurred.

What the criticism does not settle

The maintainer advisories document remote code execution against Apache mod_php before application code starts. The related stale-state advisory also distinguishes confirmed paths from conditional ones, including application-dependent PHP-FPM exposure.

The PHP Foundation’s account says its team found no functional circulating exploits at the moment of public release. That is a bounded observation, not a claim that no working exploit existed or could appear later.

Taylor’s strongest practical point is to inspect exploit prerequisites. His wider reassurance about easy exploitation is a time-sensitive judgment, not a reason to defer the published PHP fixes.

What the thread adds

The Hacker News discussion adds both reported failed reproductions and objections to the essay’s conclusion:

  • kgeist reports testing two public examples: one required an existing file-inclusion weakness; another produced a stale write but no code execution. “It just triggered a stale write.” This is the commenter’s account, not independent replication.
  • pinevale challenges reassurance based on present difficulty: “you only need expertise once and then everyone can reuse the result.”
  • rectang points readers back to the PHP Foundation’s confirmed exploit results, separating weak public examples from evidence held by maintainers.
  • noduerme questions whether failed model-generated examples can establish impossibility: “Or is that assumption just based on the fact that the PoCs so far rely on nerfing PHP?”

From a 73-comment thread, in HN’s own order.

Caveat: the repositories’ behavior is reported by Taylor and commenters, while the maintainer-confirmed exploit paths remain a separate reason to patch.