Wednesday, October 21, 2026 will be remembered as one of the worst single days in internet security history — not because of one incident, but because four unrelated emergencies landed at once. Two critical vulnerabilities in PHP — the language behind a huge share of the web — were serious enough for security agencies to advise taking websites offline rather than leaving them unpatched. Node.js shipped emergency fixes for ten flaws, four of them high severity. A popular AI tool, LiteLLM, was found booby-trapped with credential-stealing malware. And an Indian certificate authority, eMudhra, turned out to have issued web-trust certificates whose private keys anyone could reconstruct in under a second — a cleanup security professionals quoted by Ars Technica called "bigger than Heartbleed." Here is what happened, who is affected, what the industry is doing about it, and exactly how to secure your own website.
At a glance: the four emergencies
| Incident | What happened | Fix / status |
|---|---|---|
| PHP RCE pair | Two critical flaws (CVE-2026-109618, CVE-2026-109619), CVSS 9.2, allow unauthenticated remote code execution on PHP web servers | Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 — released Oct 21 |
| Node.js flaws | Ten vulnerabilities; four high severity, including a Brotli-decoder flaw that permits remote code execution and two TLS certificate-check bypasses | Update to Node.js 26.12.1, 24.22.1 or 22.23.4, then restart |
| LiteLLM compromise | Version 1.107.0 on PyPI and its Docker images carried an infostealer and a remote access trojan stealing cloud and AI credentials | Malicious releases removed; anyone who installed in the window must rotate all credentials |
| eMudhra CA keys | Eight intermediate CA certificates had private keys so weak they can be recovered from the public certificate in under a second | Browsers blocked them Oct 17–20; eMudhra revoked them and is exiting the TLS business |
| GitLab RCE | CVE-2026-110264: unauthenticated remote code execution in self-managed GitLab CE/EE, scored CVSS 10.0 | Upgrade to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13 — no workaround |
| Railway breach | Unauthorised access to the customer environment-variable store; some stored secrets were decrypted | Rotate all environment variables and database credentials; Railway invalidated every API token |
| Plex2Shell | Four Plex Media Server flaws chained into unauthenticated code execution; actively exploited to install cryptominers | Update to Plex Media Server 1.43.3.10861 or later; in CISA KEV with Oct 23 / Nov 3 deadlines |
| SBI data exposure | State Bank of India identified 3,897 customer records with personal data among about 375,000 records found on the dark web | Bank investigating authenticity and source; balances reported safe; customers warned over phishing |
| OpenCode key exposure | OpenAI, Anthropic and Google API keys exposed for about 1.4% of OpenCode Console users in a distillation attack (disclosed Oct 17) | Revoke the keys in each provider's own dashboard, reissue, and set spend limits |
| Rajasthan Police claim | A hacker group claims 70,000 identity records and 59,460 mobile numbers are for sale | Unverified — no official comment or independent confirmation yet |
1. The PHP emergency: patch it or take it offline
The day's headline act was PHP. In a security advisory, the PHP project confirmed two critical vulnerabilities, both rated CVSS 9.2, that can let an unauthenticated attacker execute code on a web server — no login, no user interaction:
- CVE-2026-109618 — RCE via out-of-memory corruption. PHP's out-of-memory handling can interrupt a request while its internal data is only partially initialised; the cleanup code may then treat that invalid data as valid.
- CVE-2026-109619 — RCE via stale global state. Request-owned internal state can survive after its memory has been freed, and a later request on the same worker may use it before initialisation resets it.
According to TechCrunch's roundup, the flaws were discovered with AI assistance — researchers at Wiz noted the bugs had sat in the code for decades, but proving them exploitable required a chain of steps at the edge of human research, and frontier AI models lowered that barrier substantially. That is the uncomfortable new reality: AI is now finding — and weaponising — the bugs everyone else walked past.
The official response was unlike anything in recent memory. The U.S. National Security Agency advised organisations running PHP to update immediately or take their systems offline until they could. The EU's CERT-EU issued the same guidance, and the Australian Cyber Security Centre urged organisations to hunt down every PHP system in their estate. Government websites around the world went offline as a precaution, Reuters reported. Hosting giant GoDaddy warned customers the flaws could allow code execution over the internet, "potentially leading to data theft, website defacement or full system compromise." CERT-EU assessed that all PHP versions from PHP 5 onward could be affected.
"Effective Immediately, all organizations using PHP for their systems are advised to be prepared for an update addressing two critical vulnerabilities. PHP is widely used for web applications. These vulnerabilities often provide a direct path to the server's file system or…"
The NSA's cybersecurity directorate (@NSACyber) posted this advisory on X on October 21, 2026, as the PHP security releases landed.
2. Are all PHP frameworks affected? Yes — and here is why
This is the question every Laravel, WordPress and Symfony user asked first, and the honest answer is: yes, if the PHP underneath them is unpatched — the framework cannot save you. These flaws live in the PHP interpreter itself, below every framework and CMS. The PHP advisory states that all PHP installations serving web requests are at risk — PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed — with the risk highest for mod_php, where a demonstrated exploit triggers before any application code runs. In plain terms:
- Laravel, Symfony, CodeIgniter, CakePHP, Yii — affected through the runtime, not their own code.
- WordPress, Drupal, Joomla, Magento — same exposure; as Huntress put it, PHP "quietly powers WordPress, Drupal, Joomla, and Magento sites, shared hosting platforms, control panels, and an awful lot of software that doesn't even advertise that it runs PHP."
- Updating your framework, CMS or plugins does not fix this. Only updating PHP itself (or your host applying a backported patch) does.
- PHP 8.1 and older no longer receive fixes from the PHP project. The security team published minimal source backports for 7.4, 8.0 and 8.1 as an emergency courtesy, and some Linux distributions backport fixes into older packages — but if you are still running end-of-life PHP, this week is your deadline to upgrade.
3. Node.js: a Brotli RCE and broken TLS checks
The same day, the Node.js project shipped 26.12.1, 24.22.1 and 22.23.4, fixing ten vulnerabilities. The four high-severity ones:
| CVE | Flaw | Lines affected |
|---|---|---|
| CVE-2026-111497 | Out-of-bounds write in the Brotli decoder — permits remote code execution when a process decompresses attacker-controlled Brotli data | 22, 24, 26 |
| CVE-2026-106069 | TLS certificate hostname check can be bypassed when a host loosely resolves to an IP address | 22, 24, 26 |
| CVE-2026-105483 | TLS hostname bypass using IP addresses written in fullwidth digits | 24, 26 |
| CVE-2026-105482 | dns.resolve truncates names containing a NUL character | 22, 24, 26 |
Three medium and three low-severity fixes round out the release — and, notably, the same updates remove the compromised eMudhra intermediates from Node's bundled trust store. Two operational warnings: a running Node process keeps executing the old code until it is restarted, and end-of-life Node lines are affected but receive no fix. Don't forget software that bundles its own Node runtime, such as Electron apps.
4. LiteLLM: the AI tool that stole credentials
The third emergency was a supply-chain attack. Aikido's analysis shows that LiteLLM 1.107.0 — a widely used open-source proxy for routing requests across LLM providers — was published to PyPI with malicious code injected into its compiled wheels through a build-configuration trick (a data = "cook" directive in pyproject.toml that bundled files from a directory that exists only in the compromised build environment, never in the public source). The official Docker images were poisoned too. Anyone who installed the PyPI package between 11:39 and 12:47 UTC on October 21, or pulled the images (including via latest) between 11:46 and 14:20 UTC, got two payloads:
- An infostealer that runs at every Python startup and harvests browser passwords, SSH private keys, shell history, AWS/Azure/GCP credentials (including live instance-metadata credentials), Kubernetes tokens, CI/CD secrets, AI-developer-tool credentials — and the LiteLLM database itself, with every stored provider API key.
- A remote access trojan — a background daemon that checks in hourly through a GitHub-hosted dead drop and executes whatever code the attacker serves, indefinitely.
The response was fast: PyPI quarantined and removed 1.107.0, the images were pulled from Docker Hub and GHCR, GitHub took down the attacker's dead-drop repository, and LiteLLM confirmed containment and published remediation guidance. But removal is not recovery: anyone who installed during the window must treat every credential on that machine as stolen and rotate it — check for the tell-tale files /tmp/.pc_once_* and /tmp/remote_code_loader.lock.
5. eMudhra: the certificate keys anyone could guess
The fourth incident may prove the longest-lived. On October 17, an independent researcher ("Wayne") reported that eight intermediate CA certificates from Indian provider eMudhra — six for TLS, two for code signing — had been generated in an April 30, 2025 key ceremony with elliptic-curve private keys below the number 256 (one key was literally 4; the rest were zeros apart from a final byte). A private CA key is supposed to be an unguessable 384-bit secret; these could be reconstructed from the public certificate in under a second. Whoever holds such a key can mint trusted certificates for any website — or sign malware with a trusted publisher identity.
The giants moved within hours. Google pushed an emergency Chrome update blocking the TLS intermediates; Mozilla blocked them in Firefox the same day (October 17) and later removed eMudhra's emSign root; Apple followed on October 19 and Microsoft on October 20; Chrome's removal completes across devices by October 27. Sectigo revoked its cross-signed copies, Cloudflare updated its services, and the fix rippled into Go (1.26.10 / 1.27.3), Python's certifi bundle and the Node.js releases above. eMudhra revoked the eight certificates within 14 hours and maintains its infrastructure was never breached and the affected CAs issued no end-entity certificates; as of October 21, Certificate Transparency logs showed no confirmed abuse — although the keys sat recoverable for roughly 17 months, and clients that skip revocation and CT checks (API clients, containers, build pipelines, embedded devices) remain the exposed gap. The commercial verdict was still brutal: eMudhra announced it is exiting the TLS certificate business entirely, moving customers to other providers free of charge.
The rest of October 21: five more incidents from the same day
The four stories above were the ones with patches attached. They were not the whole day. Within the same 24 hours, a perfect-score GitLab flaw, a breach at deployment platform Railway, an actively exploited Plex exploit chain and a bank data exposure in India all landed — plus one large claim that remains unverified. Two of them connect directly to the LiteLLM story above: the target, again and again, was other people's AI API keys.
GitLab: a second CVSS 10.0 remote code execution flaw in nine days
On October 21 GitLab shipped emergency patches for CVE-2026-110264, an integer overflow in the regular expression engine bundled with GitLab Community and Enterprise editions that, under certain conditions, lets an unauthenticated attacker execute arbitrary code on a self-managed server. GitLab scored it 10.0, the maximum. Every version from 7.0 onward is affected; the fixes are 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13, and there is no workaround — upgrading is the only fix.
GitLab.com already runs the patched version, and GitLab Dedicated tenants on recent internal releases need do nothing. Everyone else should treat this as a tonight job, especially because patching nine days ago does not save you: the October 12 release that fixed a separate 10.0 flaw in the same regex toolkit (CVE-2026-97229, in the CI/CD regex compiler) sits below these new fixed versions, so an instance patched then is in range again now. GitLab reports no sign of exploitation so far, and the flaw is not in CISA's known-exploited catalog — this is a race you can still win by patching first. (The Hacker News)
Railway: environment variables accessed, every API token invalidated
Deployment platform Railway disclosed on October 21 that it had detected anomalous activity in the systems that store customer environment variables — the secrets apps run on: API keys, database credentials, registry logins. Its investigation indicates an unauthorised party may have accessed the encrypted variables and, for some of them, obtained the decrypted contents.
Railway paused builds and deployments platform-wide, invalidated OAuth sessions that evening, and by the early hours of October 22 had invalidated every Railway API token in existence. Its guidance to customers is blunt: rotate all environment variables and database credentials (PostgreSQL, MongoDB, Redis, MySQL), review service logs, and check usage on connected services — it specifically names OpenAI, Anthropic, xAI's Grok, OpenRouter, Stripe, GitHub, AWS and GCP. Railway says it believes the incident is part of a broader pattern of attacks on platform companies aimed at compromising AI inference provider keys, and that it has notified those upstream providers. If you host anything on Railway, act as if your secrets were exposed. (GitGuardian's incident summary)
Plex2Shell: an old patch, a new exploit chain, cryptominers in the wild
The clearest warning of the day came from home servers. Plex2Shell is the name given to four Plex Media Server flaws — CVE-2026-96652 and CVE-2026-96655 (server-side request forgery), CVE-2026-96654, and CVE-2026-96656 (external control of file name or path, scored 8.6) — which chained together give an unauthenticated attacker remote code execution and the server owner's admin token. The fix, Plex Media Server 1.43.3.10861, has been available since early August.
The researcher who found the flaws published a full write-up and proof of concept on October 16. Exploitation was observed the next day, against honeypots first, deploying the XMRig cryptominer and proxy software that routes strangers' traffic through the victim's connection. Shadowserver counts put nearly 49,000 vulnerable Plex servers exposed on the internet. On October 20 CISA added all four flaws to its Known Exploited Vulnerabilities catalog; federal agencies must remediate two of them by October 23 and the rest by November 3. Plex itself says the flaws are being actively and widely exploited. Update to 1.43.3.10861 or later — and if your server faced the internet on an older build, check for unfamiliar processes, unexpected outbound connections and unexplained high CPU. (The Hacker News)
SBI: India's largest bank reports customer data on the dark web
State Bank of India told the stock exchanges on October 21 that customer data had been found on the dark web. The bank was alerted on October 16 by its threat intelligence provider, the Defence Cyber Agency and CERT-In. Its preliminary analysis of roughly 375,000 records found online identified 3,897 customer records containing personal information: names, registered mobile numbers, dates of birth, gender, email addresses, residential addresses, branch and customer file identifiers, lead IDs and loan-related metadata.
SBI says balances are safe, core banking is unaffected and there is no material impact on operations, and it has engaged an independent CERT-In-empanelled agency to establish the authenticity, source and full extent of the exposure — which means the bank itself has not yet confirmed where the data came from. For customers, the practical risk is targeted phishing and impersonation: loan and address details make a fraudulent call or message sound genuine. Treat any unsolicited contact claiming to be the bank as hostile until you have verified it through the bank's own channels. (The Hindu BusinessLine)
OpenCode: the key theft that explains the pattern
Four days earlier, on October 17, OpenCode had disclosed the incident that ties the week's theme together. An attacker reached a legacy Console system the company was in the process of decommissioning, and provider API keys that users had saved in Console workspaces — OpenAI, Anthropic and Google keys among them — may have been exposed. OpenCode puts the affected share at about 1.4% of Console users, specifically those who had linked external providers; everyone affected was emailed, and the company says it is working with the three providers on remediation. OpenCode attributes the intrusion to a large-scale distillation attack: stolen keys used to run high-volume inference against victims' accounts, harvesting model outputs — and some users reported unauthorised charges before the disclosure. Keys added through the local CLI were not part of the incident. If you ever pasted a provider key into OpenCode Console, revoke it in the provider's own dashboard, issue a fresh one, and set a spend limit while you are there. (Cyera's incident write-up)
Rajasthan Police: a large claim, still unverified
One item on the day's board is a claim, not a confirmed incident, and we label it as such. A group calling itself Scarlettgroup says it breached Rajasthan Police and is offering the data for sale on a cybercrime forum: roughly 70,000 identity records, 59,460 mobile numbers and about 6.6 GB of attachments said to include eKYC documents, FIRs, witness statements, identity cards, salary slips and bank statements, with redacted samples posted as supposed proof. As of publication, Rajasthan Police has not commented and no independent verification of the claim exists. Threat actors exaggerate and fabricate listings often enough that this stays in the unproven column until the police or a forensic source confirms it — but if the samples prove genuine, the exposure of witness and investigation material would be among the most sensitive of the week. (Tezzbuzz)
Read together, October 21 had a shape: vulnerabilities are being found faster than teams can patch them, while AI API keys have become a currency worth breaching platforms to steal. The order of operations for the week is the same everywhere — patch the software, rotate the secrets, and revoke anything you cannot account for.
Which servers are affected?
| Your stack | Your exposure |
|---|---|
| Any PHP website | Every PHP version serving web requests; Apache mod_php carries the highest demonstrated risk, then PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. Shared hosting and control panels included. |
| PHP 8.1 or older | End of life — no upstream fix. Distro backport or emergency source backport only; plan an upgrade now. |
| Node.js servers & APIs | 22/24/26 lines before the Oct 21 releases; anything decompressing untrusted Brotli data, plus TLS clients of those runtimes; bundled runtimes (Electron) count too. |
| AI / Python infrastructure | Any machine or container that installed LiteLLM 1.107.0 in the Oct 21 windows — cloud VMs are the worst case because metadata credentials were targeted. |
| Anything trusting eMudhra | Browsers are patched; the risk concentrates in non-browser clients with stale trust stores that skip revocation checks. |
What is the estimated loss?
Here we have to be straight with you, because you will see dramatic numbers quoted elsewhere: no authority has published a verified total loss figure for October 21, and any precise dollar number circulating without a named source should not be trusted. What is documented so far is the shape of the damage: government and commercial websites voluntarily taken offline (with the downtime and emergency-patching labour that implies) across multiple countries; a credential-rotation bill for every organisation that touched the poisoned LiteLLM release; and one listed company — eMudhra — winding down an entire business line within days. The PHP flaws, meanwhile, were disclosed before confirmed exploitation (the ACSC said it was not aware of active exploitation at advisory time), which is precisely why the patch-or-offline order mattered: the cost was front-loaded into prevention. Expect insurer, vendor and government tallies to emerge over the coming weeks; we will update this article when a sourced figure exists.
How to secure your own website — the checklist
- Find your PHP version today (
php -v, your hosting panel, or your provider's status page). You need 8.5.12, 8.4.27, 8.3.36 or 8.2.35 — or proof of a vendor backport. Debian, Ubuntu and Red Hat backport fixes without changing the version number, so check the package changelog, not just the version string. - On shared hosting, ask your host directly whether the server's PHP has been patched or backported, and when. If they cannot answer, that silence is your answer — escalate or move.
- Restart after patching. PHP-FPM workers and web servers keep running old code in memory; a patch without a restart is not a patch. The same applies to Node.js processes.
- If you cannot patch today, apply the PHP team's partial mitigations — they reduce exposure but do not make you safe: set
memory_limit=-1at the server level (php_admin_value, so apps can't override it); keeppost_max_sizelow (8M without uploads, 32M with); disablesession.upload_progress.enabledand restart workers; on PHP 8.5 also setfatal_error_backtraces=0; enforce request-size and field-count limits at your proxy or WAF. For high-value sites, CERT-EU's advice stands: a short planned outage beats an unplanned breach. - Update Node.js and restart every process — including build tools, PM2/systemd services and anything with a bundled runtime.
- Audit LiteLLM. If version 1.107.0 was installed anywhere on October 21, assume compromise: rotate cloud keys, SSH keys, API keys and CI/CD secrets; check for
/tmp/.pc_once_*and/tmp/remote_code_loader.lock; follow LiteLLM's official remediation guidance. - Check your certificate chain. If your site's certificate chains to eMudhra/emSign (or a Sectigo cross-sign of it), reissue from another CA now. Keep server CA bundles updated, and add CAA records and Certificate Transparency monitoring so a bad certificate for your domain gets spotted in hours, not months.
- Close the standing gaps this week exposed: inventory every runtime you actually run (you cannot patch what you don't know exists), enable automatic security updates where safe, subscribe to the php.net and Node.js security lists, keep offline backups, and run PHP workers with least privilege so one flaw can't become a full-server compromise.
What a good host looks like this week: Hostinger told its customers it had already applied a security fix for their PHP version — no action needed on their part. If your host has not said the same about CVE-2026-109618 and CVE-2026-109619, ask them directly. (Referral link: we may earn a commission, at no extra cost to you.)
Frequently Asked Questions
Is every PHP framework really affected — Laravel, WordPress, all of them?
Yes, through the runtime. The two critical flaws are in the PHP interpreter, and the advisory covers all PHP installations serving web requests. Frameworks and CMSs inherit the exposure; only a PHP update (or a vendor backport) removes it. Updating WordPress or Laravel alone does not.
My host says my PHP version number didn't change. Am I patched?
Possibly. Major Linux distributions backport security fixes into the version they ship, so the number can stay the same while the flaw is fixed. Ask for the package changelog or the host's advisory reference — "trust, but verify" is the right posture this week.
Should I take my site offline if I can't patch immediately?
That is literally what the NSA and CERT-EU advised organisations to consider for systems they could not patch. For most shared-hosting customers the practical route is different: confirm your host has patched the fleet (reputable hosts did so within hours), and apply the partial mitigations above in the meantime.
I use LiteLLM but not version 1.107.0. Am I safe?
The malicious code was in 1.107.0's PyPI wheels and Docker/GHCR images during the October 21 windows. Other versions were not reported compromised — but confirm your installed version and pin, and rotate any credentials that were ever present on a machine that ran 1.107.0.
Does the eMudhra incident mean my browser is unsafe?
No — Chrome, Firefox, Safari and Edge all blocked the compromised intermediates between October 17 and 20 without you needing to do anything. The residual risk is in non-browser software with stale trust stores, which is an update-your-software problem, not a browsing problem.
Sources: PHP security advisory and releases · TechCrunch · Reuters · Aikido (LiteLLM analysis) · Node.js October 2026 security releases · SOCRadar and Palo Alto Unit42 (eMudhra) · Inc42 (eMudhra business exit). This article is a developing story; figures and statuses are as reported on October 21–22, 2026.
Be the first to share a useful question or thought.