Una vulnerabilità reale ha mostrato che un processo tenant poteva cambiare rapidamente un percorso mentre un'operazione amministrativa eseguiva controlli e modifiche sui nomi dei file. Il problema non era l'accesso diretto al bersaglio, ma il tempo tra controllo e uso da parte di root.
La correzione ha sostituito le traversate privilegiate vulnerabili con un helper che:
La regressione è stata verificata nei due ambienti documentati: il bersaglio esterno usato per il test non è stato modificato e il churn è stato rilevato con esito fail-closed. Sono stati inoltre ricontrollati i workflow coinvolti, inclusi creazione, WordPress, duplicazione e backup.
Questa correzione chiude il caso riprodotto, ma non rende sicura per definizione ogni futura operazione root. Un nuovo workflow che riapre per nome un oggetto scelto in un albero mutabile deve essere analizzato e progettato con lo stesso principio.
I nuovi flussi di backup e restore creano file di configurazione temporanei protetti e passano ai client soltanto il percorso. Password e contenuti dello snapshot non compaiono negli argomenti o nei log.
I workflow più recenti adottano questo modello; alcune catene storiche devono essere ancora riallineate. Sui server documentati, la visibilità dei processi tra utenti differenti è inoltre limitata. È una difesa aggiuntiva, non un sostituto della migrazione: ogni cambio nel trasporto dei segreti deve mantenere coerenti tutti i componenti della catena.
Le connessioni al database centrale richiedono TLS e gli account di automazione sono separati per nodo e limitati alle tabelle necessarie. La modalità corrente cifra il trasporto, ma la verifica completa dell'identità dell'endpoint resta subordinata a hostname e certificati adeguati. Non viene quindi descritta come già completata.
Nel restore, un'identità ambigua, un artefatto extra, un hash errato, un database orfano, un link vietato o una condizione runtime inattesa interrompono il preflight. Il sistema non prova a “correggere” automaticamente dati che non riesce ad attribuire con certezza.
Dopo l'inizio della fase distruttiva, un errore tenta di riaffermare l'isolamento e conserva diagnosi e stati. Nessun software può garantire il successo di questi tentativi in presenza di un guasto grave a kernel, filesystem o web server; il valore del fail-closed sta nel non riaprire consapevolmente un risultato parziale come se fosse valido.
