On October 21, 2026, the PHP Foundation released emergency fixes for two critical flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619. The security world is calling them PHP2Shell. Both score 9.2 out of 10. Both let an attacker run code on a web server without logging in. And both were found with the help of AI.
totallab.com runs on WordPress, and WordPress runs on PHP. Our server was on the fixed PHP release by 18:30 UK time on October 21, and we checked it for signs of attack. We found none.
Patching closes this hole. It does not close the next one. So we are removing PHP from our public website altogether and moving the site to a static build served from infrastructure we have control over. Here is what happened, why we made that call, and what it means for the software in your lab.
On this page
What PHP2Shell is
PHP is the language behind about 70% of the world’s websites, including every WordPress, Drupal and Joomla site. PHP2Shell is a family of memory-safety bugs in the PHP engine itself, not in any one website’s code.
The flaws sit in how PHP cleans up after a fatal error. When an out-of-memory error cuts a request short, PHP can leave pointers to memory it has already freed. The next request handled by the same worker can then read that memory or corrupt it.
That gives an attacker two routes. The first is remote code execution with no password and no account. The second is a quiet read of the server’s working memory, which can hold passwords, session tokens and API keys belonging to other visitors.
Wiz Research demonstrated working, unauthenticated attacks against the latest WordPress, Drupal and Joomla releases. Because the bug lives below the application, even a one-line “Hello World” page on an unpatched server is exposed. Every PHP release going back to version 5.4, more than a decade of releases, carries at least one of the flaws.
The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older may never receive a fix.
The official response was unusual. The US National Security Agency told organizations to patch PHP or take affected systems offline. Authorities in Belgium, the Netherlands, Finland and the Czech Republic shut down websites while they applied the patch.
Why AI changes the risk
The vulnerable code had been in PHP for more than ten years. PHP is one of the most heavily reviewed codebases on the internet. What changed this year was the tooling.
Three teams found parts of the problem, and all three used frontier AI models. Calif, a California AI red-teaming firm, found the first piece with help from an OpenAI model. Wiz Research found further bugs in August using Google’s Gemini 4 Argon and OpenAI’s GPT-5.6 Sol. OpenAI then brought the PHP maintainers, the researchers and the major hosting and cloud providers together to build and verify one coordinated fix.
Turning these flaws into a working attack meant chaining several bugs and adapting to each server’s memory layout, a job Wiz describes as at the edge of what human researchers could manage. With AI, one of their researchers did in a week what they estimate would have taken a world-class team months. Wiz calls it “an AI inflection point.”
We agree, and we think the lesson is simple. Complexity no longer protects anyone. A flaw that is too fiddly to exploit today should be treated as exploitable tomorrow. Within hours of the patch, a user on X claimed a working proof-of-concept. At the time of writing, no attacks in the wild had been reported. Nobody should count on that grace period next time.
What we did, step by step
October 20. The PHP Foundation posted advance notice of a critical security release. We confirmed which PHP version totallab.com runs and what else on our server depends on it.
October 21, 14:00 UTC. The patched PHP releases went public. Our server was running PHP 8.2.35 by 18:30 UK time.
October 21 to 22. We reviewed our server logs for the warning signs Wiz published: unusual multipart upload requests followed by memory-limit errors, bursts of HTTP 500 responses, oversized session cookies and unexplained PHP worker restarts. We found no indicators of compromise.
October 22. We decided that patching was not enough, and began moving the public website off PHP entirely.
Why we are moving off PHP
totallab.com publishes product pages, scientific guides and free lab calculators. None of that needs a programming language running on our server every time someone opens a page. Yet today, every page view starts PHP, a WordPress installation, a database and multiple plugins. Each one is code we did not write and have to trust.
We will host it ourselves. That puts patching, logging and access control in our hands rather than a shared hosting platform’s.
A static site still runs a web server, and we will keep that patched. But PHP2Shell, and every future flaw like it in PHP or a WordPress plugin, will have nothing on our site to attack. We expect the move to be complete within the next few weeks.
Is your TotalLab software affected?
No. TotalLab’s analysis software, including Phoretix 1D, SameSpots, SpotMap 2D, SpotMap MS and AuditSafe, is desktop software that does not contain or depend on PHP. Your installed software, your data and your licenses are unaffected, and you do not need to do anything.
We do not store any customer analysis data on totallab.com.
What this means for the software you rely on
PHP2Shell is a reminder that most software is assembled from components its vendor did not write. A lab’s risk sits as much in those components as in the vendor’s own code. It is worth asking each of your software suppliers:
- Do you know every third-party component inside the software you supply us?
- When a flaw like PHP2Shell is announced, how fast can you tell us whether we are affected?
- Who in your company makes that call?
In the EU, those questions now carry legal weight. Since September 11, 2026, the Cyber Resilience Act has required manufacturers of software and connected products to report actively exploited vulnerabilities, including those in third-party components built into their products. The deadlines are tight: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days of a fix becoming available.
Labs also run plenty of quiet PHP: instrument web interfaces, sample-tracking portals, intranet tools written years ago by someone who has since left. If any of those run PHP 8.1 or older, a fix may never come.
This is our daily work. We build 21 CFR Part 11 and GMP software for regulated labs, OEM software that ships inside other companies’ instruments, and Cyber Resilience Act compliance programs for manufacturers. We publish a security contact for coordinated vulnerability reports at security.totallab.com. We keep a full inventory of the third-party components in every product we ship, so when a flaw is announced we can tell customers within hours whether they are affected.
If your lab or your instrument depends on software and nobody can tell you what is inside it, ask us. If it is old and nobody wants to touch it, we also modernize legacy lab software without disrupting validated workflows.
FAQ
Was totallab.com hacked?
No. Our server was running the patched PHP release by 18:30 UK time on October 21, 2026, and our log review found no sign of attack.
Do TotalLab products use PHP?
No. TotalLab’s analysis products are desktop applications that do not contain or depend on PHP. No action is needed by customers.
What is PHP2Shell?
PHP2Shell is the name for two critical vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619, disclosed and patched on October 21, 2026. Both are rated 9.2 under CVSS v4.0 and can let an attacker run code on a web server without logging in, or read sensitive data from server memory.
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older may not receive a fix, so systems on those versions need an upgrade plan.
Are WordPress sites affected by PHP2Shell?
Yes, if the server runs an unpatched version of PHP. The flaw is in PHP itself, so updating WordPress or its plugins does not fix it. The PHP installation on the server must be updated.
Was PHP2Shell really found by AI?
AI did much of the heavy lifting. Calif, Wiz Research and OpenAI all used frontier AI models to find the flaws and build working exploits, which is why code that had survived more than a decade of human review fell so quickly.
Does the Cyber Resilience Act apply to PHP2Shell?
The CRA’s reporting rules apply when a vulnerability in a product, including one in a third-party component it contains, is actively exploited. Those rules have been in force since September 11, 2026. Manufacturers whose products include PHP should check whether they are affected now, so they can meet the 24-hour early-warning deadline if exploitation is confirmed.
Is your lab software as safe as you think?
Tell us what your software does and what it runs on. Within two working days, our developers will tell you what we would check, what we would fix, and whether it is worth replacing.
References
- Wiz Research. PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet. October 21, 2026.
- University of Washington IT. Critical PHP vulnerabilities (Oct 2026).
- CNN. Websites shut down globally after AI finds a critical flaw affecting 70% of the internet. October 21, 2026.
- Al Jazeera. World leaders warn of security flaws found in PHP programming language. October 22, 2026.
- Fortune. AI tools discovered the PHP vulnerability that could take down 70% of the internet. October 21, 2026.
- Sophos Counter Threat Unit. Proof-of-concept exploit released for PHP vulnerabilities. October 21, 2026.
- SiteGround. SiteGround moves early to protect customers ahead of critical PHP security release. October 21, 2026.
- Penningtons Manches Cooper. EU Cyber Resilience Act: new reporting obligations in force. 2026.
- National Cyber Security Centre Ireland. EU Cyber Resilience Act.
