Historique des pannes de Knowbe4

1. 20 octobre 2026 à 11:37 UTCidentified

   Nous avons identifié la cause de l'enregistrement de domaine étant incapable de donner des conseils et travaillent sur la mise en œuvre d'un correctif. Nous continuerons à afficher sur notre page d'état toute nouvelle information ou mise à jour.

2. 21 octobre 2026 à 15:33 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

3. 23 octobre 2026 à 14:55 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 13 octobre 2026 à 15:03 UTCinvestigating

   Nous enquêtons actuellement sur un problème affectant la connexion à la console. Nous fournirons ici d'autres mises à jour lorsque disponibles.

2. 13 octobre 2026 à 15:07 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

3. 13 octobre 2026 à 16:15 UTCresolved

   Cet incident a été résolu.

4. 14 octobre 2026 à 14:29 UTCpostmortem

   Résumé Le 13 octobre 2026, de 14:19 à 15:05 \(UTC\), les clients de toutes les régions n'ont pas pu se connecter à la console KnowBe4 Security Awareness Training \(SAT\), à l'expérience d'apprenant KnowBe4 et à la console PhishER via KnowBe4 SAT. Les connexions SAML et mot de passe ont retourné des erreurs, et la console SAT de KnowBe4 n'est pas apparue dans la plate-forme de KnowBe4. Certains processus d'arrière-plan, y compris la synchronisation des utilisateurs et les courriels de formation, ont également échoué pendant cette période. L'incident a été causé par une libération de production qui a été en conflit avec un autre changement de notre code. Nous avons retourné la version, et les connexions récupérées entre les régions entre 14:59 et 15:05 \(UTC\). Aucune perte de données n'a été causée par ce problème. ## **La cause de la mort** Un déploiement de code a supprimé une valeur de configuration de démarrage pour accélérer le temps de démarrage de l'application. Un composant distinct, ajouté à notre code après que le changement initial a été testé, n'a pas tenu compte de cette valeur modifiée. Par conséquent, chaque tentative de sauvegarder un enregistrement utilisateur a soulevé une erreur, y compris la mise à jour qui enregistre les tentatives de connexion. ** Impact client** Les clients de toutes les régions ne pouvaient pas se connecter à la console KSAT via SAML ou mot de passe. Ils n'ont pas non plus pu accéder à la console PhishER via la console SAT KnowBe4. La création d'un nouvel utilisateur, la synchronisation de l'utilisateur et les courriels de formation ont échoué pendant cette période, mais ont été automatiquement réévalués après le retour du déploiement. **Atténuation et réparation** Nous avons constaté que le déploiement a supprimé une valeur de configuration qu'un autre composant exigeait encore. Cela a été atténué par le retour à la libération, et nous avons confirmé la récupération dans toutes les régions au moyen de vérifications directes et de tests automatisés. Nous avons également retourné la modification originale de notre code source et préparé une version corrigée qui comprend une correction de compatibilité, afin que l'amélioration originale puisse être réintroduite en toute sécurité. ** Mesures préventives** Nous ajoutons des vérifications de code et des tests pour les déploiements.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 13 octobre 2026 à 08:47 UTCinvestigating

   Nous avons reçu des rapports indiquant que le module de sécurité d'email de KnowBe4 montre l'erreur "La sécurité d'email de KnowBe4 d'ajout empêche ce message d'être envoyé" lors de l'envoi des e-mails. Nous enquêtons sur cette question et mettrons à jour cette page lorsque nous aurons plus d'informations.

2. 13 octobre 2026 à 11:07 UTCmonitoring

   Nous avons implémenté un correctif pour le Web Add-in envoyant des erreurs et nous sommes surveillant les résultats pour s'assurer qu'aucun autre problème ne se produise.

3. 13 octobre 2026 à 13:41 UTCresolved

   Cet incident a été résolu.

4. 20 octobre 2026 à 12:48 UTCpostmortem

   Du lundi 12 octobre 2026, vers 14h25 \(UTC\), au mardi 13 octobre 2026, vers 15h07 \(UTC\), certains clients de l'UE cas de Prevent and Protect ont eu de la difficulté à envoyer des courriels de Microsoft Outlook. Les messages touchés n'ont pas été envoyés, et l'ajout de KnowBe4 Email Security affiche l'erreur suivante : « L'ajout de KnowBe4 Email Security empêche l'envoi de ce message ». Ce problème a été causé par une erreur dans la façon dont une version supplémentaire a été préparée pour la publication, qui a produit deux copies légèrement différentes de la même version. Lorsque Outlook charge l'add-in, il télécharge un ensemble de fichiers qui doivent correspondre. Dans les cas de l'UE, Outlook a parfois reçu des fichiers des deux copies, de sorte que l'add-in ne pouvait pas terminer le chargement, et le message n'a pas été envoyé. Certains appareils ont également enregistré le téléchargement échoué, de sorte que l'erreur a continué sur ces appareils jusqu'à ce qu'une correction ait été appliquée. Pour résoudre ce problème, notre équipe a corrigé les fichiers supplémentaires de l'UE afin que chaque client reçoive un ensemble correspondant. Nous avons ensuite publié une version mise à jour de l'ajout à toutes les régions, ce qui a permis de corriger les erreurs enregistrées. Le add-in de KnowBe4 Email Security est retourné à la performance normale d'environ 15:07 \(UTC\) le 13 octobre 2026. Pour éviter ce type de problème à l'avenir, nous changeons la façon dont les versions complémentaires sont préparées et publiées, de sorte que chaque version produit toujours le même ensemble de fichiers et chaque client reçoit la même version en même temps. Nous changeons aussi l'add-in afin que les téléchargements de fichiers add-in échoués ne soient pas enregistrés sur les appareils. Enfin, nous ajoutons des alertes pour ajouter des erreurs de chargement pour les détecter plus tôt. Aucune perte de données n'a été causée par ce problème.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 28 septembre 2026 à 21:10 UTCinvestigating

   Nous enquêtons actuellement sur un problème concernant les performances dégradées pour Prévenir et protéger sur nos serveurs américains.

2. 29 septembre 2026 à 13:44 UTCmonitoring

   Nous avons identifié un problème avec les cas américains de Prévenir et protéger qui a entraîné une dégradation des performances. Un correctif a été mis en place et nous continuerons de suivre cette question.

3. 2 octobre 2026 à 10:32 UTCresolved

   Cet incident a été résolu.

4. 6 octobre 2026 à 15:51 UTCpostmortem

   Résumé Du lundi 28 septembre 2026, vers 16h00 \(UTC\), au mercredi 30 septembre 2026, vers 12h35 \(UTC\), certains clients ont connu un flux de courrier retardé et des problèmes intermittents d'accès aux instances américaines de Prevent and Protect. Le 28 septembre, notre surveillance a montré un trafic réseau lourd, avec des pics au sommet de chaque heure. Certains clients ont commencé à éprouver des difficultés intermittentes à accéder aux instances américaines des consoles Prevent and Protect. Les recherches internes que le traitement du courrier dépend du moment de départ, et les messages ont été en attente par conséquent. Les clients ont signalé le problème à notre équipe de soutien, et nous avons affiché un avis de page de statut. La performance s'est rétablie plus tard dans la journée, alors que le trafic américain diminuait. Le 29 septembre, nos ingénieurs ont examiné les données de la veille sur les passerelles de courrier, les services internes dont ils dépendent et la couche réseau. Les retards d'acheminement du courrier et les problèmes d'accès à la console sont revenus brièvement, puis ils se sont atténués à mesure que le trafic réseau diminuait, suivant le même schéma que le 28 septembre. Le 30 septembre, de 12:19 à 12:35 \(UTC\), notre équipe a augmenté la capacité des services de réseau américains tandis que le service a continué. Leur charge a chuté immédiatement après le changement, et Prevent and Protect est revenue à des performances normales vers 12h35 \(UTC\) le 30 septembre 2026. Nous avons surveillé la circulation maximale au cours des 30 septembre et 1er octobre et nous n'avons constaté aucune récurrence. Aucune perte de données n'a été causée par ce problème. ## **La cause de la mort** Cette question a été causée par une limite de capacité dans les services de réseau qui traitent le trafic pour nos services de traitement du courrier américains. Pendant les pics de trafic, et surtout pendant les pics horaires, les services réseau ne pouvaient pas traiter les connexions assez rapidement. Ce retard supplémentaire pour le trafic passant par eux et a causé la baisse de certaines connexions. Que le trafic inclus les demandes internes nos passerelles de courrier envoient pour rechercher les membres de la liste de distribution, de sorte que les bonnes politiques sont appliquées. Ces demandes sont soumises à un délai strict afin qu'une recherche lente ne puisse pas retarder indéfiniment le traitement du courrier. Lorsque les services réseau ont retardé les demandes au-delà de cette limite, ils ont échoué. Par conséquent, le traitement du courrier a ralenti et les messages ont été en attente. Deux facteurs ont rendu la question pire et plus difficile à identifier. Premièrement, certaines demandes internes ont également utilisé ces services de réseau et ont été touchées par la limite de capacité. Deuxièmement, les services de réseau ont commencé à se dégrader avant que leur utilisation de calcul atteigne des niveaux qui signaleraient normalement un problème. La surveillance de calcul standard n'a pas attrapé la saturation du réseau, donc la cause a pris plus de temps à identifier. Trouver un moyen sûr d'augmenter la capacité sans interrompre le service a aussi pris du temps, c'est pourquoi la correction a été appliquée le 30 septembre. **Atténuation et réparation** Nous avons constaté que les services de réseau américains n'avaient pas assez de capacité pour gérer le trafic de pointe. Nous avons atténué cette situation en augmentant leur capacité de façon à maintenir le service tout au long du changement. Après l'augmentation de la capacité, les services de réseau ont géré le trafic de pointe sans autres problèmes. Nous avons également constaté que l'utilisation de calcul seul n'était pas un signe fiable de saturation du réseau. Nous avons élargi notre surveillance pour suivre les indicateurs de santé du réseau en plus de calculer l'utilisation. Enfin, nous avons constaté qu'il était difficile de trouver où les demandes internes défaillantes ont diminué. Nous avons ajouté l'enregistrement qui montre où les requêtes internes échouent et le temps écoulé. ** Impact client** Pendant le pic du trafic américain les 28 et 29 septembre, certains clients ont connu des retards dans le traitement et la livraison du courrier entrant et sortant par Prevent and Protect. Les messages adressés aux listes de distribution ont peut-être été traités plus lentement alors que les recherches ont été récupérées. Certains clients ont également eu des difficultés intermittentes à se connecter ou à utiliser la console américaine. L'impact s'est atténué chaque jour à mesure que le trafic américain diminuait, et le courrier en attente a été traité une fois la capacité récupérée. Après le changement du 30 septembre, nous n'avons pas vu de dégradation supplémentaire pendant le pic de trafic. ** Mesures préventives** Pour éviter ce type de problème à l'avenir, nous avons augmenté la capacité des services de réseau américains et élargi notre surveillance pour suivre les indicateurs de santé de réseau en plus de calculer l'utilisation. Nous avons également ajouté l'enregistrement pour améliorer la visibilité dans les demandes internes défaillantes.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 24 septembre 2026 à 17:53 UTCinvestigating

   Nous avons identifié un problème avec Protect qui a entraîné une dégradation des performances, et notre équipe d'ingénieurs examine une solution.

2. 24 septembre 2026 à 18:39 UTCmonitoring

   Nous avons identifié un problème avec Protect qui a entraîné une dégradation des performances. Un correctif a été mis en place et nous continuerons de suivre cette question.

3. 24 septembre 2026 à 19:57 UTCinvestigating

   Nous avons identifié un problème avec Protect & Prevent qui a entraîné une dégradation des performances, et notre équipe d'ingénierie est en train d'examiner une solution.

4. 24 septembre 2026 à 21:46 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

5. 25 septembre 2026 à 09:16 UTCresolved

   Cet incident a été résolu.

6. 6 octobre 2026 à 15:51 UTCpostmortem

   Résumé Du jeudi 24 septembre 2026, vers 17h07 \(UTC\), au vendredi 25 septembre 2026, vers 09h16 \(UTC\), certains clients ont connu une lenteur intermittente, des erreurs et un flux de courrier retardé pour les instances américaines de Protect and Prevent. Le 24 septembre, une augmentation exceptionnelle du trafic de courrier électronique a imposé une charge soutenue sur les services de réseau qui traitent le trafic pour notre traitement de courrier américain. Notre surveillance nous a alerté vers 17h07 \(UTC\). Certains clients ont vu un accès lent ou intermittent à Protection et des erreurs occasionnelles lors du chargement des pages ou des options avancées. L'accès était incohérent, de sorte que certains clients pouvaient utiliser Protect tandis que d'autres voyaient des erreurs. Le traitement du courrier par les instances américaines s'est ralenti, et certains messages ont été retardés ou n'ont pas paru dans la boîte de réception de la modération lorsque prévu. La performance semble s'améliorer, donc nous avons déplacé notre avis de page d'état à Surveillance à 18:39 \(UTC\). Plus tard, le problème a repris, et les clients ont signalé une lenteur continue à notre équipe de soutien. À 19:57 \(UTC\), nous avons déplacé l'avis de retour à Enquêter et l'avons élargi pour inclure également Prévenir que l'impact est devenu plus clair. Notre équipe a surveillé les systèmes touchés pendant que le volume élevé du courrier s'est réduit. Lorsque la charge sur les services réseau est revenue à la normale, le traitement du courrier s'est rétabli et les files d'attente du courrier sont retournées à la normale du jour au lendemain. Nous avons confirmé que Protect se chargeait normalement et que des messages d'essai étaient remis à nouveau, puis continué la surveillance. Protéger et prévenir le retour à une performance normale vers 09:16 \(UTC\) le 25 septembre 2026. Aucune perte de données n'a été causée par ce problème. ## **La cause de la mort** Ce problème a été causé par une augmentation exceptionnelle du trafic de courriels. L'augmentation du volume a imposé une charge soutenue aux services de réseau qui gèrent le trafic pour notre traitement du courrier américain. Ces services de réseau fonctionnent dans des limites de capacité fixe, et leur capacité n'a pas pu être augmentée pendant la crise. Parce qu'ils ne pouvaient pas suivre la poussée, ils ont ralenti, et certains traitements ont échoué par intermittence. Par conséquent, un grand volume de courrier a été en attente dans le traitement du courrier aux États-Unis, certaines pages et actions dans Protect erreurs retournées, et certains messages ont été retardés ou ne sont pas apparus dans la boîte de réception de modération lorsque prévu. Deux facteurs ont rendu la question plus difficile à gérer. Premièrement, parce que l'accès a échoué par intermittence, certaines vérifications ont réussi tandis que les clients ont continué à voir des erreurs, rendant la récupération plus difficile à confirmer. Deuxièmement, notre surveillance a montré une charge maximale sur les services réseau plus clairement que la charge actuelle, ce qui a rendu plus difficile de juger en temps réel si la charge était encore élevée. **Atténuation et réparation** Nous avons constaté que les services de réseau qui s'occupent du traitement du courrier aux États-Unis avaient atteint leurs limites de capacité fixes pendant l'augmentation du trafic et que leur capacité ne pouvait pas être augmentée pendant l'événement. Notre équipe a surveillé les systèmes touchés tandis que le volume de courrier élevé a diminué et la charge de service réseau est revenue à la normale. Le traitement du courrier a ensuite été récupéré et le courrier en attente a été traité. Comme le problème semblait s'améliorer avant de se répéter, nous avons confirmé le rétablissement de plusieurs façons avant de résoudre l'incident. Nous avons confirmé que Protect chargeait normalement, que les messages d'essai étaient envoyés par le traitement du courrier américain et que les demandes de soutien progressaient normalement. Nous avons également surveillé pendant la nuit et n'avons reçu aucun nouveau rapport de clients sur des cas américains. ** Impact client** Certains clients avaient un accès lent ou intermittent à Protection, et ont parfois vu des erreurs lors du chargement des pages ou des options avancées. Le traitement du courrier par des instances américaines a été retardé pour protéger et prévenir. Dans certains cas, les messages ont été retardés ou ne sont pas apparus dans la boîte de réception de la modération lorsque prévu. Les clients dont le courrier est chiffré, déchiffré ou modéré à mesure qu'il transite par notre traitement du courrier américain étaient plus susceptibles d'être touchés. La plupart Protégez les clients utilisant l'add-in n'a pas été affecté par les retards de traitement du courrier. Les consoles Protect and Prevent sont demeurées disponibles, bien que certaines actions de console aient été affectées par le traitement plus lent du courrier. ** Mesures préventives** Pour éviter ce type de problème à l'avenir, nous améliorons notre surveillance des augmentations inhabituelles du volume des courriels. Nous améliorons également notre surveillance pour montrer la charge actuelle sur nos services réseau, pas seulement les valeurs de pointe. De plus, nous évaluons les moyens d'accroître notre capacité de réseau de façon plus dynamique pendant les pics de trafic soudains et d'évaluer les améliorations à long terme de l'infrastructure de réseau qui s'occupe du traitement du courrier américain. Nous avons également depuis augmenté la capacité des services de réseau américains en réponse à[un incident ultérieur](https://status.knowbe4.com/incidents/9wc6rjm8g70v).

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 23 septembre 2026 à 09:52 UTCidentified

   Nous avons reçu des rapports d'utilisateurs recevant des messages d'erreur "Accès refusé" tout en essayant de se connecter. Nous avons identifié le problème et nous travaillons à la mise en œuvre d'une solution et nous mettrons à jour cette page lorsque nous aurons plus d'informations.

2. 23 septembre 2026 à 10:57 UTCmonitoring

   Le problème a été identifié et un correctif a été mis en place et mettra à jour cette page lorsque nous aurons plus d'informations.

3. 23 septembre 2026 à 14:58 UTCresolved

   Cet incident a été résolu avec succès et tous les systèmes sont pleinement opérationnels.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 23 septembre 2026 à 09:00 UTCinvestigating

   Nous avons reçu des rapports selon lesquels certains utilisateurs ne sont pas en mesure de soumettre avec succès des présentations de formulaires Web. Nous enquêtons sur cette question et mettrons à jour cette page lorsque nous aurons plus d'informations.

2. 23 septembre 2026 à 10:47 UTCidentified

   Le problème a été identifié et une correction a été mise en œuvre. Une mise à jour avec plus d'informations suivra en conséquence.

3. 23 septembre 2026 à 10:58 UTCmonitoring

   Le problème a été identifié et un correctif a été mis en place et mettra à jour cette page lorsque nous aurons plus d'informations.

4. 23 septembre 2026 à 14:58 UTCresolved

   Cet incident a été résolu avec succès et tous les systèmes sont pleinement opérationnels.

5. 20 octobre 2026 à 15:53 UTCpostmortem

   Le mercredi 23 septembre 2026, d'environ 08:15 à 11:18 \(UTC\), certains clients ont connu la lenteur et ont échoué à soumettre des formulaires au Royaume-Uni des formulaires Web sécurisés. Ce problème a été causé par les limites de performance de la base de données dans l'environnement de production britannique à la suite d'un changement récent. Un réglage de la base de données a également causé l'inefficacité de certaines requêtes. Par conséquent, les délais de réponse ont augmenté et certains formulaires ont échoué. Pour résoudre ce problème, notre équipe a temporairement interrompu une tâche de synchronisation de fond pour réduire la charge, ajusté les paramètres de la base de données pour améliorer l'efficacité de la requête et augmenté le débit de stockage. Les formulaires Web sécurisés sont retournés à des performances normales par 11:18 \(UTC\). Pour éviter ce type de problème à l'avenir, nous ajoutons une surveillance supplémentaire pour la bande passante de la base de données. Nous améliorons également l'efficacité de la tâche de synchronisation de fond. Aucune perte de données n'a été causée par ce problème.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 21 septembre 2026 à 09:32 UTCinvestigating

   Nous avons reçu des rapports selon lesquels les utilisateurs ne sont pas en mesure d'envoyer des courriels via Web Access (Secure Message Portal) dans la région du Royaume-Uni, avec erreur "503 Service Indisponible". Nous enquêtons sur cette question et mettrons à jour cette page lorsque nous aurons plus d'informations.

2. 21 septembre 2026 à 14:36 UTCmonitoring

   Nous avons mis en place un correctif et suivons les résultats.

3. 21 septembre 2026 à 14:38 UTCmonitoring

   Nous restons à l'affût de tout autre problème.

4. 22 septembre 2026 à 08:27 UTCresolved

   Cet incident a été résolu avec succès et tous les systèmes sont pleinement opérationnels.

5. 8 octobre 2026 à 13:45 UTCpostmortem

   Le lundi 21 septembre 2026, de 08h55 à mardi 22 septembre 2026, vers 14h30 \(UTC\), certains utilisateurs ont connu des erreurs et n'ont pas pu envoyer d'emails via Web Access \(Secure Message Portal\) dans la région du Royaume-Uni. Cet incident a été causé par une erreur de configuration lors d'une mise à jour de la base de données, ce qui a entraîné une interruption du service. Pour résoudre ce problème, nous avons retourné la configuration, et Web Access est revenu à la performance normale à 14:30 \(UTC\) le 22 septembre 2026. Pour éviter ce type de problème à l'avenir, nous examinons et mettons à jour notre configuration de base de données. Aucune perte de données n'a été causée par ce problème.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 18 septembre 2026 à 11:07 UTCinvestigating

   Nous avons reçu des rapports selon lesquels les utilisateurs ne peuvent pas se connecter aux instances DE et UK de KSAT. Nous enquêtons sur cette question et mettrons à jour cette page lorsque nous aurons plus d'informations.

2. 18 septembre 2026 à 16:48 UTCresolved

   Cet incident a été résolu.

3. 8 octobre 2026 à 14:07 UTCpostmortem

   Résumé Le 17 septembre 2026, un travail d'arrière-plan a archivé un grand groupe d'utilisateurs et s'est déroulé comme une seule transaction de base de données. Cette transaction a verrouillé un grand nombre de lignes d'utilisateurs, ce qui a provoqué des connexions de la région américaine à temps parce qu'elles écrivent sur la même table. Après avoir atteint une limite d'exécution de la plate-forme, le travail a été terminé et a automatiquement rejugé cinq fois par intervalles de 15 minutes, ce qui a entraîné une panne de 75 minutes. Pour résoudre le problème, nous avons déployé une correction qui découplait les connexions du verrou. Nous avons ensuite déployé un correctif de suivi pour une régression introduite par le changement de connexion, ainsi que pour le travail d'archivage. Ce qui s'est passé Un changement antérieur a déplacé l'action "archiver tous les utilisateurs" d'une requête web synchrone, time-out dans un travail de fond non lié. Lorsqu'un grand groupe d'utilisateurs a été archivé, cela a déclenché la nouvelle tâche de fond. Le travail a verrouillé toutes les lignes d'utilisateur touchées dans une seule transaction, exécutant des écrits par utilisateur et un appel de service externe synchrone avant de commettre. Les tentatives de connexion, qui écrivent à la même table, étaient en attente derrière le travail verrouillé et chronométrés pour les utilisateurs américains. Lorsque le travail a atteint une limite d'exécution de 15 minutes, il a été mis fin au milieu de la transaction, la transaction a été reportée et le travail a été remis à la file d'attente. Ce cycle s'est produit cinq fois, entraînant une panne de 75 minutes. Lorsque des défaillances ont été détectées en interne à 22:35 \(UTC\), un incident a été déclaré, et un ingénieur a été bipé pour répondre. L'atténuation pour découpler l'action d'écriture du flux de connexion a été déployée à environ 23:44 \(UTC\). L'atténuation elle-même a provoqué une régression: tout utilisateur dans une région qui avait déjà mal saisi un mot de passe ne pouvait plus se connecter parce que réinitialise pour des tentatives de connexion échouées a essayé d'écrire dans une base de données en lecture seule. Dès 09:17 \(UTC\) le 18 septembre 2026, la correction de cette régression a été déployée dans toutes les régions. Le problème original d'archive seulement aux États-Unis a réapparu deux fois plus entre 13:45 et 14:05 \(UTC\) avant qu'une correction permanente ne soit déployée à environ 15:00 \(UTC\). L'incident a été entièrement résolu par 19:12 \(UTC\) le 18 septembre 2026. ## **La cause de la mort** Un travail d'arrière-plan à simple transaction non consolidé pour l'archivage des utilisateurs de grands groupes tenait des verrous exclusifs sur de nombreuses lignes touchées, bloquant ainsi l'écriture de la propre ligne du processus de connexion. Un changement antérieur pour déplacer cette opération hors d'un délai de demande Web et dans un travail de fond a supprimé la seule limite restante sur sa durée. La limite d'exécution de 15 minutes de la plate-forme a ensuite déclenché des cycles de kill-and-Reliver automatiques, répétant la dispute de verrouillage cinq fois et entraînant une fenêtre de sortie de 75 minutes. ## **Conclusions et atténuations** Nous avons constaté que la transaction d'archive non liée verrouillait un grand nombre de lignes utilisateur touchées, bloquant d'autres écritures de table. Ceci a été atténué à court terme en découplant la dépendance d'écriture du processus de connexion de la table affectée, puis corrigé à long terme en corrigeant la tâche d'archive. Nous avons également constaté que l'entente non coordonnée entre les travailleurs amplifie l'argumentation du verrouillage. Cette situation a été atténuée à court terme par une réduction manuelle de la participation des travailleurs. La solution à long terme pour étaler et sérialiser ces emplois est prévue. Enfin, nous avons constaté que la régression login-fix causait des défaillances de connexion pour toutes les régions pour les utilisateurs ayant déjà échoué parce que les écrits ont été rejetés par une base de données en lecture seule. Cela a été corrigé par un changement de code ciblé qui a été déployé et vérifié dans toutes les régions. **Mesures préventives** Nous améliorons nos opérations d'archivage en grand groupe en les liant, en les traitant en petits lots engagés et en gardant les appels externes en dehors de la transaction de base de données. Nous ajoutons également un changement-vérification à un travailleur de fond spécifique pour sauter les écrits qui ne changent rien. Enfin, nous ajoutons des alertes directes pour l'âge des transactions dans la base de données et des délais de purge, en plus des contrôles indirects périodiques. ** Impact client et récupération** Les pannes de connexion ont duré environ 75 minutes dans la région américaine. Deux brèves répétitions seulement aux États-Unis se sont produites le lendemain matin et ont été nettoyées manuellement en quelques minutes. Certaines actions administratives, comme la gestion des utilisateurs, ont également été affectées. Les connexions des partenaires n'étaient pas affectées. La régression secondaire a duré environ 10 heures et a affecté toutes les régions pour les utilisateurs qui avaient précédemment échoué à une tentative de connexion. Dans l'après-midi du 18 septembre, le rétablissement complet a été confirmé dans toutes les régions, et la page d'état a été marquée comme résolue. Aucune perte de données n'a été causée par ce problème. **Conclusion** Une seule transaction de fond non liée, combinée à un mécanisme de réessayer automatique, a causé une panne de connexion dans la région des États-Unis. Le travail de déclenchement spécifique et son comportement de réessayer ont été corrigés, et la connexion ne dépend plus du chemin d'écriture revendiqué. Une régression du même incident et deux récidives mineures ont été résolues en quelques heures. Le travail de prévention, y compris la coordination des travailleurs et la surveillance des transactions dans la base de données, est suivi ci-dessus.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 17 septembre 2026 à 22:44 UTCinvestigating

   Nous avons reçu des rapports selon lesquels les utilisateurs ne peuvent pas se connecter à l'instance américaine de KSAT. Nous enquêtons sur cette question et mettrons à jour cette page lorsque nous aurons plus d'informations.

2. 18 septembre 2026 à 01:28 UTCmonitoring

   Nous avons mis en place un correctif et nous suivons les résultats pour nous assurer qu'aucun autre problème ne se pose.

3. 18 septembre 2026 à 14:02 UTCinvestigating

   Nous avons reçu de nouveaux rapports indiquant que les utilisateurs ne pouvaient pas se connecter à l'instance américaine de KSAT. Nous enquêtons sur cette question et mettrons à jour cette page lorsque nous aurons plus d'informations.

4. 18 septembre 2026 à 16:47 UTCresolved

   Cet incident a été résolu.

5. 5 octobre 2026 à 21:16 UTCpostmortem

   Résumé Le 17 septembre 2026, un travail d'arrière-plan a archivé un grand groupe d'utilisateurs et s'est déroulé comme une seule transaction de base de données. Cette transaction a verrouillé un grand nombre de lignes d'utilisateurs, ce qui a provoqué des connexions de la région américaine à temps parce qu'elles écrivent sur la même table. Après avoir atteint une limite d'exécution de la plate-forme, le travail a été terminé et a automatiquement rejugé cinq fois par intervalles de 15 minutes, ce qui a entraîné une panne de 75 minutes. Pour résoudre le problème, nous avons déployé une correction qui découplait les connexions du verrou. Nous avons ensuite déployé un correctif de suivi pour une régression introduite par le changement de connexion, ainsi que pour le travail d'archivage. Ce qui s'est passé Un changement antérieur a déplacé l'action "archiver tous les utilisateurs" d'une requête web synchrone, time-out dans un travail de fond non lié. Lorsqu'un grand groupe d'utilisateurs a été archivé, cela a déclenché la nouvelle tâche de fond. Le travail a verrouillé toutes les lignes d'utilisateur touchées dans une seule transaction, exécutant des écrits par utilisateur et un appel de service externe synchrone avant de commettre. Les tentatives de connexion, qui écrivent à la même table, étaient en attente derrière le travail verrouillé et chronométrés pour les utilisateurs américains. Lorsque le travail a atteint une limite d'exécution de 15 minutes, il a été mis fin au milieu de la transaction, la transaction a été reportée et le travail a été remis à la file d'attente. Ce cycle s'est produit cinq fois, entraînant une panne de 75 minutes. Lorsque des défaillances ont été détectées en interne à 22:35 \(UTC\), un incident a été déclaré, et un ingénieur a été bipé pour répondre. L'atténuation pour découpler l'action d'écriture du flux de connexion a été déployée à environ 23:44 \(UTC\). L'atténuation elle-même a provoqué une régression: tout utilisateur dans une région qui avait déjà mal saisi un mot de passe ne pouvait plus se connecter parce que réinitialise pour des tentatives de connexion échouées a essayé d'écrire dans une base de données en lecture seule. Dès 09:17 \(UTC\) le 18 septembre 2026, la correction de cette régression a été déployée dans toutes les régions. Le problème original d'archive seulement aux États-Unis a réapparu deux fois plus entre 13:45 et 14:05 \(UTC\) avant qu'une correction permanente ne soit déployée à environ 15:00 \(UTC\). L'incident a été entièrement résolu par 19:12 \(UTC\) le 18 septembre 2026. ## **La cause de la mort** Un travail d'arrière-plan à simple transaction non consolidé pour l'archivage des utilisateurs de grands groupes tenait des verrous exclusifs sur de nombreuses lignes touchées, bloquant ainsi l'écriture de la propre ligne du processus de connexion. Un changement antérieur pour déplacer cette opération hors d'un délai de demande Web et dans un travail de fond a supprimé la seule limite restante sur sa durée. La limite d'exécution de 15 minutes de la plate-forme a ensuite déclenché des cycles de kill-and-Reliver automatiques, répétant la dispute de verrouillage cinq fois et entraînant une fenêtre de sortie de 75 minutes. ## **Conclusions et atténuations** Nous avons constaté que la transaction d'archive non liée verrouillait un grand nombre de lignes utilisateur touchées, bloquant d'autres écritures de table. Ceci a été atténué à court terme en découplant la dépendance d'écriture du processus de connexion de la table affectée, puis corrigé à long terme en corrigeant la tâche d'archive. Nous avons également constaté que l'entente non coordonnée entre les travailleurs amplifie l'argumentation du verrouillage. Cette situation a été atténuée à court terme par une réduction manuelle de la participation des travailleurs. La solution à long terme pour étaler et sérialiser ces emplois est prévue. Enfin, nous avons constaté que la régression login-fix causait des défaillances de connexion pour toutes les régions pour les utilisateurs ayant déjà échoué parce que les écrits ont été rejetés par une base de données en lecture seule. Cela a été corrigé par un changement de code ciblé qui a été déployé et vérifié dans toutes les régions. **Mesures préventives** Nous améliorons nos opérations d'archivage en grand groupe en les liant, en les traitant en petits lots engagés et en gardant les appels externes en dehors de la transaction de base de données. Nous ajoutons également un changement-vérification à un travailleur de fond spécifique pour sauter les écrits qui ne changent rien. Enfin, nous ajoutons des alertes directes pour l'âge des transactions dans la base de données et des délais de purge, en plus des contrôles indirects périodiques. ** Impact client et récupération** Les pannes de connexion ont duré environ 75 minutes dans la région américaine. Deux brèves répétitions seulement aux États-Unis se sont produites le lendemain matin et ont été nettoyées manuellement en quelques minutes. Certaines actions administratives, comme la gestion des utilisateurs, ont également été affectées. Les connexions des partenaires n'étaient pas affectées. La régression secondaire a duré environ 10 heures et a affecté toutes les régions pour les utilisateurs qui avaient précédemment échoué à une tentative de connexion. Dans l'après-midi du 18 septembre, le rétablissement complet a été confirmé dans toutes les régions, et la page d'état a été marquée comme résolue. Aucune perte de données n'a été causée par ce problème. **Conclusion** Une seule transaction de fond non liée, combinée à un mécanisme de réessayer automatique, a causé une panne de connexion dans la région des États-Unis. Le travail de déclenchement spécifique et son comportement de réessayer ont été corrigés, et la connexion ne dépend plus du chemin d'écriture revendiqué. Une régression du même incident et deux récidives mineures ont été résolues en quelques heures. Le travail de prévention, y compris la coordination des travailleurs et la surveillance des transactions dans la base de données, est suivi ci-dessus.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 16 septembre 2026 à 17:47 UTCidentified

   Nous avons identifié un problème causant des problèmes de connexion et d'accès pour les comptes de notre instance britannique.

2. 16 septembre 2026 à 18:16 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

3. 16 septembre 2026 à 20:58 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 11 septembre 2026 à 12:43 UTCresolved

   Le 8 septembre, nous avons fait savoir que les courriels HTML entrants rendus partiellement ou en blanc dans Classic Outlook en raison d'une mise à niveau de routine de la bibliothèque HTML dans le moteur d'enlèvement de code nuisible de Defend interagissent avec le moteur de rendu Word hérité de Classic Outlook. Les nouvelles perspectives et les nouvelles perspectives sur le Web n'étaient pas affectées. Il s'agissait strictement d'un problème d'affichage : aucun courriel n'a été retardé, perdu ou compromis, et la détection des menaces est restée pleinement active. L'ingénierie a retourné la mise à jour pour restaurer le rendu normal. Si vous avez temporairement désactivé la suppression de code nuisible pendant cette fenêtre, veuillez la réactiver pour assurer une protection complète.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 4 septembre 2026 à 10:53 UTCinvestigating

   Nous avons reçu des rapports d'un problème avec la livraison de la vérification par courriel MFA pour Workspace. Nous enquêtons sur cette question et mettrons à jour cette page lorsque nous aurons plus d'informations.

2. 4 septembre 2026 à 14:24 UTCmonitoring

   Nous avons reçu des rapports selon lesquels la question de la livraison de la vérification par courriel MFA for Workspace a été atténuée par Microsoft, et nous surveillons les résultats.

3. 7 septembre 2026 à 08:25 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 26 août 2026 à 16:19 UTCinvestigating

   Nous avons identifié un problème dans lequel les utilisateurs pourraient subir des retards dans le traitement des messages, et notre équipe d'ingénierie examine une solution.

2. 26 août 2026 à 16:46 UTCmonitoring

   Notre équipe d'ingénieurs a mis en place une solution pour le problème qui cause des retards de traitement des messages dans PhishER, et nous surveillons les résultats.

3. 26 août 2026 à 19:51 UTCresolved

   Notre équipe d'ingénierie a mis en place une solution pour le problème qui cause des retards de traitement de messages dans PhishER.

4. 16 octobre 2026 à 20:36 UTCpostmortem

   Résumé Au cours d'un déploiement de routine le 26 août 2026, un cadre de gestion de l'infrastructure a éliminé de façon inattendue les files d'attente primaires de traitement de messages et les files d'attente secondaires de messages qui ne pouvaient pas être traités. Cela a entraîné une interruption temporaire de la livraison des courriels aux boîtes de réception des clients PhishER. Aucune perte de données n'a été causée par ce problème. ## **La cause de la mort** Le 24 août 2026, un changement de configuration interne a laissé les enregistrements de configuration en direct hors de synchronisation avec notre code. Une mise à jour ultérieure du code n'a pas retourné ces enregistrements. Lorsqu'un déploiement de production de routine a eu lieu le 26 août 2026, le code de configuration actif ne contenait pas les enregistrements de ressources déplacés. Par conséquent, le déploiement a traité les files d'attente actives comme des ressources non gérées et les a retirées. **Atténuation et réparation** La surveillance automatisée nous a avertis d'une baisse du traitement des messages, et une équipe d'intervention en cas d'incident a été constituée. Nous avons constaté que les files d'attente avaient été supprimées. Cela a été atténué à court terme par la reprise des emplois de production touchés pour recréer les files d'attente manquantes. Nous avons ensuite vérifié que le traitement des courriels en temps réel avait repris. Enfin, nous avons rejoué des charges utiles d'email détenues dans le stockage en nuage pendant la panne dans les boîtes de réception des clients. **Échéancier** Toutes les heures sont en UTC. * **24 août 2026, 18:41 :** Un changement de configuration interne a écrit des enregistrements de ressources mis à jour dans la configuration de production en direct. * **26 août 2026, 15 h 15 :** Un déploiement de production a supprimé les files d'attente entrantes et les files d'attente qui contiennent des messages qui ne pouvaient pas être traités dans la production, arrêtant la livraison des courriels dans les boîtes de réception des clients. * **26 août 2026, 15 h 59 :** Notre surveillance automatisée a alerté l'équipe d'ingénierie à zéro message en cours de traitement, et une équipe d'intervention en cas d'incident a été bipé. * **26 août 2026, 16 h 01** Nous avons confirmé que les files d'attente avaient été supprimées et vérifié que les charges utiles des courriels entrants étaient encore stockées en toute sécurité. * **26 août 2026, 16 h 15 :** Nous avons identifié l'inadéquation de configuration comme étant la cause principale. * **26 août 2026, 16 h 25** Notre équipe est revenue sur les emplois de production touchés, et les files d'attente ont été recréées. * **26 août 2026, 18:44 :** Notre rejouage automatisé a fini de livrer tous les courriels en retard aux boîtes de réception des clients. ** Mesures préventives** Afin d'éviter ce type de problème à l'avenir, nous avons supprimé une étape de configuration en direct des vérifications avant fusion et séparé la planification de déploiement des changements de production. Nous avons également ajouté des vérifications automatisées pour confirmer la santé de la file d'attente après la libération. ** Impact client** De 15h15 à 16h25 \(UTC\) le 26 août 2026, les courriels reçus soumis à PhishER n'ont pas été traités dans les boîtes de réception des clients. Les charges utiles des courriels entrants ont été stockées en toute sécurité dans le stockage en nuage tout au long de la perturbation. Après la restauration des files d'attente, un replay automatisé a été livré aux boîtes de réception des clients. Tous les messages en retard ont été envoyés par 18:44 \(UTC\). Aucune donnée de messagerie client n'a été perdue à la suite de ce problème.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 21 août 2026 à 08:52 UTCinvestigating

   Nous avons reçu des rapports selon lesquels le bouton d'alerte Phish de Gmail montre l'erreur [rapportPhishAttend()] Une erreur interne s'est produite. S'il vous plaît essayez à nouveau." Nous enquêtons sur cette question et mettrons à jour cette page lorsque nous aurons plus d'informations.

2. 21 août 2026 à 12:03 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 21 août 2026 à 13:08 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

4. 21 août 2026 à 14:57 UTCresolved

   Cet incident a été résolu.

5. 26 août 2026 à 15:55 UTCpostmortem

   Le vendredi 21 août 2026, de 05:20 à 12:55 \(UTC\), certains clients ont connu des défaillances intermittentes lors de l'utilisation de l'add-in Gmail Phish Alert Button pour signaler des courriels suspects, en recevant le message "Une erreur interne s'est produite" au lieu d'une confirmation de rapport réussie. Le problème touchait les clients de toutes les régions, les volumes d'erreurs les plus élevés étant concentrés dans les régions de services UE-Ouest et États-Unis-Est. Ce problème a été causé par une perturbation d'un service de cache sur la plate-forme Google Apps Script, sur laquelle l'add-in s'appuie pour stocker la configuration de session par utilisateur. Le service a commencé à renvoyer des résultats vides par intermittence en lisant, tout en acceptant de nouveaux écrits, ce qui a causé l'échec des déclarations. KnowBe4 a engagé Google directement et a déposé un rapport de bogue officiel entre environ 12:19 et 12:39 \(UTC\). Le volume d'erreurs a fortement diminué peu de temps après que l'état du côté du fournisseur a été éliminé, et le bouton d'alerte Phish de Gmail est revenu à une performance normale d'environ 12:55 \(UTC\). Pour éviter ce type de problème à l'avenir, nous continuons à travailler avec Google pour suivre la résolution du défaut de cache sous-jacent. Aucune perte de données n'a été causée par ce problème.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 18 août 2026 à 14:29 UTCinvestigating

   Nous enquêtons sur un problème qui provoque le retour d'un rapport de non-livraison (NDR) lorsqu'un message est signalé via le bouton d'alerte Phish et que « Nous envoyer une copie » est activé dans les paramètres du compte

2. 18 août 2026 à 15:26 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

3. 18 août 2026 à 20:14 UTCresolved

   Cet incident a été résolu.

4. 30 septembre 2026 à 20:06 UTCpostmortem

   Le mardi 18 août 2026, de 14h10 à 14h55 \(UTC\), les clients utilisant le bouton d'alerte Phish \(PAB\) avec la fonction **Envoyez-nous une copie** activée ont reçu des rapports de non-livraison pour la boîte aux lettres **Envoyez-nous une copie**. Ce problème a été causé par un changement de configuration de l'infrastructure de routage des courriels partagés. Ce changement a rebaptisé un composant de messagerie utilisé par nos environnements de mise en scène et de production. Comme une règle de production dépendait de ce composant partagé, le nom a causé des défaillances de livraison à la boîte aux lettres **Envoyez-nous une copie** et déclenché des rapports de non-livraison. Pour résoudre ce problème, notre équipe a mis à jour la configuration affectée pour référencer le bon composant, et la fonction **Envoyez-nous une copie** est retournée à la performance normale par 14:55 \(UTC\). Pour éviter ce genre de problème à l'avenir, nous séparons les configurations de routage des courriels pour nos environnements de mise en scène et de production. Nous réconcilions également les configurations héritées en nos normes actuelles de gestion de l'infrastructure. Aucune perte de données n'a été causée par ce problème.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 5 août 2026 à 19:29 UTCinvestigating

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

2. 5 août 2026 à 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 août 2026 à 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 août 2026 à 19:19 UTCidentified

   Nous avons identifié un problème empêchant les paramètres de compte de charger dans la console SAT.

2. 4 août 2026 à 19:51 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

3. 5 août 2026 à 12:17 UTCresolved

   Cet incident a été résolu.

4. 28 septembre 2026 à 14:35 UTCpostmortem

   Le mardi 4 août 2026, de 18:22 à 19:43 \(UTC\), certains clients ont éprouvé des problèmes de chargement de la page ** Paramètres de compte** dans la console KnowBe4 à travers la CA, DE, UE, Royaume-Uni et États-Unis. Ce problème a été causé par une série de changements d'applications qui ont accru la complexité d'une requête GraphQL utilisée par l'expérience Paramètres de compte. Chaque changement est resté en dessous du seuil de complexité configuré de la plate-forme lorsqu'il a été évalué individuellement, mais combiné, la demande a dépassé ce seuil et a empêché la page de charger. L'ingénierie a identifié le seuil de complexité comme facteur contributif et a déployé un changement correctif à partir d'environ 19:14 \(UTC\). Une fois la correction vérifiée dans les régions touchées, la console KnowBe4 est revenue à une performance normale d'environ 19:43 \(UTC\). Pour prévenir cette question à l'avenir, nous avons augmenté le seuil de complexité. Aucune perte de données n'a été causée par ce problème.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 28 juillet 2026 à 20:00 UTCinvestigating

   Nous enquêtons sur un problème lié aux courriels mis en quarantaine par PhishRIP de façon inattendue

2. 28 juillet 2026 à 20:35 UTCmonitoring

   Une correction a été implémentée pour ce problème et les requêtes PhishRIP ne sont plus en attente de messages. Nous enquêtons encore sur des questions qui pourraient avoir été touchées

3. 29 juillet 2026 à 18:58 UTCresolved

   Cet incident a été résolu.

4. 30 juillet 2026 à 16:38 UTCpostmortem

   Résumé Le 28 juillet 2026, une mise à jour du service PhishRIP a amené certaines requêtes de recherche PhishRIP à correspondre plus largement qu'elles ne l'auraient dû. Des courriels bénins qui ne répondaient pas aux critères d'expéditeur configurés ont été mis en quarantaine sur certains comptes clients. Des tickets automatisés de surveillance et d'assistance à la clientèle ont rapidement fait surface. Le génie a repris le changement dans les environ 25 minutes suivant la déclaration de l'incident et a arrêté la quarantaine non intentionnelle. Ingénierie puis manuellement restauré les courriels mal mis en quarantaine aux boîtes de réception des clients. La cause de la mort Le 28 juillet 2026, nous avons déployé une mise à jour de maintenance au service de requête derrière PhishRIP. Cette mise à jour a été conçue pour améliorer le traitement des adresses d'expéditeurs invalides en permettant au système de revenir à la recherche seulement la partie du domaine de l'adresse. Cependant, la logique de validation existante utilisait une expression régulière qui exigeait un symbole "@" dans le champ de l'expéditeur. Lorsqu'une requête utilise un domaine nu, tel que [example.com](http://example.com) sans nom d'utilisateur ou symbole "@", le regex indique que le domaine est invalide. Ce conflit entre la validation existante et la mise à jour de la recherche de domaine a conduit le système à supprimer complètement les critères d'expéditeur. La requête s'est déroulée contre les boîtes de réception en utilisant seulement les paramètres restants, les courriels de correspondance et de quarantaine bien en dehors de l'expéditeur prévu. **Échéancier** Toutes les heures sont en UTC. **Heure** - Oui. Notre surveillance automatisée a détecté des modèles d'exécution de requêtes anormales et a alerté nos ingénieurs, qui ont immédiatement commencé à enquêter. Autres Le problème a été aggravé par un incident de production de haute gravité, et une équipe d'intervention a été constituée. Autres Notre équipe de support a intensifié les premiers tickets clients qui ont signalé des quarantaines inattendues, corroborant l'alerte de surveillance. La cause fondamentale a été attribuée à un déploiement d'API de requêtes récentes, et l'ingénierie a commencé à revenir au changement. Les communications d'incident ont été postées sur notre page de statut, avec PhishRIP marqué comme Dégradé. 20:16 Le déploiement a été entièrement repris. Les vérifications de production ont confirmé que les questions de sujet et de domaine correspondaient de nouveau uniquement à leurs objectifs et qu'aucun autre message n'était mis en quarantaine par erreur. Notre page de statut a été mise à jour en conséquence. Autres L'ingénierie a commencé à restaurer les courriels mal mis en quarantaine. 03:49 \(prochaine journée\)= Les restaurations ont été effectuées pour tous les ensembles de requêtes client enregistrés par notre équipe de support. **Atténuation et assainissement** **Code retourné.** Nous avons pesé l'arrêt des opérations PhishRIP actives au milieu de la course contre le retour du code. Réduire les tâches de base aurait perturbé les flux de travail légitimes de sécurité pour chaque locataire, de sorte que le retour était la meilleure option. Le retour au code a été déployé et vérifié dans la production dans les 40 minutes suivant l'escalade. **Restauration par courriel.** Pour éviter de relâcher des e-mails vraiment malveillants dans les environnements clients, nous les avons restaurés manuellement plutôt que en vrac. L'ingénierie a utilisé des outils d'administration interne pour restaurer les e-mails en lots, et a travaillé avec Support pour vérifier chaque identifiant de compte, l'identifiant de requête et recevoir l'approbation du client d'abord. Tous les comptes déclarés ont été rétablis du jour au lendemain. ** Mesures préventives** * **Couverture de la régression** : Nous ajoutons des tests d'unité et d'intégration pour les requêtes d'expéditeurs de domaine, non standard et à chaîne nue pour attraper ces cas d'entrée avant le déploiement. * **Gardiers de secours**: Nous ajoutons une vérification dans le moteur de requête qui bloque les requêtes en cours d'exécution si leurs paramètres de filtrage de cœur sont supprimés pendant l'évaluation. **Conclusion** Une seule règle de validation en a résulté : un regex qui a supposé que chaque champ expéditeur contenait un `@`. Lorsque les requêtes utilisaient un domaine nu, cette hypothèse laissait tomber le filtre de l'expéditeur et les requêtes correspondaient beaucoup plus au courrier que prévu. La correction a été simple une fois que nous l'avons trouvé, et le retour a arrêté les dommages dans les 25 minutes suivant la déclaration de l'incident. Restaurer le courrier mis en quarantaine a été un processus plus difficile : nous ne pouvions pas restaurer les courriels en vrac sans risquer que des courriels véritablement malveillants retournent dans des boîtes de réception. Notre équipe a choisi de procéder avec soin, compte de travail par compte avec Support toute la nuit. Deux mesures préventives auraient été prises plus tôt : un test couvrant uniquement les requêtes d'expéditeur de domaine, et un garde-corps qui refuse d'exécuter une requête lorsque son filtre d'expéditeur a été dépouillé. Les deux sont maintenant prévus. Le problème immédiat est résolu et tous les comptes rendus ont été rétablis. ## **Glossaire** * **PhishRIP:** Une fonctionnalité PhishER qui permet aux administrateurs de rechercher et de mettre en quarantaine des courriels d'hameçonnage correspondants dans chaque boîte de réception utilisateur dans une organisation. * **Regex \(expression régulière):** Un modèle utilisé dans le logiciel pour rechercher du texte et valider l'entrée, comme vérifier qu'une adresse e-mail est formatée correctement. * ** Code retourné :** Sauvegarder une mise à jour logicielle pour revenir à la version stable précédente.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 17 juillet 2026 à 13:18 UTCinvestigating

   Nous enquêtons sur les utilisateurs ne pouvant pas acheter les licences Protect sur store.knowbe4.com. Nous mettrons à jour cette page lorsque nous aurons plus d'informations.

2. 17 juillet 2026 à 18:55 UTCmonitoring

   Nous avons mis en place un correctif et nous suivons les résultats pour nous assurer qu'aucun autre problème ne se pose.

3. 20 juillet 2026 à 18:24 UTCinvestigating

   Nous avons reçu des rapports selon lesquels les clients ne sont pas en mesure d'acheter des licences Protect sur store.knowbe4.com. Nous enquêtons sur cette question et mettrons à jour cette page lorsque nous aurons plus d'informations.

4. 29 juillet 2026 à 18:40 UTCmonitoring

   Nous avons implémenté un correctif pour la boutique en ligne et nous suivons les résultats pour nous assurer qu'il n'y a pas d'autres problèmes.

5. 17 août 2026 à 21:02 UTCmonitoring

   Nous continuons de surveiller le correctif mis en place pour la boutique en ligne, afin de nous assurer qu'aucun autre problème ne se pose.

6. 11 septembre 2026 à 15:04 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.