Cronologia delle interruzioni di Knowbe4

1. 20 ottobre 2026 alle ore 11:37 UTCidentified

   Abbiamo identificato la causa della registrazione di dominio non essendo in grado di dare consigli e stiamo lavorando per implementare una correzione. Continueremo a pubblicare sulla nostra pagina di stato con qualsiasi nuova informazione o aggiornamenti.

2. 21 ottobre 2026 alle ore 15:33 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

3. 23 ottobre 2026 alle ore 14:55 UTCresolved

   Questo incidente è stato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 13 ottobre 2026 alle ore 15:03 UTCinvestigating

   Stiamo attualmente indagando su un problema che riguarda il login della console. Forniremo ulteriori aggiornamenti qui quando disponibile.

2. 13 ottobre 2026 alle ore 15:07 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

3. 13 ottobre 2026 alle ore 16:15 UTCresolved

   Questo incidente è stato risolto.

4. 14 ottobre 2026 alle ore 14:29 UTCpostmortem

   # Summary # Il 13 ottobre 2026, da circa 14:19 a 15:05 \(UTC\), i clienti in tutte le regioni non sono stati in grado di accedere alla console KnowBe4 Security Awareness Training \(SAT\), alla KnowBe4 Learner Experience e alla console PhishER tramite KnowBe4 SAT. I login SAML e password hanno restituito gli errori, e la console KnowBe4 SAT non è comparso nella piattaforma KnowBe4. Alcuni processi di sfondo, tra cui la sincronizzazione degli utenti e le e-mail di formazione, anche fallito in questo momento. L'incidente è stato causato da un rilascio di produzione in conflitto con un altro cambiamento nel nostro codice. Abbiamo reindirizzato il rilascio, e i login recuperati in tutte le regioni tra 14:59 e 15:05 \(UTC\). Nessuna perdita di dati si è verificata a seguito di questo problema. ♪#Root Cause ♪ Una distribuzione del codice ha rimosso un valore di configurazione di avvio per accelerare il tempo di avvio dell'applicazione. Un componente separato, aggiunto al nostro codice dopo la modifica originale è stato testato, non ha tenuto conto di quel valore modificato. Di conseguenza, ogni tentativo di salvare un record utente ha sollevato un errore, incluso l'aggiornamento che registra tentativi di accesso. Revisione: I clienti di tutte le regioni non possono accedere alla console KSAT tramite SAML o password. Essi non sono stati in grado di accedere all'esperienza dell'esperiente, e non hanno potuto accedere alla console PhishER attraverso la console KnowBe4 SAT. La nuova creazione dell'utente, la sincronizzazione degli utenti e le e-mail di formazione sono fallite in questo periodo, ma sono state automaticamente riattivate dopo che l'implementazione è stata ripristinata. # Mitigation and Remediation # Abbiamo scoperto che l'implementazione ha rimosso un valore di configurazione che un altro componente ancora richiesto. Ciò è stato mitigato dalla riversione del rilascio, e abbiamo confermato il recupero in tutte le regioni attraverso controlli diretti e test automatizzati. Abbiamo anche reindirizzato il cambiamento originale nel nostro codice sorgente e preparato una versione corretta che include una correzione di compatibilità, in modo che il miglioramento originale può essere reintrodotto in modo sicuro. ## ** Misure preventive** Stiamo aggiungendo ulteriori verifiche di codice e test per le implementazioni.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 13 ottobre 2026 alle ore 08:47 UTCinvestigating

   Abbiamo ricevuto segnalazioni che il componente aggiuntivo per la sicurezza e-mail KnowBe4 mostra l'errore "La sicurezza e-mail aggiuntivo KnowBe4 impedisce che questo messaggio venga inviato" quando si inviano e-mail. Stiamo indagando su questo problema e aggiorneremo questa pagina quando avremo maggiori informazioni.

2. 13 ottobre 2026 alle ore 11:07 UTCmonitoring

   Abbiamo implementato una correzione per gli errori di invio di Web Add-in e stiamo monitorando i risultati per assicurarsi che non si verifichino ulteriori problemi.

3. 13 ottobre 2026 alle ore 13:41 UTCresolved

   Questo incidente è stato risolto.

4. 20 ottobre 2026 alle ore 12:48 UTCpostmortem

   Da lunedì 12 ottobre 2026, a circa 14:25 \(UTC\), a martedì 13 ottobre 2026, a circa 15:07 \(UTC\), alcuni clienti nelle istanze UE di prevenire e proteggere hanno avuto difficoltà a inviare e-mail da Microsoft Outlook. I messaggi non sono stati inviati e l'add-in di KnowBe4 Email Security ha mostrato il seguente errore: "L'add-in KnowBe4 Email Security sta impedendo che questo messaggio venga inviato." Questo problema è stato causato da un errore nel modo in cui una versione add-in è stata preparata per il rilascio, che ha prodotto due copie leggermente diverse della stessa versione. Quando Outlook carica l'add-in, scarica un insieme di file che devono corrispondere. Nelle istanze UE, Outlook a volte ha ricevuto file da entrambe le copie, quindi l'add-in non poteva finire il caricamento, e il messaggio non è stato inviato. Alcuni dispositivi hanno anche salvato il download fallito, quindi l'errore è continuato su quei dispositivi fino a quando non è stata applicata una correzione. Per risolvere questo problema, il nostro team ha corretto i file aggiuntivi UE in modo che ogni cliente riceva un set corrispondente. Abbiamo poi rilasciato una versione aggiornata del componente aggiuntivo a tutte le regioni, che ha eliminato eventuali errori salvati. Il componente aggiuntivo KnowBe4 Email Security torna alle normali prestazioni di circa 15:07 \(UTC\) il 13 ottobre 2026. Per evitare questo tipo di problema in futuro, stiamo cambiando come le versioni add-in sono preparate e rilasciate, in modo che ogni versione produce sempre lo stesso insieme di file e ogni cliente riceve la stessa versione contemporaneamente. Stiamo anche cambiando il componente aggiuntivo in modo che i download falliti dei file add-in non vengano salvati sui dispositivi. Infine, stiamo aggiungendo avvisi per errori di carico aggiuntivi per rilevarli prima. Nessuna perdita di dati si è verificata a seguito di questo problema.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 28 settembre 2026 alle ore 21:10 UTCinvestigating

   Stiamo attualmente indagando su un problema relativo alle prestazioni degradate per prevenire e proteggere sui nostri server statunitensi.

2. 29 settembre 2026 alle ore 13:44 UTCmonitoring

   Abbiamo identificato un problema con le istanze statunitensi di Prevent and Protect che ha portato a prestazioni degradate. Una soluzione è stata implementata, e continueremo a monitorare questo problema.

3. 2 ottobre 2026 alle ore 10:32 UTCresolved

   Questo incidente è stato risolto.

4. 6 ottobre 2026 alle ore 15:51 UTCpostmortem

   # Summary # Da lunedì 28 settembre 2026, a circa 16:00 \(UTC\), a mercoledì 30 settembre 2026, a circa 12:35 \(UTC\), alcuni clienti hanno sperimentato il flusso di posta ritardato e i problemi intermittenti di accesso alle istanze statunitensi di Prevent and Protect. Il 28 settembre, il nostro monitoraggio ha mostrato traffico di rete pesante, con punte in cima ad ogni ora. Alcuni clienti hanno iniziato a sperimentare problemi intermittenti di accesso alle istanze degli Stati Uniti delle console Prevent e Protect. Ricerca interna che l'elaborazione della posta dipende dalla tempistica iniziata, e i messaggi sono stati in coda di conseguenza. I clienti hanno segnalato il problema al nostro team di supporto, e abbiamo postato un avviso di pagina di stato. Le prestazioni recuperate più tardi quel giorno come il traffico degli Stati Uniti è diminuito. Il 29 settembre, i nostri ingegneri hanno esaminato i dati del giorno precedente attraverso i gateway di posta, i servizi interni da cui dipendono, e lo strato di rete. I ritardi del flusso di posta e i problemi di accesso alla console sono tornati brevemente, poi facilitati come il traffico di rete è diminuito, seguendo lo stesso modello del 28 settembre. Il 30 settembre, da circa 12:19 a 12:35 \(UTC\), il nostro team ha aumentato la capacità dei servizi di rete degli Stati Uniti, mentre il servizio è continuato. Il loro carico cadde subito dopo il cambiamento, e Prevent and Protect tornò alle normali prestazioni di circa 12:35 \(UTC\) il 30 settembre 2026. Abbiamo monitorato il traffico di punta del 30 settembre e il 1 ottobre e non abbiamo visto ricorrenza. Nessuna perdita di dati si è verificata a seguito di questo problema. ♪#Root Cause ♪ Questo problema è stato causato da un limite di capacità nei servizi di rete che gestiscono il traffico per i nostri servizi di mail-processing degli Stati Uniti. Durante il traffico di picco, e soprattutto durante le punte orarie, i servizi di rete non potevano elaborare connessioni abbastanza velocemente. Questo ha aggiunto ritardo al traffico che passa attraverso di loro e ha causato alcuni collegamenti a cadere. Il traffico includeva richieste interne che i nostri gateway di posta inviano per cercare i membri della lista di distribuzione, quindi le politiche giuste sono applicate. Queste richieste sono soggette a un limite di tempo rigoroso in modo che una ricerca lenta non può contenere l'elaborazione della posta indefinitamente. Quando i servizi di rete hanno ritardato le richieste oltre tale limite, hanno fallito. Di conseguenza, l'elaborazione della posta è rallentata e i messaggi sono stati in coda. Due fattori hanno reso il problema peggiore e più difficile da identificare. In primo luogo, alcune richieste interne hanno utilizzato anche questi servizi di rete e sono stati colpiti dal limite di capacità. In secondo luogo, i servizi di rete hanno cominciato a degradare prima che il loro uso di calcolo raggiunto livelli che normalmente segnalerebbero un problema. Il monitoraggio dei calcoli standard non ha catturato la saturazione della rete, quindi la causa ha richiesto più tempo per identificare. Trovare un modo sicuro per aumentare la capacità senza interrompere il servizio ha anche richiesto tempo, per questo motivo la correzione è stata applicata il 30 settembre. # Mitigation and Remediation # Abbiamo scoperto che i servizi di rete degli Stati Uniti non hanno abbastanza capacità per gestire il traffico di punta. L'abbiamo mitigato aumentando la loro capacità in un modo che ha mantenuto il servizio in esecuzione durante il cambiamento. Dopo l'aumento della capacità, i servizi di rete hanno gestito il massimo traffico senza ulteriori problemi. Abbiamo anche scoperto che l'uso di calcolo da solo non era un segno affidabile di saturazione di rete. Abbiamo ampliato il nostro monitoraggio per monitorare gli indicatori di salute della rete, oltre all'uso di calcolo. Infine, abbiamo scoperto che à ̈ stato difficile trovare dove le richieste interne fallirono. Abbiamo aggiunto la registrazione che mostra dove le richieste interne falliscono e il tempo fuori. Revisione: Durante il picco del traffico degli Stati Uniti il 28 e 29 settembre, alcuni clienti hanno sperimentato ritardi nella lavorazione e nella fornitura di posta in entrata e in uscita attraverso Prevent and Protect. I messaggi indirizzati alle liste di distribuzione possono essere stati elaborati più lentamente mentre le ricerche sono state rielaborate. Alcuni clienti avevano anche difficoltà intermittenti di accesso a o utilizzando la console statunitense. L'impatto ha facilitato ogni giorno come il traffico degli Stati Uniti è diminuito, e la posta in coda è stata elaborata una volta recuperata la capacità. Dopo il cambiamento del 30 settembre, non abbiamo visto nessun ulteriore degrado durante il traffico di picco. ## ** Misure preventive** Per prevenire questo tipo di problema in futuro, abbiamo aumentato la capacità dei servizi di rete degli Stati Uniti e ampliato il nostro monitoraggio per monitorare gli indicatori di salute della rete, oltre all'uso di calcolo. Abbiamo anche aggiunto logging per migliorare la visibilità nelle richieste interne fallite.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 24 settembre 2026 alle ore 17:53 UTCinvestigating

   Abbiamo identificato un problema con Protect che ha portato a prestazioni degradate, e il nostro team di ingegneria sta cercando una soluzione.

2. 24 settembre 2026 alle ore 18:39 UTCmonitoring

   Abbiamo identificato un problema con Protect che ha portato a prestazioni degradate. Una soluzione è stata implementata, e continueremo a monitorare questo problema.

3. 24 settembre 2026 alle ore 19:57 UTCinvestigating

   Abbiamo identificato un problema con Protect & Prevent che ha portato a prestazioni degradate, e il nostro team di ingegneri sta cercando una soluzione.

4. 24 settembre 2026 alle ore 21:46 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

5. 25 settembre 2026 alle ore 09:16 UTCresolved

   Questo incidente è stato risolto.

6. 6 ottobre 2026 alle ore 15:51 UTCpostmortem

   # Summary # Da giovedì 24 settembre 2026, a circa 17:07 \(UTC\), a venerdì 25 settembre 2026, a circa 09:16 \(UTC\), alcuni clienti hanno sperimentato lentezza intermittente, errori e flusso di posta ritardato per le istanze statunitensi di Proteggere e prevenire. Il 24 settembre un picco insolitamente grande nel traffico e-mail posto carico sostenuto sui servizi di rete che gestiscono il traffico per la nostra elaborazione di posta degli Stati Uniti. Il nostro monitoraggio ci ha avvisato a circa 17:07 \(UTC\). Alcuni clienti hanno visto l'accesso lento o intermittente a proteggere e errori occasionali quando si caricano pagine o opzioni avanzate. L'accesso era incoerente, in modo che alcuni clienti potrebbero utilizzare Protect mentre altri vedevano errori. L'elaborazione della posta tramite le istanze degli Stati Uniti ha rallentato, e alcuni messaggi sono stati ritardati o non sono comparsi nella casella di posta di moderazione quando previsto. Le prestazioni sembravano migliorare, quindi abbiamo spostato il nostro avviso di pagina di stato al Monitoraggio a 18:39 \(UTC\). Il problema si è poi ripreso, e i clienti hanno riferito la lentezza continua al nostro team di supporto. A 19:57 \(UTC\), abbiamo spostato l'avviso di nuovo per indagare e ampliarlo per includere anche Prevenire come l'impatto è diventato più chiaro. Il nostro team ha monitorato i sistemi interessati mentre il volume elevato della posta è sottosopra. Come il carico sui servizi di rete restituito alla normalità, l'elaborazione della posta recuperata, e le code di posta ritornano alla normalità durante la notte. Abbiamo confermato che Protect stava caricando normalmente e che i messaggi di prova sono stati consegnati di nuovo, e poi ha continuato il monitoraggio. Proteggere e prevenire ritornato alle normali prestazioni di circa 09:16 \(UTC\) il 25 settembre 2026. Nessuna perdita di dati si è verificata a seguito di questo problema. ♪#Root Cause ♪ Questo problema è stato causato da un picco insolitamente grande nel traffico e-mail. L'aumento del volume ha posto un carico sostenuto sui servizi di rete che gestiscono il traffico per la nostra elaborazione di posta degli Stati Uniti. Tali servizi di rete operano entro limiti di capacità fissi, e la loro capacità non può essere scalata durante il picco. Perche' non riuscivano a tenere il passo, rallentarono e qualche elaborazione fallì in modo intermittente. Di conseguenza, un grande volume di posta è stato in coda nell'elaborazione della posta degli Stati Uniti, alcune pagine e azioni in Proteggere gli errori restituiti, e alcuni messaggi sono stati ritardati o non sono comparsi nella casella di posta di moderazione quando previsto. Due fattori hanno reso il problema più difficile da gestire. In primo luogo, perché l'accesso fallito intermittentemente, alcuni controlli sono riusciti mentre i clienti hanno continuato a vedere gli errori, rendendo il recupero più difficile da confermare. In secondo luogo, il nostro monitoraggio ha mostrato un carico massimo sui servizi di rete più chiaramente del carico corrente, che ha reso più difficile giudicare in tempo reale se il carico era ancora elevato. # Mitigation and Remediation # Abbiamo scoperto che i servizi di rete che gestiscono l'elaborazione della posta degli Stati Uniti avevano raggiunto i loro limiti di capacità fissi durante il picco di traffico, e la loro capacità non poteva essere aumentata durante l'evento. Il nostro team ha monitorato i sistemi interessati mentre il volume elevato della posta è subsided e il carico del servizio di rete è tornato alla normalità. Elaborazione di posta poi recuperato, e la posta in coda è stata elaborata. Poiché il problema era in precedenza sembrato migliorare prima di ricorrente, abbiamo confermato il recupero in diversi modi prima di risolvere l'incidente. Abbiamo confermato che Protect stava caricando normalmente, che i messaggi di prova sono stati consegnati attraverso l'elaborazione di posta degli Stati Uniti, e che le richieste di supporto stavano progredendo normalmente. Abbiamo anche monitorato durante la notte e non abbiamo ricevuto nuovi rapporti dai clienti sulle istanze degli Stati Uniti. Revisione: Alcuni clienti hanno avuto accesso lento o intermittente a Proteggere, e occasionalmente ha visto errori durante il caricamento di pagine o opzioni avanzate. L'elaborazione della posta tramite le istanze degli Stati Uniti è stata ritardata per proteggere e prevenire. In alcuni casi, i messaggi sono stati ritardati o non sono comparsi nella casella di posta di moderazione quando previsto. I clienti la cui posta è crittografata, decifrata, o moderata come passa attraverso la nostra elaborazione di posta degli Stati Uniti erano più probabilità di essere colpiti. La maggior parte dei clienti che utilizzano l'add-in non sono stati colpiti dai ritardi di elaborazione della posta. Le console di Protezione e Prevenzione sono rimaste disponibili, anche se alcune azioni di console sono state influenzate dalla più lenta elaborazione della posta. ## ** Misure preventive** Per prevenire questo tipo di problema in futuro, stiamo migliorando il nostro monitoraggio di aumenti insoliti nel volume di e-mail. Stiamo anche migliorando il nostro monitoraggio per mostrare il carico attuale sui nostri servizi di rete, non solo i valori di picco. Inoltre, stiamo valutando i modi per scalare la nostra capacità di rete più dinamicamente durante i picchi di traffico improvvisi, e valutare i miglioramenti a lungo termine per l'infrastruttura di rete che gestisce l'elaborazione della posta degli Stati Uniti. Da allora abbiamo aumentato la capacità dei servizi di rete degli Stati Uniti in risposta a[un successivo incidente](https://status.knowbe4.com/incidents/9wc6rjm8g70v).

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 23 settembre 2026 alle ore 09:52 UTCidentified

   Abbiamo ricevuto rapporti di utenti che ricevono messaggi di errore "Access Denied" mentre si cerca di effettuare il login. Abbiamo identificato il problema e stiamo lavorando per implementare una soluzione e aggiorneremo questa pagina quando avremo maggiori informazioni.

2. 23 settembre 2026 alle ore 10:57 UTCmonitoring

   Il problema è stato identificato e una correzione è stata implementata e aggiornerà questa pagina quando abbiamo più informazioni.

3. 23 settembre 2026 alle ore 14:58 UTCresolved

   Questo incidente è stato risolto con successo e tutti i sistemi sono completamente operativi.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 23 settembre 2026 alle ore 09:00 UTCinvestigating

   Abbiamo ricevuto segnalazioni che alcuni utenti non sono in grado di inviare correttamente le presentazioni webform. Stiamo indagando su questo problema e aggiorneremo questa pagina quando avremo maggiori informazioni.

2. 23 settembre 2026 alle ore 10:47 UTCidentified

   Il problema è stato identificato e una correzione è stata implementata. Un aggiornamento con ulteriori informazioni seguirà di conseguenza.

3. 23 settembre 2026 alle ore 10:58 UTCmonitoring

   Il problema è stato identificato e una correzione è stata implementata e aggiornerà questa pagina quando abbiamo più informazioni.

4. 23 settembre 2026 alle ore 14:58 UTCresolved

   Questo incidente è stato risolto con successo e tutti i sistemi sono completamente operativi.

5. 20 ottobre 2026 alle ore 15:53 UTCpostmortem

   Mercoledì 23 settembre 2026, da circa 08:15 a 11:18 \(UTC\), alcuni clienti hanno sperimentato la lentezza e le presentazioni dei moduli falliti in UK istanze di Secure Webforms. Questo problema è stato causato dai limiti delle prestazioni del database nell'ambiente di produzione del Regno Unito a seguito di un recente cambiamento. Un'impostazione del database ha anche causato alcune domande da eseguire in modo inefficiente. Di conseguenza, i tempi di risposta sono aumentati e alcune sottomissioni di forma sono fallite. Per risolvere questo problema, il nostro team ha temporaneamente sospeso un'attività di sincronizzazione di sfondo per ridurre il carico, ha regolato le impostazioni del database per migliorare l'efficienza delle query e l'aumento del throughput di archiviazione. Secure Webforms è tornato alle normali prestazioni di 11:18 \(UTC\). Per prevenire questo tipo di problema in futuro, stiamo aggiungendo ulteriore monitoraggio per la larghezza di banda del database. Stiamo anche migliorando l'efficienza del compito di sincronizzazione di sfondo. Nessuna perdita di dati si è verificata a seguito di questo problema.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 21 settembre 2026 alle ore 09:32 UTCinvestigating

   Abbiamo ricevuto rapporti che gli utenti non sono in grado di inviare e-mail tramite Web Access (Secure Message Portal) nella regione del Regno Unito, con Errore "503 Service Non disponibile". Stiamo indagando su questo problema e aggiorneremo questa pagina quando avremo maggiori informazioni.

2. 21 settembre 2026 alle ore 14:36 UTCmonitoring

   Abbiamo implementato una correzione e stiamo monitorando i risultati.

3. 21 settembre 2026 alle ore 14:38 UTCmonitoring

   Stiamo continuando a monitorare eventuali ulteriori problemi.

4. 22 settembre 2026 alle ore 08:27 UTCresolved

   Questo incidente è stato risolto con successo e tutti i sistemi sono completamente operativi.

5. 8 ottobre 2026 alle ore 13:45 UTCpostmortem

   Lunedì 21 settembre 2026, da circa 08:55 a martedì 22 settembre 2026, a circa 14:30 \(UTC\), alcuni utenti hanno riscontrato errori e non sono stati in grado di inviare e-mail tramite Web Access \(Secure Message Portal\) nella regione del Regno Unito. Questo incidente è stato causato da un errore di configurazione durante un aggiornamento del database, che ha portato alla rottura del servizio intermittente. Per risolvere questo problema, abbiamo ripristinato la configurazione e Web Access è tornato alle normali prestazioni entro le 14:30 \(UTC\) il 22 settembre 2026. Per prevenire questo tipo di problema in futuro, stiamo rivedendo e aggiornando la nostra configurazione del database. Nessuna perdita di dati si è verificata a seguito di questo problema.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 18 settembre 2026 alle ore 11:07 UTCinvestigating

   Abbiamo ricevuto rapporti che gli utenti non sono in grado di accedere alle istanze DE e UK di KSAT. Stiamo indagando su questo problema e aggiorneremo questa pagina quando avremo maggiori informazioni.

2. 18 settembre 2026 alle ore 16:48 UTCresolved

   Questo incidente è stato risolto.

3. 8 ottobre 2026 alle ore 14:07 UTCpostmortem

   # Summary # Il 17 settembre 2026, un lavoro di sottofondo ha archiviato un grande gruppo di utenti e ha eseguito come una singola transazione di database non-bounded. Questa transazione ha bloccato un gran numero di righe degli utenti, causando i login della regione degli Stati Uniti a time out perché scrivono alla stessa tabella. Dopo aver colpito un limite di esecuzione della piattaforma, il lavoro è stato terminato e riattivato automaticamente cinque volte in intervalli di 15 minuti, con un'interruzione di 75 minuti. Per risolvere il problema, abbiamo implementato una correzione che i login decoupled dal blocco. Abbiamo poi implementato una correzione di follow-up per una regressione introdotta dal cambiamento di login, così come per il lavoro di archivio. # What Happened # Un precedente cambiamento ha spostato l'azione "archivi tutti gli utenti" da una richiesta web sincrona, time-out in un lavoro di sfondo senza limiti. Quando un grande gruppo di utenti è stato archiviato, questo ha innescato il nuovo lavoro di sfondo. Il lavoro ha bloccato tutte le righe utente interessate in una singola transazione, eseguendo scrivanie per utente e una chiamata di servizio esterna sincrona prima di commettere. I tentativi di login, che scrivono alla stessa tabella, sono stati in coda dietro il lavoro bloccato e timed out per gli utenti degli Stati Uniti. Quando il lavoro ha raggiunto un limite di esecuzione della piattaforma di 15 minuti, è stato terminato la media transazione, la transazione è rotolata indietro, e il lavoro è stato ridistribuito alla coda. Questo ciclo si è verificato cinque volte, con un'interruzione di 75 minuti. Quando i guasti sono stati rilevati internamente alle 22:35 \(UTC\), è stato dichiarato un incidente e un ingegnere è stato chiamato a rispondere. La mitigazione per decouplare l'azione di scrittura dal flusso di login è stata implementata a circa 23:44 \(UTC\). La mitigazione stessa ha causato una regressione: qualsiasi utente in qualsiasi regione che in precedenza aveva sbagliato una password non poteva più accedere perché i reset per tentativi di login falliti hanno cercato di scrivere a un database di sola lettura. Entro le 09:17 \(UTC\) il 18 settembre 2026, la soluzione per questa regressione è stata dispiegata in tutte le regioni. L'edizione originale del lavoro di archivio degli Stati Uniti è stata ripetuta due volte più tra le 13:45 e le 14:05 \(UTC\) prima che una fissazione permanente sia stata dispiegata a circa 15:00 \(UTC\). L'incidente è stato completamente risolto entro 19:12 \(UTC\) il 18 settembre 2026. ♪#Root Cause ♪ Un lavoro di sfondo senza limiti per l'archiviazione di utenti di grandi gruppi ha tenuto serrature esclusive su molte righe interessate, bloccando la propria riga del processo di login. Una modifica precedente per spostare questa operazione fuori un timeout di richiesta web e in un lavoro di sfondo rimosso l'unico limite rimanente sulla sua durata. Il limite di esecuzione di 15 minuti della piattaforma ha poi attivato cicli di kill-and-redeliver automatici, ripetendo la conteggiatura di blocco cinque volte e con conseguente una finestra di uscita di 75 minuti. # Findings and Mitigations # Abbiamo scoperto che l'operazione di archivio senza limiti ha bloccato un gran numero di righe utente interessate, bloccando altre voci di tabella. Questo è stato mitigato a breve termine decoupling della dipendenza di scrittura del processo di login dalla tabella interessata, e quindi fissato a lungo termine correggendo il lavoro di archivio. Abbiamo anche scoperto che la concurrenza operaia non coordinata amplifica la contesa di blocco. Ciò è stato mitigato a breve termine riducendo manualmente la convalutazione del lavoratore. La fissazione a lungo termine per pugnalare e serializzare questi lavori è prevista. Infine, abbiamo scoperto che la regressione login-fix ha causato guasti di accesso all-regione per gli utenti con precedenti tentativi falliti perché le scritture sono state respinte da un database di sola lettura. Questo è stato fissato tramite un cambiamento di codice mirato che è stato distribuito e verificato in tutte le regioni. ## ** Misure preventive** Stiamo migliorando le nostre operazioni di archivio di grandi gruppi legandole, elaborandole in lotti piccoli, impegnati, e mantenendo chiamate esterne al di fuori della transazione del database. Stiamo anche aggiungendo un cambiamento-check a un lavoratore di sfondo specifico per saltare le scritture che non cambiano nulla. Infine, stiamo aggiungendo avvisi diretti per l'età delle transazioni del database e ritardi di purificazione, oltre a controlli periodici indiretti. Revisione: I guasti di login durarono circa 75 minuti nella regione degli Stati Uniti. Due brevi ricorsi solo negli Stati Uniti si sono verificati la mattina successiva e sono stati cancellati manualmente in pochi minuti. Alcune azioni di amministrazione, come la gestione degli utenti, sono state anche interessate. I login dei partner non sono stati influenzati. La regressione secondaria è durata circa 10 ore e ha interessato tutte le regioni per gli utenti che avevano precedentemente fallito un tentativo di login. Nel pomeriggio del 18 settembre, il recupero completo è stato confermato in tutte le regioni, e la pagina di stato è stata contrassegnata come risolta. Nessuna perdita di dati si è verificata a seguito di questo problema. # Conclusione # Un'unica operazione di fondo senza limiti, combinata con un meccanismo di riprovazione automatico, ha causato un outage di login nella regione degli Stati Uniti. Il lavoro di attivazione specifico e il suo comportamento di riprovazione sono stati fissati, e il login non dipende più dal percorso di scrittura sostenuto. Una regressione dello stesso incidente e due ricorsi minori sono stati risolti in poche ore. Il mantenimento del lavoro preventivo, compreso il coordinamento dei lavoratori e il monitoraggio delle transazioni del database, è tracciato sopra.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 17 settembre 2026 alle ore 22:44 UTCinvestigating

   Abbiamo ricevuto segnalazioni che gli utenti non sono in grado di accedere all'istanza statunitense di KSAT. Stiamo indagando su questo problema e aggiorneremo questa pagina quando avremo maggiori informazioni.

2. 18 settembre 2026 alle ore 01:28 UTCmonitoring

   Abbiamo implementato una correzione e stiamo monitorando i risultati per assicurarsi che non si verifichino ulteriori problemi.

3. 18 settembre 2026 alle ore 14:02 UTCinvestigating

   Abbiamo ricevuto nuovi rapporti degli utenti che non sono in grado di accedere all'istanza statunitense di KSAT. Stiamo indagando su questo problema e aggiorneremo questa pagina quando avremo maggiori informazioni.

4. 18 settembre 2026 alle ore 16:47 UTCresolved

   Questo incidente è stato risolto.

5. 5 ottobre 2026 alle ore 21:16 UTCpostmortem

   # Summary # Il 17 settembre 2026, un lavoro di sottofondo ha archiviato un grande gruppo di utenti e ha eseguito come una singola transazione di database non-bounded. Questa transazione ha bloccato un gran numero di righe degli utenti, causando i login della regione degli Stati Uniti a time out perché scrivono alla stessa tabella. Dopo aver colpito un limite di esecuzione della piattaforma, il lavoro è stato terminato e riattivato automaticamente cinque volte in intervalli di 15 minuti, con un'interruzione di 75 minuti. Per risolvere il problema, abbiamo implementato una correzione che i login decoupled dal blocco. Abbiamo poi implementato una correzione di follow-up per una regressione introdotta dal cambiamento di login, così come per il lavoro di archivio. # What Happened # Un precedente cambiamento ha spostato l'azione "archivi tutti gli utenti" da una richiesta web sincrona, time-out in un lavoro di sfondo senza limiti. Quando un grande gruppo di utenti è stato archiviato, questo ha innescato il nuovo lavoro di sfondo. Il lavoro ha bloccato tutte le righe utente interessate in una singola transazione, eseguendo scrivanie per utente e una chiamata di servizio esterna sincrona prima di commettere. I tentativi di login, che scrivono alla stessa tabella, sono stati in coda dietro il lavoro bloccato e timed out per gli utenti degli Stati Uniti. Quando il lavoro ha raggiunto un limite di esecuzione della piattaforma di 15 minuti, è stato terminato la media transazione, la transazione è rotolata indietro, e il lavoro è stato ridistribuito alla coda. Questo ciclo si è verificato cinque volte, con un'interruzione di 75 minuti. Quando i guasti sono stati rilevati internamente alle 22:35 \(UTC\), è stato dichiarato un incidente e un ingegnere è stato chiamato a rispondere. La mitigazione per decouplare l'azione di scrittura dal flusso di login è stata implementata a circa 23:44 \(UTC\). La mitigazione stessa ha causato una regressione: qualsiasi utente in qualsiasi regione che in precedenza aveva sbagliato una password non poteva più accedere perché i reset per tentativi di login falliti hanno cercato di scrivere a un database di sola lettura. Entro le 09:17 \(UTC\) il 18 settembre 2026, la soluzione per questa regressione è stata dispiegata in tutte le regioni. L'edizione originale del lavoro di archivio degli Stati Uniti è stata ripetuta due volte più tra le 13:45 e le 14:05 \(UTC\) prima che una fissazione permanente sia stata dispiegata a circa 15:00 \(UTC\). L'incidente è stato completamente risolto entro 19:12 \(UTC\) il 18 settembre 2026. ♪#Root Cause ♪ Un lavoro di sfondo senza limiti per l'archiviazione di utenti di grandi gruppi ha tenuto serrature esclusive su molte righe interessate, bloccando la propria riga del processo di login. Una modifica precedente per spostare questa operazione fuori un timeout di richiesta web e in un lavoro di sfondo rimosso l'unico limite rimanente sulla sua durata. Il limite di esecuzione di 15 minuti della piattaforma ha poi attivato cicli di kill-and-redeliver automatici, ripetendo la conteggiatura di blocco cinque volte e con conseguente una finestra di uscita di 75 minuti. # Findings and Mitigations # Abbiamo scoperto che l'operazione di archivio senza limiti ha bloccato un gran numero di righe utente interessate, bloccando altre voci di tabella. Questo è stato mitigato a breve termine decoupling della dipendenza di scrittura del processo di login dalla tabella interessata, e quindi fissato a lungo termine correggendo il lavoro di archivio. Abbiamo anche scoperto che la concurrenza operaia non coordinata amplifica la contesa di blocco. Ciò è stato mitigato a breve termine riducendo manualmente la convalutazione del lavoratore. La fissazione a lungo termine per pugnalare e serializzare questi lavori è prevista. Infine, abbiamo scoperto che la regressione login-fix ha causato guasti di accesso all-regione per gli utenti con precedenti tentativi falliti perché le scritture sono state respinte da un database di sola lettura. Questo è stato fissato tramite un cambiamento di codice mirato che è stato distribuito e verificato in tutte le regioni. ## ** Misure preventive** Stiamo migliorando le nostre operazioni di archivio di grandi gruppi legandole, elaborandole in lotti piccoli, impegnati, e mantenendo chiamate esterne al di fuori della transazione del database. Stiamo anche aggiungendo un cambiamento-check a un lavoratore di sfondo specifico per saltare le scritture che non cambiano nulla. Infine, stiamo aggiungendo avvisi diretti per l'età delle transazioni del database e ritardi di purificazione, oltre a controlli periodici indiretti. Revisione: I guasti di login durarono circa 75 minuti nella regione degli Stati Uniti. Due brevi ricorsi solo negli Stati Uniti si sono verificati la mattina successiva e sono stati cancellati manualmente in pochi minuti. Alcune azioni di amministrazione, come la gestione degli utenti, sono state anche interessate. I login dei partner non sono stati influenzati. La regressione secondaria è durata circa 10 ore e ha interessato tutte le regioni per gli utenti che avevano precedentemente fallito un tentativo di login. Nel pomeriggio del 18 settembre, il recupero completo è stato confermato in tutte le regioni, e la pagina di stato è stata contrassegnata come risolta. Nessuna perdita di dati si è verificata a seguito di questo problema. # Conclusione # Un'unica operazione di fondo senza limiti, combinata con un meccanismo di riprovazione automatico, ha causato un outage di login nella regione degli Stati Uniti. Il lavoro di attivazione specifico e il suo comportamento di riprovazione sono stati fissati, e il login non dipende più dal percorso di scrittura sostenuto. Una regressione dello stesso incidente e due ricorsi minori sono stati risolti in poche ore. Il mantenimento del lavoro preventivo, compreso il coordinamento dei lavoratori e il monitoraggio delle transazioni del database, è tracciato sopra.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 16 settembre 2026 alle ore 17:47 UTCidentified

   Abbiamo identificato un problema che causa problemi di accesso e di accesso per i conti sulla nostra istanza UK.

2. 16 settembre 2026 alle ore 18:16 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

3. 16 settembre 2026 alle ore 20:58 UTCresolved

   Questo incidente è stato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 11 settembre 2026 alle ore 12:43 UTCresolved

   Su Septermber 8th abbiamo fatto sapere che le e-mail HTML in entrata rese parzialmente o in bianco in Classic Outlook a causa di un aggiornamento di libreria HTML di routine nel motore di rimozione codice dannoso di Defend che interagisce con il vecchio motore di rendering Word di Classic Outlook. Nuovo Outlook e Outlook sul web non sono stati colpiti. Questo è stato rigorosamente un problema di visualizzazione: nessuna e-mail è stata ritardata, persa, o compromessa, e il rilevamento delle minacce è rimasto pienamente attivo. L'ingegneria ha ripristinato l'aggiornamento per ripristinare il rendering normale. Se si disattiva temporaneamente la rimozione di codice dannoso durante questa finestra, si prega di riattivarlo per garantire una protezione completa.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 4 settembre 2026 alle ore 10:53 UTCinvestigating

   Abbiamo ricevuto rapporti di un problema con la consegna della verifica di posta elettronica MFA per lo spazio di lavoro. Stiamo indagando su questo problema e aggiorneremo questa pagina quando avremo maggiori informazioni.

2. 4 settembre 2026 alle ore 14:24 UTCmonitoring

   Abbiamo ricevuto rapporti che il problema con la consegna della verifica di posta elettronica MFA for Workspace è stato mitigato da Microsoft, e stiamo monitorando i risultati.

3. 7 settembre 2026 alle ore 08:25 UTCresolved

   Questo incidente è stato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 26 agosto 2026 alle ore 16:19 UTCinvestigating

   Abbiamo identificato un problema in cui gli utenti possono sperimentare ritardi nei messaggi in fase di elaborazione, e il nostro team di ingegneria sta cercando una soluzione.

2. 26 agosto 2026 alle ore 16:46 UTCmonitoring

   Il nostro team di ingegneri ha implementato una soluzione per il problema che causa i ritardi di elaborazione dei messaggi in PhishER, e stiamo monitorando i risultati.

3. 26 agosto 2026 alle ore 19:51 UTCresolved

   Il nostro team di ingegneria ha implementato una soluzione per il problema che causando ritardi di elaborazione dei messaggi in PhishER.

4. 16 ottobre 2026 alle ore 20:36 UTCpostmortem

   # Summary # Durante una distribuzione di routine il 26 agosto 2026, un framework di gestione delle infrastrutture inaspettatamente rimosso sia le code di elaborazione dei messaggi primari che le code secondarie che tengono i messaggi che non potrebbero essere elaborati. Ciò ha comportato una temporanea interruzione della consegna e-mail in arrivo alle caselle di posta dei clienti PhishER. Nessuna perdita di dati si è verificata a seguito di questo problema. ♪#Root Cause ♪ Il 24 agosto 2026, una modifica di configurazione interna ha lasciato record di configurazione dal vivo di sincronizzazione con il nostro codice. Un successivo aggiornamento del codice non ha cambiato i record. Quando una distribuzione di produzione di routine è avvenuta il 26 agosto 2026, il codice di configurazione attivo non contiene i record di risorse trasferite. Di conseguenza, la distribuzione ha trattato le code attive come risorse non gestite e le ha rimosse. # Mitigation and Remediation # Il monitoraggio automatizzato ci ha avvisato di una diminuzione dell'elaborazione dei messaggi, e un team di risposta incidente è stato assemblato. Abbiamo scoperto che le code erano state cancellate. Ciò è stato mitigato a breve termine rifacendo i lavori di produzione colpiti per ricreare le code mancanti. Abbiamo quindi verificato che l'elaborazione e-mail in tempo reale era ripresa. Infine, abbiamo riprodotto i carichi di posta elettronica tenuti in cloud storage durante l'outage nelle caselle di posta dei clienti. # Timeline # Tutte le volte sono in UTC. # August 24, 2026, 18:41 # Una modifica di configurazione interna ha scritto record di risorse aggiornati nella configurazione di produzione dal vivo. ♪ August 26, 2026, 15:15 ♪ Una distribuzione di produzione ha rimosso le code in entrata e le code che tengono i messaggi che non potrebbero essere elaborati in produzione, interrompendo la consegna e-mail nelle caselle di posta dei clienti. Traduzione: Il nostro monitoraggio automatizzato ha avvertito il team di ingegneria a zero messaggi in fase di elaborazione, e un team di risposta incidente è stato chiamato. Traduzione: Abbiamo confermato che le code erano state cancellate e verificate che i carichi di pagamento delle email in arrivo erano ancora memorizzati in modo sicuro. # August 26, 2026, 16:15 # Abbiamo identificato il errore di configurazione come causa principale della radice. Traduzione: Il nostro team ha ripreso i lavori di produzione colpiti, e le code sono state ricreate. Traduzione: Il nostro riplay automatizzato ha finito di fornire tutte le e-mail di backlogged alle caselle di posta dei clienti. ## ** Misure preventive** Per evitare questo tipo di problema in futuro, abbiamo rimosso un passo di configurazione dal vivo dai controlli pre-merge e dalla pianificazione separata della distribuzione dai cambiamenti di produzione. Abbiamo anche aggiunto controlli automatizzati per confermare la salute della coda dopo che le uscite sono complete. Revisione: Dalle 15:15 alle 16:25 \(UTC\) il 26 agosto 2026, le e-mail in arrivo inviate a PhishER non sono state elaborate nelle caselle di posta del cliente. I carichi di posta elettronica in entrata sono stati memorizzati in modo sicuro nell'archiviazione del cloud durante tutta la disgregazione. Dopo che le code sono state ripristinate, una riproduzione automatizzata ha consegnato e-mail detenute alle caselle di posta dei clienti. Tutti i messaggi registrati sono stati consegnati da 18:44 \(UTC\). Nessun dato e-mail del cliente è stato perso a seguito di questo problema.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 21 agosto 2026 alle ore 08:52 UTCinvestigating

   Abbiamo ricevuto segnalazioni che il pulsante Gmail Phish Alert mostra l'errore "[reportPhishAttempt()] Si è verificato un errore interno. Si prega di riprovare." quando si segnala phish. Stiamo indagando su questo problema e aggiorneremo questa pagina quando avremo maggiori informazioni.

2. 21 agosto 2026 alle ore 12:03 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

3. 21 agosto 2026 alle ore 13:08 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

4. 21 agosto 2026 alle ore 14:57 UTCresolved

   Questo incidente è stato risolto.

5. 26 agosto 2026 alle ore 15:55 UTCpostmortem

   Venerdì 21 agosto 2026, da circa 05:20 a 12:55 \(UTC\), alcuni clienti hanno sperimentato guasti intermittenti durante l'utilizzo di Gmail Phish Alert Button add-in per segnalare e-mail sospette, ricevendo il messaggio "Un errore interno è avvenuto" invece di una conferma del rapporto di successo. Il problema riguardava i clienti in tutte le regioni, con i volumi di errore più elevati concentrati nelle regioni di servizio UE-Ovest e US-Est. Questo problema è stato causato da una disgregazione in un servizio di caching sulla piattaforma Google Apps Script, che l'add-in si basa su per memorizzare la configurazione di sessione per utente. Il servizio ha cominciato intermittentemente restituire i risultati vuoti sulla lettura mentre ancora accettando nuove scritture, causando sottomissioni di report interessati a fallire. KnowBe4 impegnato Google direttamente e archiviato un bug report formale tra circa 12:19 e 12:39 \(UTC\). Il volume di errore è diminuito bruscamente poco dopo che la condizione lato fornitore è stata sgomberata, e il pulsante Gmail Phish Alert è tornato alle prestazioni normali di circa 12:55 \(UTC\). Per evitare questo tipo di problema in futuro, stiamo continuando a lavorare con Google per monitorare la risoluzione del difetto di caching sottostante. Nessuna perdita di dati si è verificata a seguito di questo problema.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 18 agosto 2026 alle ore 14:29 UTCinvestigating

   Stiamo indagando su un problema che causa un rapporto non di consegna (NDR) da restituire quando un messaggio viene segnalato tramite il pulsante di avviso Phish e "Inviaci una copia" è abilitato nelle impostazioni dell'account

2. 18 agosto 2026 alle ore 15:26 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

3. 18 agosto 2026 alle ore 20:14 UTCresolved

   Questo incidente è stato risolto.

4. 30 settembre 2026 alle ore 20:06 UTCpostmortem

   Martedì 18 agosto 2026, da circa 14:10 a 14:55 \(UTC\), i clienti che utilizzano il Pulsante Phish Alert \(PAB\) con la funzione **Inviaci una funzione Copy** ha permesso di ricevere report non di consegna per il **Inviaci una casella di posta Copy**. Questo problema è stato causato da una modifica di configurazione all'infrastruttura di routing email condivisa. Questa modifica ha rinominato un componente di messaggistica utilizzato sia dal nostro ambiente di stadi e produzione. Poiché una regola di produzione dipendeva da questo componente condiviso, il rinominare ha causato guasti di consegna al ** Inviaci una casella di posta Copia** e ha attivato rapporti non di consegna. Per risolvere questo problema, il nostro team ha aggiornato la configurazione interessata per fare riferimento al componente corretto, e la funzione ** Inviaci una copia** restituita alle prestazioni normali di 14:55 \(UTC\). Per evitare questo tipo di problema in futuro, stiamo separando le configurazioni di routing e-mail per i nostri ambienti di staging e produzione. Stiamo anche riconciliando le configurazioni legacy nei nostri attuali standard di gestione delle infrastrutture. Nessuna perdita di dati si è verificata a seguito di questo problema.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 5 agosto 2026 alle ore 19:29 UTCinvestigating

   We are currently investigating an issue affecting Google PhishRIP queries, which may cause them to fail.

2. 5 agosto 2026 alle ore 21:24 UTCmonitoring

   Based on our investigation into the recent errors affecting Google PhishRIP queries, it appears these may be related to suspended Gmail accounts. We are continuing to monitor the issue.

3. 6 agosto 2026 alle ore 21:56 UTCresolved

   Upon further investigation we have determined that the errors affecting Google PhishRIP queries were related to individual issues on Google accounts.

1. 4 agosto 2026 alle ore 19:19 UTCidentified

   Abbiamo identificato un problema che impedisce alle impostazioni dell'account di caricare nella console SAT.

2. 4 agosto 2026 alle ore 19:51 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

3. 5 agosto 2026 alle ore 12:17 UTCresolved

   Questo incidente è stato risolto.

4. 28 settembre 2026 alle ore 14:35 UTCpostmortem

   Martedì 4 agosto 2026, dalle 18:22 alle 19:43 \(UTC\), alcuni clienti hanno sperimentato problemi di caricamento della pagina **Account Settings** nella console KnowBe4 attraverso le regioni CA, DE, EU, UK e US. Questo problema è stato causato da una serie di modifiche di applicazione che hanno aumentato la complessità di una richiesta GraphQL utilizzata dall'esperienza Impostazioni account. Ogni cambiamento è rimasto al di sotto della soglia di complessità configurata della piattaforma quando valutato individualmente, ma combinato, la richiesta ha superato quella soglia e ha impedito alla pagina di caricare. Ingegneria ha identificato la soglia di complessità come il fattore di contributo e ha implementato un cambiamento correttivo a partire da circa 19:14 \(UTC\). Dopo che la correzione è stata verificata nelle regioni colpite, la console KnowBe4 è tornata alle normali prestazioni di circa 19:43 \(UTC\). Per evitare questo problema in futuro, abbiamo aumentato la soglia di complessità. Nessuna perdita di dati si è verificata a seguito di questo problema.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 28 luglio 2026 alle ore 20:00 UTCinvestigating

   Stiamo indagando su un problema relativo alle e-mail in quarantena da PhishRIP inaspettatamente

2. 28 luglio 2026 alle ore 20:35 UTCmonitoring

   Una correzione è stata implementata per questo problema e le query PhishRIP non sono più in quarantena messaggi inaspettatamente. Stiamo ancora indagando su quesiti che potrebbero essere stati influenzati

3. 29 luglio 2026 alle ore 18:58 UTCresolved

   Questo incidente è stato risolto.

4. 30 luglio 2026 alle ore 16:38 UTCpostmortem

   # Summary # Il 28 luglio 2026, un aggiornamento al servizio PhishRIP ha causato alcune query di ricerca PhishRIP per soddisfare più ampiamente di quanto avrebbero dovuto. Le email di Benign che non soddisfavano i criteri di mittente configurati sono state messe in quarantena in alcuni account dei clienti. I biglietti automatizzati di monitoraggio e assistenza clienti hanno superato rapidamente il problema. L'ingegneria ha annullato il cambiamento entro circa 25 minuti dal dichiarare l'incidente e ha fermato la quarantena indesiderata. Ingegneria quindi manualmente ripristinato le e-mail in quarantena erroneamente alle caselle di posta dei clienti. ♪#Root cause ♪ Il 28 luglio 2026, abbiamo implementato un aggiornamento di manutenzione al servizio di query dietro PhishRIP. Questo aggiornamento è stato progettato per migliorare la gestione degli indirizzi non validi del mittente consentendo al sistema di rientrare alla ricerca solo della porzione di dominio dell'indirizzo. Tuttavia, la logica di validazione esistente ha usato un'espressione regolare che ha richiesto un simbolo "@" nel campo del mittente. Quando una query ha usato un dominio nudo, come [example.com](http://example.com) senza nome utente o simbolo "@", il regex ha contrassegnato il dominio come non valido. Questo conflitto tra la validazione esistente e l'aggiornamento di Domain-search ha causato il sistema a rilasciare completamente i criteri di mittente. La query correva contro le caselle di posta utilizzando solo i suoi parametri rimanenti, e-mail di corrispondenza e di quarantena ben al di fuori del mittente previsto. # Timeline # Tutte le volte sono in UTC. ♫ Time ♫ ♫ Event ♫ | --- | | 19:36 | Il nostro monitoraggio automatizzato ha rilevato modelli di esecuzione anomala query e ha avvisato i nostri ingegneri, che hanno iniziato immediatamente a indagare. # | 19:51 | Il problema è stato aumentato a un incidente di produzione ad alta velocità, e un team di risposta è stato assemblato. # | 19:52 | Il nostro team di supporto ha aumentato i primi biglietti del cliente che hanno segnalato quarantene inaspettate, confermando l'avviso di monitoraggio. | 19:54 | La causa principale è stata tracciata a una recente distribuzione API query, e l'ingegneria ha iniziato a ripristinare il cambiamento. | 20:00 | Le comunicazioni incidenti sono state inviate alla nostra pagina di stato, con PhishRIP contrassegnato come degradato. | 20:16 | La distribuzione è stata completamente rimossa. | | 20:35 | I controlli di produzione hanno confermato che l'oggetto e le domande di dominio erano di nuovo corrispondenti solo i loro obiettivi previsti, e che nessun altro messaggio veniva messo in quarantena in errore. La nostra pagina di stato è stata aggiornata di conseguenza. # | 20:39 | Ingegneria ha iniziato a ripristinare le e-mail in quarantena errata. | 03:49 \(giorno successivo\) | Restauro sono stati completati per tutti i set di query del cliente registrati attraverso il nostro team di supporto. # Mitigation and remediation # ♪Code revert ♪ Abbiamo pesato bloccando le operazioni di PhishRIP attive a metà corsa contro la deviazione del codice. L'eliminazione dei compiti di sfondo avrebbe interrotto i flussi di lavoro legittimi di sicurezza per ogni inquilino, quindi la deviazione era l'opzione migliore. Il revert del codice è stato distribuito e verificato in produzione entro circa 40 minuti di escalation. Restauro di posta elettronica. Per evitare di rilasciare e-mail genuinamente dannose di nuovo in ambienti dei clienti, li abbiamo ripristinati manualmente piuttosto che in massa. Ingegneria ha usato strumenti di amministrazione interni per ripristinare le e-mail in lotti, e ha lavorato con Supporto per verificare ogni ID account, ID query e ricevere prima l'approvazione del cliente. Tutti i conti segnalati sono stati ripristinati durante la notte. Traduzione: Traduzione: Stiamo aggiungendo test di unità e integrazione per le query del mittente di dominio, non standard e stringa nuda per catturare questi casi di input prima dell'implementazione. ♪Query guardrails ♪ Stiamo aggiungendo un controllo nel motore di query che blocca le query da eseguire se i loro parametri di filtraggio del nucleo sono caduti durante la valutazione. # Conclusione # Una singola regola di validazione ha causato questo: un regex che ha assunto ogni campo del mittente conteneva un `@`. Quando le query hanno usato un dominio nudo, tale ipotesi ha lasciato cadere il filtro del mittente e le query corrispondevano molto più posta che previsto. La correzione è stata semplice una volta trovata, e la deviazione ha fermato il danno entro circa 25 minuti di dichiarare l'incidente. Ripristinare la posta in quarantena è stato un processo più difficile: non potevamo ripristinare le e-mail in massa senza rischiare e-mail genuinamente dannose tornare in caselle di posta. Il nostro team ha scelto di procedere con attenzione, lavorando con il supporto per tutta la notte. Due misure preventive avrebbero preso questo in precedenza: una prova che copre solo domande di mittente di dominio, e una guardrail che rifiuta di eseguire una query quando il suo filtro mittente è stato spogliato. Entrambi sono ora previsti. Il problema immediato è risolto, e tutti i conti segnalati sono stati ripristinati. Traduzione: # PhishRIP # Una funzione PhishER che consente agli amministratori di cercare e quarantena corrispondenza e-mail di phishing in ogni casella di posta dell'utente in un'organizzazione. ***Regex \(espressione regolare\):** Un modello utilizzato nel software per cercare il testo e convalidare l'ingresso, come il controllo che un indirizzo e-mail è formattato correttamente. ♪Code revert ♪ Eseguire un aggiornamento software per tornare alla versione stabile precedente.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 17 luglio 2026 alle ore 13:18 UTCinvestigating

   Stiamo indagando gli utenti in grado di acquistare Proteggi licenze su store.knowbe4.com. Aggiorneremo questa pagina quando avremo maggiori informazioni.

2. 17 luglio 2026 alle ore 18:55 UTCmonitoring

   Abbiamo implementato una correzione e stiamo monitorando i risultati per assicurarsi che non si verifichino ulteriori problemi.

3. 20 luglio 2026 alle ore 18:24 UTCinvestigating

   Abbiamo ricevuto rapporti che i clienti non sono in grado di acquistare Proteggi licenze su store.knowbe4.com. Stiamo indagando su questo problema e aggiorneremo questa pagina quando avremo maggiori informazioni.

4. 29 luglio 2026 alle ore 18:40 UTCmonitoring

   Abbiamo implementato una correzione per il negozio online e stiamo monitorando i risultati per assicurarsi che non si verifichino ulteriori problemi.

5. 17 agosto 2026 alle ore 21:02 UTCmonitoring

   Stiamo continuando a monitorare la correzione implementata per il negozio online, per garantire che non si verifichino ulteriori problemi.

6. 11 settembre 2026 alle ore 15:04 UTCresolved

   Questo incidente è stato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.