Wiz frames PHP2Shell as a milestone: their AI agent harness autonomously proposed suspicious lifetime patterns, wrote targeted fuzz harnesses, triaged crashes, and iterated to a working PoC without a human auditor driving the loop. They position this as proof that LLM-driven pipelines can now independently discover complex memory-safety bugs in mature C codebases like PHP core.
By submitting the Wiz writeup to HN with the framing 'AI uncovers critical RCE in PHP,' the submitter amplifies the narrative that the discovery methodology — not the bug itself — is the headline. The 407-point score suggests the community reads this as a notable inflection point for automated vulnerability research.
The editorial emphasizes that the operational urgency comes from PHP's defaults: session.upload_progress.enabled=1 has been shipping in php.ini for over a decade, meaning operators who have never heard of the feature are still exposed. The argument is that the AI-discovery angle is interesting but secondary to the fact that a pre-auth RCE primitive has been quietly listening on a double-digit percentage of the public web.
The editorial explicitly notes that 'heap UAFs in C codebases are a weekly occurrence' and that what makes PHP2Shell notable is how it was found, not what was found. This frames the vulnerability itself as a predictable consequence of PHP core still being written in C, with memory-safety bugs being an ongoing baseline rather than a surprise.
Wiz's research team published PHP2Shell, a writeup of a critical remote code execution bug in PHP itself — not a framework, not an extension, but the core engine that still runs a double-digit percentage of the public web. The vulnerability is a heap use-after-free in the `session.upload_progress` code path, a feature that's been quietly enabled by default in `php.ini` for over a decade. By uploading a multipart form that triggers the progress tracker and racing session serialization, an attacker can get a dangling pointer onto the heap, groom it, and turn it into arbitrary code execution inside the PHP worker.
What makes this notable isn't the bug class — heap UAFs in C codebases are a weekly occurrence — it's how it was found. Wiz ran an AI agent harness over the PHP source tree, letting the model propose suspicious lifetime patterns, write targeted fuzz harnesses, triage the crashes, and iterate until it had a working proof-of-concept. The team is positioning this as the first widely-publicized critical CVE in a tier-one open source project discovered end-to-end by an LLM-driven pipeline rather than a human auditor using LLM assistance.
Upstream PHP shipped fixes across the supported branches. The affected versions span the currently maintained lines — 8.1 is on security-only support through the end of 2025, 8.2 is in active bugfix support until December 2025 and then security-only through December 2026, 8.3 is in active support, and 8.4 is the current GA. Point releases with the patch are available on php.net; distro packages are rolling out.
The immediate operational story is boring and urgent: if you run PHP anywhere a client can POST to it, you have a pre-auth RCE primitive sitting in the default configuration until you patch. `session.upload_progress.enabled` defaults to `1`. You don't have to use it. You don't have to know it exists. It's listening. The exploit doesn't need authentication, doesn't need a valid session, and doesn't need the application to call any particular API — it only needs the request to reach `php-fpm` or `mod_php`. That's WordPress, Laravel, Symfony, Magento, MediaWiki, Nextcloud, and roughly half the long tail of the internet.
The deeper story is the methodology. For twenty years the PHP core has been one of the most-stared-at pieces of C code on earth. It has had full-time security researchers, bug bounty programs, dedicated fuzzing infrastructure at Google (OSS-Fuzz has been grinding on it since 2017), and an adversarial community that will absolutely publish an 0-day for clout. The idea that a UAF in a default-on feature survived that gauntlet, and then fell to an agent loop that a small team put together, says something uncomfortable about where the frontier of vuln research is going.
This is the first high-signal data point that AI-driven vulnerability discovery has crossed from "found a trivial bug in a toy codebase" to "found a critical, exploitable, pre-auth RCE in production infrastructure." Google's Big Sleep agent flagged a stack buffer underflow in SQLite last year; Project Naptime has posted a steady drumbeat of smaller finds. PHP2Shell is a step up in impact. Expect every major cloud security vendor to have a near-identical pipeline running against OpenSSL, nginx, Redis, Postgres, systemd, and the Linux kernel by Q1 — some of them already do, they just haven't shipped a writeup yet.
For defenders, the economics shift in both directions. Finding bugs gets cheaper, which is good when it's your side running the agent and bad when it's the other side. The gap between "CVE assigned" and "public exploit" is going to compress because the same tooling that found the bug can also draft the exploit. For maintainers, the pressure to actually run these agents in-house — before someone else does and sells the result — just became hard to ignore.
Patch today. Don't batch this into your Thursday maintenance window. The fix is a point release on each supported line — `apt upgrade php8.x` or the equivalent, restart `php-fpm`, done — and the exploit requirements are low enough that mass scanning will start within hours of the technical writeup circulating. If you're on an unsupported branch (anything 8.0 or earlier), you're not getting a patch; the only answer is to upgrade the major line or set `session.upload_progress.enabled = 0` in `php.ini` and restart. That mitigation also works as a stopgap on patched versions if you can't ship an update immediately — it costs you nothing unless you have an app that actively reads the progress key, which almost nothing does.
Audit your edge. If you have a WAF, add a rule that drops multipart requests with a `PHP_SESSION_UPLOAD_PROGRESS` field until you've confirmed the patch is deployed everywhere. If you run shared hosting or a multi-tenant platform, assume at least one tenant is behind on patches and treat the worker pool as the trust boundary. Container images pinned to a specific PHP tag need a rebuild; `FROM php:8.3-fpm` without a digest will pull the fixed version on next build, but anything using a pinned digest or a vendored base image is still vulnerable until you bump it.
Longer term, this is a nudge to actually look at what's enabled by default in your language runtime. `session.upload_progress`, `expose_php`, `allow_url_include`, `enable_dl` — the list of PHP ini settings that are on by default and almost nobody uses is long, and each one is attack surface. The same audit applies to Node (`--experimental-*` flags that leaked into production), Python (`pickle` in web paths), and the JVM's serialization defaults. Default-on features in mature runtimes are where the next decade of agent-found bugs will live.
The interesting question isn't whether AI will find more CVEs — it will, and fast. The question is what the disclosure cycle looks like when a research team can go from "point the agent at a repo" to "working PoC" in a week. Coordinated disclosure assumes a human-paced attacker; agent-paced attackers compress that window hard. Expect maintainers of foundational open source — PHP, OpenSSL, curl, the kernel — to start publishing their own agent findings pre-emptively, if only to drain the pool before someone less friendly does. PHP2Shell is the opening shot. Patch your servers, then update your threat model.
Can anyone explain the two month window between reporting and disclosure? I do understand Responsible Disclosure as a concept, but looking at the timeline and severity, I struggle to understand the timing, especially the month that passed before an acknowledgment.Edit: Apparently this had been repor
Ok, based on my reads on Wiz and Calif writeups, there are 5-6 issues mapped to 2 CVEs.Wiz (with GPT 5.6 Sol + Gemini 4 Argon) : Remote process-memory disclosure; OPcache type confusion; Fatal-error backtrace UAF. POC on Wordpress, Drupal and JoomlaCalif (with LLM, no specific model, but model is ac
Seems to have been prompted from research by calif.io who started disclosure on August 11 vs Wiz on August 24th? A bit unclear on the participants and how they all interacted... https://calif.io/php2shell/
From the related article on calif.io:> We therefore control where PHP places a pointer and its associated type information. This is application-dependent RCE under both Apache mod_php and PHP-FPM.Both articles describe how you can end up with freed memory that still has pointers into it. I can un
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
So from what I gather, it was found by OpenAI (via unspecified model?) and independently by Wiz (via Gemini Argon)… but before that it was found by Calif (via unspecified but consumer-available model)… but Calif credit LCFR_HAX before them with first discovery, disclosure, and remediation efforts.I