Check Point e AWS: RCE root pre-auth e MITM sui dispositivi IoT Python

🛡️ Executive Summary

• Check Point corregge CVE-2026-91843, stack overflow pre-auth che può portare all’esecuzione remota di codice con privilegi root.
• AWS corregge CVE-2026-92943: l’IoT Device SDK Python verificava la CA del certificato TLS ma non il nome dell’host.
• Per AWS non esistono workaround; serve la versione 1.6.1. Check Point distribuisce invece una LivePatch urgente per i server interessati.

Due nuove vulnerabilità colpiscono componenti che dovrebbero stabilire chi può essere considerato affidabile prima ancora che inizi una normale sessione applicativa. Check Point ha corretto uno stack overflow nel processo di login dei Security Management e Log Server che può consentire a un aggressore remoto non autenticato di eseguire codice come root. AWS ha invece scoperto che il proprio IoT Device SDK for Python poteva accettare un certificato TLS valido per un hostname differente da quello di AWS IoT Core, aprendo la strada a un attacco adversary-in-the-middle capace di intercettare telemetria e iniettare messaggi MQTT. Due bug differenti, ma con la stessa conseguenza architetturale: il controllo di fiducia fallisce proprio nel punto in cui dovrebbe bloccare l’attaccante.

Check Point CVE-2026-91843 porta dalla login non autenticata ai privilegi root

Check Point ha pubblicato il 16 settembre 2026 un avviso ufficiale urgente su CVE-2026-91843, assegnando alla vulnerabilità un punteggio CVSS 9,8. Il difetto è uno stack-based buffer overflow nel processo di login dei Security Management Server e Log Server: l’elaborazione avviene prima dell’autenticazione e, in caso di sfruttamento riuscito, un attaccante remoto può arrivare all’esecuzione di codice arbitrario con privilegi root. Sono coinvolti Security Management Server, Multi-Domain Security Management Server e relativi Log Server in diversi rami R81 e R82. Check Point dichiara di non avere, al momento della disclosure, indicazioni di exploitation attiva e ha distribuito la correzione attraverso LivePatch, invitando comunque gli amministratori a verificare l’effettiva installazione. Il precedente è particolarmente pesante: a luglio CVE-2026-16232 aveva già esposto SmartConsole e il piano di controllo Check Point, con sfruttamento confermato contro installazioni di gestione raggiungibili dalla rete.

Leggi anche: Check Point corregge due RCE VPN mentre gli agenti AI scalano l’attacco PaperCut

Il rischio Check Point è nel piano che controlla firewall, policy e amministratori

La differenza rispetto a una RCE su un server applicativo qualsiasi è rappresentata dal ruolo del sistema compromesso. Il Security Management Server governa policy firewall, oggetti di rete, amministratori e distribuzione delle configurazioni verso i gateway: raggiungere root sul piano di gestione significa quindi compromettere un punto dal quale dipendono altri controlli di sicurezza.

Il Security Knowledge Base sk1000155 pubblicato da Check Point contiene la remediation attraverso LivePatch per CVE-2026-91843; gli ambienti con aggiornamenti automatici abilitati dovrebbero aver ricevuto la protezione, ma l’indicazione operativa resta verificare lo stato della patch invece di presumere che il rollout sia già avvenuto.

La successione delle disclosure aumenta inoltre il peso del patching: soltanto pochi giorni prima Check Point aveva corretto CVE-2026-85102 e CVE-2026-85103, due RCE pre-auth da 9,8 legate alla gestione dei certificati VPN. Il nuovo bug non dimostra una compromissione in corso, ma conferma quanto il piano amministrativo delle appliance di sicurezza sia ormai una superficie offensiva primaria.

AWS IoT Device SDK verificava il certificato ma non che appartenesse al server giusto

Il problema AWS è meno immediato di una RCE root, ma tecnicamente insidioso. Nel Security Bulletin AWS 2026-114 Amazon descrive CVE-2026-92943, una mancata validazione dell’hostname nel livello TLS del client MQTT di AWS IoT Device SDK for Python. Le versioni dalla 1.5.3 alla 1.6.0, quando utilizzate con Python 3.7 o successivo, controllavano che il certificato presentato dal server fosse firmato da una Certification Authority presente nel trust store del dispositivo, ma non verificavano correttamente che quel certificato fosse stato emesso per l’endpoint AWS IoT Core realmente contattato. Un aggressore già posizionato sul percorso di rete può quindi presentare un certificato perfettamente valido ma relativo a un altro hostname e impersonare AWS IoT Core. È un errore della stessa famiglia concettuale già incontrata nella vulnerabilità AWS SageMaker che indeboliva la verifica TLS: la cifratura rimane attiva, ma perde valore se l’identità della controparte non viene validata correttamente.

Anche mutual TLS e SigV4 falliscono se il client si fida dell’endpoint sbagliato

La vulnerabilità interessa entrambi i percorsi di connessione predefiniti dello SDK: l’autenticazione reciproca X.509 su porta 8883 e WebSocket con AWS Signature Version 4 su porta 443. Non è invece interessato il percorso ALPN su porta 443. Questo particolare spiega perché il problema non possa essere ridotto alla semplice presenza o assenza di TLS: il canale può essere cifrato e il dispositivo può perfino autenticarsi con un proprio certificato, ma se non viene verificato correttamente l’hostname del server il dispositivo può instaurare quella sessione con l’intermediario sbagliato. AWS afferma che un attacco riuscito permette di leggere la telemetria del dispositivo e iniettare messaggi MQTT arbitrari che il client considera autentici. In una flotta IoT l’impatto dipende quindi da ciò che i messaggi controllano: un topic utilizzato esclusivamente per telemetria non equivale a uno dal quale dispositivi o gateway ricevono comandi operativi. Il caso rafforza il quadro già emerso dalle recenti vulnerabilità AWS tra Security Agent, DJL e Systems Manager: il confine reale spesso è nel client, nell’SDK o nell’agente, non nel servizio cloud gestito.

AWS impone la 1.6.1, Check Point richiede verifica immediata della LivePatch

Per CVE-2026-92943 AWS non indica alcun workaround: le connessioni vulnerabili coincidono con percorsi documentati e normalmente utilizzati dallo SDK. La correzione è contenuta in AWSIoTPythonSDK 1.6.1 e Amazon chiede di aggiornare anche fork o codice derivato che incorpori le versioni precedenti. Gli amministratori devono quindi cercare installazioni dalla 1.5.3 alla 1.6.0 e non limitarsi ai package installati direttamente, perché una copia vendorizzata del codice può sopravvivere fuori dal normale dependency management. Sul fronte Check Point la priorità è diversa: installare o verificare la LivePatch associata a sk1000155, controllare anche i server di log e le installazioni Multi-Domain e ridurre quanto più possibile la raggiungibilità del piano di gestione. In entrambi i casi la patch è più importante del punteggio numerico: AWS richiede una posizione adversary-in-the-middle, mentre Check Point offre una superficie pre-auth con impatto root. Sono condizioni differenti e vanno prioritizzate in base alla reale esposizione dell’ambiente.

Continua con:

• Cisco FMC sotto attacco: Cyclops Blink e Qilin sfruttano falle, AWS corregge MCP
• CISA mette GitLab e altri cinque exploit nel KEV, Check Point teme attacchi imminenti

Il controllo di sicurezza fallisce quando verifica soltanto metà della fiducia

Le due vulnerabilità mostrano perché autenticazione e crittografia non debbano essere trattate come proprietà binarie. Check Point elaborava input controllabile prima di avere autenticato l’utente; AWS stabiliva una sessione TLS senza verificare correttamente che il certificato appartenesse all’hostname atteso. In entrambi i casi una protezione esisteva, ma il percorso di validazione lasciava aperto il passaggio decisivo. Per gli amministratori la risposta è concreta: patch immediata dei management server Check Point, verifica effettiva delle LivePatch installate e aggiornamento di ogni deployment AWSIoTPythonSDK alla 1.6.1, compresi fork e applicazioni embedded difficili da censire. Il rischio più interessante non è quindi il CVSS isolato, ma ciò che accade quando un controllo formalmente presente smette di rappresentare un vero confine di fiducia.