Istoricul incidentelor Knowbe4

1. 20 octombrie 2026 la 11:37 UTCidentified

   Am identificat cauza înregistrării domeniului care nu poate da sfaturi și lucrează la punerea în aplicare a unui fix. Vom continua să posta pe pagina noastră de stare cu orice informații noi sau actualizări.

2. 21 octombrie 2026 la 15:33 UTCmonitoring

   A fost implementată o soluţie şi monitorizăm rezultatele.

3. 23 octombrie 2026 la 14:55 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.

1. 13 octombrie 2026 la 15:03 UTCinvestigating

   În prezent investigăm o problemă care afectează autentificarea consolei. Vom furniza mai multe actualizări aici, atunci când sunt disponibile.

2. 13 octombrie 2026 la 15:07 UTCmonitoring

   A fost implementată o soluţie şi monitorizăm rezultatele.

3. 13 octombrie 2026 la 16:15 UTCresolved

   Acest incident a fost rezolvat.

4. 14 octombrie 2026 la 14:29 UTCpostmortem

   "Summary" Pe 13 octombrie 2026, de la aproximativ 14:19 la 15:05 \ [UTC\), clienții din toate regiunile nu s-au putut conecta la KnowBe4 Security Awareness Training \ [SAT\) consola, KnowBe4 Learner Experience, și consola PhishER prin KnowBe4 SAT. SAML și login-uri parole returnat erori, și consola KnowBe4 SAT nu a apărut în platforma KnowBe4. Unele procese de fundal, inclusiv sincronizarea utilizatorilor și e-mailuri de formare, de asemenea, a eșuat în acest timp. Incidentul a fost cauzat de o lansare de producţie care a intrat în conflict cu o altă schimbare a codului nostru. Am revenit la lansare, și login-uri recuperate în regiuni între 14:59 și 15:05 \ [UTC\]. Nu s-a produs nicio pierdere de date ca urmare a acestei probleme. ## **Root Cause** O implementare de cod a eliminat o valoare de configurare de pornire pentru a accelera timpul de pornire a aplicației. O componentă separată, adăugată la codul nostru după ce modificarea originală a fost testată, nu a cont pentru această valoare modificată. Ca rezultat, fiecare încercare de a salva un record de utilizator a ridicat o eroare, inclusiv actualizarea care înregistrează încercările de sign-in. Traducerea şi adaptarea: Clienții din toate regiunile nu s-au putut conecta la consola KSAT prin SAML sau parolă. De asemenea, ei nu au putut accesa Experienţa Learner şi nu au putut accesa consola PhishER prin consola KnowBe4. Crearea de noi utilizatori, sincronizarea cu utilizatorul și e-mailurile de formare au eșuat în acest timp, dar au fost rejudecate automat după ce implementarea a fost returnată. Traducerea şi adaptarea: Am constatat că implementarea a eliminat o valoare de configurare care o altă componentă încă mai necesită. Acest lucru a fost atenuat prin revenirea la versiune, și am confirmat redresarea în toate regiunile prin controale directe și teste automatizate. De asemenea, am returnat modificarea originală în codul nostru sursă și am pregătit o versiune corectată care include un fix de compatibilitate, astfel încât îmbunătățirea originală poate fi reintrodusă în siguranță. ## **Măsuri preventive** Adăugăm verificări de coduri suplimentare şi teste pentru desfăşurare.

Traducere automată din actualizarea oficială a incidentului.

1. 13 octombrie 2026 la 08:47 UTCinvestigating

   Am primit rapoarte că KnowBe4 Email Security Add-in arată eroarea "Add-in KnowBe4 e-mail de securitate împiedică acest mesaj să fie trimis" atunci când trimite e-mailuri. Investigăm această problemă și vom actualiza această pagină atunci când vom avea mai multe informații.

2. 13 octombrie 2026 la 11:07 UTCmonitoring

   Am implementat un fix pentru erori de trimitere web add-in și noi suntem monitorizarea rezultatelor pentru a vă asigura că nu apar alte probleme.

3. 13 octombrie 2026 la 13:41 UTCresolved

   Acest incident a fost rezolvat.

4. 20 octombrie 2026 la 12:48 UTCpostmortem

   De luni, 12 octombrie 2026, la aproximativ 14:25 \ [UTC\), până marți, 13 octombrie 2026, în jurul orei 15:07 \ (UTC\), unii clienți din UE în cazuri de Prevent și Protect au avut dificultăți în trimiterea de e-mailuri de la Microsoft Outlook. Mesajele afectate nu au fost trimise, iar e-mailul KnowBe4 afişat următoarea eroare: "Add-in KnowBe4 Email Security împiedică trimiterea acestui mesaj." Această problemă a fost cauzată de o eroare în modul în care a fost pregătită o versiune adăugată pentru lansare, care a produs două copii ușor diferite ale aceleiași versiuni. Când Outlook încarcă adăugarea, descarcă un set de fișiere care trebuie să se potrivească. În cazurile UE, Outlook a primit uneori fișiere din ambele copii, astfel încât adăugarea nu a putut termina încărcarea, iar mesajul nu a fost trimis. Unele dispozitive au salvat, de asemenea, descărcarea eșuată, astfel încât eroarea a continuat pe aceste dispozitive până când a fost aplicată o fixare. Pentru a rezolva această problemă, echipa noastră a corectat fișierele adăugate UE, astfel încât fiecare client să primească un set de potrivire. Apoi am lansat o versiune actualizată a adăugării în toate regiunile, care a eliminat orice erori salvate. @ info: whatsthis Pentru a preveni acest tip de problemă în viitor, schimbăm modul în care versiunile adăugate sunt pregătite și lansate, astfel încât fiecare versiune produce întotdeauna același set de fișiere și fiecare client primește aceeași versiune în același timp. De asemenea, schimbăm add-in-ul astfel încât descărcările eșuate de fișiere add-in nu sunt salvate pe dispozitive. În cele din urmă, adăugăm alerte pentru erori de încărcare suplimentare pentru a le detecta mai devreme. Nu s-a produs nicio pierdere de date ca urmare a acestei probleme.

Traducere automată din actualizarea oficială a incidentului.

1. 28 septembrie 2026 la 21:10 UTCinvestigating

   Investigăm în prezent o problemă privind performanța degradată pentru Prevent și Protect pe serverele noastre din SUA.

2. 29 septembrie 2026 la 13:44 UTCmonitoring

   Am identificat o problemă cu cazurile americane de prevenire și protecție care a dus la o performanță degradată. A fost pusă în aplicare o soluţie şi vom continua să monitorizăm această problemă.

3. 2 octombrie 2026 la 10:32 UTCresolved

   Acest incident a fost rezolvat.

4. 6 octombrie 2026 la 15:51 UTCpostmortem

   "Summary" De luni, 28 septembrie 2026, la aproximativ 16:00 \ [UTC\), până miercuri, 30 septembrie 2026, în jurul orei 12:35 \ (UTC\), unii clienţi au avut probleme cu fluxul întârziat de mail şi intermitente accesând instanţele americane de Prevent şi Protecţie. Pe 28 septembrie, monitorizarea noastră a arătat trafic intens în reţea, cu vârfuri în vârful fiecărei ore. Unii clienţi au început să se confrunte cu probleme intermitente accesând instanţele americane ale consolelor Prevent şi Protect. Căutarea internă pe care o procesează poșta depinde de momentul inițial, iar mesajele au fost coadă ca urmare. Clienții au raportat problema echipei noastre de sprijin, și am postat un aviz pagina de stare. Performanţa şi-a revenit mai târziu în acea zi, pe măsură ce traficul american a scăzut. Pe 29 septembrie, inginerii noştri au revăzut datele din ziua precedentă prin portalurile poştale, serviciile interne de care depind şi stratul de reţea. Întârzierile fluxului de mail și problemele de acces la consolă au revenit pe scurt, apoi s-au ușurat pe măsură ce traficul de rețea a scăzut, urmând același model ca și 28 septembrie. Pe 30 septembrie, de la aproximativ 12:19 la 12:35 \[UTC\), echipa noastră a crescut capacitatea serviciilor de rețea americane în timp ce serviciul a continuat. Sarcina lor a scăzut imediat după schimbare, și Prevent și Protect a revenit la performanța normală de aproximativ 12:35 \ [UTC\) la 30 septembrie 2026. Am monitorizat traficul de vârf pe 30 septembrie și 1 octombrie și nu s-au înregistrat recurențe. Nu s-a produs nicio pierdere de date ca urmare a acestei probleme. ## **Root Cause** Această problemă a fost cauzată de o limită de capacitate în serviciile de rețea care se ocupă de trafic pentru serviciile noastre de prelucrare a poștei din SUA. În timpul traficului de vârf, și mai ales în timpul piroanelor orare, serviciile de rețea nu au putut procesa conexiunile suficient de repede. Această întârziere suplimentară a traficului care trece prin ele şi a cauzat scăderea unor conexiuni. Acest trafic includea cereri interne pe care portalurile noastre poştale le trimit pentru a căuta membrii listei de distribuţie, astfel că se aplică politicile corecte. Aceste cereri sunt supuse unei limite stricte de timp, astfel încât o căutare lentă nu poate ține până procesarea de mail pe termen nelimitat. Atunci când serviciile de rețea au întârziat cererile dincolo de această limită, acestea au eșuat. Ca urmare, procesarea corespondenţei a fost încetinită, iar mesajele au fost coadă. Doi factori au înrăutăţit problema şi au îngreunat identificarea. În primul rând, unele cereri interne au utilizat și aceste servicii de rețea și au fost afectate de limita de capacitate. În al doilea rând, serviciile de rețea au început să se degradeze înainte ca utilizarea lor de calcul să atingă niveluri care ar semnala în mod normal o problemă. Monitorizarea standard nu a prins saturaţia reţelei, aşa că a durat mai mult să se identifice. Găsirea unei modalităţi sigure de creştere a capacităţii fără întreruperea serviciului a necesitat de asemenea timp, motiv pentru care fixarea a fost aplicată la 30 septembrie. Traducerea şi adaptarea: Am constatat că serviciile de rețea americane nu au avut suficientă capacitate pentru a gestiona traficul de vârf. Am redus acest lucru prin creșterea capacității lor într-un mod care a ținut de funcționare serviciu în întreaga schimbare. După creșterea capacității, serviciile de rețea au gestionat traficul de vârf fără alte probleme. Am constatat, de asemenea, că utilizarea calculatorului singur nu a fost un semn de încredere de saturare a rețelei. Ne-am extins monitorizarea pentru a urmări indicatorii de sănătate de rețea în plus față de utilizarea de calcul. În cele din urmă, am constatat că era dificil să aflăm unde cererile interne au cedat. Am adăugat logare care arată în cazul în care cererile interne eșuează și pauză. Traducerea şi adaptarea: În timpul celui mai mare trafic american din 28 şi 29 septembrie, unii clienţi au avut întârzieri în procesarea şi livrarea corespondenţei prin intermediul Prevent and Protect. Mesajele adresate listelor de distribuție ar fi putut fi prelucrate mai lent în timp ce căutările au fost recuperate. Unii clienţi au avut, de asemenea, dificultăţi intermitente de conectare la sau folosind consola SUA. Impactul s-a redus în fiecare zi, pe măsură ce traficul din SUA a scăzut, iar corespondenţa din coadă a fost procesată după recuperarea capacităţii. După schimbarea din 30 septembrie, nu am mai văzut degradare în timpul traficului de vârf. ## **Măsuri preventive** Pentru a preveni acest tip de problemă în viitor, am sporit capacitatea serviciilor de rețea ale SUA și am extins monitorizarea noastră pentru a urmări indicatorii de sănătate de rețea, pe lângă utilizarea de calcul. Am adăugat, de asemenea, logare pentru a îmbunătăți vizibilitatea în cereri interne eșuate.

Traducere automată din actualizarea oficială a incidentului.

1. 24 septembrie 2026 la 17:53 UTCinvestigating

   Am identificat o problemă cu Protect care a dus la performanţe degradate, iar echipa noastră de inginerie caută o soluţie.

2. 24 septembrie 2026 la 18:39 UTCmonitoring

   Am identificat o problemă cu Protect care a dus la performanţe degradate. A fost pusă în aplicare o soluţie şi vom continua să monitorizăm această problemă.

3. 24 septembrie 2026 la 19:57 UTCinvestigating

   Am identificat o problemă cu Protect & Prevent care a dus la performanţe degradate, iar echipa noastră de inginerie caută o soluţie.

4. 24 septembrie 2026 la 21:46 UTCmonitoring

   A fost implementată o soluţie şi monitorizăm rezultatele.

5. 25 septembrie 2026 la 09:16 UTCresolved

   Acest incident a fost rezolvat.

6. 6 octombrie 2026 la 15:51 UTCpostmortem

   "Summary" De joi, 24 septembrie 2026, la aproximativ 17:07 \ [UTC\), până vineri, 25 septembrie 2026, în jurul 09:16 \ (UTC\), unii clienți au experimentat lentoare intermitentă, erori, și fluxul de mail întârziat pentru cazurile americane de Protect and Prevent. Pe 24 septembrie, un vârf neobişnuit de mare în e-mail trafic plasat sarcină susţinută pe serviciile de reţea care se ocupă de trafic pentru procesarea noastră de e-mail din SUA. Monitorizarea noastră ne-a alertat la aproximativ 17:07 \ [UTC\]. Unii clienți au văzut acces lent sau intermitent la Protect și erori ocazionale la încărcarea paginilor sau opțiuni avansate. Accesul a fost inconsistent, astfel încât unii clienți ar putea folosi Protect în timp ce alții au văzut erori. Procesarea mail-ului prin instanţe americane a încetinit, iar unele mesaje au fost întârziate sau nu au apărut în inbox-ul moderator când era de aşteptat. Spectacolul părea să se îmbunătățească, așa că am mutat notificarea paginii de stare la monitorizare la 18:39 \ [UTC\]. Problema a reapărut ulterior, iar clienţii au raportat că echipa noastră de sprijin a fost în continuare lentă. La 19:57 \ [UTC\), am mutat notificarea înapoi la Investigare și extins-l pentru a include, de asemenea, Prevent ca impactul a devenit mai clar. Echipa noastră a monitorizat sistemele afectate în timp ce volumul ridicat de mail a scăzut. Pe măsură ce încărcătura serviciilor de rețea a revenit la normal, procesarea poștei a revenit la normal peste noapte. Am confirmat că Protect se încărca normal şi că mesajele de test au fost livrate din nou şi apoi au continuat monitorizarea. Protejează și Prevent a revenit la performanța normală cu aproximativ 09:16 \ [UTC\) la 25 septembrie 2026. Nu s-a produs nicio pierdere de date ca urmare a acestei probleme. ## **Root Cause** Această problemă a fost cauzată de un vârf neobișnuit de mare în traficul de e-mail. Volumul crescut plasat o sarcină susținută pe serviciile de rețea care se ocupă de trafic pentru procesarea noastră de poștă din SUA. Aceste servicii de rețea funcționează în limitele capacității fixe, iar capacitatea lor nu a putut fi mărită în timpul vârfului. Pentru că nu au putut ţine pasul cu valul, au încetinit, şi unele procesare a eşuat intermitent. Ca urmare, un volum mare de e-mail a fost coadă în SUA de prelucrare a mail-ului, unele pagini și acțiuni în Protejează erorile returnate, și unele mesaje au fost întârziate sau nu au apărut în inbox moderare, atunci când se așteaptă. Doi factori au îngreunat gestionarea problemei. În primul rând, deoarece accesul a eșuat intermitent, unele verificări au reușit în timp ce clienții au continuat să vadă erori, ceea ce a îngreunat recuperarea pentru a confirma. În al doilea rând, monitorizarea noastră a arătat sarcina maximă pe serviciile de rețea mai clar decât sarcina curentă, ceea ce a făcut mai greu de judecat în timp real dacă sarcina era încă ridicată. Traducerea şi adaptarea: Am constatat că serviciile de reţea care se ocupă de procesarea corespondenţei americane au atins limitele de capacitate fixă în timpul creşterii traficului, iar capacitatea lor nu a putut fi crescută în timpul evenimentului. Echipa noastra a monitorizat sistemele afectate in timp ce volumul ridicat de mail s-a diminuat si incarcarea serviciului de retea a revenit la normal. Procesarea mail-ului a fost apoi recuperată, iar corespondenţa a fost procesată. Deoarece problema părea să se îmbunătăţească înainte de a se repeta, am confirmat recuperarea în mai multe moduri înainte de rezolvarea incidentului. Am confirmat că Protect se încărca în mod normal, că mesajele de testare au fost livrate prin procesarea poștei americane și că cererile de sprijin progresau în mod normal. De asemenea, am monitorizat peste noapte și nu am primit rapoarte noi de la clienți cu privire la cazurile din SUA. Traducerea şi adaptarea: Unii clienți au avut acces lent sau intermitent la Protect, și, ocazional, au văzut erori la încărcarea paginilor sau opțiuni avansate. Procesarea poștei prin intermediul cazurilor americane a fost întârziată pentru Protect and Prevent. În unele cazuri, mesajele au fost amânate sau nu au apărut în inbox-ul moderare atunci când se aștepta. Clientii a caror mail este criptat, decriptat, sau moderat ca trece prin nostru de procesare a postei SUA au fost mai probabil sa fie afectate. Cele mai multe Protect clientii folosind add-in nu au fost afectate de întârzierile de procesare a postei. Consolele Protect and Prevent au rămas disponibile, deşi unele acţiuni de consolă au fost afectate de procesarea mai lentă a corespondenţei. ## **Măsuri preventive** Pentru a preveni acest tip de problemă în viitor, îmbunătăţim monitorizarea creşterilor neobişnuite ale volumului de e-mail. De asemenea, ne îmbunătăţim monitorizarea pentru a arăta încărcătura curentă a serviciilor noastre de reţea, nu numai valorile maxime. În plus, evaluăm modalități de a ne mări capacitatea de rețea într-un mod mai dinamic în timpul unor creșteri bruște ale traficului și de a evalua îmbunătățirile pe termen lung ale infrastructurii de rețea care se ocupă de procesarea poștei americane. De asemenea, am crescut capacitatea serviciilor de rețea ale SUA ca răspuns la [un incident ulterior] [https://status.knowbe4.com/incidente/9wc6rjm8g70v].

Traducere automată din actualizarea oficială a incidentului.

1. 23 septembrie 2026 la 09:52 UTCidentified

   Am primit rapoarte ale utilizatorilor care au primit mesaje de eroare "Access Negat" în timp ce încercam să ne logăm. Am identificat problema și lucrăm la implementarea unei soluții și vom actualiza această pagină atunci când vom avea mai multe informații.

2. 23 septembrie 2026 la 10:57 UTCmonitoring

   Problema a fost identificată și o fixare a fost pusă în aplicare și va actualiza această pagină atunci când vom avea mai multe informații.

3. 23 septembrie 2026 la 14:58 UTCresolved

   Acest incident a fost rezolvat cu succes și toate sistemele sunt pe deplin operaționale.

Traducere automată din actualizarea oficială a incidentului.

1. 23 septembrie 2026 la 09:00 UTCinvestigating

   Am primit rapoarte că unii utilizatori nu sunt în măsură să depună cu succes transmiteri de formulare web. Investigăm această problemă și vom actualiza această pagină atunci când vom avea mai multe informații.

2. 23 septembrie 2026 la 10:47 UTCidentified

   Problema a fost identificată și a fost pusă în aplicare o soluție. O actualizare cu mai multe informații va urma în consecință.

3. 23 septembrie 2026 la 10:58 UTCmonitoring

   Problema a fost identificată și o fixare a fost pusă în aplicare și va actualiza această pagină atunci când vom avea mai multe informații.

4. 23 septembrie 2026 la 14:58 UTCresolved

   Acest incident a fost rezolvat cu succes și toate sistemele sunt pe deplin operaționale.

5. 20 octombrie 2026 la 15:53 UTCpostmortem

   Miercuri, 23 septembrie 2026, de la aproximativ 08:15 la 11:18 \ (UTC\), unii clienți au experimentat lentețe și transmiteri de formulare eșuate în Marea Britanie cazuri de Security Webforms. Această problemă a fost cauzată de limitele de performanță ale bazei de date în mediul de producție din Regatul Unit în urma unei schimbări recente. Un set de baze de date a determinat, de asemenea, anumite întrebări să funcționeze ineficient. Ca urmare, timpul de răspuns a crescut, iar unele formulare au eșuat. Pentru a rezolva această problemă, echipa noastră a întrerupt temporar o sarcină de sincronizare de fundal pentru a reduce sarcina, a ajustat setările bazei de date pentru a îmbunătăți eficiența interogării, și a crescut procesul de stocare. Security Webforms a revenit la performanta normala pana la 11:18 \ [UTC\]. Pentru a preveni acest tip de problemă în viitor, adăugăm o monitorizare suplimentară pentru banda de bandă a bazei de date. Suntem, de asemenea, îmbunătățirea eficienței sarcinii de sincronizare fundal. Nu s-a produs nicio pierdere de date ca urmare a acestei probleme.

Traducere automată din actualizarea oficială a incidentului.

1. 21 septembrie 2026 la 09:32 UTCinvestigating

   Am primit rapoarte că utilizatorii nu pot trimite e-mailuri prin intermediul Web Access (Secure Message Portal) în regiunea UK, cu eroare "503 Service Indisponibile." Investigăm această problemă și vom actualiza această pagină atunci când vom avea mai multe informații.

2. 21 septembrie 2026 la 14:36 UTCmonitoring

   Am implementat un fix și sunt monitorizarea rezultatelor.

3. 21 septembrie 2026 la 14:38 UTCmonitoring

   Continuăm să monitorizăm orice alte probleme.

4. 22 septembrie 2026 la 08:27 UTCresolved

   Acest incident a fost rezolvat cu succes și toate sistemele sunt pe deplin operaționale.

5. 8 octombrie 2026 la 13:45 UTCpostmortem

   Luni, 21 septembrie 2026, de la aproximativ 08:55 până marţi, 22 septembrie 2026, la aproximativ 14:30 \ (UTC\), unii utilizatori au experimentat erori şi nu au putut trimite e-mailuri prin intermediul Web Access \ [Secure Message Portal\) în regiunea Marea Britanie. Acest incident a fost cauzat de o eroare de configurare în timpul unei actualizări a bazei de date, ceea ce a dus la perturbarea intermitentă a serviciului. Pentru a rezolva această problemă, am returnat configurația, iar accesul la internet a revenit la performanța normală până la 14:30 \ [UTC\) la 22 septembrie 2026. Pentru a preveni acest tip de problemă în viitor, revizuim și actualizăm configurația bazei noastre de date. Nu s-a produs nicio pierdere de date ca urmare a acestei probleme.

Traducere automată din actualizarea oficială a incidentului.

1. 18 septembrie 2026 la 11:07 UTCinvestigating

   Am primit rapoarte că utilizatorii nu se pot conecta la cazurile DE și UK ale KSAT. Investigăm această problemă și vom actualiza această pagină atunci când vom avea mai multe informații.

2. 18 septembrie 2026 la 16:48 UTCresolved

   Acest incident a fost rezolvat.

3. 8 octombrie 2026 la 14:07 UTCpostmortem

   "Summary" Pe 17 septembrie 2026, un loc de muncă de fundal arhivat un grup mare de utilizatori și a fugit ca o singură tranzacție de bază de date fără fir. Această tranzacție blocat un număr mare de rânduri de utilizator, cauzand login-uri din regiunea SUA pentru a time out, deoarece acestea scriu la aceeași masă. După ce a atins o limită de execuție a platformei, locul de muncă a fost terminat și a fost rejudecat automat de cinci ori la intervale de 15 minute, ceea ce a dus la o pană de 75 de minute. Pentru a rezolva problema, am implementat un fix care decuplat login-uri de blocare. Apoi am implementat un fix follow-up pentru o regresie introdusă de schimbarea de autentificare, precum și pentru locul de muncă arhival. Ce s-a întâmplat? O schimbare anterioară a mutat acțiunea "arhivă toți utilizatorii" dintr-o cerere web sincronă, time-out într-un loc de muncă de fundal fără legătură. Când un grup mare de utilizatori a fost arhivat, acest lucru a declanşat noul loc de muncă de fundal. Treaba blocat toate rândurile de utilizator afectate într-o singură tranzacție, efectuarea scrie per utilizator și un apel sincron extern înainte de a comite. Încercările de autentificare, care scriu la aceeaşi masă, au fost puse la coadă în spatele locului de muncă blocat şi programate pentru utilizatorii americani. Când locul de muncă a atins o limită de execuție a platformei de 15 minute, acesta a fost încheiat la jumătatea tranzacției, tranzacția a fost returnată, iar locul de muncă a fost redirecționat la coadă. Acest ciclu a avut loc de cinci ori, rezultând o pană de 75 de minute. Atunci când au fost detectate eșecuri interne la 22:35 \ [UTC\), a fost declarat un incident, și un inginer a fost chemat să răspundă. Atenuarea decuplării acțiunii de scriere din fluxul de conectare a fost implementată la aproximativ 23:44 \ (UTC\). Atenuarea în sine a cauzat o regresie: orice utilizator din orice regiune care anterior nu a mai putut introduce o parolă nu s-a mai putut loga deoarece resetele pentru încercările de autentificare eșuate au încercat să scrie într-o bază de date numai pe bază de citire. Până la 09:17 \ [UTC\) la 18 septembrie 2026, fix pentru această regresie a fost desfășurat în regiuni. Originalul job de arhivă americană a reapărut de două ori mai mult între 13:45 și 14:05 \ (UTC\) înainte ca o fixație permanentă să fie implementată la aproximativ 15:00 \ (UTC\). Incidentul a fost rezolvat complet la ora 19:12 \ [UTC\) la data de 18 septembrie 2026. ## **Root Cause** Un loc de muncă de fundal nelegată, o singură tranzacție pentru arhivarea utilizatorilor de grup mare a avut loc încuietori exclusive pe multe rânduri afectate, blocând procesul de autentificare propria rand scrie. O modificare prealabilă pentru a muta această operațiune de pe o cerere de web timeout și într-un loc de muncă de fundal eliminat singura limită rămasă pe durata sa. Limita de execuţie de 15 minute a platformei a declanşat cicluri automate de ucidere şi livrare, repetând disputa de blocare de cinci ori şi rezultând o fereastră de ieşire de 75 de minute. ## **Findings and Metuments** Am constatat că tranzacția arhivă nelegată blocat un număr mare de rânduri de utilizator afectate, blocarea altor tabele scrie. Acest lucru a fost atenuat pe termen scurt prin decuplarea dependenței de scriere a procesului de autentificare de tabelul afectat și apoi fixat pe termen lung prin corectarea jobului arhivă. Am constatat, de asemenea, că muncitorul necoordonat a amplificat disputa de blocare. Acest lucru a fost atenuat pe termen scurt prin reducerea manuală a convailității lucrătorilor. Fix pe termen lung pentru a stagna și serializa aceste locuri de muncă este planificat. În cele din urmă, am constatat că regresia login-fix a cauzat eşecuri de conectare ale tuturor regiunilor pentru utilizatorii cu tentative anterioare eşuate, deoarece scrierile au fost respinse de o bază de date numai pentru citire. Acest lucru a fost stabilit prin intermediul unei modificări de cod specifice care a fost desfășurată și verificată în toate regiunile. ## **Preventive Measures** Noi imbunatatim operatiunile noastre de arhivare de grup prin legarea lor, prelucrarea lor in loturi mici, angajate, si pastrarea apeluri externe in afara tranzactiei de baza de date. Am adăugat, de asemenea, o schimbare-verifica la un anumit lucrător de fundal pentru a sări peste scrie care nu schimbă nimic. În cele din urmă, adăugăm alerte directe pentru vârsta tranzacţiei în baza de date şi purjăm întârzierile, pe lângă controalele indirecte periodice. Traducerea şi adaptarea: Eșecurile de autentificare au durat aproximativ 75 de minute în regiunea SUA. În dimineaţa următoare au avut loc două recurenţe scurte, care au fost eliminate manual în câteva minute. Unele acțiuni administrative, cum ar fi gestionarea utilizatorilor, au fost, de asemenea, afectate. Autentificarea partenerilor nu a fost afectată. Regresia secundară a durat aproximativ 10 ore și a afectat toate regiunile pentru utilizatorii care anterior nu au reușit o încercare de autentificare. Până în după-amiaza zilei de 18 septembrie, recuperarea completă a fost confirmată în toate regiunile, iar pagina statutului a fost marcată ca fiind rezolvată. Nu s-a produs nicio pierdere de date ca urmare a acestei probleme. ## **Conclusion** O singură tranzacție de fundal nelegată, combinată cu un mecanism de rejudecare automată, a cauzat o întrerupere de conectare în regiunea SUA. Declanşarea specifică de locuri de muncă şi comportamentul său retry au fost fixe, şi login nu mai depinde de calea de scriere susţinută. O regresie cu același incident și două recurențe minore au fost rezolvate în câteva ore. Activitățile preventive rămase, inclusiv coordonarea lucrătorilor și monitorizarea tranzacțiilor în baza de date, sunt urmărite mai sus.

Traducere automată din actualizarea oficială a incidentului.

1. 17 septembrie 2026 la 22:44 UTCinvestigating

   Am primit rapoarte conform cărora utilizatorii nu se pot conecta la cazul KSAT din SUA. Investigăm această problemă și vom actualiza această pagină atunci când vom avea mai multe informații.

2. 18 septembrie 2026 la 01:28 UTCmonitoring

   Am pus în aplicare un fix și noi suntem monitorizarea rezultatelor pentru a vă asigura că nu apar alte probleme.

3. 18 septembrie 2026 la 14:02 UTCinvestigating

   Am primit noi rapoarte că utilizatorii nu se pot conecta la cazul KSAT din SUA. Investigăm această problemă și vom actualiza această pagină atunci când vom avea mai multe informații.

4. 18 septembrie 2026 la 16:47 UTCresolved

   Acest incident a fost rezolvat.

5. 5 octombrie 2026 la 21:16 UTCpostmortem

   "Summary" Pe 17 septembrie 2026, un loc de muncă de fundal arhivat un grup mare de utilizatori și a fugit ca o singură tranzacție de bază de date fără fir. Această tranzacție blocat un număr mare de rânduri de utilizator, cauzand login-uri din regiunea SUA pentru a time out, deoarece acestea scriu la aceeași masă. După ce a atins o limită de execuție a platformei, locul de muncă a fost terminat și a fost rejudecat automat de cinci ori la intervale de 15 minute, ceea ce a dus la o pană de 75 de minute. Pentru a rezolva problema, am implementat un fix care decuplat login-uri de blocare. Apoi am implementat un fix follow-up pentru o regresie introdusă de schimbarea de autentificare, precum și pentru locul de muncă arhival. Ce s-a întâmplat? O schimbare anterioară a mutat acțiunea "arhivă toți utilizatorii" dintr-o cerere web sincronă, time-out într-un loc de muncă de fundal fără legătură. Când un grup mare de utilizatori a fost arhivat, acest lucru a declanşat noul loc de muncă de fundal. Treaba blocat toate rândurile de utilizator afectate într-o singură tranzacție, efectuarea scrie per utilizator și un apel sincron extern înainte de a comite. Încercările de autentificare, care scriu la aceeaşi masă, au fost puse la coadă în spatele locului de muncă blocat şi programate pentru utilizatorii americani. Când locul de muncă a atins o limită de execuție a platformei de 15 minute, acesta a fost încheiat la jumătatea tranzacției, tranzacția a fost returnată, iar locul de muncă a fost redirecționat la coadă. Acest ciclu a avut loc de cinci ori, rezultând o pană de 75 de minute. Atunci când au fost detectate eșecuri interne la 22:35 \ [UTC\), a fost declarat un incident, și un inginer a fost chemat să răspundă. Atenuarea decuplării acțiunii de scriere din fluxul de conectare a fost implementată la aproximativ 23:44 \ (UTC\). Atenuarea în sine a cauzat o regresie: orice utilizator din orice regiune care anterior nu a mai putut introduce o parolă nu s-a mai putut loga deoarece resetele pentru încercările de autentificare eșuate au încercat să scrie într-o bază de date numai pe bază de citire. Până la 09:17 \ [UTC\) la 18 septembrie 2026, fix pentru această regresie a fost desfășurat în regiuni. Originalul job de arhivă americană a reapărut de două ori mai mult între 13:45 și 14:05 \ (UTC\) înainte ca o fixație permanentă să fie implementată la aproximativ 15:00 \ (UTC\). Incidentul a fost rezolvat complet la ora 19:12 \ [UTC\) la data de 18 septembrie 2026. ## **Root Cause** Un loc de muncă de fundal nelegată, o singură tranzacție pentru arhivarea utilizatorilor de grup mare a avut loc încuietori exclusive pe multe rânduri afectate, blocând procesul de autentificare propria rand scrie. O modificare prealabilă pentru a muta această operațiune de pe o cerere de web timeout și într-un loc de muncă de fundal eliminat singura limită rămasă pe durata sa. Limita de execuţie de 15 minute a platformei a declanşat cicluri automate de ucidere şi livrare, repetând disputa de blocare de cinci ori şi rezultând o fereastră de ieşire de 75 de minute. ## **Findings and Metuments** Am constatat că tranzacția arhivă nelegată blocat un număr mare de rânduri de utilizator afectate, blocarea altor tabele scrie. Acest lucru a fost atenuat pe termen scurt prin decuplarea dependenței de scriere a procesului de autentificare de tabelul afectat și apoi fixat pe termen lung prin corectarea jobului arhivă. Am constatat, de asemenea, că muncitorul necoordonat a amplificat disputa de blocare. Acest lucru a fost atenuat pe termen scurt prin reducerea manuală a convailității lucrătorilor. Fix pe termen lung pentru a stagna și serializa aceste locuri de muncă este planificat. În cele din urmă, am constatat că regresia login-fix a cauzat eşecuri de conectare ale tuturor regiunilor pentru utilizatorii cu tentative anterioare eşuate, deoarece scrierile au fost respinse de o bază de date numai pentru citire. Acest lucru a fost stabilit prin intermediul unei modificări de cod specifice care a fost desfășurată și verificată în toate regiunile. ## **Preventive Measures** Noi imbunatatim operatiunile noastre de arhivare de grup prin legarea lor, prelucrarea lor in loturi mici, angajate, si pastrarea apeluri externe in afara tranzactiei de baza de date. Am adăugat, de asemenea, o schimbare-verifica la un anumit lucrător de fundal pentru a sări peste scrie care nu schimbă nimic. În cele din urmă, adăugăm alerte directe pentru vârsta tranzacţiei în baza de date şi purjăm întârzierile, pe lângă controalele indirecte periodice. Traducerea şi adaptarea: Eșecurile de autentificare au durat aproximativ 75 de minute în regiunea SUA. În dimineaţa următoare au avut loc două recurenţe scurte, care au fost eliminate manual în câteva minute. Unele acțiuni administrative, cum ar fi gestionarea utilizatorilor, au fost, de asemenea, afectate. Autentificarea partenerilor nu a fost afectată. Regresia secundară a durat aproximativ 10 ore și a afectat toate regiunile pentru utilizatorii care anterior nu au reușit o încercare de autentificare. Până în după-amiaza zilei de 18 septembrie, recuperarea completă a fost confirmată în toate regiunile, iar pagina statutului a fost marcată ca fiind rezolvată. Nu s-a produs nicio pierdere de date ca urmare a acestei probleme. ## **Conclusion** O singură tranzacție de fundal nelegată, combinată cu un mecanism de rejudecare automată, a cauzat o întrerupere de conectare în regiunea SUA. Declanşarea specifică de locuri de muncă şi comportamentul său retry au fost fixe, şi login nu mai depinde de calea de scriere susţinută. O regresie cu același incident și două recurențe minore au fost rezolvate în câteva ore. Activitățile preventive rămase, inclusiv coordonarea lucrătorilor și monitorizarea tranzacțiilor în baza de date, sunt urmărite mai sus.

Traducere automată din actualizarea oficială a incidentului.

1. 16 septembrie 2026 la 17:47 UTCidentified

   Am identificat o problemă care cauzează probleme de conectare și acces la conturi în cazul nostru din Regatul Unit.

2. 16 septembrie 2026 la 18:16 UTCmonitoring

   A fost implementată o soluţie şi monitorizăm rezultatele.

3. 16 septembrie 2026 la 20:58 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.

1. 11 septembrie 2026 la 12:43 UTCresolved

   Pe 8 Septermber ne-am dat seama că e-mailurile HTML de intrare redate parțial sau gol în Outlook clasic din cauza unui upgrade de bibliotecă HTML de rutină în motorul dăunător-cod-removare Defend interacționează cu motorul de redare Word moștenire clasic Outlook. New Outlook și Outlook pe web nu au fost afectate. Aceasta a fost strict o problemă de afișare: niciun e-mail nu a fost întârziat, pierdut sau compromis, iar detectarea amenințării a rămas pe deplin activă. Inginerie a revenit actualizarea pentru a restabili redarea normală. În cazul în care ați dezactivat temporar îndepărtarea codului dăunător în timpul acestei ferestre, vă rugăm să îl reactivează pentru a asigura protecția completă.

Traducere automată din actualizarea oficială a incidentului.

1. 4 septembrie 2026 la 10:53 UTCinvestigating

   Am primit rapoarte de o problemă cu livrarea de verificare e-mail MFA pentru Workspace. Investigăm această problemă și vom actualiza această pagină atunci când vom avea mai multe informații.

2. 4 septembrie 2026 la 14:24 UTCmonitoring

   Am primit rapoarte că problema cu livrarea de verificare e-mail MFA pentru Workspace a fost atenuată de către Microsoft, și suntem monitorizarea rezultatelor.

3. 7 septembrie 2026 la 08:25 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.

1. 26 august 2026 la 16:19 UTCinvestigating

   Am identificat o problemă în care utilizatorii pot experimenta întârzieri în procesarea mesajelor, iar echipa noastră de inginerie caută o soluţie.

2. 26 august 2026 la 16:46 UTCmonitoring

   Echipa noastră de inginerie a implementat un fix pentru problema care cauzează întârzieri de procesare a mesajelor în PhishER, și noi monitorizăm rezultatele.

3. 26 august 2026 la 19:51 UTCresolved

   Echipa noastră de inginerie a implementat un fix pentru problema care cauzează întârzieri de procesare a mesajelor în PhishER.

4. 16 octombrie 2026 la 20:36 UTCpostmortem

   "Summary" În timpul unei derulări de rutină la 26 august 2026, un cadru de gestionare a infrastructurii a îndepărtat în mod neașteptat atât cozile primare de procesare a mesajelor, cât și cozile secundare care dețin mesaje care nu au putut fi prelucrate. Acest lucru a dus la o întrerupere temporară de livrare de e-mail de intrare la Inboxes clientilor PhishER ." Nu s-a produs nicio pierdere de date ca urmare a acestei probleme. ## **Root Cause** La 24 august 2026, o schimbare de configurare internă a lăsat înregistrări de configurare live din sincronizare cu codul nostru. O actualizare ulterioară a codului nu a revenit la aceste înregistrări. Atunci când o desfășurare de producție de rutină a avut loc pe 26 august 2026, codul de configurare activă nu conținea înregistrările de resurse transferate. În consecință, desfășurarea a tratat cozile active ca resurse negestionate și le-a eliminat. Traducerea şi adaptarea: Monitorizarea automată ne-a alertat la o scădere în procesarea mesajelor, și o echipă de răspuns la incidente a fost asamblat. Am descoperit că cozile au fost şterse. Acest lucru a fost atenuat pe termen scurt prin reluarea locurilor de muncă de producție afectate pentru a recrea cozile lipsă. Apoi am verificat că procesarea e-mailurilor în timp real a fost reluată. În cele din urmă, am rejucat e-mail-uri încărcate în stocare în cloud în timpul întreruperii în inboxurile clienților. "Timeline" Toate timpurile sunt în UTC. ***24 august 2026, 18:41:** O modificare internă de configurare a scris înregistrările actualizate ale resurselor în configurația de producție live. * ** 26 august 2026, 15:15:** O desfășurare a producției a eliminat cozile de intrare și cozile care dețin mesaje care nu puteau fi prelucrate în producție, oprind livrarea de e-mail în inboxurile clienților. * ** 26 august 2026, 15:59:** Monitorizarea noastră automată a alertat echipa de inginerie la zero mesaje fiind prelucrate, și o echipă de răspuns incident a fost chemat. * ** 26 august 2026, 16:01:** Am confirmat că cozile au fost şterse şi verificate că încărcăturile e-mail primite erau încă stocate în siguranţă. * ** 26 august 2026, 16:15:** Am identificat nepotrivirea configuraţiei ca fiind cauza principală. * ** 26 august 2026, 16:25:** Echipa noastră a refăcut locurile de muncă afectate de producție, și cozile au fost recreate. * ** 26 august, 2026, 18:44:** Redarea noastră automată a terminat livrarea tuturor e-mail-uri backlogged la inbox-urile clienților. ## **Măsuri preventive** Pentru a preveni acest tip de problemă în viitor, am îndepărtat un pas live-configurare de la controalele pre-înregistrare și planificarea de desfășurare separată de schimbările de producție. Am adăugat, de asemenea, controale automate pentru a confirma starea de sănătate a cozii după eliberări sunt complete. Traducerea şi adaptarea: De la 15:15 la 16:25 \ [UTC\) pe 26 august 2026, e-mailurile primite trimise la PhishER nu au fost prelucrate în inbox-uri client. Încărcăturile de e-mail de intrare au fost stocate în condiții de siguranță în stocare în cloud pe tot parcursul întreruperii. După ce cozile au fost restaurate, o reluare automată a fost livrată e-mailurile clienților. Toate mesajele backlogged au fost livrate de 18:44 \ [UTC\]. Nu s-au pierdut date de e-mail ale clienților ca urmare a acestei probleme.

Traducere automată din actualizarea oficială a incidentului.

1. 21 august 2026 la 08:52 UTCinvestigating

   Am primit rapoarte că butonul de alertă Gmail Phish arată eroarea "[reportPhishAttemp] A avut loc o eroare internă. Vă rugăm să încercați din nou." atunci când raportează phish. Investigăm această problemă și vom actualiza această pagină atunci când vom avea mai multe informații.

2. 21 august 2026 la 12:03 UTCidentified

   Problema a fost identificată și se pune în aplicare o soluție.

3. 21 august 2026 la 13:08 UTCmonitoring

   A fost implementată o soluţie şi monitorizăm rezultatele.

4. 21 august 2026 la 14:57 UTCresolved

   Acest incident a fost rezolvat.

5. 26 august 2026 la 15:55 UTCpostmortem

   Vineri, 21 august 2026, de la aproximativ 05:20 la 12:55 \ (UTC\), unii clienţi au avut eşecuri intermitente când au folosit butonul de alertă Phish Gmail pentru a raporta e-mail-uri suspecte, primind mesajul "O eroare internă a avut loc" în loc de confirmarea unui raport de succes. Problema a afectat clienții din toate regiunile, cele mai mari volume de erori fiind concentrate în regiunile de servicii UE-Vest și SUA-Est. Această problemă a fost cauzată de o perturbare a unui serviciu de cache pe platforma Google Apps Script, pe care adăugarea se bazează pentru a stoca configurația sesiunii per utilizator. Serviciul a început să întoarcă în mod intermitent rezultatele goale la citire în timp ce acceptau încă scrieri noi, ceea ce a dus la eșuarea rapoartelor. KnowBe4 angajat Google direct și a depus un raport oficial de eroare între aproximativ 12:19 și 12:39 \ (UTC\). Volumul de eroare a scăzut brusc la scurt timp după ce starea vânzător-side eliminate, și butonul de alertă Gmail Phish a revenit la performanța normală cu aproximativ 12:55 \ [UTC\]. Pentru a preveni acest tip de problemă în viitor, continuăm să lucrăm cu Google pentru a urmări rezoluția defectului de cache de bază. Nu s-a produs nicio pierdere de date ca urmare a acestei probleme.

Traducere automată din actualizarea oficială a incidentului.

1. 18 august 2026 la 14:29 UTCinvestigating

   Investigăm o problemă care cauzează returnarea unui raport de non-livrare (NDR) atunci când un mesaj este raportat prin butonul de alertă Phish și "Trimiteți-ne o copie" este activat în Setări Cont

2. 18 august 2026 la 15:26 UTCmonitoring

   A fost implementată o soluţie şi monitorizăm rezultatele.

3. 18 august 2026 la 20:14 UTCresolved

   Acest incident a fost rezolvat.

4. 30 septembrie 2026 la 20:06 UTCpostmortem

   Marţi, 18 august 2026, de la aproximativ 14:10 la 14:55 \ [UTC\), clienţii care utilizează butonul Phish Alert \ (PAB\) cu funcţia **Trimite-ne un exemplar** activate rapoarte primite non-livrare pentru **Trimite-ne o copie** cutie poştală. Această problemă a fost cauzată de o modificare a configurației infrastructurii de rutare a e-mailurilor partajate. Această schimbare a redenumit o componentă de mesagerie folosită atât de mediile noastre de montare, cât și de producție. Deoarece o regulă de producție depindea de această componentă comună, redenumirea a cauzat eșecuri de livrare la **Trimite-ne o cutie poștală Copy** și a declanșat rapoarte non-livrare. Pentru a rezolva această problemă, echipa noastră a actualizat configurația afectată pentru a face trimitere la componenta corectă, iar caracteristica **Trimite-ne o copie** a revenit la performanța normală până la 14:55 \ [UTC\]. Pentru a preveni acest tip de problemă în viitor, separăm configuraţiile de rutare prin e-mail pentru mediile noastre de montaj şi producţie. De asemenea, reconciliem configuraţiile moștenite cu standardele actuale de gestionare a infrastructurii. Nu s-a produs nicio pierdere de date ca urmare a acestei probleme.

Traducere automată din actualizarea oficială a incidentului.

1. 5 august 2026 la 19:29 UTCinvestigating

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

2. 5 august 2026 la 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 august 2026 la 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 august 2026 la 19:19 UTCidentified

   Am identificat o problemă care împiedică setările contului să se încarce în consola SAT.

2. 4 august 2026 la 19:51 UTCmonitoring

   A fost implementată o soluţie şi monitorizăm rezultatele.

3. 5 august 2026 la 12:17 UTCresolved

   Acest incident a fost rezolvat.

4. 28 septembrie 2026 la 14:35 UTCpostmortem

   Marți, 4 august 2026, de la aproximativ 18:22 la 19:43 \ (UTC\), unii clienți au avut probleme cu încărcarea paginii **Account Setări** în consola KnowBe4 din regiunile CA, DE, UE, Marea Britanie și SUA. Această problemă a fost cauzată de o serie de modificări de aplicare care au crescut complexitatea unei cereri GraphQL utilizate de experiența Setări Cont. Fiecare modificare a rămas sub pragul de complexitate configurat al platformei atunci când a fost evaluată individual, dar combinată, cererea a depășit acest prag și a împiedicat încărcarea paginii. Ingineria a identificat pragul de complexitate ca factor care contribuie și a implementat o schimbare corectivă începând cu aproximativ 19:14 \ (UTC\). După ce fix a fost verificat în regiunile afectate, consola KnowBe4 a revenit la performanța normală cu aproximativ 19:43 \ [UTC\]. Pentru a preveni această problemă în viitor, am sporit pragul complexității. Nu s-a produs nicio pierdere de date ca urmare a acestei probleme.

Traducere automată din actualizarea oficială a incidentului.

1. 28 iulie 2026 la 20:00 UTCinvestigating

   Investigăm o problemă legată de e-mailurile aflate în carantină de PhishRIP pe neaşteptate

2. 28 iulie 2026 la 20:35 UTCmonitoring

   S-a pus în aplicare un fix pentru această problemă, iar întrebările PhishRIP nu mai sunt mesaje cu caracter carantinic pe neaşteptate. Încă investigăm întrebări care ar fi putut fi afectate

3. 29 iulie 2026 la 18:58 UTCresolved

   Acest incident a fost rezolvat.

4. 30 iulie 2026 la 16:38 UTCpostmortem

   "Summary" La 28 iulie 2026, o actualizare a serviciului PhishRIP a determinat unele întrebări de căutare PhishRIP să se potrivească mai larg decât ar fi trebuit. E-mailuri benigne care nu au îndeplinit criteriile configurate expeditor au fost în carantină în cadrul unor conturi de clienți. Biletele de monitorizare automată și de sprijin pentru clienți au ieșit la suprafață rapid problema. Ingineria a returnat schimbarea în aproximativ 25 de minute de la declararea incidentului şi a oprit carantina neintenţionată. Ingineria apoi a restaurat manual e-mailurile incorect carantina la clienti . Cauza Root Pe 28 iulie 2026, am implementat o actualizare de întreținere la serviciul de interogare din spatele PhishRIP. Această actualizare a fost concepută pentru a îmbunătăți manipularea adreselor expeditorului invalid, permițând sistemului să se retragă la căutarea numai a porțiunii domeniului de adresa. Cu toate acestea, logica de validare existentă a folosit o expresie regulată care necesita un simbol "@" în câmpul expeditorului. Atunci când o cerere a folosit un domeniu gol, cum ar fi [exemplu.com](http://exemplu.com) fără nume de utilizator sau simbol "@," regex a semnalat domeniul ca fiind invalid. Acest conflict între validarea existentă și actualizarea domeniului de cercetare a determinat sistemul să scadă în întregime criteriile expeditorului. Interogatoriul a fugit împotriva inboxes folosind doar parametrii rămași, potrivire și e-mailuri cu mult în afara expeditorului intenționat. "Timeline" Toate timpurile sunt în UTC. Traducerea şi adaptarea: - Da. Pagina noastră de stare a fost actualizată în consecință. Traducerea şi adaptarea: **Cod revert.** Am cântărit oprirea operaţiunilor active PhishRIP la jumătatea cursei împotriva inversării codului. Oprirea sarcinilor de fundal ar fi perturbat fluxurile de lucru legitime de securitate pentru fiecare chiriaș, astfel încât revenirea a fost opțiunea mai bună. Codul revert a fost implementat și verificat în producție în aproximativ 40 de minute de la escaladare. ** Restaurarea e-mailului.** Pentru a evita eliberarea de e-mailuri cu adevărat maliţioase înapoi în mediile clienţilor, le-am restaurat manual mai degrabă decât în vrac. Inginerie folosit instrumente interne admin pentru a restabili e-mailuri în loturi, și a lucrat cu Suport pentru a verifica fiecare ID cont, ID-ul de interogare, și primi aprobarea clientului mai întâi. Toate conturile raportate au fost restaurate peste noapte. ## **Măsuri preventive** * **Regresia acoperire**: Adăugăm teste de unitate și integrare numai pentru domenii, non-standarde, precum și întrebări expeditorului fără coarde pentru a prinde aceste cazuri de intrare înainte de desfășurare. * ** Query Guardrails**: Adăugăm un cec în motorul de interogare care blochează interogările de funcționare dacă parametrii de filtrare de bază sunt scăzuți în timpul evaluării. ## **Conclusion** O singură regulă de validare a cauzat acest lucru: un regex care a presupus fiecare câmp expeditor conținea o @@ Atunci când întrebările au folosit un domeniu gol, această ipoteză a scăzut filtrul expeditorului și întrebările s-au potrivit mult mai mult cu mail decât era destinat. Fix a fost simplu odată ce l-am găsit, și revert oprit prejudiciul în aproximativ 25 de minute de la declararea incidentului. Restaurarea e-mail-ului în carantină a fost un proces mai dificil: nu am putut restabili e-mailurile în vrac fără a risca e-mailuri cu adevărat maliţioase care se întorc în inboxes. Echipa noastră a ales să continue cu atenție, cont de lucru de cont cu Suport pe tot parcursul nopții. Două măsuri preventive ar fi prins acest lucru mai devreme: un test care acoperă numai domeniile expeditorului întrebări, și un parapet care refuză să ruleze o interogare atunci când filtrul expeditorului său a fost deposedat. Ambele sunt acum planificate pentru. Problema imediată este rezolvată şi toate conturile raportate au fost restaurate. Glosar * **PhishRIP:** O caracteristică PhishER care permite administratorilor de căutare și carantină potrivire phishing e-mailuri pe fiecare inbox utilizator într-o organizație. * ** Regex \ (exprimare regulată\): ** Un model folosit în software pentru a căuta text și a valida intrare, cum ar fi verificarea faptului că o adresă de e-mail este formatată corect. * ** Cod revert:** Back o actualizare software pentru a reveni la versiunea stabilă anterioară.

Traducere automată din actualizarea oficială a incidentului.

1. 17 iulie 2026 la 13:18 UTCinvestigating

   Investigăm utilizatorii care nu pot cumpăra licențe de protecție pe magazin.knowbe4.com. Vom actualiza această pagină atunci când vom avea mai multe informații.

2. 17 iulie 2026 la 18:55 UTCmonitoring

   Am pus în aplicare un fix și noi suntem monitorizarea rezultatelor pentru a vă asigura că nu apar alte probleme.

3. 20 iulie 2026 la 18:24 UTCinvestigating

   Am primit rapoarte că clienții nu sunt în măsură să cumpere licențe de protecție pe magazin.knowbe4.com. Investigăm această problemă și vom actualiza această pagină atunci când vom avea mai multe informații.

4. 29 iulie 2026 la 18:40 UTCmonitoring

   Am implementat un fix pentru magazinul online și noi suntem monitorizarea rezultatelor pentru a vă asigura că nu apar alte probleme.

5. 17 august 2026 la 21:02 UTCmonitoring

   Continuăm să monitorizăm fixarea implementată pentru magazinul online, pentru a ne asigura că nu vor mai apărea alte probleme.

6. 11 septembrie 2026 la 15:04 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.