PTC Windchill e FlexPLM CVE-2026-126325: RCE critica da deserializzazione

PTC ha rilasciato le patch per una nuova falla critica di esecuzione di codice remoto in Windchill e FlexPLM — i sistemi di product lifecycle management (PLM) che custodiscono modelli CAD, distinte base e dati di progettazione regolamentati di aziende aerospaziali, automobilistiche, della difesa e dei dispositivi medici. CVE-2026-126325 è una deserializzazione di dati non attendibili che può portare all'esecuzione di codice sull'application server, valutata CVSS 9.2 da PTC. Non risultano ancora sfruttamenti in corso e la vulnerabilità non è nel catalogo KEV della CISA. Questa è la finestra, non il cessato allarme: a giugno 2026 il precedente bug di deserializzazione negli stessi identici prodotti, CVE-2026-12569, passò dall'advisory al KEV con scadenza federale di tre giorni in otto giorni, con gli attaccanti che installavano web shell sulle istanze esposte a internet. L'orologio su questa falla è già partito.

Notizia in evoluzione — pubblicata alle 14:10 (13:10 UTC) del 12 novembre 2026. Aggiornata man mano che PTC e CISA pubblicano.

In breve

CVE	CVE-2026-126325
Prodotto / versioni colpite	PTC Windchill 11.0 M030 · 11.1 M020 · 11.2.1.0 · 12.0.2.0 · 12.1.2.0 · 13.0.2.0 · da 13.1.0.0 a 13.1.4.0; PTC FlexPLM le stesse release fino alla 13.1.3.0 (secondo NVD)
Corretta in	Patch disponibili — vedi l'articolo PTC Support CS483249 per le build corrette per ramo; gli ambienti ospitati da PTC (cloud) sono già aggiornati, le installazioni on-premise del cliente devono applicare la patch da sé
CVSS	9.2 Critica · CVSS 4.0 · assegnato da PTC (CNA) · CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H (Automatable: Yes); anche 9.0 Critica · CVSS 3.1 · Scope Changed
Sfruttata attivamente	Nessuna evidenza al 2026-11-12 (OffSeq threat radar; nessuna fonte riporta sfruttamenti)
CISA KEV	Non presente (catalogo versione 2026.11.10)
PoC pubblico	Nessuno pubblico al 2026-11-12
Advisory ufficiale	Articolo PTC Support CS483249 (ptc.com)

Cos'è davvero CVE-2026-126325

La debolezza è validazione impropria dell'input (CWE-20) e deserializzazione di dati non attendibili (CWE-502). In parole semplici: l'applicazione accetta un oggetto serializzato dalla rete e lo ricostruisce senza prima validare che cosa sia. In un'applicazione Java enterprise — e Windchill è una grande applicazione Java — questa è la via classica verso l'esecuzione di codice remoto. Una gadget chain di deserializzazione trasforma "ricostruisci questo oggetto" in "esegui questo codice", e all'attaccante non serve né una primitiva di memory corruption né una credenziale.

Il vettore CVSS 4.0 pubblicato da PTC va letto con precisione, perché non è la stringa massimale in stile 9.8:

• AV:N / PR:N / UI:N — raggiungibile dalla rete, nessun privilegio, nessuna interazione dell'utente. L'attaccante invia una richiesta; nessuno deve cliccare.
• AC:H — complessità d'attacco Alta. Esiste una condizione che l'attaccante non controlla del tutto (uno specifico gadget, una configurazione, un timing) che rende lo sfruttamento affidabile più difficile di un bug banale.
• AU:Y (Automatable: Yes) — ricognizione, armamento e sfruttamento possono essere automatizzati su larga scala una volta che esiste una catena funzionante. L'alta complessità rallenta il primo exploit; non rallenta il centesimo.
• VC:H/VI:H/VA:H e uno scope Changed sul vettore 3.1 — compromissione completa di riservatezza, integrità e disponibilità dei dati che l'application server PLM può raggiungere, cioè l'intero archivio di progettazione.

"Alta complessità, non ancora sfruttata" è il motivo per cui hai qualche giorno invece di qualche ora. Non è un motivo per deprioritizzare. I bug di deserializzazione vengono ricostruiti dal diff della patch di routine, e AU:Y ti dice che il vendor si aspetta una versione armata che scali una volta che esiste.

I miei server Windchill o FlexPLM sono esposti?

Secondo NVD, la superficie colpita copre l'intera gamma supportata — Windchill e FlexPLM dalla linea 11.0 fino alle 13.1.x. Se usi uno dei due prodotti, considera di essere vulnerabile finché non hai confermato una build corretta. Due domande decidono l'ordine di priorità:

1. L'istanza è raggiungibile da internet? Il PLM dovrebbe stare dietro il firewall, servito a ingegneri, fornitori e workflow di change management. In pratica, i portali fornitori e l'accesso remoto alla progettazione spingono le istanze sul perimetro. Un Windchill esposto a internet con una RCE di rete non autenticata è la prima cosa da correggere stanotte — è esattamente il profilo che a giugno portò la CVE nel KEV.
2. Cosa può raggiungere l'application server? Il raggio d'azione dell'esecuzione di codice su un app server PLM è il dato che è autorizzato a servire: geometrie CAD, distinte base, ordini di modifica tecnica e — per i prime contractor della difesa e dell'aerospazio — dati tecnici controllati ITAR/EAR la cui sola esfiltrazione è un evento da notificare.

"Abbiamo applicato la patch a giugno." — La correzione di giugno riguardava CVE-2026-12569. Questa è una falla distinta con una patch propria. Una build che ha chiuso il bug di giugno non chiude questa; verifica la tua versione specificamente contro l'articolo PTC Support CS483249.

Remediation

1. Sono vulnerabile?

Identifica la build esatta in esecuzione di ogni istanza Windchill e FlexPLM — non la versione che pensi di aver installato, ma quella effettivamente attiva dopo l'ultima finestra di manutenzione. Inventaria prima le istanze esposte a internet (controlla le regole edge/WAF e i dati di superficie d'attacco esterna per qualunque cosa risponda sulle porte HTTP(S) di Windchill), poi quelle interne. Qualunque build nella gamma 11.0–13.1.x non allineata al livello corretto di CS483249 rientra nel perimetro.

2. Patch — le versioni corrette esatte

Applica la build corretta per ramo indicata nell'articolo PTC Support CS483249. PTC assegna build corrette per linea di release (11.x, 12.x, 13.0, 13.1); installa quella del tuo ramo invece di forzare un aggiornamento maggiore sotto pressione. Gli ambienti ospitati da PTC (cloud) sono già stati aggiornati da PTC; le installazioni on-premise e gestite dal cliente sono responsabilità del cliente e sono quelle a rischio ora. Conferma la stringa di build dopo la patch e dopo il riavvio del servizio — un server mai riavviato sta ancora eseguendo il codice vulnerabile.

3. Non puoi applicare la patch stanotte? Controlli compensativi

• Togli l'istanza da internet. Se un'istanza Windchill o FlexPLM è raggiungibile da internet, limitala immediatamente alla rete interna o a una VPN/allowlist. È il controllo di maggior valore e chiude la precondizione di rete non autenticata.
• Mettici davanti un filtro delle richieste. Dove l'esposizione non può essere rimossa, poni un WAF/reverse proxy davanti e limita l'accesso agli specifici endpoint applicativi necessari ai tuoi utenti. Questo alza ulteriormente una complessità d'attacco già Alta; non sostituisce la patch.
• Tratta i controlli compensativi come un rimedio temporaneo misurato in giorni, non come una correzione. Fissa adesso la scadenza della patch.

4. Caccia alla compromissione

Non sono ancora stati pubblicati IOC di vendor o ricercatori per CVE-2026-126325, quindi caccia sul comportamento, non sugli indicatori — e non inventare IOC. Segnali generalizzabili per una RCE Java da deserializzazione su un app server (mappati su MITRE ATT&CK):

• Processi figli generati dall'account di servizio Windchill/application server — shell, cmd.exe/powershell.exe, interpreti di scripting, strumenti di rete lanciati dal processo Java (T1190 Exploit Public-Facing Application, T1059 Command and Scripting Interpreter).
• File nuovi o modificati nelle directory web/app — una web shell JSP/servlet è la prima cosa che un operatore installa per la persistenza, esattamente come accaduto a giugno (T1505.003 Web Shell).
• Connessioni in uscita anomale dall'host PLM verso destinazioni mai viste — il download di uno strumento, un beacon, oppure lo staging e l'esfiltrazione in massa di dati CAD/BOM (T1041 Exfiltration Over C2 Channel).
• Pattern di richiesta insoliti verso gli endpoint applicativi che deserializzano input — payload serializzati grandi o malformati nei body delle richieste.

5. Bonifica e verifica

Se trovi una web shell o un impianto, rimuovere il file non basta: ricostruisci da un'immagine nota buona dove possibile, ruota ogni credenziale e segreto di service account che l'host compromesso poteva leggere (i server PLM custodiscono credenziali di integrazione e di database) e invalida le sessioni attive. Poi conferma la correzione dopo la patch — ri-testa che l'endpoint di deserializzazione rifiuti la prova che aveva dimostrato il problema, invece di fidarti della sola stringa di versione.

Cosa non si sa ancora

• Le build corrette esatte sono nell'articolo CS483249 di PTC (dietro il portale clienti); NVD e i tracker di terze parti non le elencano ancora.
• Lo stato di sfruttamento. Al momento non c'è evidenza di sfruttamento in corso e la CVE non è nel KEV della CISA — ma il precedente di giugno sugli stessi prodotti sconsiglia ogni compiacenza.
• La gadget chain. PTC non ha pubblicato dettagli tecnici sul sink di deserializzazione né sulla precondizione AC:H, e non esiste ancora un PoC pubblico. È lecito attendersi che l'analisi del diff della patch restringa il campo in pochi giorni.
• Arricchimento CISA SSVC / NVD. Il record NVD è ancora in stato "Received"; seguiranno un'analisi NVD completa e un'eventuale decisione SSVC della CISA.

Non indovinare se sei sfruttabile — dimostralo

La risposta onesta a "è uscita la patch di una RCE critica, ma non è confermato lo sfruttamento — con quanta urgenza corro?" non è una ricerca della stringa di versione. Una stringa di versione ti dice quale build è installata; non ti dice se il tuo Windchill, nella tua rete, con la tua configurazione ed esposizione, può davvero essere raggiunto e portato all'esecuzione di codice. Quel divario è dove le aziende o applicano la patch nel panico a tutto insieme o deprioritizzano in silenzio — e sono entrambe scommesse costose.

Zero Hunt è un red team autonomo basato su AI che gira su un apparato on-premise con modelli privati propri, con un human in the loop per ogni azione che conta. Di fronte a una divulgazione come questa, il suo swarm di 10 agenti identifica la versione esatta di Windchill/FlexPLM installata e, in modalità gray-box contro i tuoi stessi sistemi, ne analizza quella versione per il percorso di deserializzazione raggiungibile in input e itera un proof-of-concept funzionante — in un container effimero e irrobustito che non tocca mai l'host dell'apparato — finché non raggiunge dimostrabilmente il sink o dimostrabilmente non ci riesce. Poiché i modelli girano in locale, puntare il motore su un sistema PLM che custodisce progetti controllati ITAR/EAR e credenziali di integrazione non invia nulla di tutto ciò a terze parti. Ottieni una risposta classificata e supportata da evidenze su quali istanze specifiche sono davvero sfruttabili, così quelle realmente esposte vengono corrette per prime.

Una volta stabilito questo, l'AI Remediation Advisor lo trasforma in un piano di correzione ordinato per sfruttabilità reale — prima lo stato CISA KEV, poi ciò che è stato dimostrato raggiungibile nel tuo ambiente, poi CVSS ed EPSS — con la build PTC esatta da installare, le note di rollback e il controllo compensativo per tenere la linea fino alla finestra di manutenzione, e poi ri-verifica la correzione con la stessa prova che aveva dimostrato il problema. È la differenza tra un penetration test automatizzato e continuo che tiene il passo con divulgazioni come questa e il report annuale che ti avrebbe parlato del bug di giugno nell'ingaggio dell'anno prossimo. Per come triagiare quando l'orologio del KEV è il fattore forzante, vedi la nostra nota su CISA BOD 26-04 e il patching basato sul rischio; per il contesto più ampio sul perché una breccia PLM sia spionaggio industriale e non un incidente IT, vedi la nostra analisi di giugno su CVE-2026-12569.