PHP2Shell: Gemini 4 Argon and GPT-5.6 Sol Uncovered the Massive Security Flaw
Set Trending Topics as a preferred source on Google.
When universities, chambers of commerce and corporations all pull their websites offline at once, something big is usually going on: Two critical vulnerabilities in the PHP programming language took numerous websites in Austria and around the world offline on Wednesday. Known as PHP2Shell, the flaws allow attackers to run code remotely on web servers without logging in. A.I. played a part in finding them.
Why the Flaws Are So Dangerous
According to the security company Wiz, PHP runs on about 70 percent of all websites worldwide, including those built with WordPress, Drupal and Joomla. The two flaws (CVE-2026-109618 and CVE-2026-109619) sit in the core of the language, specifically in its memory management. If a request hits the memory limit or triggers a fatal error at the wrong moment, internal data is left in a broken state. A later request to the same server process can exploit that state and, in the worst case, execute arbitrary code. According to CERT.at, Austria’s computer emergency response team, every PHP installation that processes web requests is affected.
Wiz says the bugs have been in the code for more than a decade and affect practically every version back to PHP 5.4. They are fixed in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. There are no official patches for older versions. The PHP Foundation rates the severity at 9.2 out of 10 and says the score of 10 circulating online is wrong.
Universities, Corporations and Chambers Offline
In Austria, numerous organizations took their sites offline as a precaution. According to the Austrian outlets oe24 and MeinBezirk, those affected included the University of Vienna with its Moodle, webmail and u:cloud services, the Vienna University of Economics and Business, TU Wien, BOKU, the Medical University of Vienna and Johannes Kepler University Linz, as well as voestalpine, Novomatic, the Burgenland state portal, the Chamber of Labor, the Austrian Economic Chamber, the automobile club ÖAMTC and the press release service APA-OTS. Over the course of the evening, the first sites came back online after the update.
How Anexia Responded
The Austrian cloud and hosting provider Anexia, based in Carinthia, took a drastic step. In the morning, the company informed customers about the flaws on its status page and prepared hardening measures. In the early afternoon, it decided to take all managed services running PHP completely offline as a precaution at 3:45 p.m. local time, a quarter of an hour before the patch was released. Anexia said the known workarounds did not provide effective protection and that it expected a working exploit to be in circulation right after the patch. Requests during this period were dropped, while data and configurations remained unchanged, according to Anexia.
After the release at 4 p.m., Anexia rolled out the new versions and gradually brought systems back online after checking them. About two-thirds of the affected systems were running again by early evening, and the Anexia Engine customer portal was fully available. Older PHP and operating system versions need fixes backported from long-term support sources, which takes longer. Anexia is contacting customers for whom no fix is available individually. Customers who manage their own servers should update immediately or keep PHP offline until then, Anexia said.
Found With Gemini and GPT
Several teams discovered the flaws independently. The security company Wiz found the first vulnerability in August with its A.I. tool Atlas, which relies on Google’s Gemini 4 Argon and OpenAI’s GPT-5.6 Sol, among others. A few days later, Wiz used it to take over Drupal and WordPress websites without logging in. According to Wiz, A.I. mainly sped up the tedious work of adapting the exploits to different PHP versions and configurations. A single researcher accomplished in a week what would previously have taken a team months, the company said.
Independently, the security start-up Calif and OpenAI itself had reported the same root cause to the PHP team a few days earlier. A developer at the PHP Foundation had even spotted a first sign of the problem in 2024 during an external security audit, but found no concrete attack path at the time.
The PHP Foundation Admits Mistakes
The PHP Foundation is being unusually candid about the incident. The fact that the flaw had been known since 2024 and that the fix stalled for months was a structural failure, the foundation wrote in a detailed blog post. It blamed the security team’s decision-making process and a lack of resources, adding that there are simply too few experienced engineers who know the entire PHP codebase.
The release itself was chaotic as well. The CVE numbers, along with an incorrect severity score, leaked online the day before, prompting the PHP project to move the release forward by a day. That evening, Calif accidentally published a video of its proof of concept, and the vendor Chainguard distributed patched container images before the embargo lifted. According to the PHP security team, however, no working public exploits were known at the time of the release.
In response, the foundation is expanding its security work. It set up a dedicated Ecosystem Security Team in May, and since the summer, additional paid developers have been handling security reports and hardening. The security team will make decisions by majority in the future, and leadership will be brought in earlier on serious cases. The PHP Foundation is also calling on companies, hosting providers and public institutions to support the work financially. Its most important message, though, is simpler: Anyone running PHP needs to update now.
