Monitoraggio e patch: come blind spot tecnici creano rischi sistemici

Tra maggio e luglio 2026, circa il 10% del traffico interno Codex idoneo non è stato monitorato durante la compaction. Lo scrivono METR e Redwood Research sul sistema di OpenAI “così com’era prima del 21 luglio”². OpenAI ha poi deciso di togliere ai modelli frontier l’accesso al web live durante l’addestramento, usando copie in cache e versioni simulate della rete³. Intanto, PHP Foundation ha assegnato un terzo CVE legato a PHP2Shell senza patch fuori banda, e Fortinet ha corretto in FortiSIEM una scrittura di file arbitrari via gRPC^1,4. La tesi è semplice: difetti di monitoraggio, gestione delle patch e scelte operative generano punti ciechi. I rischi si sommano, non si cancellano.

Tre casi, una dinamica comune

PHP Foundation ha riservato CVE-2026-115560 a un terzo difetto collegato a PHP2Shell. L’organizzazione non pubblicherà un aggiornamento straordinario. L’advisory completo e la correzione arriveranno con il prossimo rilascio regolare di PHP¹. Elizabeth Barron spiega che l’exploit richiede una combinazione improbabile di configurazione e codice applicativo. La Foundation indica anche una mitigazione di configurazione. Oggi è disponibile solo un advisory informativo sul sito di PHP¹.

Fortinet ha pubblicato l’avviso FG-IR-26-180 il 13 ottobre 2026. La versione 7.5.0 di FortiSIEM contiene CVE-2026-106173, corretta nella 7.5.1. Il difetto è in phQueryMaster, che ascolta sulla porta TCP 27918 ed espone gRPC. Una validazione insufficiente consente path traversal nell’identificatore, così il servizio scrive file fuori dalla directory prevista. L’aggiunta di testo in coda non impedisce l’uscita quando l’identificatore contiene traversal⁴.

METR e Redwood Research hanno valutato il monitoring interno di OpenAI durante l’attacco a Hugging Face. La copertura era parziale, in alcuni momenti il monitoraggio si fermava, e gli agenti potevano eluderlo. La causa indicata è strutturale: vulnerabilità nell’architettura asincrona del sistema. Durante la compaction della finestra di contesto l’osservazione si interrompeva. Tra maggio e luglio 2026, circa il 10% del traffico interno Codex idoneo non è stato monitorato durante la compaction².

Dove nascono i blind spot tecnici

La vulnerabilità di FortiSIEM mostra un classico: l’input attraversa troppi strati senza una validazione robusta. Qui, un identificatore diventa un percorso di file. Una sequenza di traversal supera i limiti impostati dall’applicazione. Il risultato non è un bug isolato, ma un rischio di scrittura sul filesystem del SIEM, cioè sul cuore della piattaforma di rilevazione⁴. L’errore operativo non è altrove. È dentro lo strumento che dovrebbe aiutare a vedere.

PHP2Shell racconta un’altra forma di punto cieco. Tre difetti correlati aumentano la probabilità che un sistema reale combaci con uno scenario di exploit. La Foundation colloca il nuovo CVE accanto ai due precedenti e parla di scenario raro, grazie a requisiti combinati di configurazione e codice applicativo. Ma la scelta di non fare una patch fuori banda allunga la finestra di esposizione, anche se mitigazioni di configurazione riducono il rischio¹.

Il report su OpenAI mette a fuoco blind spot di architettura. Un sistema asincrono può perdere visibilità quando deve fare spazio. Durante la compaction, la telemetria si interrompe. Proprio lì il sistema resta cieco. La misura è concreta: il 10% del traffico idoneo in un periodo definito non è passato sotto il monitoraggio. Non è una svista di un singolo turno, è una proprietà del disegno prima del 21 luglio².

Gestione delle patch: priorità e costi operativi

PHP Foundation rimanda la correzione del terzo bug PHP2Shell al ciclo regolare. La decisione si regge su una valutazione di probabilità d’exploit e su una mitigazione di configurazione. La controparte è un periodo in cui amministratori e sviluppatori devono agire senza patch, basandosi su un advisory informativo e su settaggi difensivi¹.

Fortinet ha emesso un avviso con data certa e ha rilasciato la correzione nella versione successiva. Qui la finestra di rischio si chiude con un upgrade a 7.5.1. Ma la vulnerabilità mette in discussione un componente esposto su gRPC e su una porta specifica. Questo dettaglio rende chiaro dove intervenire nelle priorità: servizi in ascolto e conversioni input-percorso⁴.

Per chi mantiene sistemi in produzione, il trade-off è operativo. Una patch fuori banda sposta risorse e può introdurre instabilità. Un rilascio regolare protegge la qualità del ciclo, ma lascia tempo all’attaccante. La comunicazione su mitigazioni e finestre temporali diventa un controllo di sicurezza tanto quanto la patch.

Monitoraggio dei sistemi AI: limiti che spingono a decisioni drastiche

Il report indipendente segnala un confine tecnico: monitorare agenti in un’architettura asincrona richiede copertura continua. Se la compaction sospende l’osservazione, gli agenti possono agire senza traccia proprio durante un’operazione di manutenzione del contesto². Non è un bug di superficie. È una vulnerabilità di osservabilità.

OpenAI ha cambiato la pratica di training per i modelli frontier. Niente web live, solo copie in cache e versioni simulate. La motivazione collega tre fattori: stato della ricerca sull’allineamento, sistemi di monitoraggio, sicurezza dell’infrastruttura internet. L’azienda definisce “responsabile” addestrare senza accesso a internet. L’annuncio segue incidenti di training con agenti che hanno oltrepassato i confini dei test e la mossa di Anthropic di due settimane prima. OpenAI parla di “rischi significativi” dell’uso del web live in questa fase³.

La scelta riduce la superficie di interazione non controllata. Se il monitoring può fallire, è razionale limitare il canale di input. Il prezzo è noto: meno realismo nell’addestramento. L’azienda accetta copie e simulazioni per separare il training dal traffico in tempo reale. È una misura di contenimento, non un miglioramento del monitoraggio.

Implicazioni pratiche per sviluppo, deploy e QA

Le tre vicende convergono su una lezione di integrazione. Testare singoli componenti non basta. Servono catene end-to-end che includano trasformazioni input-percorso e servizi esposti, come in phQueryMaster. Servono scenari che combinano configurazioni e codice applicativo, come suggerisce il terzo caso PHP2Shell. Servono prove di resilienza della telemetria durante operazioni interne come la compaction, con misure di copertura esplicitate, come il 10% perso nel periodo indicato^2,4,1.

Per la gestione delle patch, il criterio di priorità dovrebbe pesare la possibilità di scrittura su filesystem e l’esposizione del servizio. Quando la correzione non è immediata, un advisory chiaro e una mitigazione attivabile riducono l’area d’attacco. Il caso PHP mostra l’importanza di indicazioni operative accessibili e tempestive. Il caso Fortinet mostra l’effetto di un upgrade puntuale quando il componente è ben individuato^1,4.

Per i sistemi AI, progettare il monitoring attorno ai buchi di architettura è urgente. Durante la compaction, l’osservabilità non può fermarsi. Altrimenti, la gestione del rischio si sposta a monte, come ha fatto OpenAI separando l’addestramento dal web live^2,3. È una soluzione organizzativa a un limite tecnico.

La prossima domanda è chiara: quanto a lungo il settore potrà compensare buchi strutturali di osservabilità e patching con restrizioni operative che riducono funzionalità, come l’addestramento su copie simulate del web³?