Two critical PHP flaws let attackers run code on web servers without logging in. Here is what PHP2Shell is, who is affected, and what to ask your IT team this week.
On 21 October 2026, the PHP project released emergency fixes for two critical flaws that let an attacker run code on a web server without logging in. Within hours, government and public-sector websites across Europe had gone offline, many of them deliberately, so that teams could patch before attackers arrived. The flaws, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell, sit inside PHP itself. That makes this PHP vulnerability different from a typical application bug: well-written code does not protect you.
The PHP project's own site now lists the patched releases from the emergency security update.
PHP runs on 69.3% of websites whose server-side language is known, according to W3Techs figures cited by Tenable. For most businesses in India and the UAE, the question is therefore not whether PHP is somewhere in the estate, but where.
What Is the PHP2Shell Vulnerability?
PHP2Shell is a pair of bugs, both rated 9.2 on the CVSS v4.0 scale by PHP's own security team. CVE-2026-109618 is an out-of-memory flaw: if memory runs out while a request is only partly set up, later cleanup can treat that half-built data as valid. CVE-2026-109619 is a use-after-free, where leftover state from one request points to memory that a later request on the same worker can use.
Either one can lead to unauthenticated remote code execution. In plain terms, the server can be tricked into running instructions the attacker supplies, with no account and no stolen password. Memory can also leak from PHP worker processes, which may expose passwords, tokens and API keys. The US National Security Agency warned the flaw could "provide a direct path to the server's file system or database".
The flaw sits below your application code, so secure code alone is not enough.
According to The Hacker News, Wiz Research, Calif and OpenAI's Codex Security team found and reported the flaws. Calif says in a blog post that it found them with the help of a large language model on 1 August, and Wiz says they had stayed hidden in the PHP codebase for more than a decade.
Which PHP Versions Need the Security Update?
Nearly every version back to PHP 5.4 is affected, across PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP security update shipped on 21 October as versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
Older branches are harder. PHP 7.4 to 8.1 have no official release, only source backports, and the PHP project no longer maintains 8.1 or earlier. PHP 5.4 to 7.3 are end-of-life with no fix at all. Many Linux distributions also keep old-looking version numbers after patching, so check your vendor's changelog for the CVE identifiers rather than trusting the version string.
Which PHP versions are fixed, and which are not.
Who Has Been Affected So Far?
Most outages were precautionary. The Guardian reported that Belgian, Dutch, Finnish, French and German government sites were taken down temporarily, along with council websites in Edinburgh, Bristol and Oxford. In the Netherlands, the national digital identity service, the House of Representatives and the national cybersecurity centre's site all went offline. The Wikimedia Foundation pulled several systems until they could be patched, and the Australian Signals Directorate was briefly affected.
Governments that took sites offline as a precaution.
The threat is real. Amazon's security chief, CJ Moses, said a decoy system saw an attempt to exploit the flaws on 17 October, four days before public disclosure. The UK's National Cyber Security Centre told organisations to check for "backdoors installed by an attacker". Because AI tools can reverse-engineer a public fix with little effort, Costin Raiu of TLP:Black described it as a "race to exploit".
Prof Alan Woodward of Surrey University is most worried about "a long tail of websites who may not be maintained as well", which could stay vulnerable for weeks or months. That includes the small business site built years ago and never touched since.
What to Do Now
Updating is the only complete fix, so patch PHP first and restart all workers afterwards. If you cannot do it today, PHP suggests interim steps: set memory_limit to -1 in a way applications cannot override, switch off session upload progress, and keep request sizes low at the proxy. The NSA's advice for anyone who cannot patch immediately is to take the system offline. Cloudflare has deployed firewall rules for known attack paths, but it calls them a stopgap.
WordPress, which the Guardian notes also runs on PHP, falls under the same advice, so ask your hosting provider or agency to confirm in writing that the patched runtime is live. After updating, look for signs of earlier compromise: unusual multipart requests followed by memory-limit errors, repeated HTTP 500 responses and unexplained worker restarts.
A first-day response plan for IT teams.
Frameworks do not change any of this. Teams that build on PHP frameworks such as Laravel, as we did for the Dr.Today doctor and lab booking platform, should treat the runtime as part of the product. The code on top can be flawless and still sit on a vulnerable foundation.
Questions Leaders Should Ask This Week
You do not need to read a CVE to act on this. Ask your IT head or vendor where PHP runs in the business: the public website, customer portals, plugins attached to your ERP or CRM, and anything hosted by a third party. Ask which versions are live, who owns patching, and how quickly an urgent update can reach production. Ask whether anything is still running a branch the PHP project no longer supports. A short written answer within a day is a reasonable request.
Ask about your suppliers too. The agency that built and hosts your website, software tools with PHP underneath, and payment or logistics partners with public portals may all be exposed. Request written confirmation of each one's patch status and keep the replies on file.
It is also a good moment to revisit the basics of keeping applications secure over time. AaiNova's guide to mobile app security best practices for enterprises covers the habits that keep business apps and their back ends in good shape.
Why This Is a Signal Problem
Most leadership teams will have learnt about PHP2Shell from the news, not from their own systems. A runtime version on a forgotten server never shows up in a revenue report, yet it carries real financial risk. The same blind spot appears elsewhere in a company: a proposal untouched for weeks, an invoice 46 days overdue, a key employee whose output suddenly drops. Each is a signal that someone senior should see before it becomes a loss.
This is the idea behind AaiNova's Enterprise AI Tower. It reads the data already sitting in your CRM, ERP and other systems and turns it into signals for CXOs across revenue, cash, operations and people, each paired with a recommended action that runs only after approval. A risk such as an internet-facing application on an unsupported runtime is exactly the kind of signal a dashboard like this can be set up to raise.
Security is only one department. In revenue, a proposal sitting 20 days without a follow-up, or a prospect with a record of paying late, is a signal. In cash, an invoice 55 days past due on a large account is another. In operations, customs clearance running at 2.3 times its usual time, or a won deal with no activity for 48 days, points to stalled delivery. In people, a strong performer whose output suddenly drops may be about to leave. In technology, an unsupported PHP version on a public site, or a vendor who has not confirmed a patch, belongs on the same screen. The value lies in seeing all of these in one place, ranked by severity, with a named owner for each.
The kind of signal leadership should see before it becomes a loss.
Final Thoughts
PHP2Shell is a serious PHP vulnerability with a clear fix, and the organisations that moved first lost the least. Patch what you can today, isolate what you cannot, and make sure the next warning of this kind reaches decision-makers from inside the company rather than from a news alert.
Not Sure Where Your Exposure Sits?
If you want an independent view of your applications, our security testing services can help you find weak points before attackers do. Contact AaiNova and we will help you plan the next step.
by Karan Saxena 
