#nodejs

Read Time:3 Minute, 26 Second

The Node.js project has released security updates for its supported 26.x, 24.x and 22.x branches, addressing ten vulnerabilities across compression, TLS verification, DNS handling, HTTP connections, cryptographic randomness and filesystem permissions. Four issues are rated high severity, with a Brotli decoder memory corruption bug carrying the most serious potential outcome: remote code execution.

The patched releases are Node.js 26.12.1, 24.22.1 and 22.23.4. Operators should install the appropriate version for their branch, rebuild containers and serverless bundles that embed the runtime, and restart long-running services. Merely updating a development workstation will not replace Node.js copies already shipped in production images.

Brotli decoder bug can cross a trust boundaryCVE-2026-111497 is an out-of-bounds write in the Brotli decoder affecting all three supported release lines. Writing beyond an allocated memory region can crash a process and, under suitable conditions, enable attacker-controlled code execution. Applications that automatically decompress untrusted Brotli content should be prioritized because remote input may reach the affected component.

The available advisory information does not fully describe the exploitation requirements. That uncertainty should not be interpreted as evidence of low risk. Internet-facing gateways, content-processing services and applications that accept compressed uploads have a clearer exposure path than systems that never handle attacker-controlled compressed data.

TLS and DNS inconsistencies weaken destination checksTwo high-severity vulnerabilities affect certificate hostname verification. CVE-2026-105483 concerns IP addresses written with full-width digits and affects the 26.x and 24.x branches. CVE-2026-106069 applies when a hostname loosely resolves to an IP address and affects 26.x, 24.x and 22.x. Both can cause an application to accept a certificate that should not match the intended endpoint.

These flaws are especially relevant to services that make outbound HTTPS requests based on user-controlled or tenant-provided destinations. Certificate validation is a core boundary against interception and redirection; unusual hostname representations should not produce a different security decision from their conventional form.

The fourth high-severity issue, CVE-2026-105482, causes dns.resolve to truncate names containing a NUL character. Security checks that inspect one string while the resolver uses a shortened version can create validation gaps. The bug affects all three supported branches.

Other fixes cover HTTP, randomness and permissionsCVE-2026-105481 addresses a keep-alive connection that can process a response written before its corresponding request was sent. CVE-2026-106072 corrects certificate validation for nonstandard IPv4 hostnames. Both are rated medium and apply to the supported branches.

Another medium-severity issue, CVE-2026-106074, can cause processes created from startup snapshots or single executable applications to repeat values returned by crypto.randomUUID() and crypto.randomInt(). Applications must not assume identifiers are unpredictable when runtime state has been cloned incorrectly.

Low-severity fixes address untrusted bytes exposed after failed ZIP header validation, wildcard behavior that grants excess filesystem access, and a Permission Model bypass through fs.realpathSync. The release also refreshes bundled components such as c-ares, CA certificates, Undici, OpenSSL and SQLite, depending on the branch.

What engineering teams should do nowInventory the exact Node.js runtime in hosts, containers, build images and serverless packages.

Upgrade to 26.12.1, 24.22.1 or 22.23.4 and replace immutable artifacts.

Test outbound HTTPS, DNS resolution and Brotli content handling after the update.

Review applications that use startup snapshots or single executables for security-sensitive random values.

Migrate any end-of-life Node.js branch to a supported release line.

Teams should also verify the runtime from inside the deployed artifact rather than trusting a manifest or base-image tag. Moving tags can leave cached layers in place, and package-lock updates do not necessarily upgrade the Node.js executable.

The breadth of this release makes it relevant even to applications that do not use Brotli directly. TLS and DNS behavior sits underneath common HTTP libraries, while embedded runtime copies can be easy to miss. A complete response combines patching with an inventory of where Node.js actually executes across the delivery pipeline.

Il problema: la fiducia basata su un nome che può cambiare proprietarioA inizio ottobre 2026 #GitHub ha corretto una falla nel sistema #npm Trusted Publishing che, secondo la società di sicurezza Bloom Security, lasciava più di 1.500 pacchetti (oltre 10 milioni di download complessivi) esposti a un takeover senza bisogno di rubare alcuna credenziale. Il bug, battezzato SlugFest, è un ottimo caso di studio per chiunque gestisca pipeline CI/CD: mostra come un meccanismo pensato per eliminare i segreti a lunga durata possa comunque fallire se il vincolo di fiducia è ancorato alla cosa sbagliata.

Trusted Publishing è arrivato su npm a luglio 2025 come alternativa ai token di pubblicazione statici. L’idea è elegante: il provider CI/CD (tipicamente GitHub Actions) genera un token OIDC di breve durata ad ogni esecuzione del workflow; npm lo scambia con una credenziale di pubblicazione temporanea solo se il token corrisponde a una configurazione di “trusted publisher” preregistrata sul pacchetto (repository, workflow, ambiente). Niente più NPM_TOKEN salvato nei secret di GitHub, niente più credenziali che restano valide per mesi se qualcuno le intercetta.

Dove si è rotto il modello: lo slug non è un identificatore stabileIl difetto individuato dal ricercatore Golan Myers di Bloom Security riguarda a cosa è legata la configurazione di trusted publisher. npm vincola il publisher allo slug del repository, cioè alla stringa owner/repository, e non all’ID numerico immutabile che GitHub assegna internamente a ogni repository. Il token OIDC generato da GitHub Actions contiene in realtà anche quell’ID, ma npm lo ignora fino a quando non avviene la prima pubblicazione riuscita da quel repository.

Myers l’ha descritta con un’immagine efficace: è come una serratura che controlla l’indirizzo scritto sulla porta invece di verificare chi sia il legittimo proprietario della casa. Se uno slug si libera — perché il repository viene rinominato, trasferito a un altro account o cancellato — chiunque lo rioccupi su GitHub eredita automaticamente la fiducia che npm aveva associato a quel nome.

La catena d’attacco passo per passoL’attaccante identifica un pacchetto npm con un trusted publisher configurato ma che non ha mai completato una prima pubblicazione tramite quel canale, puntato su uno slug owner/repository ormai libero (repository rinominato, trasferito o rimosso).

Crea su GitHub un nuovo repository con esattamente quello slug. GitHub gli assegna un ID numerico diverso da quello originale, ma lo slug torna a esistere.

Configura nel repository un workflow di pubblicazione npm (lo stesso nome file che il maintainer originale avrebbe probabilmente usato) e lo esegue tramite GitHub Actions.

Il workflow genera un token OIDC che contiene lo slug “riconquistato”. L’attaccante lo invia all’endpoint di scambio di npm.

npm confronta solo lo slug con la configurazione registrata, trova corrispondenza e rilascia una credenziale di pubblicazione temporanea senza alcuna verifica aggiuntiva sull’identità del repository.

Con quella credenziale l’attaccante pubblica una versione malevola del pacchetto, ereditando reputazione, numero di download e, soprattutto, tutti i progetti che lo dichiarano come dipendenza.

Bloom Security sottolinea un aggravante specifico del 2026: gli agenti AI che risolvono dipendenze in autonomia tendono a scegliere sempre l’ultima versione pubblicata e raramente verificano la provenienza reale di un pacchetto, rendendo questo tipo di attacco alla supply chain ancora più efficace su pipeline automatizzate.

Timeline della scoperta e della correzioneLuglio 2025 — Trusted Publishing con OIDC diventa generalmente disponibile su npm.

6 giugno 2026 — Bloom Security segnala la vulnerabilità a GitHub tramite il programma HackerOne.

9 giugno 2026 — GitHub valida la segnalazione.

2 ottobre 2026 — GitHub pubblica il changelog con la correzione definitiva.

Come GitHub ha chiuso la fallaLa correzione agisce proprio sul punto debole: il periodo in cui una configurazione di trusted publisher esiste ma non è ancora stata “convalidata” da una pubblicazione reale.

Una nuova configurazione di trusted publisher ora scade dopo 48 ore se non viene usata per completare con successo una prima pubblicazione.

Dopo quella prima pubblicazione riuscita, la configurazione diventa vincolata all’identità immutabile del repository (l’ID numerico), non più solo al nome.

Qualsiasi modifica che cambi repository o identità del progetto richiede la creazione di una nuova relazione di fiducia, che riparte da una nuova finestra di 48 ore; le modifiche ordinarie non la riavviano.

npm ora rifiuta i token di Trusted Publishing generati da eventi issue_comment di GitHub Actions, estendendo una restrizione già esistente su pull_request_target — entrambi trigger storicamente abusati per far eseguire codice a partire da contenuti controllati da terzi (ad esempio un commento su una pull request).

Cosa deve controllare chi mantiene pacchetti npmAnche con la falla corretta, vale la pena fare un controllo preventivo sulle proprie configurazioni:

Verificare ogni trusted publisher configurato sui propri pacchetti e confermare che il repository collegato sia ancora effettivamente sotto il proprio controllo.

Dopo una rinomina, un trasferimento o la cancellazione di un repository, eliminare e ricreare il vincolo di trusted publisher sullo slug corretto, piuttosto che lasciarlo “in sospeso”.

Preferire trigger di pubblicazione più sicuri — push su tag, release o workflow_dispatch — evitando pull_request_target e issue_comment.

Bloccare le versioni delle dipendenze dove possibile e controllare con attenzione gli script postinstall, specialmente nei repository dove un agente AI installa pacchetti senza supervisione diretta.

Monitorare pubblicazioni inattese e verificare le attestazioni di provenance generate automaticamente da npm.

Il caso SlugFest è un buon promemoria generale, non solo per npm: qualsiasi sistema di trust basato su OIDC “federato” (PyPI ha un meccanismo molto simile) deve ancorare la fiducia a un identificatore immutabile, non a un nome che può essere liberato e rivendicato da chiunque. Chi gestisce pipeline di pubblicazione automatizzate, su npm o altrove, farebbe bene a verificare quale dei due modelli stia effettivamente usando.

Fonte: The Hacker News e Cyber Security News.