Node.js, Java e Python: vulnerabilità recenti e guida alla risoluzione

Fonti controllate al 23 ottobre 2026 (UTC) Periodo di copertura: dal 25 luglio al 23 ottobre 2026, con focus sui nuovi annunci e sulle patch successive da settembre a ottobre. Apubblico: ingegneri e addetti alla sicurezza che si occupano della manutenzione dei servizi Node.js, Java, Python, dei contenitori, della creazione di pipeline e degli ambienti di sviluppo.

Questo articolo riassume i recenti importanti rischi per la sicurezza nei runtime Node.js, Java e Python, nelle librerie standard e nei framework e dipendenze dei server comuni e fornisce ambito di impatto, versioni fisse, misure di mitigazione temporanee, selezione di patch e metodi di verifica.

Valuta l’impatto rispetto alle versioni dei componenti, alle funzionalità abilitate e ai punti di ingresso accessibili. I dati sulla vulnerabilità provengono da avvisi ufficiali; le date si riferiscono alla divulgazione pubblica a meno che non sia esplicitamente indicata una versione precedente della patch. Non deduciamo condizioni di exploit non confermate, punteggi CVSS o sfruttamento in natura. I consigli per l’implementazione sono identificati come linee guida per l’implementazione.

TL;DR: priorità di riparazione

Aggiorna prima il runtime che ospita effettivamente il servizio. Aggiorna il ramo Node.js corrispondente almeno a 22.23.4 / 24.22.1 / 26.12.1. I servizi che utilizzano Node 24 possono essere aggiornati a 24.22.1 all’interno della stessa versione principale o a una versione successiva che contiene le stesse correzioni. S1 S2
Aggiorna le dipendenze dell’applicazione Node separatamente. Per Next.js, utilizzare 15.5.28 / 16.4.1 come base di aggiornamento; quando si utilizza React Server Components in modo indipendente, controllare il pacchetto react-server-dom-* effettivamente installato. Solo l’aggiornamento del binario Node non copre queste vulnerabilità del framework. S8 S9 S10 S11 S12
Java: copre entrambi i cicli di aggiornamenti. Installa una build del fornitore che copre sia la correzione di attendibilità del certificato di emergenza del 20 ottobre CPU che quella del 21 ottobre CVE-2026-91403. Vedere la sezione 2.2 per le versioni fuori banda Oracle JDK 11-27; verificare altre distribuzioni rispetto ai propri pacchetti di sicurezza e numeri di build completi. Aggiorna il ramo Tomcat corrispondente a 9.0.123 / 10.1.61 / 11.0.27. S16 S17 S18 S20 S21 S22 S23
Python : aggiorna separatamente l’interprete, i pacchetti applicativi e i pacchetti di certificati. Vedere la sezione 2.3 per le linee di base degli interpreti; certifi raccomanda ≥ 2026.10.19 , pip ≥ 26.2.2 , durante l’utilizzo uv ≥ 0.13.4 . Ogni venv esistente deve essere controllato. Per wrap_bio() codici correlati, corretti e non vuoti server_hostname deve essere anche passato. S29 S30 S31 S33 S35 S36 S37
Se un aggiornamento immediato è impossibile, ridurre l’esposizione ai punti di ingresso pertinenti. Dare priorità all’arresto della decodifica Brotli non attendibile, all’elaborazione di immagini/paging/archiviazione interessata e all’isolamento di voci LDAP o di autenticazione problematiche; mantenendo verificati i certificati e i nomi host TLS. WAF in entrata non può coprire percorsi in uscita come applicazioni che emettono risposte compresse dannose. S3 S11 S25 S27 S30 S32
Ricostruisci, sostituisci i vecchi processi e verifica tramite percorsi di servizio reali. Salva il file di blocco e il digest dell’immagine, ricostruisci l’applicazione e l’immagine, implementa le sostituzioni per tutti i lavoratori/JVM/contenitori; controllare il processo effettivo, l’albero delle dipendenze, il trust store e i test di regressione aziendale. Una versione più recente della riga di comando da sola non stabilisce che la correzione sia completa.
Se LiteLLM 1.107.0 è stato installato o eseguito, seguire le procedure di risposta all’incidente. Il progetto ha confermato la compromissione del rilascio il 21 ottobre. Isolare gli ambienti interessati, indagare da un ambiente pulito, ricostruire e ruotare le credenziali esposte. Non avviare Python/pip in un ambiente sospetto per verificare prima. Vedere la Sezione 9 per i dettagli. S41

1. Panoramica della vulnerabilità e valutazione del rischio

1.1 Dare priorità alla riparazione in base all’esposizione effettiva

Le priorità di distribuzione riportate di seguito costituiscono indicazioni di implementazione. Le etichette di gravità seguono ciascun fornitore, inclusa la valutazione Important di Apache. CVSS 3.1 e 4.0 sono sistemi di punteggio diversi; non classificare i problemi in base al solo punteggio.

Ecosistema/strato	Questioni chiave	Grado ufficiale o punteggio verificato	Distribuzione prioritaria
Dipendenza nativa Node.js	CVE-2026-111497: Brotli è scritto fuori limite e c’è il rischio di RCE	Node：High	Decodifica i dati Brotli S1 S3 nel corpo della richiesta esterna o nella risposta esterna
Node.js TLS / DNS	CVE-2026-105482, 105483, 106069: L’analisi e la verifica dell’identità non sono coerenti	High	URL scansione, proxy, Webhook, indirizzo di destinazione dinamico S1 S5 S6
Node.js HTTP/2	CVE-2026-56846, 56848: memoria esaurita e UAF	High	Node gestisce direttamente il traffico HTTP/2 non attendibile S7
React / Next.js	RSC / `use cache` typed arrays RCE	Critical；CVSS 4.0 9.5	Server RSC, relativi componenti cache e percorso dati S9 S10
Next.js Ottimizzazione dell’immagine	CVE-2026-96889: SVG Elaborazione immagini RCE	Critical；CVSS 4.0 9.5	Istanze su glibc Linux in grado di gestire immagini non attendibili S11
Next.js Server Actions	Una richiesta appositamente predisposta provoca l’esaurimento di CPU	High；CVSS 4.0 8.2	App Router e almeno uno Server Action S12
Java TLS Fiducia	CVE-2026-91403: continuare a fidarsi dell’intermedio interessato CA	CVSS 3.1 9.1	TLS/API Scenario S17 che utilizza la catena di fiducia interessata
Tomcat	Bypass di autenticazione JNDIRealm, errori di richiesta incrociata HTTP/2, perdita di risposta AJP	Important	Corrispondente al percorso Realm / Connector / async Servlet S21 S22 S23
Spring for GraphQL	CVE-2026-59285: Deserializzazione cercapersone RCE	High	Jackson 2 + Connection Cercapersone + Classpath sfruttabile S25
Spring Security	CVE-2026-59270: identità di gestione nota LDAP incorporata esposta	Critical	LDAP integrato è abilitato e la porta di ascolto è accessibile all’aggressore S27
CPython `ssl`	CVE-2026-19445: il contesto di commutazione SNI risulta in UAF	Critical	Python termina TLS da solo e soddisfa la condizione del ciclo di vita del contesto S29
CPython `ssl`	CVE-2026-19553: salta la verifica quando manca il nome host	High	`wrap_bio()` / Chiamata asincrona correlata mancante del nome host previsto S30
CPython `tarfile`	CVE-2026-82049: bypass combinato collegamento reale e collegamento simbolico	High	Estrai automaticamente l’archivio tar non attendibile S32
Django / GeoDjango	CVE-2026-15307: File di scrittura query spaziale, SSRF, nella condizione RCE	High	Query spaziali o interfacce di amministrazione correlate che accettano input non attendibili S38
Dipendenza dal certificato Python	certifi: sfiducia del certificato relativo a emSign	Critical; GHSA, nessuno noto CVE	Client TLS e strumento di gestione dei pacchetti S36 S37 utilizzano ancora CA bundle interessato

Abbreviazioni: RCE sta per esecuzione di codice remoto, UAF sta per use-after-free e SSRF sta per falsificazione delle richieste lato server. I permessi diretti di RCE sono solitamente i permessi del processo che ospita l’applicazione e non possono essere automaticamente equivalenti ai permessi di root.

Sequenza consigliata: gestisce innanzitutto RCE, che è raggiungibile esternamente e soddisfa le condizioni, bypass di autenticazione, perdita di dati tra utenti e problemi di autenticazione del certificato; allo stesso tempo, pianifica gli aggiornamenti per il punto di ingresso DoS rivolto al pubblico. Non è necessario eseguire payload di attacco in produzione per dimostrare la sfruttabilità. Esistono dipendenze, i percorsi del codice sono raggiungibili e le condizioni di attacco vengono soddisfatte. Queste sono tre questioni che devono essere controllate separatamente.

1.2 Tre confini facilmente confondibili

Aggiorna runtime e dipendenze separatamente. Gli aggiornamenti di sicurezza per Node, JDK, CPython non riparano automaticamente le installazioni autonome di Next.js, Spring, Django, certifi o estensioni native.
La soglia di riparazione è separata dall’attuale base di distribuzione. Non è garantito che la prima patch per una vulnerabilità in agosto copra i nuovi problemi da settembre a ottobre; La Sezione 2 utilizza gli aggiornamenti successivi verificati come obiettivo di implementazione.
Distinguere una vulnerabilità da un’effettiva compromissione della catena di fornitura. Per le vulnerabilità comuni, le patch eliminano futuri percorsi di attacco; quando sono stati eseguiti pacchetti dannosi, è necessario indagare sull’impatto delle credenziali e della persistenza. LiteLLM della Sezione 9 è l’evento ufficialmente confermato. S41

L’eventuale conferma di sfruttamento in natura dovrebbe basarsi su informazioni ufficiali. Il venditore non ha menzionato le attività di sfruttamento e non può dimostrare che non vi sia stato alcun attacco; la riparazione deve essere eseguita in base alla superficie di attacco effettiva.

2. Controllo rapido della versione fissa e della base di distribuzione

Riferimento: 2.1 Node.js、React、Next.js

componente/ramo	Versione di base consigliata	Istruzioni per l’uso
Node.js 22.x	22.23.4	Rilascio di sicurezza S1 S2 il 21 ottobre
Node.js 24.x	24.22.1	Si applica al ramo 24.x; 24.22.0 non contiene la patch di sicurezza del 21 ottobre S1 S2
Node.js 26.x	26.12.1	Sblocco di sicurezza nello stesso lotto S1 S2
Node.js 20 e rami a monte precedenti	Migrare a un ramo supportato	Node 20 non accetta questa correzione upstream; il supporto esteso del fornitore deve essere verificato separatamente S3
Next.js 15.x	15.5.28	Aggiornato il 14 ottobre S8
Next.js 16.x	16.4.1	Come sopra S8
Ramo RSC 19.0 / 19.1 / 19.2 / 19.3 autonomo	19.0.9 / 19.1.10 / 19.2.9 / 19.3.1	Controllare separatamente i tre pacchetti `react-server-dom-*`; non basta guardare lo strato superiore `react` S10
Next ha effettivamente caricato `sharp`	≥0.35.5	Condizioni ufficiali di correzione temporanea per la vulnerabilità SVG; non sostituisce le altre patch Next.js S11

Node elenca ufficialmente i rami di manutenzione interessati dalla vulnerabilità di ottobre, ma non fornisce la versione della patch introdotta inizialmente, elemento per elemento, quindi la versione iniziale precisa di ciascuna vulnerabilità non può essere determinata basandosi solo sull’intervallo dei rami di manutenzione. Durante la distribuzione, dare la priorità all’utilizzo della versione precedente dello stesso ramo o di una versione successiva confermata per contenere le stesse correzioni.

2.2 Java: CPU di ottobre più aggiornamento del certificato fuori banda

Questa tabella si applica a Oracle JDK. La seconda colonna riguarda solo il 20 ottobre CPU; il terzo include l’uscita fuori banda del 21 ottobre. Le versioni CPU da sole non coprono tutti i rischi Java discussi qui. S16 S17 S18

ramo	20 ottobre CPU	Oracle è uscito fuori band il 21 ottobre
11	11.0.33	11.0.33.0.2
17	17.0.21	17.0.21.0.2
21	21.0.13	21.0.13.0.2
25	25.0.5	25.0.5.0.2
27	27.0.1	27.0.1.0.2
8	8u511	La tabella delle versioni pubbliche mostra ancora 8u511; è necessario verificare la build di sicurezza specifica e la riparazione della catena di fiducia e non è possibile determinarla solo in base al numero di versione breve

**Java 8 deve essere confrontato con le informazioni complete sulla build:**Oracle L’avviso elenca 8u511 come versione interessata e l’elenco delle versioni elenca gli aggiornamenti successivi con lo stesso nome breve. Lo stato della patch non può essere distinto solo in base al numero di versione breve “8u511”. È necessario confermare la build di sicurezza specifica e le correzioni della catena di attendibilità. S17 S18

Temurin, Corretto, Zulu, Microsoft Build of OpenJDK, versione di rilascio OpenJDK, ecc., controllare in base ai rispettivi annunci e ai numeri di pacchetto/build completi. Ad esempio, il record di rilascio ufficiale di Adoptium afferma che la build pertinente è stata riconfezionata per aggiungere la correzione eMudhra; lo stesso nome della versione upstream non significa che il contenuto del pacchetto sia lo stesso. Le regole del suffisso .0.2 per Oracle non possono essere applicate meccanicamente ad altri editori. S20

Componenti applicativi Java	Versione di base consigliata	Osservazioni
Tomcat 9 / 10.1 / 11	9.0.123 / 10.1.61 / 11.0.27	Controllare ramo per ramo; Tomcat 10.0 ha interrotto la manutenzione S21 S22 S23
Spring for GraphQL 2.0.x	2.0.5（OSS）	Anche il supporto commerciale è 2.0.4.1 S25
Spring Security 7.1 / 7.0	7.1.1 / 7.0.7（OSS）	Corrisponde alla versione di correzione minima annunciata in agosto; è necessario controllare il successivo bollettino sulla sicurezza S27 S28 prima della distribuzione
Spring Security 6.5 / 6.4 / 5.8 / 5.7	6.5.12 / 6.4.19 / 5.8.28 / 5.7.26	L’annuncio è elencato come correzione di supporto commerciale; la migrazione viene valutata quando non esiste un supporto corrispondente e non si può presumere che Maven Central sia disponibile gratuitamente S27

Gli aggiornamenti Spring devono rispettare la versione minima e le linee di compatibilità del progetto Spring Boot BOM, Java. Non forzare direttamente tutti i moduli Spring sullo stesso numero solo per ottenere una patch.

2.3 CPython, Django e dipendenze del certificato

La seconda colonna della tabella seguente si concentra sull’emissione TLS pubblicata a settembre; le differenze di ramo per tarfile sono mostrate nella sezione 5.3. Le versioni del 21 ottobre hanno anche aggiornato gli strumenti di certificato in bundle, quindi l’ultima colonna include le linee di base di distribuzione successive. S29 S30 S33 S35

Filiale CPython	Versione minima del batch di sicurezza di settembre	Base di distribuzione consigliata
3.10	3.10.22	Ultima versione da upstream, EOL; organizzare la migrazione o verificare il supporto dell’estensione di rilascio S34
3.11	3.11.17	3.11.17 e aggiorna pip/certifi in ciascun ambiente individualmente
3.12	3.12.15	3.12.15 e aggiorna pip/certifi in ciascun ambiente individualmente
3.13	3.13.16	3.13.17
3.14	3.14.8	3.14.9
3.15	La versione finale di 3.15.0 include entrambe le correzioni TLS S31 S47	3.15.1

Le versioni di sicurezza upstream di 3.11 e 3.12 possono essere rilasciate solo nel codice sorgente; quando si utilizza il pacchetto del sistema operativo, controllare l’avviso backport del fornitore e la versione completa del pacchetto e non è necessario sostituire forzatamente il sistema Python con una versione autocompilata. S33 S34

dipendenza indipendente	Versione di base consigliata	Descrizione
Django 5.2 / 6.0 / 6.1	5.2.18 / 6.0.9 / 6.1.2	Incorporare la successiva correzione S38 S39 del 6 ottobre
certifi	≥2026.10.19	La patch iniziale GHSA è .18; PSF consiglia .19 per preservare la compatibilità per i certificati non interessati S36 S37
pip	≥26.2.2	La copia integrata di certifi deve essere aggiornata separatamente S35 S37
uv (se utilizzato)	≥0.13.4	Aggiorna S37 in base al metodo di installazione effettivo

Queste linee di base coprono le correzioni elencate. Un altro problema di media gravità in tar_filter è stato rivelato il 22 ottobre. Al 23 ottobre 2026, una versione di manutenzione ufficiale contenente questa correzione non è stata ancora confermata; pertanto, non si può ritenere che 3.13.17 / 3.14.9 / 3.15.1 abbiano coperto tutte le questioni relative al file tar. Vedere la sezione 5.4. S40

2.4 Verifica dei backport di distribuzione

Principi di implementazione applicabili a Ubuntu, Debian, RHEL e altri pacchetti software:

Registrare la versione del sistema operativo, l’origine del repository, la versione completa del pacchetto e il numero del bollettino sulla sicurezza del fornitore.
Confermare che l’avviso copra lo specifico CVE e identifichi un pacchetto fisso per la relativa versione di distribuzione.
Confronta i file binari/librerie caricati dal processo effettivamente in esecuzione, non solo dalla versione breve upstream.
Quando non c’è prova di una patch del fornitore, lasciala “da confermare” e non prenderla come unica conclusione che il numero di versione sembri vecchio o nuovo.

Esistono differenze nelle versioni del pacchetto apt/RPM e nelle strategie di backport delle diverse distribuzioni. Dovrebbero prevalere il bollettino sulla sicurezza e la versione del pacchetto completo di ciascuna distribuzione.

3. Ecosistema Node.js / JavaScript: analisi delle cause e risoluzione

3.1 CVE-2026-111497: scrittura fuori limite del decoder nativo Brotli

Divulgazione: 21-10-2026; Grado ufficiale Node: High. Le build interessate di Node 22.x, 24.x, 26.x richiedono l’installazione della sezione patch 2.1. Node Il bando non elenca un punteggio numerico CVSS. S1

Il problema si verifica nella logica di decodifica nativa durante la gestione del flusso compresso Brotli non valido, che può portare a scritture fuori limite. La descrizione ufficiale di Vercel conferma che la dimostrazione della ricerca comporta perdite di memoria dei processi e l’esecuzione di comandi. La possibilità che un utente malintenzionato possa raggiungere il decodificatore dipende dal fatto che l’applicazione o la dipendenza decodifichino effettivamente i dati che controlla. S3

Entrambe le direzioni devono essere controllate contemporaneamente:

inbound: il framework o middleware decomprime automaticamente il corpo della richiesta Brotli inviato dall’utente.
**outbound:**HTTP Client, image grabber, ecc. accedono a fonti controllabili dagli aggressori e decomprimono automaticamente il contenuto restituito.

La disabilitazione della compressione Brotli delle risposte inviate ai browser non rimuove un punto di ingresso della decodifica. Inoltre, la protezione WAF in entrata non copre le applicazioni che recuperano e decodificano le risposte esterne. S3

**Direzione patch:**Node Sposta la correzione upstream Brotli nella dipendenza nativa e integra il controllo dello stato di decodifica illegale e la propagazione degli errori. Quando si mantiene una versione autocompilata, è necessario utilizzare la versione di sicurezza ufficiale o la patch completa del ramo corrispondente. Non puoi semplicemente modificare la dichiarazione di versione di un pacchetto JavaScript. S4

Suggerimenti per l’implementazione provvisoria: interrompe la decodifica Brotli non attendibile non necessaria; verificare il comportamento di decompressione automatica del middleware e del client HTTP; se l’azienda deve accettare questo formato, completare l’elaborazione nell’ambiente patchato il prima possibile. La modifica di Accept-Encoding è semplicemente un atto di negoziazione e non dovrebbe costituire da sola la prova che una risposta dannosa è stata bloccata.

3.2 TLS / DNS tre High: L’oggetto di verifica non è coerente con l’obiettivo effettivo

Tutti e tre sono stati resi pubblici il 21 ottobre, con la soglia di aggiornamento ufficiale stabilita nella Sezione 2.1. S1

Identificatore	Problema confermato	Rami colpiti
CVE-2026-105482	`dns.resolve` Troncamento di nomi contenenti NUL	22.x / 24.x / 26.x
CVE-2026-105483	IP nel formato numerico a larghezza intera fa sì che la verifica del nome host del certificato venga ignorata	24.x / 26.x
CVE-2026-106069	Il nome host che può essere liberamente interpretato come IP comporta il bypass della verifica TLS	22.x / 24.x / 26.x

DNS L’essenza del problema è che la stringa controllata dallo strato superiore è diversa dal nome effettivamente analizzato dallo strato inferiore. La patch ufficiale rifiuta NUL alla voce di analisi e aggiunge la copertura della regressione. S6

TLS Due elementi riguardano la normalizzazione del nome, la coerenza dell’interpretazione IP e la corrispondenza del certificato. Applicare la patch in modo che l’input IP non standard venga rifiutato o gestito correttamente per evitare di confondere l’effettivo endpoint IP con l’identità del dominio del certificato. S5

Suggerimenti effettivi per la risoluzione dei problemi per : dà la priorità al controllo del codice dell’utente ricevente URL, della destinazione proxy dinamica o dell’indirizzo Webhook; standardizzazione unificata e consente il giudizio degli elenchi, rifiuta i caratteri NUL/di controllo, conferma che IPv4, IPv6 legali e i nomi di dominio internazionalizzati funzionano ancora. Se SSRF possa essere ulteriormente formato richiede l’applicazione di prove di collegamento, che non possono essere dedotte direttamente dal nome CVE.

Non utilizzare NODE_TLS_REJECT_UNAUTHORIZED=0 o rejectUnauthorized: false per eliminare gli errori di checksum post-aggiornamento. L’indirizzo, il certificato e la configurazione aziendale dovrebbero essere corretti.

3.3 Luglio HTTP/2 High-problemi relativi al modello di rischio e autorizzazione

Le seguenti questioni divulgate a luglio devono ancora essere incluse nell’indagine. Si consiglia di utilizzare direttamente la baseline della versione di sicurezza di ottobre nella sezione 2.1 durante la distribuzione. S7

CVE	Cause ed effetti	Prima versione fissa
CVE-2026-56846	Il blocco HTTP/2 header mantenuto non è incluso correttamente nel budget `maxSessionMemory` e può esaurire la memoria; Impatto 22.x / 24.x	22.23.2 / 24.18.1
CVE-2026-56848	HTTP/2 rientra nel percorso di invio durante la raccolta dei pacchetti, causando un heap UAF; impatto 22.x / 24.x / 26.x	22.23.2 / 24.18.1 / 26.5.1
CVE-2026-58043	`--permission` La corrispondenza del limite del prefisso del percorso è troppo ampia ed è possibile accedere ai file esterni all’elenco consentito.	Uguale alle tre righe di manutenzione sopra

Tutti e tre sono ufficialmente High. I primi due elementi danno priorità alla verifica se HTTP/2 viene elaborato dallo stesso Node; il terzo elemento ha un significato corrispondente solo quando si utilizza il modello di autorizzazione e si fa affidamento su questo limite. Gli elementi del modello di autorizzazione non possono essere tutti descritti come rete RCE che non richiede l’autenticazione. S7

La terminazione temporanea di HTTP/2 su un proxy separato e aggiornato e la limitazione delle origini backend è un’opzione di distribuzione per ridurre l’esposizione; le quote delle risorse possono solo controllare le conseguenze dell’esaurimento delle risorse e non possono applicare patch a UAF.

3.4 Ottobre React / Next.js: due articoli RCE e un articolo DoS

A. RCE nelle funzioni RSC / `use cache` che restituiscono array tipizzati

Data pubblica: 2026-10-14; Critical, CVSS 4.0 9.5. Identificatori avvisi ufficiali:

React：GHSA-xqc2-xf4c-x3h3。
Next.js：GHSA-673q-mjm6-r5xr。S9 S10

Il problema upstream React coinvolge più array tipizzati combinati con valori controllabili dall’aggressore nella risposta RSC. Le tre versioni del pacchetto react-server-dom-* interessate sono 19.0.0—19.0.8, 19.1.0—19.1.9, 19.2.0—19.2.8, 19.3.0; vedere il capitolo Sezione 2.1. React puramente lato browser o applicazioni che non utilizzano framework/plug-in che supportano RSC non rientrano nell’ambito di questo articolo. S10

Next.js elenchi di annunci downstream 16.0.0—16.4.0, rivisto in 16.4.1; lo scenario è rappresentato dalle funzioni App Router, Cache Components e use cache che restituiscono più matrici tipizzate. Non esiste una soluzione generale affidabile ufficiale e gli utenti delle versioni interessate sono tenuti ad eseguire l’aggiornamento in tempo. Non è opportuno affidarsi esclusivamente alla ricerca manuale di “questa funzione non sembra esistere” per terminare l’elaborazione. S9

Riferimento: B. SVG Image Optimization RCE

CVE-2026-96889/GHSA-2464-fhr4-w9xw, 2026-10-14, Critical, CVSS 4.0 9.5. Il problema si verifica nella libreria nativa upstream utilizzata per l’ottimizzazione delle immagini. I funzionari hanno sottolineato che il rischio RCE esiste nello scenario glibc Linux. S11

I campi della versione ufficiale sono:

>=10.0.0 <=15.5.27；
>16.0.0 <=16.4.0。

Il funzionario utilizza un limite inferiore rigoroso di >16.0.0 per il ramo 16.x, ma questa dichiarazione di intervallo non è sufficiente per dimostrare che 16.0.0 è sicuro. L’obiettivo di aggiornamento effettivo è uniformemente 15.5.28 / 16.4.1. S11

La soluzione temporanea ufficiale è garantire che Next carichi effettivamente in modo nitido ≥0.35.5. I file di blocco, le dipendenze nidificate e le immagini di distribuzione potrebbero ancora contenere vecchie istanze, quindi aggiungere semplicemente una nuova versione della dipendenza sharp al livello più alto non è sufficiente, l’albero delle dipendenze finale dovrebbe essere controllato e ricostruito. S11

C. Server Actions CPU esaurito

**GHSA-p3m5-59mp-jv5r, 2026-10-14, High, CVSS 4.0 8.2.**Next influisce su 13.0.0—15.5.27, 16.0.0—16.4.0, corregge 15.5.28 /16.4.1. Le condizioni sono App Router e almeno uno Server Action; le richieste dannose possono tenere occupato CPU per lungo tempo, bloccando le richieste successive nello stesso processo. Le applicazioni con Pages Router o senza Server Actions non sono interessate da questo. S12

Non esiste una soluzione ufficiale che possa sostituire l’aggiornamento. I limiti di velocità, i limiti di concorrenza e le quote di risorse possono ridurre i danni, ma non possono essere utilizzati come conclusione per la verifica delle patch.

3.5 Precedente Next.js nella stessa finestra Problema serio

I seguenti elementi hanno lo scopo di evitare distribuzioni mancanti che sono ancora bloccate nelle versioni precedenti ad agosto-settembre; non è consigliabile spostarsi ora alle vecchie soglie fisse nella tabella.

Data	Identificatore/scenario	Prima correzione; azione attuale
2026-08-25	GHSA-2xp9-vwfh-vxw4: AVIF libreria nativa di ottimizzazione delle immagini RCE, Critical	15.5.24 / 16.3.3; ora 15.5.28 / 16.4.1 S13
2026-08-25	CVE-2026-75604: RCE, Critical quando Pages Router e App Router vengono utilizzati contemporaneamente su Windows e Cache Components non è abilitato; versioni `>=13.4.0 <15.5.24`, `>=16.0.0 <16.3.3`	15.5.24 / 16.3.3; Linux/macOS non sono interessati da questo specifico problema Windows S14
2026-09-22	GHSA-vcvr-r3jv-pc5j: il percorso di generazione delle immagini Node in `next/og` elabora SVG, Critical non attendibili; 16.2.0—16.3.5	16.3.6; l’implementazione Edge non rientra nell’ambito di questo problema e 15.x non è un ramo interessato da questo RCE S15

4. Ecosistema Java: trust di runtime, contenitori e framework vengono gestiti separatamente

4.1 JDK: CPU e CVE-2026-91403 regolari sono aggiornamenti a due livelli

La matrice di rischio Java SE per Oracle CPU del 20 ottobre elenca 55 nuove patch di sicurezza, 49 delle quali sono contrassegnate come sfruttabili in rete senza autenticazione. Ciò non significa che ci siano 55 Critical, né significa che ci siano 49 percorsi RCE direttamente sfruttabili per ciascun servizio web Java; deve essere compreso insieme ai componenti, alle API, alle interazioni dell’utente e alle condizioni di distribuzione nella matrice. S16

L’evento CVE-2026-91403 (CVSS 3.1 9.1) del giorno successivo tratta un altro tipo di rischio: un insieme di CA intermedi relativi all’evento eMudhra che non è più attendibile. Interessa l’autenticazione peer TLS e la riservatezza/integrità delle comunicazioni e non può essere descritta come una vulnerabilità di corruzione della memoria JVM. S17

L’avviso Oracle elenca la versione rilasciata il 20 ottobre come interessata, quindi è necessario installare anche l’aggiornamento fuori banda del 21 ottobre. Vedere la sezione 2.2 per la versione specifica. GraalVM ha anche prodotti interessati corrispondenti e la versione corretta dovrebbe essere soggetta al suo esclusivo bollettino sulla sicurezza. S17 S18

Misure ufficiali temporanee: Eseguire prima il backup, quindi rimuovere il certificato radice specificato da ciascun truststore effettivamente utilizzato:

emSign ECC Root CA - G3, alias Oracle emsigneccrootcag3 [jdk].
AAA Certificate Services, alias Oracle comodoaaaca [jdk]. S19

JDK 11 e versioni successive, l’esempio ufficiale è:

keytool -delete -cacerts -alias "emsigneccrootcag3 [jdk]"
keytool -delete -cacerts -alias "comodoaaaca [jdk]"

Utilizza keytool dal JDK di destinazione per questi comandi e conferma che stanno operando sull’effettivo trust store dell’applicazione. Java 8 utilizza il percorso corrispondente a jre/lib/security/cacerts; la personalizzazione del truststore deve essere gestita separatamente e altri editori potrebbero avere alias diversi. La rimozione del certificato radice amplierà l’ambito del rifiuto e testerà la regressione delle catene di certificati di servizio legittimi. S19

Il funzionario offre anche la possibilità di abilitare il controllo della revoca, ma l’effetto dipende dall’effettiva implementazione di TLS, dalla raggiungibilità del servizio di revoca e dalla strategia di errore. Per le distribuzioni generali, dare la priorità all’installazione degli aggiornamenti completi del fornitore per evitare di considerare due switch JVM come prova che tutte le librerie TLS sono state corrette.

4.2 Tomcat: bypass dell’autenticazione e isolamento delle richieste tra utenti

I tre articoli seguenti sono stati pubblicati su 2026-10-20; la voce della versione riparata è datata O12 ottobre. Il grado ufficiale di Apache è Important. S21 S22 S23

CVE	Versioni interessate confermate	Scenari/risultati necessari
CVE-2026-101296	9.0.0.M1—9.0.122；10.1.0-M1—10.1.60；11.0.0-M1—11.0.26	JNDIRealm Configura il meccanismo di autenticazione SASL non GSSAPI, la verifica delle credenziali manca e potrebbero passare anche password errate
CVE-2026-101356	9.0.118—9.0.122；10.1.55—10.1.60；11.0.22—11.0.26	La gestione degli errori servlet asincroni di HTTP/2 ricicla/riusa in modo errato gli oggetti, causando richieste o risposte miste tra gli utenti
CVE-2026-103119	Conferma solo 11.0.0-M25—11.0.26	Le scritture non bloccanti AJP di grandi dimensioni possono causare una lettura insufficiente del buffer, esponendo i dati di risposta precedenti nelle richieste successive.

La correzione corrispondente è 9.0.123 / 10.1.61 / 11.0.27; AJP è elencato solo come Tomcat 11 secondo l’annuncio e non può essere espanso a tre rami con lo stesso problema. S21 S22 S23

La patch JNDIRealm risolve una lacuna di verifica nell’effettivo processo di autenticazione, per cui “l’interfaccia di accesso dell’applicazione sembra normale” non può essere utilizzata al posto della verifica. Realm, i meccanismi SASL dovrebbero essere controllati per l’effettiva configurazione del servizio e i test devono fallire per password errate. S24

Suggerimenti di implementazione provvisoria: isolare il percorso di autenticazione interessato; sospendere l’elaborazione HTTP/2 di Tomcat quando l’azienda lo consente; chiudere inutile AJP. Limitare soltanto l’accesso diretto alla porta AJP non può dimostrare che il traffico in entrata attraverso il front proxy legale non sarà influenzato. Dopo l’aggiornamento ufficiale, le richieste simultanee asincrone di due utenti indipendenti dovrebbero essere testate per confermare che non vi sia alcuna diafonia tra identità e risposte.

Riferimento: 4.3 Spring for GraphQL：CVE-2026-59285

Data pubblica: 20/08/2026; High. interessato 2.0.0—2.0.4, riparato 2.0.5 (OSS) o 2.0.4.1 (supporto commerciale). S25

Si tratta di un rischio di deserializzazione non sicuro nelle query di paging. Il requisito ufficiale è che le seguenti condizioni debbano essere soddisfatte contemporaneamente:

Utilizzare Spring for GraphQL.
Deserializzare JSON utilizzando Jackson 2.x.
Fornire il campo di paginazione della connessione al mondo esterno.
Il classpath contiene classi specifiche che possono eseguire logica imprevista durante la creazione di istanze o la deserializzazione.

Una richiesta GraphQL dannosa può causare RCE quando le condizioni sono soddisfatte. Non si può ridurre a “tutti i programmi Java che utilizzano Jackson possono essere sfruttati”. S25

Perché 2.0.4 non è sufficiente: A giugno, CVE-2026-41699 aveva fornito linee di base di patch come 2.0.4 e ad agosto l’annuncio includeva chiaramente 2.0.4 nel nuovo ambito di influenza. Pertanto, il registro delle riparazioni dovrà essere aggiornato in base ai successivi annunci e non sarà possibile utilizzare la versione minima della vecchia CVE. S26

Quando l’aggiornamento è temporaneamente non disponibile, i campi di impaginazione interessati accessibili ai chiamanti non attendibili possono essere sospesi; restringere i tipi deserializzabili e i percorsi delle classi è una misura approfondita. Le regressioni dovrebbero coprire i cursori legali, i risultati impaginati e i rifiuti di input di eccezioni e controllare le versioni effettive dei componenti all’interno del JAR dell’applicazione finale.

4.4 Spring Security: CVE-2026-59270 e relativi rischi di autenticazione

CVE-2026-59270, 20/08/2026, Critical. incorporato UnboundIdContainer registra le credenziali di amministratore conosciute per impostazione predefinita e ascolta su tutte le interfacce di rete. Quando il componente è abilitato e la porta è raggiungibile, un utente malintenzionato può leggere o modificare i dati della directory; i progetti che generalmente introducono Spring Security non esporranno automaticamente LDAP. S27

Zona interessata:

ramo	colpito	Primo canale di correzione/acquisizione
7.1	7.1.0	7.1.1 OSS; anche commerciale 7.1.0.1
7.0	7.0.0—7.0.6	7.0.7 OSS; anche commerciale 7.0.6.1
6.5 / 6.4	6.5.0—6.5.11；6.4.0—6.4.18	6.5.12/6.4.19, commerciale
5.8 / 5.7	5.8.0—5.8.27；5.7.0—5.7.25	5.8.28/5.7.26, commerciale

Fonte: S27. Risolvere i problemi relativi alla configurazione automatica spring.ldap.embedded.* e al codice di istanziazione diretta; chiudere il componente quando non è necessario per la produzione e verificare l’effettivo indirizzo di ascolto. Quando l’azienda ne ha realmente bisogno, limita prima le fonti di chiamata e poi completa l’aggiornamento dei componenti.

**Problema di autenticazione correlato: CVE-2026-47841 (High).**WebAuthn L’autenticazione utente è impostata su REQUIRED e dopo che la sessione HTTP è stata serializzata dall’archiviazione distribuita, il confronto errato dell’identità dell’oggetto potrebbe invalidare il requisito di autenticazione. L’attacco richiede inoltre che l’aggressore sia in possesso del dispositivo di autenticazione dell’utente e non di un accesso remoto arbitrario senza dispositivo. Per le corrispondenti versioni interessate di 7.1, 7.0, 6.5 e 6.4, la linea di base della patch è coerente con questi rami nella tabella sopra; la verifica dovrebbe coprire le sessioni tra nodi e richiedere comunque la verifica PIN/biometrica. S28

5. Ecosistema Python: interprete, libreria standard, framework e certificati

5.1 CVE-2026-19445: SSLContext UAF nella richiamata SNI

Data di pubblicazione: 2026-09-30; PSF Livello: Critical. Nel server Python TLS, sni_callback commuta la connessione a un altro SSLContext e quando il contesto originale non ha altri riferimenti sopravvissuti, il non autenticato Il client TLS potrebbe arrestare in modo anomalo il servizio o richiamare un puntatore in un oggetto rilasciato. S29

Il nocciolo della questione è che l’oggetto Python non è coerente con il ciclo di vita del callback TLS sottostante. Il contesto originale è stato rilasciato e il livello sottostante potrebbe ancora mantenere lo stato richiesto per la richiamata; è necessario utilizzare la patch nativa dell’interprete per correggere il ciclo di vita di riferimento. S47

Ambito: Il codice Python che funge solo da client TLS non è interessato da questo elemento; la modalità normale della presa di ascolto che mantiene il contesto originale per lungo tempo non rientra nello specifico percorso di fallimento descritto nell’annuncio. Dopo che Nginx ha terminato TLS, trasferisce solo lo HTTP locale a Python e Python gestisce direttamente SNI da solo, che è una superficie di attacco diversa. S29

Corrispondente alla versione fissa di 3.10—3.14, vedere la sezione 2.3.. La versione ufficiale di 3.15 è stata riparata e 3.15.1 può effettivamente essere selezionato. Il solo aggiornamento della dipendenza pip non può sostituire l’implementazione _ssl dell’interprete. S33 S35 S47

Mitigazione temporanea ufficiale: mantiene riferimenti forti a tutti gli SSLContext che hanno impostato il callback SNI fino alla fine del ciclo di vita del server. Ciò deve coprire l’effettiva creazione dinamica e i percorsi di commutazione; la build personalizzata OpenSSL 1.1.1 dovrebbe anche verificare le condizioni di rinegoziazione insieme al record di emissione ufficiale e dare priorità agli aggiornamenti completi. S29 S47

5.2 CVE-2026-19553: il flag del nome host è attivato, ma il nome host manca durante la chiamata

Data pubblica: 30-09-2026; High. QuandoSSLContext.check_hostname=True, se wrap_bio() non viene passato in server_hostname, l’implementazione originale potrebbe ignorare silenziosamente la verifica del nome host. Una verifica riuscita della catena di certificati non significa che anche il nome di dominio di destinazione sia stato abbinato. S30

La riparazione richiede entrambi i passaggi:

Installare la versione di sicurezza dell’interprete elencata nella sezione 2.3.
Controlla wrap_bio(), i relativi percorsi asyncio.create_connection() / loop.start_tls(), passa esplicitamente il nome host previsto e non vuoto e mantieni attivata la verifica del certificato. S30

**Differenze di compatibilità che non possono essere omesse:**3.10, 3.11, 3.12 sono per compatibilità, solo DeprecationWarning viene rilasciato per alcuni casi in cui manca il nome host; 3.13 e successivamente rilanciano ValueError. Il backport 3.12 distingue inoltre chiaramente None dalle stringhe vuote: viene aggiunto un nuovo avviso per None e viene ancora segnalato un errore per le stringhe vuote. Pertanto, gli utenti di livello inferiore non possono presumere che la verifica del nome di dominio originariamente mancante sia stata ripristinata automaticamente semplicemente aggiornando. S31 S33

In un ambiente di test, utilizzare un certificato di catena attendibile con un nome host non corrispondente e verificare che il client TLS dell’applicazione effettiva lo rifiuti. La semplice lettura del valore booleano check_hostname non costituisce completa accettazione.

5.3 CVE-2026-82049: bypass della combinazione di collegamenti nel filtro del file tar

Data pubblica: 2026-09-14; High. In CPython 3.13 e precedenti implementazioni correlate, la combinazione di collegamenti reali e collegamenti simbolici in tar non attendibile può ignorare il filtro di estrazione data / tar, esponendo il contenuto dei file all’esterno della directory di decompressione nell’albero di decompressione o modificandone permessi e tempi di modifica. S32

Gli impatti confermati di questa vulnerabilità includono l’esposizione del contenuto dei file e la modifica dei metadati; questi impatti da soli non sono sufficienti a dimostrare la sovrascrittura arbitraria del contenuto di file esterni o l’implementazione incondizionata di RCE.

Per le patch di base corrispondenti di 3.10—3.13, vedere la sezione 2.3. Python 3.14 è stato esentato da questo problema specifico a causa dei cambiamenti di comportamento di os.link() da allora 3.14.0b1, quindi l’ambito interessato del ramo 3.10—3.13 riportato sopra non si applica. S33

Misure temporanee e approfondite: sospendere l’estrazione automatica degli archivi non attendibili; utilizzare processi di lavoro isolati a basso privilegio e nuove directory esclusive quando l’azienda deve essere elaborata, negare collegamenti simbolici, collegamenti fisici e voci di dispositivo per azienda e limitare il numero di file e risorse di decompressione. Questi sono consigli per la distribuzione.

filter="data" è più adatto per archivi generici non attendibili rispetto alla strategia di attendibilità totale, ma anche il filtro stesso della vecchia versione presenta questa vulnerabilità e l’aggiunta di questo parametro da sola non può sostituire l’aggiornamento. Inoltre, il filtro non è un sandbox completo del file system. S32 S45

5.4 Rischio supplementare: CVE-2026-114583 (Medium) e stato di rilascio della patch

PSF ha rivelato in 2026-10-22 che l’elaborazione di nomi di collegamento specifici da parte di tarfile.tar_filter può essere aggirata, consentendo ai membri successivi di scrivere all’esterno della directory di spacchettamento, con un livello di Medium. La correzione ufficiale PR è stata fusa quel giorno; a partire dal 23 ottobre 2026, non è stata confermata alcuna versione di manutenzione ufficiale contenente questo commit. S40

Pertanto:

Questo articolo è elencato separatamente come Medium.
Non si può ritenere che le versioni dell’interprete rilasciate il 21 ottobre contengano questa correzione.
Il processo che utilizza ancora filter="tar" per gestire gli archivi non attendibili dovrebbe tenere traccia del backport del rilascio; isolare o sospendere questo percorso di elaborazione per un breve periodo di tempo. Quando si passa a data e si rifiutano i collegamenti, è necessario anche confermare che soddisfi i requisiti aziendali e la modifica del filtro non può essere descritta come una sandbox incondizionata.

5.5 GeoDjango: CVE-2026-15307 e successive correzioni di ottobre

2026-08-04, la query spaziale ufficiale Django High. passa implicitamente determinate stringhe/dizionari a GDALRaster e il driver può scrivere file o avviare richieste di rete; RCE può essere formato quando esistono percorsi specifici e conseguenti condizioni di esecuzione. Anche il personale con autorizzazioni di visualizzazione del modello di campo spaziale può accedere a questo percorso tramite l’elenco delle modifiche di amministrazione. S38

La correzione iniziale è 5.2.17 / 6.0.8, che limita i tipi di input accettati dalle ricerche spaziali. Questa modifica potrebbe influenzare l’attività originale di utilizzare stringhe/dizionari per esprimere raster; racchiudere semplicemente l’input non attendibile in GDALRaster non significa verificarlo. S38

Il 6 ottobre, CVE-2026-87890 (Moderato) è stato riparato: il VRT espresso in byte può fare riferimento a risorse esterne e attiva comunque richieste di rete; nello stesso giorno è stata rafforzata anche la protezione della geometria annidata DoS di CVE-2026-15830. Gli ultimi due non possono essere aggiornati per descrivere il nuovo RCE ad alto rischio, ma indicano che la linea di base di distribuzione dovrebbe essere 5.2.18 / 6.0.9 / 6.1.2. S39

L’implementazione controlla i due punti di ingresso dell’API e dell’interfaccia di amministrazione, limita la ricerca spaziale non attendibile, i permessi di scrittura dei file e l’accesso in uscita; dopo l’aggiornamento, sottoporre a test di regressione query spaziali valide e rifiutare input vietati. Le normali applicazioni Django che non utilizzano GeoDjango non dovrebbero applicare direttamente questa conclusione RCE.

5.6 certifi / pip: L’attendibilità del certificato deve coprire ogni copia

GHSA-6q48-6c7w-9gw2, 20-10-2026, Critical, noto CVE non elencato. Questo è l’aggiornamento della sfiducia del certificato causato dall’incidente intermedio eMudhra CA. Non può essere riassunto come il meccanismo di crittografia di HTTPS o come il fatto che tutti i certificati root siano stati violati. S36

L’avviso certifi elencava originariamente 2026.10.18 come patch; PSF ha successivamente consigliato esplicitamente 2026.10.19 per preservare la compatibilità con i certificati root non interessati. La linea di base operativa è .19. S36 S37

È necessario distinguere:

Fidati della posizione del materiale	Perché è necessario controllare separatamente
Pacchetto sistema operativo CA	Materiale attendibile del sistema per l’immagine o l’host
certifi nella venv	CA bundle effettivamente utilizzato dalle applicazioni o dalle richieste ecc.
pip integrato certifi	È una copia diversa rispetto allo certifi installato esternamente
uv / Altri strumenti di imballaggio	Segui gli aggiornamenti e le fonti attendibili dello strumento
File CA personalizzati, istantanee in pacchetto	Può continuare a sovrascrivere le origini attendibili predefinite per sistemi o pacchetti

Quanto sopra è una lista di controllo basata su diverse posizioni di imballaggio. PSF richiede l’aggiornamento degli strumenti correlati, degli ambienti virtuali esistenti e la ricostruzione dell’immagine; il solo aggiornamento dell’host CA o la reinstallazione dell’interprete non possono dimostrare che tutte le copie siano state aggiornate. S35 S37

Quando si esegue l’aggiornamento dal vecchio bootstrap sicuro pip, PSF fornisce i comandi per ruota fissa e SHA-256, vedere l’appendice S37. Non disattivare la verifica TLS né aggiungere --trusted-host per aggirare i problemi del certificato.

6. Processo di riparazione formale

I seguenti comandi sono per ambienti attendibili confermati. Durante l’esecuzione, il gestore pacchetti esistente, il file di blocco e il processo di distribuzione del progetto devono essere combinati per evitare di mescolare npm/pnpm/yarn o pip/uv/Poetry per generare file di blocco in conflitto.

Gestisci prima un’eccezione: Se sospetti che l’ambiente abbia eseguito il pacchetto compromesso nella Sezione 9, isolalo prima e controlla il disco, blocca il file e il record dell’immagine da un ambiente pulito; non eseguire prima il seguente comando Python/pip. S41

6.1 Stabilisci un registro che possa corrispondere al traffico reale

Ciascun servizio registra almeno:

Punto di ingresso esterno, proxy inverso, percorso di connessione diretta al sito di origine e coda in background/attività pianificate.
Il comando di avvio effettivo, l’account in esecuzione, il percorso binario, l’identità del processo o del contenitore.
Versione completa del runtime, editore/repository, versione completa del pacchetto o digest dell’immagine.
Dipendenze framework e transitive, file di blocco, librerie native e percorsi di truststore.
Corrisponde all’esistenza o meno della condizione di vulnerabilità, alla destinazione della patch, all’ambito del riavvio, alla persona responsabile e al risultato della verifica.

Anche le macchine di sviluppo, i corridori CI, i contenitori di build e le attività in background dovrebbero essere controllati in base ai loro percorsi verso contenuti non attendibili; non limitarti ad aggiornare il contenitore web rivolto al pubblico.

6.2 Node.js: determinare prima il runtime, quindi aggiornare le dipendenze dell’applicazione

Controllare nell’ambiente di servizio reale:

node -p 'JSON.stringify({execPath:process.execPath,node:process.version,openssl:process.versions.openssl,brotli:process.versions.brotli},null,2)'
npm ls next react react-dom react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack sharp --all
npm audit --omit=dev

node -p deve essere eseguito utilizzando l’eseguibile effettivo del servizio o all’interno di un contenitore effettivo; controlla i processi appena avviati e non dimostra personalmente che il vecchio lavoratore sia stato sostituito. Node può aggiungere la patch allo Brotli integrato mantenendo la stringa della versione della libreria originale. Pertanto, non fare affidamento esclusivamente su process.versions.brotli per determinare se è stato riparato. Dovresti combinarlo con la versione di sicurezza Node o con la prova backport del fornitore. S2 S4

npm ls viene utilizzato per vedere l’albero delle dipendenze effettivo; pacchetti mancanti o conflitti tra pari possono anche produrre codici di uscita diversi da zero, quindi dovresti leggere l’output specifico. npm audit viene utilizzato come ausilio per il controllo delle dipendenze e non può sostituire il controllo della libreria binaria e nativa Node.

Utilizzare mise per gestire l’ambiente di Node 24, che può essere aggiornato come segue:

mise use -g [email protected]
mise exec [email protected] -- node -p 'process.version + " " + process.execPath'

mise use -g configura la versione globale; la configurazione locale del progetto deve ancora essere verificata separatamente. Se il servizio ha corretto il vecchio percorso assoluto, l’immagine di base del contenitore o l’ambiente di un account diverso, la configurazione corrispondente deve essere aggiornata e il servizio deve essere riavviato. Il comando in sé non sostituisce un vecchio processo in esecuzione. S43

Nel progetto Next, eseguire il comando corrispondente in base al ramo selezionato. Per Next 15:

# Next 15 分支
npm install --save-exact [email protected]

Per Next 16:

# Next 16 分支
npm install --save-exact [email protected]

Controlla le dipendenze compatibili con React/RSC, blocca i file e l’istanza finale di Sharp, quindi crea in base al processo di progetto. Utilizza il file di blocco aggiornato in CI per un’installazione riproducibile e controlla la versione nell’immagine in esecuzione dopo la creazione. Non utilizzare la riparazione automatica incontrollata nelle versioni principali come soluzione predefinita per questa emergenza.

6.3 Java: verifica editore, JVM effettivo e componenti incorporati

Inventario preliminare:

java -XshowSettings:properties -version

java.home, java.runtime.version e editore nell’output dovrebbero essere allineati con JVM effettivamente utilizzato dal servizio. Per JVM con autorizzazione di collegamento, jcmd di JDK può essere utilizzato per controllare il processo di destinazione, non solo la shell di accesso.

Controlla le dipendenze nei progetti attendibili e seleziona in base agli strumenti di creazione effettivi:

./mvnw dependency:tree '-Dincludes=org.apache.tomcat.embed:*,org.springframework.security:*,org.springframework.graphql:*'

./gradlew dependencyInsight --dependency tomcat-embed-core --configuration runtimeClasspath
./gradlew dependencyInsight --dependency spring-security-core --configuration runtimeClasspath
./gradlew dependencyInsight --dependency spring-graphql --configuration runtimeClasspath

Questi comandi di compilazione possono eseguire plug-in e risolvere dipendenze online ed essere eseguiti solo su progetti attendibili. Controlla il JAR/WAR finale o il JAR effettivo nell’immagine e non sostituire le dichiarazioni del file di build per l’artefatto finale. Spring L’avvio integrato Tomcat richiede la ricostruzione dell’applicazione; l’aggiornamento di un’installazione Tomcat separata nel sistema non modificherà la copia nel pacchetto dell’applicazione.

Dopo aver aggiornato il runtime, controlla il javax.net.ssl.trustStore personalizzato, il KeyStore caricato automaticamente dall’applicazione, il runtime jlink, l’immagine GraalVM/nativa e altri moduli di consegna articolo per articolo. Le applicazioni che dispongono già di materiali attendibili personalizzati non possono terminare il controllo solo perché la directory JDK diventa nuova.

6.4 Python: elaborazione interprete per interprete ed ambiente virtuale

All’interno del venv/container effettivo confermato come attendibile:

python - <<'PY'
import sys
import ssl
import importlib.metadata as metadata

print("executable:", sys.executable)
print("version:", sys.version)
print("openssl:", ssl.OPENSSL_VERSION)
print("verify_paths:", ssl.get_default_verify_paths())
for name in ("pip", "certifi", "Django", "urllib3", "Brotli", "litellm"):
    try:
        print(name + ":", metadata.version(name))
    except metadata.PackageNotFoundError:
        print(name + ": not installed")
PY

python -m pip --version
python -m pip check

Questo script raccoglie solo informazioni e non esegue la determinazione della qualificazione della versione. ssl.get_default_verify_paths() è l’informazione sul percorso predefinito e non può dimostrare che tutti i client di terze parti utilizzino lo stesso truststore; dovrebbe essere confermato in base alla configurazione dell’applicazione.

Dopo aver completato l’aggiornamento di avvio attendibile pip dell’appendice S37, aggiornare le dipendenze del certificato in base ai vincoli del progetto, ad esempio:

python -m pip install --upgrade 'certifi>=2026.10.19'

# 仅适用于当前就选择 Django 5.2 的项目
python -m pip install --upgrade 'Django>=5.2.18,<5.3'

python -m pip check

I requisiti/file di blocco del progetto devono essere aggiornati contemporaneamente, altrimenti la successiva distribuzione potrebbe ripristinare la versione precedente. Quando si utilizza uv, Poetry o un repository di pacchetti aziendali, utilizzare i processi di blocco e pubblicazione esistenti; non modificare manualmente i pacchetti solo all’interno di un contenitore di produzione.

Il flusso di lavoro pip-audit esistente del progetto può essere utilizzato per verificare le vulnerabilità note delle dipendenze in un ambiente affidabile; non è uno scanner di codici dannosi e non copre tutti i rischi legati all’interprete, alla libreria di sistema e al trust store. S44

Non è consigliabile forzare il sistema /usr/bin/python3 a puntare a una nuova versione compilata. Utilizzare gli aggiornamenti di sicurezza del rilascio o i runtime di isolamento del progetto per evitare di interrompere gli strumenti di gestione che si basano sul sistema Python. Si tratta di una scelta di implementazione e non di un requisito di correzione aggiuntivo per questa vulnerabilità.

6.5 Ricostruisci e sostituisci l’istanza in esecuzione

Si consiglia di eseguire i seguenti passaggi come modifica completa:

Ottieni la patch dalla fonte attendibile originale e salva la versione/hash e il blocco delle dipendenze.
Restituisci le funzioni chiave in un ambiente quasi di produzione e conferma che le estensioni native sono compatibili con JVM/framework.
Aggiornare il runtime, le dipendenze dell’applicazione e l’effettivo trust store; aggiorna l’immagine di base e il sistema CA per il contenitore, non riutilizzare semplicemente il vecchio livello.
Ricostruisci applicazioni e immagini e sostituisci le istanze di servizi, lavoratori, consumatori di code e attività pianificate su base continuativa.
Ricontrolla la versione e la configurazione nella nuova istanza in esecuzione e conferma che tutte le vecchie copie sono state chiuse.
Osserva i tassi di errore, la latenza, CPU/memoria, errori di handshake TLS e arresti anomali dei processi.

Il rollback dovrebbe dare priorità al mantenimento della sicurezza delle dipendenze di runtime e patch e al rollback della configurazione dell’applicazione o delle modifiche aziendali. Se è necessario ritornare a un vecchio prodotto che presenta vulnerabilità, le corrispondenti restrizioni all’accesso dovrebbero essere ripristinate contemporaneamente e la persona responsabile e il periodo minimo di ripristino dovrebbero essere chiaramente definiti.

7. Mitigazione temporanea e selezione delle patch

7.1 Limite di copertura delle misure temporanee

Di seguito sono riportate proposte di implementazione basate sulle condizioni di utilizzo annunciate. A meno che non venga annotato il piano ufficiale, il venditore non garantisce che tutte le varianti possano essere completamente bloccate.

rischio	Misure temporanee che possono essere adottate	La parte che non può ritenersi completata in base a ciò
Decodifica Brotli	Arresta la decodifica degli input non attendibili; controllare la decompressione automatica in entrata e in uscita	WAF in entrata o la disattivazione della compressione della risposta non copre tutte le voci di decodifica S3
Next.js typed arrays RCE	Aggiorna immediatamente; isolare temporaneamente i servizi interessati, se necessario	Non esiste una soluzione universale affidabile ufficiale S9
Next.js SVG RCE	Piano ufficiale: garantire la nitidezza effettiva ≥0.35.5; sospendere i punti di ingresso rilevanti per l’ottimizzazione quando l’azienda lo consente	Non copre altri problemi Next/RSC S11
Regno Tomcat / HTTP/2 / AJP	Isolare il percorso corrispondente e chiudere i connettori non necessari	È ancora necessario il pacchetto di riparazione della filiale corrispondente S21 S22 S23
GraphQL Deserializzazione	Sospendere i campi di connessione interessati; limitare i chiamanti non attendibili	Solo il limite di lunghezza della richiesta non può risolvere il problema di tipo/deserializzazione S25
Spring embedded LDAP	Disabilitare quando non necessario; limitare la portata della porta di ascolto reale	È ancora necessario verificare l’identità amministrativa predefinita e l’integrità della directory S27
CPython SNI UAF	Piano ufficiale: Conservare il relativo riferimento forte SSLContext fino alla fine del servizio	Tutti i percorsi di creazione/cambio devono essere coperti S29
Salta il nome host Python	Soluzione ufficiale: passa correttamente il server_hostname previsto	Non è possibile semplicemente controllare il flag check_hostname o ignorare l’avviso S30 S31
Tar inaffidabile	Disabilita/metti in quarantena l’estrazione, rifiuta i collegamenti non essenziali e le voci del dispositivo	Né i filtri né le quote delle risorse sono sandbox universali S32 S40 S45
Evento di attendibilità del certificato	Aggiorna il materiale CA corretto; La fiducia Java può essere limitata in base alla mitigazione ufficiale	La disabilitazione della verifica TLS aumenta il rischio S19 S37

7.2 Selezionare la patch in base al metodo di consegna

Metodo di consegna	Dare priorità ai metodi di riparazione	Prove che dovrebbero essere conservate
Runtime gestito dalla distribuzione	Aggiornamenti di sicurezza corrispondenti del produttore	Versione completa del pacchetto, annuncio, fonte del repository
Gestore binario/runtime ufficiale	Rilascio di sicurezza ufficiale della stessa filiale	Versione, sorgente e digest, percorso di esecuzione effettivo
Node / CPython autocompilati	La versione sorgente ufficiale del ramo corrispondente o il set completo di patch del fornitore	Set di commit, parametri di creazione, librerie dipendenti e risultati di regressione
Spring / Next / Django	Compatibile con gli aggiornamenti in filiale, la ricostruzione dei blocchi delle dipendenze e le applicazioni finali	Albero delle dipendenze finale, versione attuale in JAR/pacchetto/immagine
Negozio di fiducia personalizzato	Piano di ritiro ufficiale o aggiornamento del fornitore che conferma il ritiro	Percorso di utilizzo effettivo, cambio materiale, test di successo e rifiuto TLS
Un ambiente compromesso	Ricostruire utilizzando prodotti puliti e affidabili e condurre indagini separate sugli incidenti	Digest storico del pacchetto/immagine, record di installazione, record di rotazione delle credenziali

7.3 Meccanismo di patch chiave e focus di revisione

Brotli: presta attenzione al completamento del controllo dei limiti e della restituzione dell’errore dello stato di decodifica nativa prima di accedere alla build; solo sostituendo il pacchetto JavaScript non è possibile modificare il codice compilato staticamente in Node. S4
Node DNS/TLS: si concentra sul rifiuto dell’input, sulla normalizzazione degli indirizzi, sulla distinzione tra le identità IP SAN e DNS e sulla richiamata/promessa DNS. L’analisi test di corrispondenza del percorso e del nome host TLS. S5 S6
Tomcat JNDIRealm: si concentra sul fatto che il processo di autenticazione verifichi effettivamente le credenziali, piuttosto che ottenere semplicemente un contesto di directory; dando la priorità alla versione ufficiale e non trattando la sostituzione di un singolo file sorgente come una patch binaria completa. S24
CPython ssl: si concentra sulla proprietà di riferimento di Python e sul ciclo di vita del sottostante SSLContext; wrap_bio() esegue il backport pur presentando differenze di compatibilità dei rami ed è necessario leggere l’effettiva implementazione del ramo utilizzato. S31 S47
Sfiducia nel certificato: Tali aggiornamenti potrebbero apparire come materiale attendibile o modifiche all’elenco dei rifiuti anziché modifiche evidenti dell’API. Lo stesso lotto di Node include anche il meccanismo di rigetto dell’intermedio interessato CA; le rispettive fonti di fiducia di Java e Python devono ancora essere verificate separatamente. S19 S37 S46

**Deve essere controllata anche l’associazione Brotli indipendente.**Google ha rilasciato 1.0.10 / 1.1.1 / 1.2.1 lo stesso giorno per correggere CVE-2026-111497. Le estensioni native Python o gli artefatti JNI che incorporano la stessa implementazione C interessata devono essere aggiornati/ricostruiti in modo indipendente; non si può dedurre che tutti i decoder Java puri siano interessati, né si può presumere che l’aggiornamento Node sostituisca automaticamente le copie in altre lingue. S42

8. Verifica e controlli successivi

8.1 Lista di controllo minima di verifica

Controlla gli articoli	Prove richieste
tempo di esecuzione	La versione completa o la prova del backport del fornitore sono corrette nel processo/contenitore reale
dipendenze dell’applicazione	Next/RSC/sharp, Tomcat/Spring e Django/certifi nei prodotti di distribuzione finale hanno raggiunto la soglia corrispondente
Gamma di sostituzione	Tutte le copie lavoratore/JVM/contenitore e le attività in background sono state sostituite con nuove e le vecchie istanze sono state chiuse.
TLS	I certificati di dominio validi hanno esito positivo; i nomi host non corrispondenti e le catene non valide falliscono in base alla politica; sono inclusi gli archivi fiduciari personalizzati
eMudhra sfiducia	La catena di certificati creata dall’intermedio interessato CA è stata rifiutata durante il runtime effettivo oppure vi è prova che la build di sicurezza del fornitore specifico/l’elenco di rifiuto corrispondente sia stato distribuito; il caso non può essere chiuso in base al test generale TLS o al numero di versione breve Java 8.
Decodifica e immagini Node	Sono disponibili le funzioni di risposta compressa normale, caricamento, ottimizzazione dell’immagine e RSC; è in vigore la politica relativa alle fonti non attendibili
Java Autenticazione e isolamento	Password errata rifiutata; richieste asincrone simultanee di utenti indipendenti senza combinazione identità/risposta; LDAP ascolto come previsto
Python SNI / Archivio	Il normale business del nome multidominio TLS è stabile; l’archiviazione rifiuta l’attraversamento del percorso e i collegamenti non consentiti e i file esterni alla directory non vengono modificati
Dati e regressione funzionale	Il cercapersone, le query spaziali, il controllo dei permessi e le attività in background hanno superato i test esistenti del progetto
Risorse e osservazioni	Non si verifica alcun aumento anomalo di CPU, memoria, tasso di errore, latenza ed errori TLS.
Tracciabilità	Risparmia tempo di aggiornamento, sintesi di pacchetti/immagini, modifiche alla configurazione, risultati di verifica ed elementi irrisolti

Queste sono raccomandazioni di accettazione dell’implementazione e non richiedono la produzione di uno script di attacco per ogni CVE. La verifica che comporta arresti anomali, esaurimento delle risorse e archiviazione fuori dai limiti dovrebbe utilizzare test di regressione upstream o dati di test controllati dal progetto in un ambiente isolato.

8.2 L’applicazione di patch e l’indagine sulle intrusioni sono compiti diversi

Controlla i log esistenti per individuare errori di decodifica insoliti, arresti anomali del lavoratore/JVM, scritture di file sospette, modifiche ai dati della directory, eccezioni di autenticazione, richieste in uscita e record di utilizzo delle credenziali. Questi segnali devono essere giudicati nel contesto: un incidente o un OOM non sono la prova di uno sfruttamento riuscito; l’assenza di avvisi non dimostra che un sistema non sia stato interessato.

Quando vengono scoperte modifiche non autorizzate, credenziali compromesse o dipendenze dannose confermate, è necessario conservare le prove, isolare le istanze pertinenti, ruotare le credenziali interessate da un ambiente affidabile e ricostruire il sistema. La patch non revocherà i token ottenuti dall’aggressore né ripristinerà i dati che sono stati modificati.

9. Incidente relativo alla sicurezza della catena di fornitura: compromissione LiteLLM 1.107.0

**Data di conferma ufficiale: 21-10-2026.**LiteLLM ha riferito che la pipeline di rilascio è stata compromessa. litellm==1.107.0 di PyPI e alcuni prodotti Docker/GHCR dello stesso periodo contenevano codice dannoso per il furto di segreti e il controllo remoto e i prodotti correlati sono stati ritirati. S41

Per determinare l’impatto, è necessario controllare i record storici dell’installazione e il riepilogo delle immagini; etichette come latest, main-latest e main-stable ora indicano immagini pulite, il che non dimostra che i prodotti ritirati al momento dell’incidente fossero puliti. La raccomandazione ufficiale a quel tempo era di bloccare temporaneamente 1.106.2; questa raccomandazione si basava su questo incidente e altri annunci di sicurezza devono ancora essere controllati durante la distribuzione. S41

Per ambienti in cui sono stati installati o eseguiti prodotti correlati:

Isola e conserva record, immagini e registri di installazione e ispezionali da un ambiente pulito.
Non avviare prima Python/pip in un ambiente sospetto; .pth / sitecustomize.py dannoso potrebbero essere eseguiti nuovamente dopo l’avvio.
Ricostruire host, venv/contenitori da fonti attendibili; non è possibile semplicemente disinstallare o eseguire il downgrade dei pacchetti.
Revocare/ruotare le credenziali cloud, le chiavi del provider LLM, le chiavi LiteLLM e le credenziali del database in base all’effettiva accessibilità ed esaminare l’utilizzo anomalo. S41

Si tratta di un incidente confermato della catena di fornitura e richiede la considerazione dell’esecuzione di codice dannoso, della perdita di credenziali e dei rischi di persistenza quando viene affrontato. Al 23 ottobre 2026, i funzionari stavano ancora indagando sull’intrusione iniziale.

Appendice: fonti e link citati

La seguente data di verifica della fonte è 2026-10-23, incluso l’annuncio ufficiale sulla sicurezza del progetto, l’archivio ufficiale del codice e le istruzioni del fornitore. Il testo principale [Sx] corrisponde a questa appendice; quando si eseguono aggiornamenti è opportuno verificare se il fornitore ha rilasciato revisioni successive.

S1 — Node.js: 2026-10-21 Avviso di sicurezza

Scopo: quattro runtime High, che interessano le filiali, versione di sicurezza di ottobre.
Riferimento: Official Security Bulletin

S2 — Node.js: Istruzioni ufficiali di rilascio per tre linee di manutenzione

Scopo: controllare 22.23.4, 24.22.1, 26.12.1 e le patch effettivamente unite.
Riferimento: Node.js 22.23.4
Riferimento: Node.js 24.22.1
Riferimento: Node.js 26.12.1

S3 — Vercel: avviso di sicurezza Node.js Brotli RCE

Scopo: condizioni di decodifica in entrata/uscita, limite di copertura WAF, stato Node 20.
Riferimento: Node.js security advisory: Brotli decoder RCE

S4 — Node.js: invio patch ufficiale Brotli

Scopo: Base di implementazione per il controllo della decodifica nativa e la propagazione degli errori.
Riferimento: Brotli Patch commit 49dff6f57a

S5 - Node.js: patch di normalizzazione dell’indirizzo TLS

Scopo: verifica dell’identità del certificato di numeri a larghezza intera e IP non standard.
Riferimento: IP normalization regression Patch
Riferimento: rejects the patching of non-standard IP address

S6 — Node.js: patch di verifica DNS NUL

Scopo: Rifiuto dell’input e copertura della regressione.
Riferimento: dns.resolve Input verification patch

S7 — Node.js: 2026-07-29 Avviso di sicurezza

Scopo: esaurimento della memoria HTTP/2, UAF e vulnerabilità del modello di autorizzazione.
Riferimento: July 2026 Security Releases

S8 — Next.js: aggiornamento della sicurezza 2026-10-14

Scopo: unificare la baseline di aggiornamento e tre rischi principali.
Riferimento: Next.js Security Update for Upstream Vulnerabilities

Riferimento: S9 — Next.js：typed arrays / use cache RCE

Scopo: GHSA-673q-mjm6-r5xr; influisce sull’intervallo, sulla condizione, sul punteggio e sullo stato della soluzione alternativa.
Riferimento: Next.js Official Security Bulletin

Riferimento: S10 — React：React Server Components RCE

Scopo: GHSA-xqc2-xf4c-x3h3; versioni interessate e corrette di tre pacchetti RSC.
Riferimento: React Official Security Bulletin

Riferimento: S11 — Next.js：SVG Image Optimization RCE

Scopo: CVE-2026-96889 / GHSA-2464-fhr4-w9xw; confini della versione glibc, nitidi e originali.
Riferimento: SVG Image Optimization Official Security Bulletin

Riferimento: S12 — Next.js：Server Actions DoS

Scopo: GHSA-p3m5-59mp-jv5r; influenza le condizioni, le versioni e le classificazioni.
Riferimento: Server Actions DoS Official Security Bulletin

S13 — Next.js: AVIF Ottimizzazione dell’immagine RCE

Scopo: 25-08-2026, GHSA-2xp9-vwfh-vxw4.
Riferimento: AVIF Official Security Bulletin

Riferimento: S14 — Next.js：Windows RCE

Scopo: 25-08-2026, CVE-2026-75604/GHSA-p293-qw3h-jr36.
Riferimento: Windows RCE Official Security Bulletin

Riferimento: S15 — Next.js：next/og ImageResponse RCE

Scopo: 22-09-2026, GHSA-vcvr-r3jv-pc5j; Differenza tra Node e Edge.
Riferimento: ImageResponse Official Security Bulletin
Riferimento: September 22 release notes

Riferimento: S16 — Oracle: October 2026 CPU

Scopo: matrice di rischio Java SE, quantità di patch e condizioni applicabili.
Riferimento: Oracle Critical Patch Update – October 2026
Riferimento: Oracle Java SE CPU Version list

S17 — Oracle: CVE-2026-91403 allarme fuori banda

Scopo: 21-10-2026, rischio di attendibilità del certificato JSSE, prodotti interessati e CVSS 3.1 9.1.
Riferimento: Oracle Security Alert

S18 — Oracle: JDK versione ufficiale e download

Scopo: distinguere tra CPU il 20 ottobre e la versione fuori banda il 21 ottobre; distinguere le limitazioni della versione breve di Java 8.
Riferimento: JDK release list
Riferimento: Oracle Java Download page

S19 — Oracle: eMudhra piano di ritiro temporaneo

Scopo: aggiornato il 22-10-2026; due certificati radice, keytool, truststore personalizzato e controllo delle revoche.
Riferimento: Distrusting eMudhra Intermediate Certificates in Oracle JDK

S20 — Eclipse Adoptium: rilascia il record della build

Scopo: Temurin viene riconfezionato a causa dell’incidente del certificato; il suffisso della versione Oracle non può essere applicato meccanicamente.
Riferimento: Adoptium Release Scorecards

S21 — Apache Tomcat 9 Avviso di sicurezza

Scopo: intervallo interessato esatto di 9 diramazioni con correzione 9.0.123.
Riferimento: Tomcat 9 vulnerabilities

S22 — Apache Tomcat 10 Avviso di sicurezza

Scopo: intervallo preciso del ramo 10.1 e riparazione 10.1.61; 10.0 EOL.
Riferimento: Tomcat 10 vulnerabilities

S23 — Apache Tomcat 11 Avviso di sicurezza

Scopo: tre articoli Important, 11.0.27, AJP ambito applicabile e data di divulgazione/rilascio.
Riferimento: Tomcat 11 vulnerabilities

S24 - Apache Tomcat: commit della patch JNDIRealm

Scopo: Base formale per colmare le lacune nella verifica della certificazione.
Riferimento: JNDIRealm Patch commit

Riferimento: S25 — Spring：GraphQL CVE-2026-59285

Scopo: 20/08/2026, Obbligatorio, 2.0.5 OSS / 2.0.4.1 Riparazione commerciale.
Riferimento: Spring for GraphQL Unsafe Deserialization

Riferimento: S26 — Spring：GraphQL CVE-2026-41699

Scopo: una soglia fissa precedente, solo per spiegare perché non è possibile rimanere al vecchio livello di base.
Riferimento: 6 Month GraphQL Security Bulletin

Riferimento: S27 — Spring Security：CVE-2026-59270

Scopo: incorporare UnboundID LDAP, identità di gestione nota e distinguere OSS/versione commerciale.
Riferimento: Spring embedded LDAP Security Bulletin

Riferimento: S28 — Spring Security：CVE-2026-47841

Scopo: autenticazione utente WebAuthn, serializzazione della sessione e premessa di attacco.
Riferimento: WebAuthn Security Bulletin

S29 — PSF: CVE-2026-19445 Consulenza sulla sicurezza indipendente

Scopo: 30-09-2026, Critical, SNI Condizioni e misure temporanee citate da SSLContext.
Riferimento: SSLContext UAF Official announcement

S30 — PSF: CVE-2026-19553 Consulenza sulla sicurezza indipendente

Scopo: 30-09-2026, High, nome host mancante e mitigazione dei parametri espliciti.
Riferimento: wrap_bio Official announcement of hostname verification

S31 — CPython: patch ufficiale wrap_bio e backport 3.12

Scopo: 3.10—3.12 criterio di compatibilità degli avvisi, la differenza tra None e la stringa vuota.
Riferimento: Main Patch PR #158503
Riferimento: 3.12 Backfill PR #158513
Riferimento: 3.15 Backfill PR #158511

S32 — PSF: CVE-2026-82049 Consulenza sulla sicurezza indipendente

Scopo: 2026-09-14, High, combinazione di collegamenti, modifica dei metadati ed esposizione dei contenuti.
Riferimento: tarfile link bypasses the official announcement

S33 — CPython: rilascio di sicurezza ufficiale a fine settembre/inizio ottobre

Scopo: versione minima della correzione, metodo di distribuzione del codice sorgente ed esenzione 3.14 per problemi specifici del file tar.
Riferimento: Python Cross-branch security release instructions
Riferimento: Python 3.11.17
Riferimento: Python 3.12.15
Riferimento: Python 3.13.16
Riferimento: Python 3.14.8

S34 — CPython: 3.10 ultimo rilascio sicuro

Scopo: 3.10.22 e fine del ciclo di vita a monte.
Riferimento: Python 3.10.22

S35 — CPython: versione per manutenzione di emergenza del 21-10-2026

Scopo: 3.13.17 / 3.14.9 / 3.15.1, aggiornamenti pip e certifi integrati, requisiti venv esistenti.
Riferimento: Python 3.13.17
Riferimento: Python 3.14.9
Riferimento: Python 3.15.1

S36 — certifi: annuncio di sfiducia del certificato emSign

Scopo: 20-10-2026, GHSA-6q48-6c7w-9gw2, Critical, CVE non noto.
Riferimento: certifi Official Security Bulletin

S37 — PSF: impatto di eMudhra / emSign sugli utenti Python

Scopo: raccomandazione certifi .19, base pip/uv, comando di aggiornamento di avvio attendibile con SHA-256.
Riferimento: PSF Official event and upgrade instructions

Il comando di aggiornamento di avvio pip fornito dalle istruzioni ufficiali citate da S37 è il seguente. Da utilizzare solo in ambienti Python che sono stati confermati affidabili; se vi è il sospetto di avvelenamento nella Sezione 9, isolare e ricostruire innanzitutto secondo il processo dell’incidente. Corregge l’hash del contenuto della ruota e successivamente aggiorna altre dipendenze in base al processo del progetto.

python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"

S38 — Django: 2026-08-04 rilascio sicuro

Utilizzo: CVE-2026-15307, GeoDjango Condizioni di sfruttamento, correzioni iniziali e modifiche alla compatibilità.
Riferimento: Django 6.0.8 / 5.2.17

S39 — Django: 06/10/2026 rilascio sicuro

Scopo: CVE-2026-87890, geometria DoS armatura successiva con la linea di base attualmente selezionata.
Riferimento: Django 6.1.2 / 6.0.9 / 5.2.18

S40 — PSF / CPython: ultima nota a margine tar_filter

Scopo: 22-10-2026, CVE-2026-114583 (Medium); La fusione PR non significa che sia stata rilasciata la versione di manutenzione ufficiale.
Riferimento: PSF Independent Announcement
Riferimento: CPython Patch PR #160098

S41 — LiteLLM: Rapporto ufficiale sugli incidenti nella catena di fornitura, 21 ottobre

Scopo: prodotto contaminato 1.107.0, raccolta storica, ricostruzione dell’isolamento e smaltimento delle credenziali.
Riferimento: Contained: LiteLLM v1.107.0 Compromised

S42 — Google Brotli: versione sicura ufficiale

Scopo: Brotli 1.0.10 / 1.1.1 / 1.2.1 indipendente e base di verifica della copia incorporata in più lingue.
Riferimento: Brotli releases

S43 — mise: usa la documentazione ufficiale del comando

Scopo: specificare la versione dello strumento e la semantica dei comandi della configurazione globale.
Riferimento: mise use

S44 — PyPA: progetto ufficiale di audit pip

Scopo: Python Lo scopo e i limiti delle capacità del controllo delle vulnerabilità delle dipendenze.
Riferimento: pip-audit

S45 — Python: documento filtro di estrazione file tar

Scopo: strategia dei dati, modifiche del comportamento predefinito e restrizioni che non possono sostituire la sandbox.
Riferimento: tarfile extraction filters

S46 — Node.js: meccanismo di rifiuto intermedio CA

Scopo: questa elaborazione della catena di fiducia correlata a eMudhra non equivale all’invalidazione crittografica di tutti i certificati radice.
Riferimento: Node.js PR #66871

S47 — CPython: SNI UAF note tecniche e correzioni

Scopo: ciclo di vita di riferimento, condizioni di costruzione speciali e backtracking del ramo.
Riferimento: official issue #156293
Riferimento: official patch PR #158504
Riferimento: 3.15 Backfill PR #158514