PHP2Shell, Node.js and LiteLLM: October 2026 Security Patch Guide

Updated October 24, 2026. This week brought several very different security emergencies: two critical flaws in PHP, a high-severity Node.js update, a malicious LiteLLM release distributed through PyPI and Docker, and a certificate-authority compromise that prompted fixes across multiple programming ecosystems. They are not one combined attack, and the correct response depends on the software you actually run.

Here is what is confirmed, which versions to use, and what website owners, backend teams and infrastructure operators should do next. Version numbers reflect official releases available as of the date above; where a Linux distributor or runtime vendor backports patches, check that vendor's security notice rather than judging by the upstream version string alone.

The short version: what needs attention?

Issue

Who should check?

Immediate action

PHP2Shell: CVE-2026-109618 and CVE-2026-109619

Anyone serving web requests with PHP, including CMS and embedded runtimes

Install the October 21 PHP security release for your supported branch

Node.js October security update

Node.js 22.x, 24.x and 26.x deployments

Upgrade to the patched point release, test, rebuild and redeploy

LiteLLM 1.107.0 supply-chain compromise

Teams that installed the affected Python package or pulled affected images on October 21

Investigate exposure; rebuild clean environments and rotate reachable secrets

eMudhra / emSign certificate incident

Browser clients, API clients, container images, Python and Go services, and certificate operators

Refresh affected trust stores, runtimes and certificates where relevant

Oracle's October Java security updates

Teams running Oracle Java or Oracle products

Apply the vendor patch for the exact product and supported release line

1. PHP2Shell: why so many websites went offline

On October 21, the PHP project released emergency patches for CVE-2026-109618 and CVE-2026-109619. Both were rated 9.2 under CVSS 4.0. In vulnerable web-facing PHP deployments, exploitation can lead to remote code execution without authentication. The first flaw involves memory corruption during out-of-memory handling; the second involves stale request state that can be reused after its memory is freed.

This matters even if your team never writes PHP directly. WordPress, Drupal, Joomla, plugins, appliances and managed hosting products can run PHP underneath. The PHP team explicitly identified PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed as affected web-serving configurations. Exposure and exploitability still depend on the environment; being on a vulnerable version is not proof of a successful breach.

PHP patched versions released October 21

PHP branch

Security-fixed version

8.5

8.5.12 or newer maintained patch

8.4

8.4.27 or newer maintained patch

8.3

8.3.36 or newer maintained patch

8.2

8.2.35 or newer maintained patch

PHP 8.1 and older are upstream end-of-life. Some operating-system and extended-support vendors offer backports, and PHP published minimal source backports for certain old branches. Those are special remediation paths, not a reason to continue running unsupported software indefinitely.

Several organizations took websites offline as a precaution while they investigated or patched, including the Netherlands' NCSC. That distinction matters: precautionary downtime, exploitation attempts, a publicly available proof of concept, and a confirmed intrusion are four different claims. On October 23, NCSC-NL said exploitation was more complex than initially expected and that a reported successful exploit abroad remained unconfirmed in its assessment. The advice was still to patch immediately.

Official guidance: PHP security notices, CERT-EU advisory and NCSC-NL's October 23 update.

A third PHP advisory appeared on October 23

PHP also disclosed CVE-2026-115560, a separate, much narrower potential RCE issue tied to an unusual combination of session serialization settings and application code. The PHP project said it would fix this in its next regular bugfix release, rather than issue another emergency build. If your application relies on session upload progress, review the exact conditions in the October 23 PHP advisory. Its suggested temporary protection is session.upload_progress.enabled=0 until that fix lands. This is not a replacement for the October 21 PHP2Shell patches.

2. Node.js also received serious security fixes

Node.js shipped security releases on October 21, 2026. The most striking fix, CVE-2026-111497, concerns an out-of-bounds write in the bundled Brotli decoder. Applications that decompress attacker-controlled Brotli data through node:zlib may face crashes, memory disclosure or even remote code execution. It does not mean every Node.js website can be remotely taken over without any application-specific conditions.

The same advisory covers other important bugs: CVE-2026-105482 can cause DNS resolution to truncate hostnames containing a NUL character, undermining applications that validate hostnames before resolving them; CVE-2026-105483 and CVE-2026-106069 concern TLS certificate/hostname checks in particular nonstandard IP representations. There are further HTTP and permission-related fixes in the official advisory.

Node.js patched versions

Release line

October 21 security release

Node.js 26.x

26.12.1

Node.js 24.x

24.22.1

Node.js 22.x

22.23.4

For production, remain on a supported Node.js line and install the latest maintained security patch for that line. Check the runtime inside your actual deployed process or container, not only the version installed on your laptop. Rebuild runtime images and redeploy after testing dependencies, TLS integrations, HTTP clients, and decompression paths. Read the complete Node.js October 21 security bulletin.

3. LiteLLM 1.107.0: a malicious release, not just a bug

On October 21, the LiteLLM maintainers confirmed their release pipeline had been compromised. The published litellm==1.107.0 PyPI wheels and certain official Docker image tags carried credential-stealing malware. The malicious code used Python startup hooks, meaning starting Python in an affected environment could trigger it without an application importing LiteLLM.

According to LiteLLM's incident report, the malicious PyPI release was available for roughly two hours on October 21. Affected Docker artifacts included v1.107.0 and floating tags such as latest, main-latest and main-stable during the documented compromise window. Those artifacts were subsequently removed or repointed. A clean tag visible today does not prove which image digest a machine pulled on October 21.

If you installed or ran the affected artifacts:

• Isolate the environment and preserve relevant evidence. Do not begin by running pip or Python inside a suspect installation: startup hooks may execute the malware again.

• Identify the exact installed wheel and container image digest, including cached CI and registry artifacts.

• Rebuild affected environments from trusted sources, using a verified clean, pinned release. The maintainer's initial incident guidance identifies LiteLLM 1.106.2 as a clean version for immediate recovery; also review their latest incident updates.

• Treat any credentials accessible to the affected process as potentially exposed, including AI-provider keys, cloud credentials, GitHub tokens, database passwords and CI secrets. Rotate or revoke them through a coordinated response.

• Review suspicious egress, persistence and account activity; simply uninstalling the package does not undo credential theft.

This is an especially useful reminder for AI infrastructure: a gateway that stores provider keys can become an attractive supply-chain target. Read LiteLLM's incident notice, its October 23 attack-chain report and Microsoft's technical analysis.

4. The eMudhra certificate incident affects more than browsers

On October 17, researchers reported that private keys for eight eMudhra intermediate certificate-authority certificates had been generated with inadequate randomness. Where clients still trust those intermediates, forged HTTPS certificates could be used to impersonate websites. Google says Chrome blocked the affected keys and coordinated further trust-store remediation; other software stacks with separate trust mechanisms may need their own fixes.

That helps explain why language projects released apparently unrelated security updates this week:

• Python: October 21 releases 3.15.1, 3.14.9 and 3.13.17 refresh their bundled pip to 26.2.2, which includes certifi 2026.10.19. Existing virtual environments do not automatically inherit every tooling update: follow the Python project's instructions for updating pip, uv and certificate bundles.

• Go: 1.27.3 and 1.26.10 include a crypto/x509 change to block chains involving specified intermediates (CVE-2026-111943). Since Go applications commonly include standard-library code in their binaries, rebuild and redeploy the binaries affected by the toolchain update.

• Node.js: the October 21 releases also update bundled CA certificates, along with other vulnerable dependencies.

• Website operators: if your site's certificates depend on the affected emSign ECC Root CA - G3 trust chain, consult your CA and arrange replacement. Google announced a root-store removal expected on October 27; treat that as a forthcoming compatibility deadline, not an event that has already happened.

Sources: Google Chrome/Android security team, Python core team's releases and Go release history.

5. Java teams also have an October patch cycle

Oracle's October 20 Critical Patch Update covers a broad range of Oracle products, including Java SE. For Oracle Java, the relevant October releases include 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.33 and 8u511. The Oracle advisory lists 55 new Java SE security patches, with impact depending on product, component and configuration. These are separate from PHP2Shell and do not imply that every Java application has the same RCE issue.

Java teams should use their actual JDK distributor's matching patch release, rebuild or restart affected services as required, and check embedded runtimes inside containers and third-party products. See Oracle's October 2026 CPU advisory and the Oracle Java release listing.

What production teams should do today

• Inventory what's really running. Include web servers, PHP-FPM workers, background jobs, CI agents, Docker images, Kubernetes workloads, edge functions, managed services and vendor appliances. A host-level version check cannot see everything.

• Classify the exposure. PHP2Shell calls for urgent runtime patching; the LiteLLM release compromise calls for incident response if a bad artifact actually ran; the eMudhra incident calls for certificate-trust verification. Do not apply the same fix to all three.

• Patch through supported channels. Prefer official vendor packages and security-maintained branches. With a distribution backport, confirm the advisory and installed package revision. Do not assume a lower-looking version is unpatched.

• Redeploy and verify the running artifact. Update base images and lockfiles where appropriate, rebuild containers and Go binaries, restart the affected workers, run smoke tests and inspect the versions or hashes of the live workloads. php -v on an admin shell alone cannot prove that a different PHP-FPM pool was upgraded.

• Hunt for signs of compromise. Check PHP workers spawning shells or download utilities, unexpected outbound connections, altered application files, suspicious new accounts and unusual secret use. If a malicious LiteLLM build ran, assess and rotate every reachable credential; a successful patch does not reverse an earlier intrusion.

• Keep a rollback and communications plan. Record affected services, who owns each remediation, the patch evidence, deployment time, failed tests and any compensating controls. A web application firewall can reduce exposure but does not replace security updates.

Common questions

Does PHP2Shell mean WordPress or Drupal itself was hacked?

No. These are PHP runtime vulnerabilities, not proof that a specific WordPress or Drupal website was breached. Updating CMS plugins is useful general hygiene, but it does not replace updating a vulnerable underlying PHP runtime.

Are Node.js applications vulnerable to the PHP issue?

Not merely because they use Node.js. PHP2Shell affects PHP deployments. A Node.js system may separately need the October Node.js patches, and a mixed infrastructure may run PHP elsewhere without the main application team realizing it.

Can I rely on a WAF or an automatic browser update?

Neither is a universal fix. WAF rules can help reduce exposure during a short maintenance window, but only the corrected runtime removes the PHP flaw. Browser certificate revocations do not automatically update every server-side trust store, container image or programming-language toolchain.

Bottom line

The lesson from October 2026 is not that all websites suddenly became insecure. It is that runtime bugs, compromised dependency releases and trust-infrastructure failures require different response plans. Identify your real deployment versions, apply verified patches, validate live workloads and investigate possible prior compromise where evidence warrants it. That is more useful than panic, vague warnings or a list of CVEs without context.

Editorial note: This article reflects official and named-researcher information checked on October 24, 2026. Security assessments and fixed versions may evolve; use the linked upstream advisories for subsequent changes.