We analyzed this claim: is it true that
internet attackers can reliably take over ordinary websites through recently uncovered PHP software flaws?

security researchers proved they can beat standard memory defenses in test labs, but forensic reviews have found no confirmed break-in on a live website
Flaws Crack Defenses, but Breaches Remain Unproven
Lab tests showed ways past standard website defenses, yet no real-world victims have emerged.
The story continues

Trail of Bits breaks four major web platforms
27 October 2026A research firm showed how unpatched code could give intruders full control of common internet systems.
In a nutshell
Two critical security flaws in PHP, the computer engine powering millions of websites, can allow unauthorized outsiders to bypass standard memory shields and run commands on unpatched servers. Independent researchers successfully defeated everyday operating system defenses on controlled test machines across major processor types, and official software updates were released to close the gap. While automated scanners and failed attack attempts have swept across the internet, investigators have found no confirmed case of an actual live website being compromised.
Highlights
- PHP released emergency updates on October 21, 2026, for two critical vulnerabilities officially rated at 9.2 out of 10.
- Researchers bypassed ASLR memory randomization shields on test servers running standard production configurations across both AMD64 and ARM64 processors.
- Cybersecurity firm Sophos formally retracted an alert that claimed a customer had been breached, clarifying that the incident was an unsuccessful delivery attempt.
- As of October 24, 2026, no live website has been independently confirmed as compromised by the PHP2Shell flaws.
From the Editor’s Diary
A severe software flaw proved in a laboratory creates an urgent risk, but turning that method into a reliable weapon against diverse real-world systems takes time. Website operators have a genuine window to patch their machines before attackers solve the engineering challenges of a live break-in.
Who's involved
PHP Foundation and PHP security team
the non-profit group and volunteer engineers who maintain the PHP website language
goal → repair the software flaws, release safety patches, and coordinate disclosures before attackers exploit servers
VulnCheck
a United States cybersecurity company that studies how attacks work and provides threat intelligence to clients
goal → test whether attacks can defeat everyday server defenses and document working exploit methods
Calif Research and Ryan Austin
a computer security testing firm and its lead investigator who uncovered the flaws
goal → demonstrate the memory flaws to software maintainers so developers can fix them safely
CovertSwarm and Pablo Sanchez
a cybersecurity testing firm and its lead analyst who tested attacks on alternative processor chips
goal → demonstrate whether servers using modern ARM processor chips remain vulnerable even with standard defenses switched on
Wiz Research
a cloud defense research team that tracks online vulnerabilities
goal → verify whether popular website platforms such as WordPress and Drupal can be compromised through the bugs
OpenAI Codex Security
an artificial intelligence research group investigating software flaws
goal → help locate the underlying programming mistakes and coordinate emergency software repairs
Unidentified scanners and exploit operators
automated computer programs and online actors scanning the public internet
goal → locate unpatched web servers and attempt to plant malicious software
Amazon Threat Intelligence, Sophos and other defenders
corporate engineering teams monitoring internet traffic and customer systems
goal → spot suspicious web traffic, block unauthorized intrusions, and determine whether attacks actually succeed
In short
Millions of websites rely on a background programming language called PHP, and security researchers have now shown they can slip past the standard memory defenses meant to keep those servers safe. This matters because an intruder could theoretically take over a website without needing a password or an account.
The most likely next step is a race between website operators updating their systems and attackers trying to turn these lab methods into working online break-ins.
Whether widespread break-ins actually occur remains uncertain, largely because building an attack that works reliably against every server setup is technically difficult, and no real-world breach has been verified so far.
How it unfolded
A hidden memory defect turns into a practical danger
Behind millions of everyday websites sits PHP, an engine that handles the hidden mechanics of loading web pages. During routine maintenance checks in 2024, software engineers noticed small memory glitches when servers ran short of room, but no one believed an outsider could use them to seize control. That changed on August 1, 2026, when Calif researcher Ryan Austin uncovered a practical path to hijack a computer through those exact mistakes. Ten days later, Calif privately notified PHP's core maintainers, while an OpenAI research team independently reported the same root flaw on that same day. Calif sent a working digital demonstration on August 14, and PHP verified the hazard on August 15. The findings stayed quiet so engineers could build repairs away from public view.
Quiet lab tests reveal risks for popular publishing tools
Calif's warning turned a minor housekeeping defect into an urgent priority. Software maintainers recognized that an anonymous visitor could send a crafted web request and trick a server into running foreign commands. Soon, other teams joined the inquiry. Wiz showed that test installations of Drupal and WordPress, two common publishing platforms used to run blogs and company portals, could be triggered remotely in controlled conditions. Maintainers separated the trouble into two technical defects: one where memory state broke after a system ran out of room, and another where the computer continued using memory space it had already discarded. Both discoveries showed an attack was theoretically possible, but all tests remained confined to private research laboratories, with no signs of real websites being touched. Millions of web addresses still depended on the underlying code as developers worked on a silent fix.
Early leaks shatter the coordinated repair timetable
The plan to repair the world's web servers in secret came apart days before the official release date. On October 17, decoy sensors operated by Amazon logged an unusual probe that appeared to test the weakness from an anonymous network. By October 20, identification codes for the two flaws were leaking across discussion boards alongside exaggerated severity ratings. Facing mounting rumors, the PHP Foundation moved its public announcement forward by twenty-four hours to October 21. Minutes later, Calif accidentally published a video demonstration that was quickly copied across the web before staff could pull it down. Cybersecurity firm VulnCheck pieced together the clues that evening and recreated the flaw in its own lab, but beating everyday production defenses on standard server hardware remained an unsolved hurdle.
Official updates land as automated scanners comb the web
When official patches arrived on October 21, automated tools were already scouring the internet for vulnerable targets. Web traffic monitors at F5 and Amazon detected scanning passes hours before the planned release. An independent software distributor, Chainguard, had uploaded repaired files ahead of the formal embargo deadline, giving curious observers an early look at the internal fixes. The PHP team published cleaned updates across its four supported versions later that day. While opportunistic programs tried to deposit malicious command files onto internet-facing servers, security logs showed those early efforts misfired. Official security bulletins warned that servers running PHP through the Apache web server carried clear risks, but each hosting setup handled web traffic differently, meaning a method that rattled one server did not automatically crack another.
Engineers crack standard memory shields in test environments
The critical shift arrived on October 22, when commercial analysts found a way past the standard armor used by production computers. Operating systems normally employ address space layout randomization, or ASLR, a defensive measure that continually reshuffles memory locations so rogue programs cannot guess where critical instructions sit. VulnCheck announced it had bypassed that barrier on standard 64-bit Intel and AMD systems by tricking the server into leaking memory clues before executing commands, even with error messages turned off. At the same time, Shadow Labs verified code execution across three consecutive test runs against an isolated server. While web scanners were seen trying to plant rogue network bot programs, deeper inspections revealed that the real-world attempts failed. Cybersecurity vendor Sophos briefly announced that a customer had been breached, but retracted the notice hours later after finding only harmless scans and failed deliveries.
Lab methods expand across chip designs as live victims stay absent
By October 23, researchers proved the technique was not confined to a single type of computer chip. British security firm CovertSwarm demonstrated an exploit against an ARM64 server, a modern processor design common in cloud data centers, running PHP with memory shields active and error notices hidden. Meanwhile, independent programmer 9bie reported an attack method that worked ten times out of ten in a private test image simulating a working business website. Yet broader industry checks maintained strict boundaries between laboratory successes and the open web. Mandiant confirmed that public attack scripts worked against certain Apache server plugins but failed against the widely used PHP-FPM configuration, while European consultancy NVISO noted system crashes without any verified break-ins. The PHP Foundation confirmed that patched versions held firm and that no genuine live website had been confirmed compromised.
Where things stand
As of October 24, 2026, the core facts remain settled: security researchers have overcome standard memory randomization shields to run arbitrary computer code on vulnerable, unpatched PHP servers inside test facilities. Those demonstrations were verified by VulnCheck on common Intel, AMD, and ARM systems, and independently by CovertSwarm. However, every confirmed breakthrough has taken place inside isolated test setups or controlled vendor sandboxes. No named commercial website, bank, or online service has been independently confirmed as breached, stolen from, or infected with malware through these flaws.
The official software repairs published on October 21 continue to block the demonstrated attacks. In laboratory checks, patched updates reliably deflected the very commands that cracked earlier versions. What analysts are watching now is whether outside researchers can independently replicate VulnCheck's full matrix of methods, whether publicly circulating tools can be tuned to work on live systems, and whether genuine compromises emerge. Web administrators should install the updated PHP software releases, restart their servers, and check access logs for earlier signs of tampering, because an absence of confirmed victims today does not guarantee an unpatched machine is safe tomorrow.
PHP2Shell: the PHP security crisis

PHP emergency website patch faces unproven bypass fears
21 October 2026Online warnings claimed that a new fix for the programming language powering millions of websites had failed, but technical evidence shows no broken security update.
PHP fixes flaws rated 9.2 as exploit leaks drive early attacks
21 October 2026Millions of web servers face takeover risks after flaws leaked before fixes arrived.