October 22, “Bug Day”: PHP fixes two critical flaws as Node.js patches 10 CVEs

PHP's emergency releases addressed CVE-2026-109618 and CVE-2026-109619. The PHP Security Team describes both as Critical and capable of enabling remote code execution without authentication under the relevant conditions. The patched versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Organizations using distributor-maintained builds should check their vendor's security packages and backports rather than assume the upstream version number tells the whole story. [5]

Node.js published fixes on the same day for three supported lines: 22.23.4 (LTS), 24.22.1 (LTS) and 26.12.1 (Current). Across these lines, the advisory names 10 CVEs—four High, three Medium and three Low. Nothing in the announcements establishes a technical connection between the PHP and Node.js issues. The coincidence matters because both runtimes sit below business-critical web applications. [1][2][3][4]

Among the High-severity issues, CVE-2026-111497 stands out. The Node.js Brotli decoder can perform an out-of-bounds write, a memory-safety failure that the project says may permit remote code execution (RCE). Brotli is a compression format widely used on the web. An application's actual exposure depends on whether an affected code path processes untrusted compressed input; the existence of an RCE-capable bug is not proof that widespread exploitation has occurred. [1]

Three other High-severity CVEs concern DNS and TLS: CVE-2026-105482 involves dns.resolve truncating hostnames that contain a NUL character; CVE-2026-105483 affects hostname verification when IP addresses contain fullwidth digits; and CVE-2026-106069 concerns hostnames loosely interpreted as IP addresses during certificate checks. They have different root causes from the Brotli issue, but matter for services that connect to external systems and rely on TLS identity checks. [1]

The Medium group covers CVE-2026-105481 (HTTP keep-alive response ordering), CVE-2026-106072 (certificate validation for non-canonical IPv4 hostnames) and CVE-2026-106074 (cached entropy reused by crypto.randomUUID() and randomInt() in certain startup snapshots or single-executable applications). The Low group includes CVE-2026-106070 (ZIP header validation), CVE-2026-106071 (overbroad permissions in the Permission Model) and CVE-2026-106073 (a Permission Model bypass involving fs.realpathSync). Scope varies by release line and feature use. [1]

The release notice lists seven affected CVEs for the 22.x line, eight for 24.x, and all ten for 26.x. Teams on these supported lines should move to at least 22.23.4, 24.22.1 or 26.12.1 respectively, or a later fixed release of the same supported line. Two Low issues apply only to 26.x. [1][2][3][4]

Node.js 20 and 25 also need attention—but not because another minor update is coming. Both are end-of-life: the project's EOL page lists their final updates as March 24 and March 31, 2026. When upstream support ends, security fixes cease even if an application continues to run normally. Commercially supported backports may exist, but a planned move to a maintained line remains the long-term objective. [6]

A business might use Node.js for authentication, APIs, order processing and background tasks while PHP powers its company website, WordPress installation or a legacy admin system. Customers rarely see these dependencies. If a vulnerability is exploited, however, the consequences can include service disruption, data exposure and a recovery bill much larger than a planned update.

The mere presence of JavaScript or PHP does not define risk. A statically generated website that used Node.js during build has a different attack surface from an Internet-facing Node.js API. Conversely, production containers, server-side rendering services, scheduled jobs and third-party packages may still embed an old runtime after application dependencies have been refreshed.

Start with the runtime versions actually running in production—not the versions installed on developers' laptops. For Node.js, inspect running processes and container images, select the appropriate supported patched line and test compatibility before rolling out. For PHP, check the newly fixed versions or the equivalent distributor packages; involve your hosting provider where runtime maintenance is outside your direct control. [1][5]

Redeploy the affected workloads, verify which runtime binary is loaded, exercise critical paths such as sign-in and payments, monitor errors and have a tested rollback plan. Updating npm dependencies with npm update does not, by itself, replace the Node.js executable that production is using.

Prioritize Brotli decompression paths accepting untrusted content, and treat public-facing PHP installations as urgent patch candidates. The PHP advisory emphasizes that temporary mitigations can reduce exposure to particular attack paths but do not replace a complete update. If patching must be delayed, assign an owner, a deadline and compensating controls suited to the service's business criticality. [1][5]

“Bug Day” is Automize's playful nickname for an October 2026 coincidence—not an official observance or evidence that security flaws reliably surface on October 22. Reporting and patching vulnerabilities is part of responsible open-source maintenance; counting CVEs alone tells little about whether software quality is improving or declining.

If October 22 becomes an annual reminder, its most useful ritual would be a runtime inventory: which systems are unsupported, who owns updates, and has the patch actually reached production? No cake required. Accurate asset records, tested patches and a clear owner are a better way to celebrate.