80 Knowbe4 incidents · september 2025 — official updates, affected components, duration and resolution details.
Vi har identificeret årsagen til at domæneregistreringen ikke kan give råd og arbejder på at gennemføre et fix. Vi vil fortsætte med at skrive på vores status side med nye oplysninger eller opdateringer.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Denne hændelse er blevet løst.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi undersøger i øjeblikket et problem, der påvirker konsollogin. Vi vil levere flere opdateringer her, når de er tilgængelige.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Denne hændelse er blevet løst.
# * * Oversigt * * Den 13. oktober 2026, fra ca. 14: 19 til 15: 05\ (UTC\), kunder i alle regioner var ude af stand til at logge ind på KnowBe4 Security Awareness Training\ (SAT\) konsol, KnowBe4 Learner Experience, og Phisher konsol gennem KnowBe4 SAT. SAML og kodeord logins returnerede fejl, og KnowBe4 SAT konsollen viste sig ikke på KnowBe4 platformen. Nogle baggrundsprocesser, herunder bruger synkronisering og uddannelse e-mails, også mislykkedes i løbet af denne tid. Hændelsen skyldtes en produktionsfrigivelse, der var i konflikt med en anden ændring i vores kode. Vi vendte udgivelsen tilbage, og logins genvundet på tværs af regioner mellem 14: 59 og 15: 05\ (UTC\). Intet tab af data opstod som følge af dette problem. # * * Root Case * * En kode implementering fjernet en opstart konfiguration værdi til at fremskynde programmet opstart tid. En separat komponent, tilføjet til vores kode efter den oprindelige ændring blev testet, tegnede sig ikke for den ændrede værdi. Som et resultat, hvert forsøg på at gemme en bruger rekord rejst en fejl, herunder den opdatering, der registrerer signer- i forsøg. # # * * Kundeeffekt * * Kunder i alle regioner kunne ikke logge ind på KSAT-konsollen via SAML eller adgangskode. De var også ude af stand til at få adgang til Learner Experience, og kunne ikke få adgang til Phisher konsol gennem KnowBe4 SAT konsol. Ny brugerskabelse, brugersynkronisering og uddannelse e-mails mislykkedes i løbet af denne tid, men blev automatisk genprøvet efter indsættelsen blev vendt tilbage. # * * Mitigation og genoptræning * * Vi fandt ud af, at indsættelsen fjernede en konfigurationsværdi, som en anden komponent stadig krævede. Dette blev mindsket ved at vende frigivelsen, og vi bekræftede genopretningen på tværs af alle regioner gennem direkte kontroller og automatiserede test. Vi har også vendt den oprindelige ændring i vores kildekode og udarbejdet en korrigeret version, der indeholder en kompatibilitet fix, så den oprindelige forbedring kan genindføres sikkert. # # * * Forebyggende foranstaltninger * * Vi tilføjer ekstra kode verifikationer og test for deployeringer.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi har modtaget rapporter om, at KnowBe4 Email Security Add-in viser fejlen "The add-in KnowBe4 e-mail sikkerhed forhindrer denne meddelelse i at blive sendt", når du sender e-mails. Vi undersøger dette spørgsmål og vil opdatere denne side, når vi har flere oplysninger.
Vi har implementeret en rettelse til Web Add-i at sende fejl, og vi overvåger resultaterne for at sikre, at der ikke opstår yderligere problemer.
Denne hændelse er blevet løst.
Fra mandag, 12 oktober 2026, på ca. 14: 25\ (UTC\), til tirsdag, 13 oktober, 2026, på ca. 15: 07\ (UTC\), nogle kunder i EU tilfælde af forebyggelse og Beskyt havde svært ved at sende e-mails fra Microsoft Outlook. Påvirkede meddelelser blev ikke sendt, og KnowBe4 Email Security add-in vist følgende fejl: "The add-in KnowBe4 Email Security forhindrer denne meddelelse i at blive sendt". Dette spørgsmål var forårsaget af en fejl i, hvordan en add-in version blev forberedt til udgivelse, som producerede to lidt forskellige kopier af den samme version. Når Outlook indlæser add-in, det downloader et sæt af filer, der skal matche. I EU tilfælde, Outlook undertiden modtaget filer fra begge kopier, så add-in kunne ikke afslutte indlæsning, og beskeden blev ikke sendt. Nogle enheder også gemt den mislykkede download, så fejlen fortsatte på disse enheder, indtil en rettelse blev anvendt. For at løse dette problem rettede vores team EU 's add-in-filer, så alle kunder modtager et matchende sæt. Vi har derefter udgivet en opdateret version af add-in til alle regioner, som har ryddet eventuelle gemte fejl. KnowBe4 e-mail sikkerhed add-in returneret til normal præstation ved omkring 15: 07\ (UTC\) den 13. oktober 2026. For at forhindre denne type problem i fremtiden, vi ændrer, hvordan add-in versioner er forberedt og udgivet, så hver version altid producerer det samme sæt af filer og hver kunde modtager den samme version på samme tid. Vi ændrer også add-in, så mislykkedes downloads af add-in filer ikke gemmes på enheder. Endelig tilføjer vi advarsler til add-in indlæsning fejl til at opdage dem tidligere. Intet tab af data opstod som følge af dette problem.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi er i øjeblikket ved at undersøge et problem vedrørende forringet ydeevne for at forhindre og beskytte på vores amerikanske servere.
Vi har identificeret et problem med de amerikanske tilfælde af forebyggelse og beskyttelse, der har resulteret i forringet ydeevne. Der er gennemført et fix, og vi vil fortsat overvåge dette spørgsmål.
Denne hændelse er blevet løst.
# * * Oversigt * * Fra mandag den 28. september 2026, omkring kl. 16: 00\ (UTC\), til onsdag den 30. september 2026, omkring kl. 12: 35\ (UTC\), oplevede nogle kunder forsinket postflow og intermitterende problemer med at få adgang til amerikanske tilfælde af forebyggelse og beskyttelse. Den 28. september viste vores overvågning stor netværkstrafik med pigge øverst på hver time. Nogle kunder begyndte at opleve intermitterende problemer adgang til amerikanske tilfælde af forebyggelse og Beskyt konsoller. Interne opslag, som mail behandling afhænger af startede timing ud, og meddelelser var i kø som et resultat. Kunderne rapporterede problemet til vores support team, og vi skrev en status side meddelelse. Resultaterne kom sig senere på dagen, da den amerikanske trafik faldt. Den 29. september gennemgik vores ingeniører den foregående dags data på tværs af postgateways, de interne tjenester, de er afhængige af, og netværkslaget. Mail flow forsinkelser og konsol adgang spørgsmål returneres kort, så lettet som netværkstrafikken faldt, efter samme mønster som September 28. Den 30. september, fra ca. 12: 19 til 12: 35\ (UTC\), vores team øget kapaciteten af de amerikanske netværkstjenester, mens tjenesten fortsatte. Deres belastning faldt straks efter ændringen, og forhindre og Beskyt vendt tilbage til normal ydeevne ved omkring 12: 35\ (UTC\) den 30. september 2026. Vi overvågede myldretiden over den 30. september og den 1. oktober og så ingen gentagelser. Intet tab af data opstod som følge af dette problem. # * * Root Case * * Dette spørgsmål var forårsaget af en kapacitetsgrænse i de netværkstjenester, der håndterer trafik for vores amerikanske postbearbejdningstjenester. Under myldretidstrafikken, og især under timelønningerne, kunne netværkstjenesterne ikke behandle tilslutninger hurtigt nok. Denne ekstra forsinkelse af trafikken passerer gennem dem og forårsagede nogle forbindelser til at falde. At trafikken omfattede interne anmodninger vores mail gateways sende til at slå op distributionsliste medlemmer, så de rigtige politikker anvendes. Disse anmodninger er underlagt en streng tidsfrist, så en langsom opslag kan ikke holde op mail behandling på ubestemt tid. Da netværkstjenesterne forsinkede anmodninger ud over denne grænse, mislykkedes de. Som et resultat, mail behandling aftaget, og meddelelser var i kø. To faktorer gjorde spørgsmålet værre og sværere at identificere. For det første anvendte nogle interne anmodninger også disse nettjenester og blev påvirket af kapacitetsgrænsen. For det andet begyndte netværkstjenesterne at degradere, før deres computerforbrug nåede niveauer, der normalt ville signalere et problem. Standard computerovervågning ikke fange netværket mætning, så årsagen tog længere tid at identificere. Det tog også tid at finde en sikker måde at øge kapaciteten uden at afbryde tjenesten på, hvilket er grunden til, at fixet blev anvendt den 30. september. # * * Mitigation og genoptræning * * Vi fandt ud af, at de amerikanske netværkstjenester ikke havde nok kapacitet til at håndtere myldretidstrafikken. Vi har mindsket dette ved at øge deres kapacitet på en måde, der holdt service kører gennem hele ændringen. Efter kapacitetsforøgelsen håndterede netværkstjenesterne spidsbelastningstrafikken uden yderligere problemer. Vi fandt også, at beregne brug alene var ikke et pålideligt tegn på netværk mætning. Vi har udvidet vores overvågning til at spore netværk sundhed indikatorer ud over at beregne brug. Endelig fandt vi det vanskeligt at finde ud af, hvor manglende interne anmodninger brød sammen. Vi har tilføjet logning, der viser, hvor interne anmodninger mislykkes og tid ud. # # * * Kundeeffekt * * Under toppet amerikansk trafik den 28. og 29. september oplevede nogle kunder forsinkelser i behandling og levering af indgående og udgående post gennem Prevent og Protect. Meddelelser til distributionslister kan være blevet behandlet langsommere, mens opslag blev genprøvet. Nogle kunder havde også intermitterende vanskeligheder med at logge ind på eller bruge den amerikanske konsol. Virkningen mindskedes hver dag, da den amerikanske trafik faldt, og forsendelser i kø blev behandlet, når kapaciteten blev genvundet. Efter ændringen den 30. september oplevede vi ingen yderligere forringelse under myldretiden. # # * * Forebyggende foranstaltninger * * For at forhindre denne type problem i fremtiden, har vi øget kapaciteten af de amerikanske netværkstjenester og udvidet vores overvågning til at spore netværk sundhedsindikatorer ud over at beregne brug. Vi har også tilføjet logning for at forbedre synligheden i mislykkede interne anmodninger.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi har identificeret et problem med Protect, der har resulteret i forringet ydeevne, og vores ingeniørhold undersøger et fix.
Vi har identificeret et problem med Protect, der har resulteret i forringet ydeevne. Der er gennemført et fix, og vi vil fortsat overvåge dette spørgsmål.
Vi har identificeret et problem med Protect & Prevent, der har resulteret i forringet ydeevne, og vores ingeniørhold er ved at undersøge et fix.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Denne hændelse er blevet løst.
# * * Oversigt * * Fra torsdag den 24. september 2026, på ca. 17: 07\ (UTC\), til fredag den 25. september 2026, på ca. 09: 16\ (UTC\), oplevede nogle kunder intermitterende langsommelighed, fejl og forsinket mail flow for amerikanske tilfælde af Beskyt og forebyggelse. Den 24. september, en usædvanlig stor spike i e-mail-trafik placeret vedvarende belastning på de netværkstjenester, der håndterer trafik for vores amerikanske mail behandling. Vores overvågning alarmerede os omkring 17: 07\ (UTC\). Nogle kunder så langsom eller periodisk adgang til Beskyt og lejlighedsvis fejl, når du indlæser sider eller avancerede muligheder. Adgangen var inkonsekvent, så nogle kunder kunne bruge Beskyt, mens andre så fejl. Mail behandling gennem amerikanske tilfælde bremset, og nogle meddelelser blev forsinket eller ikke vises i moderation indbakken, når forventet. Præstation syntes at forbedre, så vi flyttede vores status side varsel til Overvågning på 18: 39\ (UTC\). Spørgsmålet kom senere igen, og kunderne rapporterede fortsat langsommelighed til vores support team. På 19: 57\ (UTC\), flyttede vi meddelelsen tilbage til at undersøge og udvidet det til også at omfatte Prevent som virkningen blev klarere. Vores team overvågede de berørte systemer, mens den forhøjede postvolumen forsvandt. Da belastningen på netværkstjenester vendte tilbage til normal, mail behandling genvundet, og mail køer vendte tilbage til normal natten over. Vi bekræftede, at Protect læssede normalt, og at testmeddelelser blev leveret igen og derefter fortsatte overvågningen. Beskyt og forhindre vendt tilbage til normal ydeevne ved omkring 09: 16\ (UTC\) den 25. september 2026. Intet tab af data opstod som følge af dette problem. # * * Root Case * * Dette spørgsmål var forårsaget af en usædvanlig stor stigning i e-mail-trafik. Den øgede volumen placeret en vedvarende belastning på de netværkstjenester, der håndterer trafik til vores amerikanske mail behandling. Disse nettjenester opererer inden for fast kapacitet, og deres kapacitet kunne ikke skaleres op under spiken. Fordi de ikke kunne følge med bølgen, de satte farten ned, og nogle behandling mislykkedes periodisk. Som et resultat, blev en stor mængde post i kø i US mail behandling, nogle sider og handlinger i Beskyt returnerede fejl, og nogle meddelelser blev forsinket eller ikke vises i moderation indbakken, når forventet. To faktorer gjorde problemet sværere at håndtere. For det første, fordi adgang mislykkedes periodisk, nogle kontroller lykkedes, mens kunderne fortsatte med at se fejl, hvilket gør inddrivelse sværere at bekræfte. For det andet viste vores overvågning spidsbelastning på netværkstjenesterne tydeligere end den aktuelle belastning, hvilket gjorde det sværere at bedømme i realtid, om belastningen stadig var forhøjet. # * * Mitigation og genoptræning * * Vi fandt, at de netværkstjenester, der håndterer amerikanske mail behandling havde nået deres faste kapacitetsgrænser under trafikken spike, og deres kapacitet kunne ikke øges under arrangementet. Vores team overvågede de berørte systemer, mens den forhøjede mail volumen forsvandt og netværk service belastning vendte tilbage til normal. Post behandling derefter inddrives, og i kø mail blev behandlet. Fordi problemet tidligere havde syntes at forbedre før tilbagevendende, vi bekræftede bedring på flere måder, før du løser hændelsen. Vi bekræftede, at Protect læssede normalt, at testmeddelelser blev leveret via amerikansk postbehandling, og at støtteanmodninger blev behandlet normalt. Vi overvågede også natten over og modtog ingen nye rapporter fra kunder om amerikanske tilfælde. # # * * Kundeeffekt * * Nogle kunder havde langsom eller periodisk adgang til Beskyt, og lejlighedsvis så fejl, når du indlæser sider eller avancerede muligheder. Mail behandling gennem amerikanske tilfælde blev forsinket for Protect and Prevent. I nogle tilfælde blev meddelelser forsinket eller ikke vist i moderation indbakken, når forventet. Kunder, hvis mail er krypteret, dekrypteret eller modereret som det passerer gennem vores amerikanske mail behandling var mere tilbøjelige til at blive påvirket. De fleste Beskytte kunder, der bruger add-in blev ikke påvirket af mail behandling forsinkelser. Beskyttelses- og forebyggelseskonsollerne forblev tilgængelige, selv om nogle konsolaktioner blev påvirket af den langsommere postbehandling. # # * * Forebyggende foranstaltninger * * For at forhindre denne type problem i fremtiden, vi forbedrer vores overvågning af usædvanlige stigninger i e-mail volumen. Vi forbedrer også vores overvågning for at vise den aktuelle belastning på vores netværkstjenester, ikke kun spidsværdier. Desuden er vi ved at evaluere måder at skalere vores netværkskapacitet mere dynamisk under pludselige trafikstigninger, og vurdere langsigtede forbedringer af den netværksinfrastruktur, der håndterer amerikanske mail behandling. Vi har også siden øget kapaciteten af amerikanske netværkstjenester som reaktion på [en senere hændelse] (https: / / status.knowbe4.com / hændelser / 9wc6rjm8g70v).
Automatisk oversat fra den officielle hændelsesopdatering.
Vi har modtaget rapporter om brugere, der modtager "Access Denied" fejlmeddelelser, mens du forsøger at logge ind. Vi har identificeret problemet og arbejder på at gennemføre en løsning og vil opdatere denne side, når vi har flere oplysninger.
Spørgsmålet er blevet identificeret og en rettelse er blevet gennemført og vil opdatere denne side, når vi har flere oplysninger.
Denne hændelse er blevet løst med succes, og alle systemer er fuldt funktionsdygtige.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi har modtaget rapporter om, at nogle brugere ikke er i stand til at indsende webformindlæg. Vi undersøger dette spørgsmål og vil opdatere denne side, når vi har flere oplysninger.
Spørgsmålet er blevet identificeret, og et fix er blevet gennemført. En opdatering med flere oplysninger vil følge i overensstemmelse hermed.
Spørgsmålet er blevet identificeret og en rettelse er blevet gennemført og vil opdatere denne side, når vi har flere oplysninger.
Denne hændelse er blevet løst med succes, og alle systemer er fuldt funktionsdygtige.
Onsdag den 23. september 2026, fra ca. 08: 15 til 11: 18\ (UTC\), oplevede nogle kunder langsommelighed og fejlede form indlæg i britiske tilfælde af Secure Webforms. Dette spørgsmål var forårsaget af databasepræstationerne i det britiske produktionsmiljø efter en nylig ændring. En databaseindstilling fik også nogle forespørgsler til at køre ineffektivt. Som et resultat, svartider steg, og nogle form indlæg mislykkedes. For at løse dette problem, vores team midlertidigt pause en baggrund synkronisering opgave for at reducere belastningen, justeret databaseindstillinger for at forbedre forespørgslen effektivitet, og øget lagerkapacitet. Secure Webforms returneret til normal ydeevne ved 11: 18\ (UTC\). For at forhindre denne type problem i fremtiden, vi tilføjer yderligere overvågning for database båndbredde. Vi forbedrer også effektiviteten af baggrunden synkronisering opgave. Intet tab af data opstod som følge af dette problem.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi har modtaget rapporter om, at brugerne ikke kan sende e-mails via Web Access (Secure Message Portal) i Det Forenede Kongerige, med Fejl "503 Service Utilgængelig". Vi undersøger dette spørgsmål og vil opdatere denne side, når vi har flere oplysninger.
Vi har implementeret et fix og overvåger resultaterne.
Vi fortsætter med at overvåge for yderligere spørgsmål.
Denne hændelse er blevet løst med succes, og alle systemer er fuldt funktionsdygtige.
Mandag den 21. september 2026, fra omkring 08: 55 til tirsdag den 22. september 2026, omkring 14: 30\ (UTC\), oplevede nogle brugere fejl og var ude af stand til at sende e-mails via Web Access\ (Secure Message Portal\) i Det Forenede Kongerige. Denne hændelse var forårsaget af en konfigurationsfejl under en database opdatering, som førte til intermitterende service afbrydelse. For at løse dette problem, vendte vi konfigurationen tilbage, og Web Access vendte tilbage til normal ydeevne med 14: 30\ (UTC\) den 22. september 2026. For at forhindre denne type spørgsmål i fremtiden, vi gennemgår og opdaterer vores database konfiguration. Intet tab af data opstod som følge af dette problem.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi har modtaget rapporter om, at brugerne ikke er i stand til at logge ind på DE og UK tilfælde af KSAT. Vi undersøger dette spørgsmål og vil opdatere denne side, når vi har flere oplysninger.
Denne hændelse er blevet løst.
# * * Oversigt * * Den 17. september 2026, en baggrund job arkiveret en stor brugergruppe og kørte som en enkelt ubegrænset database transaktion. Denne transaktion låst et stort antal brugerrækker, der forårsager amerikanske region logins til tiden ud, fordi de skriver til samme tabel. Efter at have ramt en platform udførelse grænse, jobbet blev afsluttet og automatisk genforsøgt fem gange i 15-minutters intervaller, hvilket resulterer i en 75-minutters afbrydelse. For at løse problemet, har vi installeret et fix, der afkoblede login fra låsen. Vi derefter indsat en opfølgning fix for en regression indført af login ændring, samt for arkivjobbet. Hvad skete der? En forudgående ændring flyttede "arkiv alle brugere" handling fra en synkront, time- out web anmodning til en uafgrænset baggrund job. Da en stor brugergruppe blev arkiveret, udløste dette det nye baggrundsjob. Jobbet låst alle berørte brugerrækker i en enkelt transaktion, udfører per- bruger skriver og en synkront ekstern service opkald, før du begår. Login forsøg, som skriver til samme bord, var i kø bag den låste job og timet ud for amerikanske brugere. Da jobbet nåede en 15-minutters platform udførelsesgrænse, blev det afsluttet midt-transaktion, transaktionen rullede tilbage, og jobbet blev leveret tilbage til køen. Denne cyklus fandt sted fem gange, hvilket resulterede i en 75 minutters afbrydelse. Når fejl blev opdaget internt på 22: 35\ (UTC\), en hændelse blev erklæret, og en ingeniør blev bedt om at svare. Afbødelsen for at afkoble skrive handling fra login flow blev indsat på ca 23: 44\ (UTC\). Afbødningen selv forårsagede en regression: enhver bruger i enhver region, der tidligere havde misbrugt en adgangskode kunne ikke længere logge ind, fordi nulstilles for mislykkedes login forsøg forsøgte at skrive til en read- only database. Ved 09: 17\ (UTC\) den 18. september 2026, fikseringen for denne regression blev anvendt på tværs af regioner. Den oprindelige US- only arkiv job problem recurred to gange mere mellem 13: 45 og 14: 05\ (UTC\) før en permanent fix blev indsat på ca. 15: 00\ (UTC\). Hændelsen blev helt løst ved 19: 12\ (UTC\) den 18. september 2026. # * * Root Case * * Et uafgrænset, enkelt-transaktion baggrund job for large- gruppe bruger archival holdt eksklusive låse på mange berørte rækker, blokerer login-processen egen række skrive. En forudgående ændring for at flytte denne operation fra en webadresse timeout og ind i en baggrund job fjernet den eneste resterende grænse for dens varighed. Platformen 15-minutters udførelse grænse derefter udløst automatisk kill-and-redelive cykler, gentage låsen contention fem gange og resulterer i en 75-minutters udfald vindue. # # * * Resultater og efterligninger * * Vi fandt, at den ubegrænsede arkiv transaktion låst et stort antal berørte brugerrækker, blokerer andre tabel skriver. Dette blev afhjulpet på kort sigt ved at afkoble login-processens skriveafhængighed fra den berørte tabel, og derefter fast på lang sigt ved at korrigere arkivet job. Vi fandt også, at ukoordineret arbejdstager concurrence forstærker lås striden. Dette blev afbødet på kort sigt ved manuelt at reducere arbejdernes koncurrence. Den langsigtede fix til at stagnere og serialisere disse job er planlagt. Endelig fandt vi, at login- fix regression forårsaget all- region login fejl for brugere med tidligere mislykkede forsøg, fordi skriver blev afvist af en read- only database. Dette blev rettet gennem en målrettet kode ændring, der blev indsat og verificeret på tværs af alle regioner. # * * * Forebyggende foranstaltninger * * Vi forbedrer vores store gruppe archival operationer ved at hoppe dem, behandle dem i små, engagerede partier, og holde eksterne opkald uden for databasen transaktion. Vi tilføjer også en ændring-check til en bestemt baggrund arbejdstager til at springe skriver, der ikke ændrer noget. Endelig tilføjer vi direkte advarsler for databasetransaktionsalder og udrensning af forsinkelser ud over periodiske indirekte kontroller. # # * * Kundeeffekt og inddrivelse * * Login fejl varede omkring 75 minutter i den amerikanske region. To korte, US- kun gentagelser fandt sted næste morgen og blev ryddet manuelt inden for få minutter. Nogle admin handlinger, såsom brugerstyring, blev også påvirket. Partner logins var upåvirket. Den sekundære regression varede omkring 10 timer og påvirkede alle regioner for brugere, der tidligere havde undladt et login forsøg. Ved eftermiddagen i september 18, blev fuld genopretning bekræftet på tværs af alle regioner, og status side blev markeret som løst. Intet tab af data opstod som følge af dette problem. # * * Konklusion * * En enkelt uafgrænset baggrundstransaktion, kombineret med en automatisk gentry mekanisme, forårsagede en login afbrydelse i den amerikanske region. Den specifikke udløsende job og dens gentry adfærd er blevet rettet, og login ikke længere afhænger af den påståede skrive sti. En tilsvarende hændelse regression og to mindre gentagelser blev hver løst inden for timer. Der findes en oversigt over det resterende forebyggende arbejde, herunder koordinering af arbejdstagerne og overvågning af databasetransaktioner.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi har modtaget rapporter om, at brugerne ikke er i stand til at logge ind på det amerikanske tilfælde af KSAT. Vi undersøger dette spørgsmål og vil opdatere denne side, når vi har flere oplysninger.
Vi har implementeret et fix, og vi overvåger resultaterne for at sikre, at der ikke opstår flere problemer.
Vi har modtaget nye rapporter om, at brugere ikke kan logge ind på det amerikanske tilfælde af KSAT. Vi undersøger dette spørgsmål og vil opdatere denne side, når vi har flere oplysninger.
Denne hændelse er blevet løst.
# * * Oversigt * * Den 17. september 2026, en baggrund job arkiveret en stor brugergruppe og kørte som en enkelt ubegrænset database transaktion. Denne transaktion låst et stort antal brugerrækker, der forårsager amerikanske region logins til tiden ud, fordi de skriver til samme tabel. Efter at have ramt en platform udførelse grænse, jobbet blev afsluttet og automatisk genforsøgt fem gange i 15-minutters intervaller, hvilket resulterer i en 75-minutters afbrydelse. For at løse problemet, har vi installeret et fix, der afkoblede login fra låsen. Vi derefter indsat en opfølgning fix for en regression indført af login ændring, samt for arkivjobbet. Hvad skete der? En forudgående ændring flyttede "arkiv alle brugere" handling fra en synkront, time- out web anmodning til en uafgrænset baggrund job. Da en stor brugergruppe blev arkiveret, udløste dette det nye baggrundsjob. Jobbet låst alle berørte brugerrækker i en enkelt transaktion, udfører per- bruger skriver og en synkront ekstern service opkald, før du begår. Login forsøg, som skriver til samme bord, var i kø bag den låste job og timet ud for amerikanske brugere. Da jobbet nåede en 15-minutters platform udførelsesgrænse, blev det afsluttet midt-transaktion, transaktionen rullede tilbage, og jobbet blev leveret tilbage til køen. Denne cyklus fandt sted fem gange, hvilket resulterede i en 75 minutters afbrydelse. Når fejl blev opdaget internt på 22: 35\ (UTC\), en hændelse blev erklæret, og en ingeniør blev bedt om at svare. Afbødelsen for at afkoble skrive handling fra login flow blev indsat på ca 23: 44\ (UTC\). Afbødningen selv forårsagede en regression: enhver bruger i enhver region, der tidligere havde misbrugt en adgangskode kunne ikke længere logge ind, fordi nulstilles for mislykkedes login forsøg forsøgte at skrive til en read- only database. Ved 09: 17\ (UTC\) den 18. september 2026, fikseringen for denne regression blev anvendt på tværs af regioner. Den oprindelige US- only arkiv job problem recurred to gange mere mellem 13: 45 og 14: 05\ (UTC\) før en permanent fix blev indsat på ca. 15: 00\ (UTC\). Hændelsen blev helt løst ved 19: 12\ (UTC\) den 18. september 2026. # * * Root Case * * Et uafgrænset, enkelt-transaktion baggrund job for large- gruppe bruger archival holdt eksklusive låse på mange berørte rækker, blokerer login-processen egen række skrive. En forudgående ændring for at flytte denne operation fra en webadresse timeout og ind i en baggrund job fjernet den eneste resterende grænse for dens varighed. Platformen 15-minutters udførelse grænse derefter udløst automatisk kill-and-redelive cykler, gentage låsen contention fem gange og resulterer i en 75-minutters udfald vindue. # # * * Resultater og efterligninger * * Vi fandt, at den ubegrænsede arkiv transaktion låst et stort antal berørte brugerrækker, blokerer andre tabel skriver. Dette blev afhjulpet på kort sigt ved at afkoble login-processens skriveafhængighed fra den berørte tabel, og derefter fast på lang sigt ved at korrigere arkivet job. Vi fandt også, at ukoordineret arbejdstager concurrence forstærker lås striden. Dette blev afbødet på kort sigt ved manuelt at reducere arbejdernes koncurrence. Den langsigtede fix til at stagnere og serialisere disse job er planlagt. Endelig fandt vi, at login- fix regression forårsaget all- region login fejl for brugere med tidligere mislykkede forsøg, fordi skriver blev afvist af en read- only database. Dette blev rettet gennem en målrettet kode ændring, der blev indsat og verificeret på tværs af alle regioner. # * * * Forebyggende foranstaltninger * * Vi forbedrer vores store gruppe archival operationer ved at hoppe dem, behandle dem i små, engagerede partier, og holde eksterne opkald uden for databasen transaktion. Vi tilføjer også en ændring-check til en bestemt baggrund arbejdstager til at springe skriver, der ikke ændrer noget. Endelig tilføjer vi direkte advarsler for databasetransaktionsalder og udrensning af forsinkelser ud over periodiske indirekte kontroller. # # * * Kundeeffekt og inddrivelse * * Login fejl varede omkring 75 minutter i den amerikanske region. To korte, US- kun gentagelser fandt sted næste morgen og blev ryddet manuelt inden for få minutter. Nogle admin handlinger, såsom brugerstyring, blev også påvirket. Partner logins var upåvirket. Den sekundære regression varede omkring 10 timer og påvirkede alle regioner for brugere, der tidligere havde undladt et login forsøg. Ved eftermiddagen i september 18, blev fuld genopretning bekræftet på tværs af alle regioner, og status side blev markeret som løst. Intet tab af data opstod som følge af dette problem. # * * Konklusion * * En enkelt uafgrænset baggrundstransaktion, kombineret med en automatisk gentry mekanisme, forårsagede en login afbrydelse i den amerikanske region. Den specifikke udløsende job og dens gentry adfærd er blevet rettet, og login ikke længere afhænger af den påståede skrive sti. En tilsvarende hændelse regression og to mindre gentagelser blev hver løst inden for timer. Der findes en oversigt over det resterende forebyggende arbejde, herunder koordinering af arbejdstagerne og overvågning af databasetransaktioner.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi har identificeret et problem, der forårsager login og adgang problemer for konti på vores britiske instans.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Denne hændelse er blevet løst.
Automatisk oversat fra den officielle hændelsesopdatering.
På Septermember 8th gjorde vi opmærksom på, at indgående HTML-e-mails gjort delvis eller blank i Classic Outlook på grund af en rutine HTML-bibliotek opgradering i Defend "s harmful- code-fjernelse motor interagere med Classic Outlook" s arv Word rendering motor. Nye Outlook og Outlook på nettet var upåvirket. Dette var strengt et display problem: ingen e-mail blev forsinket, tabt, eller kompromitteret, og trussel detektion forblev fuldt aktiv. Teknikken har vendt opdateringen for at genoprette normal rendering. Hvis du midlertidigt deaktiveret harmful- kode fjernelse under dette vindue, bedes du re- aktivere det for at sikre fuldstændig beskyttelse.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi har modtaget rapporter om et problem med levering af e-mail-verifikation MFA for arbejdsplads. Vi undersøger dette spørgsmål og vil opdatere denne side, når vi har flere oplysninger.
Vi har modtaget rapporter om, at problemet med levering af e-mail-verifikation MFA for Workspace er blevet mildnet af Microsoft, og vi overvåger resultaterne.
Denne hændelse er blevet løst.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi har identificeret et problem, hvor brugerne kan opleve forsinkelser i de meddelelser, der behandles, og vores ingeniørhold undersøger en rettelse.
Vores ingeniørhold har implementeret en rettelse for det problem, der forårsager besked behandling forsinkelser i Phisher, og vi overvåger resultaterne.
Vores ingeniørhold har implementeret en rettelse for det problem, der forårsager besked behandling forsinkelser i Phisher.
# * * Oversigt * * Under en rutinemæssig implementering den 26. august 2026, en infrastruktur management ramme uventet fjernet både den primære message- behandling køer og den sekundære køer, der holder meddelelser, der ikke kunne behandles. Dette resulterede i en midlertidig afbrydelse af indgående e-mail levering til Phisher kunders indbakker. Intet tab af data opstod som følge af dette problem. # * * Root Case * * Den 24. august 2026, en intern konfiguration ændring venstre live konfiguration poster ud af synkronisering med vores kode. En senere kode opdatering ikke vende disse optegnelser. Da en rutinemæssig produktionsindsats løb den 26. august 2026, indeholdt den aktive konfigurationskode ikke de overførte ressourceregistreringer. Som følge heraf behandlede indsættelsen de aktive køer som uforvaltede ressourcer og fjernede dem. # * * Mitigation og genoptræning * * Automatiseret overvågning advarede os om et fald i meddelelsesprocessen, og et team blev samlet. Vi fandt ud af, at køerne var blevet slettet. Dette blev afbødet på kort sigt ved at gendrive de berørte produktionsjob for at genskabe de manglende køer. Derefter bekræftede vi, at real- tid e-mail behandling var genoptaget. Endelig, vi genspillede e-mail nyttelast afholdt i cloud storage under afbrydelser i kundernes indbakker. # * * * Tidslinje * * Alle tidspunkter er i UTC. * * * 24. august 2026, 18: 41: * * En intern konfigurationsændring skrev opdaterede ressourceregistreringer i live produktionskonfiguration. * * * 26. august 2026, 15: 15: * * En produktion implementering fjernet indgående køer og køer, der holder meddelelser, der ikke kunne behandles i produktionen, stoppe e-mail levering i kundernes indbakker. * * * 26. august 2026, 15: 59: * * Vores automatiske overvågning alarmerede ingeniørholdet til nul beskeder, der blev behandlet, og et hændelsesresponsteam blev tilkaldt. * * * 26. august 2026, 16: 01: * * Vi bekræftede, at køerne var blevet slettet og bekræftet, at indgående e-mail nyttelast stadig var gemt sikkert. * * * 26. august 2026, 16: 15: * * Vi identificerede konfigurationsmismatch som den primære årsag. * * * 26. august 2026, 16: 25: * * Vores team genstartede de berørte produktionsjob, og køerne blev genskabt. * * * 26. august 2026, 18: 44: * * Vores automatiske replay færdig med at levere alle bagloggede e-mails til kundernes indbakker. # # * * Forebyggende foranstaltninger * * For at forhindre denne type problem i fremtiden, har vi fjernet en live- konfiguration trin fra pre-fletning kontrol og adskilt implementering planlægning fra produktionsændringer. Vi har også tilføjet automatiske kontroller for at bekræfte køens sundhed efter udgivelsen er færdig. # # * * Kundeeffekt * * Fra 15: 15 til 16: 25\ (UTC\) den August 26, 2026, indgående e-mails indsendt til Phisher blev ikke behandlet i kunde indbakker. Indgående e-mail nyttelaster blev gemt sikkert i cloud storage under afbrydelsen. Efter køerne blev restaureret, en automatiseret replay leveret holdt e-mails til kundernes indbakker. Alle backloggede beskeder blev leveret af 18: 44\ (UTC\). Ingen kunde e-mail data blev tabt som følge af dette problem.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi har modtaget rapporter om, at Gmail Phish Alert Button viser fejlen "[reportPhishAttempt ()] Der er sket en intern fejl. Prøv igen". Vi undersøger dette spørgsmål og vil opdatere denne side, når vi har flere oplysninger.
Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Denne hændelse er blevet løst.
Fredag den 21. august 2026, fra omkring 05: 20 til 12: 55\ (UTC\), oplevede nogle kunder intermitterende fejl, når du bruger Gmail Phish Alert Button add-in til at rapportere mistænkelige e-mails, der modtager "En intern fejl er opstået" besked i stedet for en vellykket rapport bekræftelse. Emnet berørte kunder i alle regioner, med de største fejlmængder koncentreret i EU- West og US- East serviceområder. Dette spørgsmål var forårsaget af en afbrydelse i en caching-tjeneste på Googles Apps Script platform, som add-in bygger på at gemme per- bruger session konfiguration. Tjenesten begyndte periodisk at returnere tomme resultater på læse, mens du stadig accepterer nye skriver, forårsager berørte rapport indlæg til at mislykkes. KnowBe4 engagerede Google direkte og indgav en formel fejlrapport mellem ca. 12: 19 og 12: 39\ (UTC\). Fejlvolumen faldt kraftigt kort tid efter, da ventor- side tilstand ryddet, og Gmail Phish Alert Button vendte tilbage til normal ydeevne med ca. 12: 55\ (UTC\). For at forhindre denne type problem i fremtiden, vi fortsætter med at arbejde med Google til at spore løsningen af den underliggende caching defekt. Intet tab af data opstod som følge af dette problem.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi undersøger et problem som forårsager at en Non- Delivery Report (NDR) returneres når en meddelelse rapporteres via Phish Alert knappen og "Send os en kopi" er aktiveret i kontoindstillinger
Et fix er blevet gennemført, og vi overvåger resultaterne.
Denne hændelse er blevet løst.
Tirsdag den 18. august 2026, fra ca. 14: 10 til 14: 55\ (UTC\), kunder, der bruger Phish Alert Button\ (PAB\) med * * Send os en Copy * * funktion aktiveret modtaget nondelivery rapporter for * * Send os en Copy * * postkasse. Dette spørgsmål var forårsaget af en konfigurationsændring til den delte e-mail routing infrastruktur. Denne ændring omdøbte en meddelelseskomponent, der bruges af både vores iscenesættelse og produktionsmiljøer. Fordi en produktionsregel afhang af denne delte komponent, omdøbningen forårsagede leveringssvigt til * * Send os en Kopi * * postkasse og udløste nondelivery rapporter. For at løse dette problem, vores team opdateret den berørte konfiguration til at henvise til den korrekte komponent, og * * Send os en Kopi * * funktion returneres til normal ydeevne med 14: 55\ (UTC\). For at forhindre denne type problem i fremtiden, er vi at adskille e-mail routing konfigurationer til vores iscenesættelse og produktionsmiljøer. Vi er også ved at forene arv konfigurationer i vores nuværende infrastrukturforvaltningsstandarder. Intet tab af data opstod som følge af dette problem.
Automatisk oversat fra den officielle hændelsesopdatering.
We are currently investigating an issue affecting Google PhishRIP queries, which may cause them to fail.
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.
Upon further investigation we have determined that the errors affecting Google PhishRIP queries were related to individual issues on Google accounts.
Vi har identificeret et problem, der forhindrer kontoindstillinger i at indlæse i SAT-konsollen.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Denne hændelse er blevet løst.
Tirsdag den 4. august 2026, fra ca. 18: 22 til 19: 43\ (UTC\), oplevede nogle kunder problemer med at indlæse * * Kontoindstillinger * * siden i KnowBe4 konsollen på tværs af regionerne CA, DE, EU, Storbritannien og USA. Dette spørgsmål var forårsaget af en række programændringer, der øgede kompleksiteten af en GraphQL anmodning, der anvendes af Kontoindstillinger erfaring. Hver ændring forblev under platformens konfigurerede kompleksitet tærskel, når vurderes individuelt, men kombineret, anmodningen oversteg denne tærskel og forhindrede siden i at indlæse. Teknikken identificerede kompleksitetstærsklen som den medvirkende faktor og anvendte en korrigerende ændring, der begyndte omkring 19: 14\ (UTC\). Efter fixet blev verificeret på tværs af de berørte regioner, vendte KnowBe4 konsollen tilbage til normal ydeevne med ca. 19: 43\ (UTC\). For at forhindre dette spørgsmål i fremtiden har vi øget kompleksitetstærsklen. Intet tab af data opstod som følge af dette problem.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi undersøger et problem i forbindelse med e-mails, der blev sat i karantæne af PhishRIP uventet
En rettelse er blevet gennemført for dette spørgsmål, og PhishRIP forespørgsler er ikke længere i karantæne meddelelser uventet. Vi undersøger stadig spørgsmål, der kan være blevet påvirket
Denne hændelse er blevet løst.
# * * Oversigt * * Den 28. juli 2026, en opdatering til PhishRIP-tjenesten forårsagede nogle PhishRIP søgning forespørgsler til at matche mere bredt, end de burde have. Benigne e-mails, der ikke opfyldte de konfigurerede afsenderkriterier, blev sat i karantæne på tværs af nogle kundekonti. Automatiseret overvågning og kundesupport billetter dukkede problemet hurtigt op. Engineering vendt ændringen inden for cirka 25 minutter efter at erklære hændelsen og stoppet den utilsigtede karantæne. Engineering derefter manuelt restaureret forkert karantæne e-mails til kundernes indbakker. # * * Root cause * * Den 28. juli 2026, vi indsat en vedligeholdelse opdatering til forespørgsel service bag PhishRIP. Opdateringen var designet til at forbedre håndteringen af ugyldige afsenderadresser ved at tillade systemet at falde tilbage til søgning kun domænet del af adressen. Imidlertid anvendte eksisterende valideringslogik et regulært udtryk, der krævede et "@" -symbol i afsenderfeltet. Når en forespørgsel brugte et bare domæne, såsom [example.com] (http: / / example.com) uden brugernavn eller "@" symbol, markerede regex domænet som ugyldigt. Denne konflikt mellem den eksisterende validering og domæne søgningsopdateringen fik systemet til at droppe afsenderkriterier helt. Forespørgslen kørte mod indbakker ved hjælp af kun sine resterende parametre, matchende og karantæne e-mails godt uden for den tilsigtede afsender. # * * * Tidslinje * * Alle tidspunkter er i UTC. * * tid * * tid * * begivenhed * * begivenhed * * ECB 's Styrelsesråd ; 124; 19: 36; 124; Vores automatiserede overvågning opdaget unormal forespørgsel udførelse mønstre og advarede vores ingeniører, der straks begyndte at undersøge.; ; 124; 19: 51; 124; Emnet blev eskaleret til en høj sværhedsgrad produktion hændelse, og et svar team blev samlet.; Vores support team eskalerede de første kunde billetter, der rapporterede uventede karantæne, bekræfter overvågning alarm. ; 124; 19: 54; 124; Rodårsagen blev sporet til en nylig forespørgsler API implementering, og ingeniørarbejde begyndte at vende ændringen. Der blev sendt meddelelser til vores statusside med PhishRIP markeret som Degraderet. 124; 20: 16; deployeringen var fuldt vendt. ; 124; 20: 35; Produktionskontrol bekræftede, at emne og domæne forespørgsler igen var matchende kun deres tilsigtede mål, og at ingen yderligere meddelelser blev sat i karantæne ved en fejl. Vores statusside blev opdateret i overensstemmelse hermed.; ; 20: 39; Engineering begyndte at genoprette forkert karantæne e-mails. Der blev gennemført restaureringer for alle kundesøgningssæt logget gennem vores supporthold. # * * Mitigation og oprydning * * * * Kode tilbage. * * Vi vejede stop aktive PhishRIP operationer mid- køre mod at vende koden. At stoppe baggrundsopgaverne ville have forstyrret legitime sikkerhedsarbejdsgange for hver lejer, så det var bedre at vende tilbage. kodens tilbagevenden blev indsat og verificeret i produktionen inden for ca. 40 minutter efter eskalering. * * Email restaurering. * * For at undgå at frigive ægte ondsindede e-mails tilbage til kundemiljøer, vi manuelt restaurerede dem snarere end i bulk. Engineering brugt interne admin værktøjer til at gendanne e-mails i partier, og arbejdede med Support til at kontrollere hver konto ID, forespørgsel ID, og modtage kundegodkendelse først. Alle indberettede konti blev genoprettet natten over. # # * * Forebyggende foranstaltninger * * * * * Regressionsdækning * *: Vi tilføjer enhed og integration test for domæne-kun, ikke-standard, og bare- streng afsender forespørgsler til at fange disse input-sager før implementering. * * * Forespørgsel guardrails * *: Vi tilføjer en check i forespørgslen motor, der blokerer forespørgsler fra at køre, hvis deres centrale filtreringsparametre er faldet under evalueringen. # * * Konklusion * * En enkelt valideringsregel forårsagede dette: en regex, der antog alle afsenderfelter indeholdt et '@'. Når forespørgsler brugt en bare domæne, denne antagelse faldt afsenderen filter og forespørgsler matchede langt mere post end planlagt. Fixet var ligetil, da vi fandt det, og tilbagefald stoppede skaden inden for omkring 25 minutter efter at erklære hændelsen. Gendannelse i karantæne mail var en hårdere proces: vi kunne ikke gendanne e-mails i bulk uden at risikere virkelig ondsindede e-mails, der går tilbage til indbakker. Vores team valgte at gå forsigtigt frem, arbejde konto for konto med Support hele natten. To forebyggende foranstaltninger ville have fanget dette tidligere: en test, der dækker domæne-kun afsender forespørgsler, og en gardrail, der nægter at køre en forespørgsel, når dens afsender filter er blevet fjernet. Begge er nu planlagt. Det umiddelbare problem er løst, og alle indberettede konti er blevet genoprettet. # # * * Ordliste * * * * * PhishRIP: * * En Phisher funktion, der lader administratorer søge efter og karantæne matchende phishing e-mails på tværs af hver bruger indbakke i en organisation. * * * Regex\ (regulært udtryk\): * * Et mønster, der bruges i software til at søge tekst og validere input, såsom kontrol af, at en e-mail-adresse er formateret korrekt. * * * Kode tilbage: * * Backing ud en software opdatering til at vende tilbage til den tidligere stabile version.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi undersøger brugere bliver ude af stand til at købe Beskyt licenser på store.knobe4.com. Vi vil opdatere denne side, når vi har flere oplysninger.
Vi har implementeret et fix, og vi overvåger resultaterne for at sikre, at der ikke opstår flere problemer.
Vi har modtaget rapporter om, at kunderne ikke er i stand til at købe Beskyt licenser på store.knowbe4.com. Vi undersøger dette spørgsmål og vil opdatere denne side, når vi har flere oplysninger.
Vi har implementeret et fix til online butikken og vi overvåger resultaterne for at sikre, at der ikke opstår yderligere problemer.
Vi fortsætter med at overvåge den gennemførte fix for online butik, for at sikre, at der ikke opstår yderligere problemer.
Denne hændelse er blevet løst.
Automatisk oversat fra den officielle hændelsesopdatering.
