Historial de interrupciones de Knowbe4

1. 20 de octubre de 2026 a las 11:37 UTCidentified

   Hemos identificado la causa del registro de dominios siendo incapaz de dar consejos y estamos trabajando en implementar una solución. Seguiremos publicando en nuestra página de estado con cualquier nueva información o actualizaciones.

2. 21 de octubre de 2026 a las 15:33 UTCmonitoring

   Se ha aplicado una solución y estamos monitoreando los resultados.

3. 23 de octubre de 2026 a las 14:55 UTCresolved

   Este incidente ha sido resuelto.

Traducido automáticamente desde la actualización oficial del incidente.

1. 13 de octubre de 2026 a las 15:03 UTCinvestigating

   Actualmente estamos investigando un problema que afecta el login de consola. Proporcionaremos más actualizaciones aquí cuando esté disponible.

2. 13 de octubre de 2026 a las 15:07 UTCmonitoring

   Se ha aplicado una solución y estamos monitoreando los resultados.

3. 13 de octubre de 2026 a las 16:15 UTCresolved

   Este incidente ha sido resuelto.

4. 14 de octubre de 2026 a las 14:29 UTCpostmortem

   ## **Summary** El 13 de octubre de 2026, de aproximadamente 14:19 a 15:05 \(UTC\), los clientes en todas las regiones no pudieron iniciar sesión en la consola KnowBe4 Security Awareness Training \(SAT\), la Experiencia SaberBe4 Learner y la consola PhishER a través de KnowBe4 SAT. Los logins de SAML y contraseña devolvieron errores, y la consola KnowBe4 SAT no apareció en la plataforma KnowBe4. Algunos procesos de fondo, incluyendo sincronización de usuarios y correos electrónicos de capacitación, también fallaron durante este tiempo. El incidente fue causado por una liberación de producción que contrajo otro cambio en nuestro código. Revertimos la versión, y los logins recuperados a través de regiones entre 14:59 y 15:05 \(UTC\). No se produjeron pérdidas de datos como resultado de esta cuestión. ## ## Root Cause ## Una implementación de código removió un valor de configuración de inicio para acelerar el tiempo de inicio de aplicaciones. Un componente separado, añadido a nuestro código después de la prueba del cambio original, no representó ese valor cambiado. Como resultado, cada intento de guardar un registro de usuario causó un error, incluyendo la actualización que registra intentos de registro. ## ** Impacto del cliente** Los clientes de todas las regiones no pudieron acceder a la consola KSAT a través de SAML o contraseña. También no pudieron acceder a la Experiencia de los Aprendedores, y no pudieron acceder a la consola de PhishER a través de la consola de KnowBe4 SAT. Nueva creación de usuarios, sincronización de usuarios y correos electrónicos de entrenamiento fallaron durante este tiempo, pero fueron automáticamente retrigados después de que el despliegue fue revertido. ## **Mitigation and Remediation** Encontramos que el despliegue removió un valor de configuración que otro componente aún requería. Esto se mitigó revertiendo la liberación, y confirmamos la recuperación en todas las regiones mediante cheques directos y pruebas automatizadas. También revertimos el cambio original en nuestro código fuente y preparamos una versión corregida que incluye una solución de compatibilidad, por lo que la mejora original puede ser reintroducida de forma segura. ## ** Medidas preventivas** Añadimos verificaciones y pruebas de código adicionales para implementaciones.

Traducido automáticamente desde la actualización oficial del incidente.

1. 13 de octubre de 2026 a las 8:47 UTCinvestigating

   Hemos recibido informes de que el complemento KnowBe4 Email Security muestra el error "La seguridad de correo electrónico KnowBe4 impide que este mensaje sea enviado" al enviar correos electrónicos. Estamos investigando este problema y actualizaremos esta página cuando tengamos más información.

2. 13 de octubre de 2026 a las 11:07 UTCmonitoring

   Hemos implementado una solución para el envío de errores Web Add-in y estamos monitoreando los resultados para asegurarnos de que no se produzcan más problemas.

3. 13 de octubre de 2026 a las 13:41 UTCresolved

   Este incidente ha sido resuelto.

4. 20 de octubre de 2026 a las 12:48 UTCpostmortem

   Desde el lunes 12 de octubre de 2026, aproximadamente a las 14:25 \(UTC\), hasta el martes, 13 de octubre de 2026, alrededor de 15:07 \(UTC\), algunos clientes en casos de la UE de Prevención y Protección tuvieron dificultad para enviar correos electrónicos de Microsoft Outlook. Los mensajes afectados no fueron enviados, y el complemento KnowBe4 Email Security mostró el siguiente error: "El add-in KnowBe4 Email Security está impidiendo que este mensaje sea enviado". Este problema fue causado por un error en cómo se preparó una versión add-in para su lanzamiento, que produjo dos copias ligeramente diferentes de la misma versión. Cuando Outlook carga el add-in, descarga un conjunto de archivos que deben coincidir. En los casos de la UE, Outlook a veces recibió archivos de ambas copias, por lo que el add-in no pudo terminar la carga, y el mensaje no fue enviado. Algunos dispositivos también guardaron la descarga fallida, por lo que el error continuó en esos dispositivos hasta que se aplicó una solución. Para resolver este problema, nuestro equipo corrigió los archivos adicionales de la UE para que cada cliente reciba un conjunto de coincidencias. A continuación publicamos una versión actualizada del add-in a todas las regiones, que despejó cualquier error guardado. El complemento KnowBe4 Email Security devolvió al rendimiento normal alrededor de 15:07 \(UTC\) el 13 de octubre de 2026. Para evitar este tipo de problema en el futuro, estamos cambiando cómo se preparan y liberan versiones adicionales, de modo que cada versión siempre produce el mismo conjunto de archivos y cada cliente recibe la misma versión al mismo tiempo. También estamos cambiando el add-in para que las descargas fallidas de archivos add-in no se guarden en dispositivos. Por último, estamos agregando alertas para errores de carga adicionales para detectarlos antes. No se produjeron pérdidas de datos como resultado de esta cuestión.

Traducido automáticamente desde la actualización oficial del incidente.

1. 28 de septiembre de 2026 a las 21:10 UTCinvestigating

   Actualmente estamos investigando un problema sobre el rendimiento degradado para prevenir y proteger en nuestros servidores estadounidenses.

2. 29 de septiembre de 2026 a las 13:44 UTCmonitoring

   Hemos identificado un problema con las instancias estadounidenses de prevención y protección que han dado lugar a resultados degradados. Se ha aplicado una solución y seguiremos vigilando esta cuestión.

3. 2 de octubre de 2026 a las 10:32 UTCresolved

   Este incidente ha sido resuelto.

4. 6 de octubre de 2026 a las 15:51 UTCpostmortem

   ## **Summary** Desde el lunes, 28 de septiembre de 2026, aproximadamente a las 16:00 \(UTC\), hasta el miércoles 30 de septiembre de 2026, alrededor de las 12:35 \(UTC\), algunos clientes experimentaron retraso en el flujo de correo y problemas intermitentes accediendo a casos estadounidenses de prevención y protección. El 28 de septiembre, nuestro monitoreo mostró tráfico de red pesado, con picos en la parte superior de cada hora. Algunos clientes comenzaron a experimentar problemas intermitentes accediendo a casos estadounidenses de las consolas Prevent y Protect. Las búsquedas internas que el procesamiento de correos depende de la fecha inicial, y los mensajes fueron consultados como resultado. Los clientes comunicaron el problema a nuestro equipo de soporte, y publicamos un aviso de página de estado. El rendimiento se recuperó más tarde ese día mientras el tráfico de EE.UU. disminuyó. El 29 de septiembre, nuestros ingenieros revisaron los datos del día anterior a través de las pasarelas de correo, los servicios internos que dependen y la capa de red. Los retrasos en el flujo de correo y las cuestiones de acceso a la consola regresaron brevemente, luego se alivió cuando el tráfico de la red disminuyó, siguiendo el mismo patrón que el 28 de septiembre. El 30 de septiembre, de aproximadamente 12:19 a 12:35 \(UTC\), nuestro equipo aumentó la capacidad de los servicios de red estadounidenses mientras el servicio continuó. Su carga cayó inmediatamente después del cambio, e Prevent y Protect regresaron al rendimiento normal alrededor de 12:35 \(UTC\) el 30 de septiembre de 2026. Supervisamos el tráfico máximo del 30 de septiembre y el 1 de octubre y no vimos recidivas. No se produjeron pérdidas de datos como resultado de esta cuestión. ## ## Root Cause ## Este problema fue causado por un límite de capacidad en los servicios de red que manejan el tráfico para nuestros servicios de procesamiento de correos estadounidenses. Durante el tráfico máximo, y especialmente durante los picos por hora, los servicios de red no pudieron procesar las conexiones lo suficientemente rápido. Este retraso añadido al tráfico que pasa a través de ellos y causó algunas conexiones a caer. Ese tráfico incluyó solicitudes internas nuestras pasarelas de correo envían a buscar miembros de la lista de distribución, por lo que las políticas correctas se aplican. Estas solicitudes están sujetas a un límite de tiempo estricto para que una búsqueda lenta no pueda mantener el procesamiento de correo indefinidamente. Cuando los servicios de red retrasaron las solicitudes más allá de ese límite, fracasaron. Como resultado, el procesamiento de correo se ralentizó, y los mensajes fueron consultados. Dos factores hicieron que la cuestión fuera peor y más difícil de identificar. En primer lugar, algunas solicitudes internas también utilizaron estos servicios de red y se vieron afectadas por el límite de capacidad. En segundo lugar, los servicios de red comenzaron a degradarse antes de que su uso compute alcanzara niveles que normalmente indicarían un problema. El monitoreo estándar de computación no alcanzó la saturación de la red, por lo que la causa tomó más tiempo identificar. Encontrar una manera segura de aumentar la capacidad sin interrumpir el servicio también tomó tiempo, por lo que la solución fue aplicada el 30 de septiembre. ## **Mitigation and Remediation** Encontramos que los servicios de red estadounidenses no tenían suficiente capacidad para manejar el tráfico máximo. Hemos mitigado esto aumentando su capacidad de una manera que mantuvo el servicio funcionando a lo largo del cambio. Después del aumento de la capacidad, los servicios de red se ocuparon del tráfico máximo sin más problemas. También encontramos que el uso de computación por sí solo no era un signo confiable de saturación de red. Hemos ampliado nuestro monitoreo para rastrear los indicadores de salud de la red además de calcular el uso. Finalmente, encontramos que era difícil encontrar dónde se desmoronaron las solicitudes internas. Hemos añadido registro que muestra dónde fallan las solicitudes internas y el tiempo fuera. ## ** Impacto del cliente** Durante el máximo tráfico de Estados Unidos los días 28 y 29 de septiembre, algunos clientes experimentaron retrasos en el procesamiento y entrega de correos entrantes y salientes a través de Prevent and Protect. Los mensajes dirigidos a las listas de distribución pueden haberse procesado con más lentitud mientras se retumbaban las búsquedas. Algunos clientes también tuvieron dificultad intermitente para iniciar sesión en o utilizar la consola estadounidense. El impacto se alivió cada día a medida que el tráfico estadounidense disminuyó, y el correo solicitado fue procesado una vez recuperada la capacidad. Después del cambio del 30 de septiembre, no vimos más degradación durante el tráfico máximo. ## ** Medidas preventivas** Para prevenir este tipo de problema en el futuro, hemos incrementado la capacidad de los servicios de red de los Estados Unidos y ampliado nuestro monitoreo para rastrear los indicadores de salud de la red, además de utilizar el cálculo. También hemos añadido logging para mejorar la visibilidad en solicitudes internas fallidas.

Traducido automáticamente desde la actualización oficial del incidente.

1. 24 de septiembre de 2026 a las 17:53 UTCinvestigating

   Hemos identificado un problema con Protect que ha resultado en un rendimiento degradado, y nuestro equipo de ingeniería está buscando una solución.

2. 24 de septiembre de 2026 a las 18:39 UTCmonitoring

   Hemos identificado un problema con Protect que ha resultado en un rendimiento degradado. Se ha aplicado una solución y seguiremos vigilando esta cuestión.

3. 24 de septiembre de 2026 a las 19:57 UTCinvestigating

   Hemos identificado un problema con Protect & Prevent que ha resultado en un rendimiento degradado, y nuestro equipo de ingeniería está buscando una solución.

4. 24 de septiembre de 2026 a las 21:46 UTCmonitoring

   Se ha aplicado una solución y estamos monitoreando los resultados.

5. 25 de septiembre de 2026 a las 9:16 UTCresolved

   Este incidente ha sido resuelto.

6. 6 de octubre de 2026 a las 15:51 UTCpostmortem

   ## **Summary** Desde el jueves 24 de septiembre de 2026, aproximadamente 17:07 \(UTC\), hasta el viernes, 25 de septiembre de 2026, alrededor de 09:16 \(UTC\), algunos clientes experimentaron la lentitud intermitente, errores y el flujo de correo retardado para casos estadounidenses de Protección e Prevención. El 24 de septiembre, un aumento inusualmente grande en el tráfico de correo electrónico colocó carga sostenida en los servicios de red que manejan el tráfico para nuestro procesamiento de correo de EE.UU.. Nuestro monitoreo nos alertó a aproximadamente 17:07 \(UTC\). Algunos clientes vieron un acceso lento o intermitente a Protectar y errores ocasionales al cargar páginas o opciones avanzadas. El acceso era inconsistente, por lo que algunos clientes podían utilizar Protect mientras otros veían errores. El procesamiento de correo a través de las instancias estadounidenses se ralentizó, y algunos mensajes se retrasaron o no aparecieron en la caja de moderación cuando se esperaba. El rendimiento pareció mejorar, por lo que movimos nuestro aviso de página de estado a Monitoreo a las 18:39 \(UTC\). El problema se repitió más tarde, y los clientes informaron que continuaba la lentitud con nuestro equipo de apoyo. A las 19:57 \(UTC\), trasladamos el aviso de vuelta a Investigar y ampliarlo para incluir también a Prevent ya que el impacto se hizo más claro. Nuestro equipo monitoreó los sistemas afectados mientras el volumen de correo elevado se disminuía. A medida que la carga en los servicios de red retornaba a la normalidad, el procesamiento de correo se recuperaba y las colas de correo retornaban a la normalidad durante la noche. Confirmamos que Protect estaba cargando normalmente y que los mensajes de prueba estaban siendo entregados de nuevo, y luego continuaba el monitoreo. Proteger y prevenir regresó a la normalidad de rendimiento alrededor de 09:16 \(UTC\) el 25 de septiembre de 2026. No se produjeron pérdidas de datos como resultado de esta cuestión. ## ## Root Cause ## Este problema fue causado por un aumento inusualmente grande en el tráfico de correo electrónico. El volumen aumentado colocó una carga sostenida en los servicios de red que manejan el tráfico para nuestro procesamiento de correo de EE.UU.. Estos servicios de red funcionan dentro de límites de capacidad fijos, y su capacidad no se puede ampliar durante el pico. Debido a que no pudieron mantenerse al día con la oleada, se ralentizó, y algunos procesamiento fallaron intermitentemente. Como resultado, un gran volumen de correo fue consultado en el procesamiento de correos estadounidenses, algunas páginas y acciones en Protect devuelto errores, y algunos mensajes se retrasaron o no aparecieron en la caja de moderación cuando se esperaba. Dos factores dificultaron la gestión del problema. Primero, debido a que el acceso falló intermitentemente, algunos cheques tuvieron éxito mientras que los clientes continuaron viendo errores, haciendo la recuperación más difícil de confirmar. En segundo lugar, nuestro monitoreo mostró una carga máxima en los servicios de red más claramente que la carga actual, lo que hizo más difícil juzgar en tiempo real si la carga seguía siendo elevada. ## **Mitigation and Remediation** Encontramos que los servicios de red que manejan el procesamiento de correos estadounidenses habían alcanzado sus límites de capacidad fijos durante el aumento del tráfico, y su capacidad no podía aumentarse durante el evento. Nuestro equipo monitoreó los sistemas afectados mientras que el volumen de correo elevado se subside y la carga de servicio de red devuelto a la normalidad. El procesamiento de correo se recuperó y el correo solicitado fue procesado. Debido a que la cuestión había aparecido anteriormente para mejorar antes de la repetición, confirmamos la recuperación de varias maneras antes de resolver el incidente. Confirmamos que Protect estaba cargando normalmente, que los mensajes de prueba estaban siendo entregados a través del procesamiento de correo de EE.UU., y que las solicitudes de soporte estaban progresando normalmente. También monitoreamos durante la noche y no recibimos nuevos informes de clientes sobre casos estadounidenses. ## ** Impacto del cliente** Algunos clientes tenían acceso lento o intermitente a Protect, y ocasionalmente vieron errores al cargar páginas o opciones avanzadas. El procesamiento de correos a través de los casos de EE.UU. se retrasó para proteger e prevenir. En algunos casos, los mensajes se retrasaron o no aparecieron en la caja de moderación cuando se esperaba. Los clientes cuyo correo está encriptado, descifrado o moderado a medida que pasa a través de nuestro procesamiento de correo de EE.UU. fueron más propensos a ser afectados. La mayoría de los clientes protectores usando el complemento no se vieron afectados por los retrasos del procesamiento de correo. Las consolas Protect and Prevent seguían disponibles, aunque algunas acciones de consola se vieron afectadas por el procesamiento de correo más lento. ## ** Medidas preventivas** Para evitar este tipo de problema en el futuro, estamos mejorando nuestro monitoreo de aumentos inusuales en el volumen de correo electrónico. También estamos mejorando nuestro monitoreo para mostrar la carga actual en nuestros servicios de red, no sólo valores máximos. Además, estamos evaluando maneras de escalar nuestra capacidad de red más dinámicamente durante los picos repentinos de tráfico, y evaluando mejoras a largo plazo en la infraestructura de red que maneja el procesamiento de correo estadounidense. También hemos aumentado la capacidad de los servicios de red de los Estados Unidos en respuesta a [un incidente posterior](https://status.knowbe4.com/incidents/9wc6rjm8g70v).

Traducido automáticamente desde la actualización oficial del incidente.

1. 23 de septiembre de 2026 a las 9:52 UTCidentified

   Hemos recibido informes de usuarios que reciben mensajes de error "Access Denied" mientras intentan iniciar sesión. Hemos identificado el problema y estamos trabajando en la implementación de una solución y actualizaremos esta página cuando tengamos más información.

2. 23 de septiembre de 2026 a las 10:57 UTCmonitoring

   La cuestión ha sido identificada y se ha implementado una solución y actualizará esta página cuando tengamos más información.

3. 23 de septiembre de 2026 a las 14:58 UTCresolved

   Este incidente se ha resuelto con éxito y todos los sistemas están en pleno funcionamiento.

Traducido automáticamente desde la actualización oficial del incidente.

1. 23 de septiembre de 2026 a las 9:00 UTCinvestigating

   Hemos recibido informes de que algunos usuarios son incapaces de presentar con éxito las presentaciones webform. Estamos investigando este problema y actualizaremos esta página cuando tengamos más información.

2. 23 de septiembre de 2026 a las 10:47 UTCidentified

   Se ha determinado la cuestión y se ha aplicado una solución. Una actualización con más información seguirá en consecuencia.

3. 23 de septiembre de 2026 a las 10:58 UTCmonitoring

   La cuestión ha sido identificada y se ha implementado una solución y actualizará esta página cuando tengamos más información.

4. 23 de septiembre de 2026 a las 14:58 UTCresolved

   Este incidente se ha resuelto con éxito y todos los sistemas están en pleno funcionamiento.

5. 20 de octubre de 2026 a las 15:53 UTCpostmortem

   El miércoles 23 de septiembre de 2026, de aproximadamente 08:15 a 11:18 \(UTC\), algunos clientes experimentaron la lentitud y la presentación de formularios fallidos en Reino Unido casos de Webforms Seguros. This issue was caused by database performance limits in the UK production environment following a recent change. Un ajuste de bases de datos también causó que algunas consultas se ejecutaran ineficientemente. Como resultado, los tiempos de respuesta aumentaron y algunas presentaciones de formulario fracasaron. Para resolver este problema, nuestro equipo pausó temporalmente una tarea de sincronización de antecedentes para reducir la carga, ajustar la configuración de la base de datos para mejorar la eficiencia de las consultas y aumentar el rendimiento de almacenamiento. Webforms seguros devueltos al rendimiento normal por 11:18 \(UTC\). Para evitar este tipo de problema en el futuro, estamos agregando monitoreo adicional para el ancho de banda de bases de datos. También estamos mejorando la eficiencia de la tarea de sincronización de antecedentes. No se produjeron pérdidas de datos como resultado de esta cuestión.

Traducido automáticamente desde la actualización oficial del incidente.

1. 21 de septiembre de 2026 a las 9:32 UTCinvestigating

   Hemos recibido informes de que los usuarios no pueden enviar correos electrónicos a través de Web Access (Secure Message Portal) en la región del Reino Unido, con Error "503 Service No disponible". Estamos investigando este problema y actualizaremos esta página cuando tengamos más información.

2. 21 de septiembre de 2026 a las 14:36 UTCmonitoring

   Hemos implementado una solución y estamos monitoreando los resultados.

3. 21 de septiembre de 2026 a las 14:38 UTCmonitoring

   Continuamos monitoreando cualquier otro problema.

4. 22 de septiembre de 2026 a las 8:27 UTCresolved

   Este incidente se ha resuelto con éxito y todos los sistemas están en pleno funcionamiento.

5. 8 de octubre de 2026 a las 13:45 UTCpostmortem

   El lunes 21 de septiembre de 2026, de aproximadamente 08:55 a martes 22 de septiembre de 2026, aproximadamente a las 14:30 \(UTC\), algunos usuarios experimentaron errores y no pudieron enviar correos electrónicos a través de Web Access \(Secure Message Portal\) en la región del Reino Unido. Este incidente fue causado por un error de configuración durante una actualización de la base de datos, lo que llevó a una interrupción intermitente del servicio. Para resolver este problema, revertimos la configuración, y el Acceso Web volvió a su rendimiento normal a las 14:30 \(UTC\) el 22 de septiembre de 2026. Para evitar este tipo de problema en el futuro, estamos revisando y actualizando nuestra configuración de bases de datos. No se produjeron pérdidas de datos como resultado de esta cuestión.

Traducido automáticamente desde la actualización oficial del incidente.

1. 18 de septiembre de 2026 a las 11:07 UTCinvestigating

   Hemos recibido informes de que los usuarios son incapaces de acceder a las instancias DE y UK de KSAT. Estamos investigando este problema y actualizaremos esta página cuando tengamos más información.

2. 18 de septiembre de 2026 a las 16:48 UTCresolved

   Este incidente ha sido resuelto.

3. 8 de octubre de 2026 a las 14:07 UTCpostmortem

   ## **Summary** El 17 de septiembre de 2026, un trabajo de fondo archivó un gran grupo de usuarios y funcionó como una única transacción de bases de datos sin límites. Esta transacción cerró un gran número de filas de usuarios, causando que los logins de la región de Estados Unidos a tiempo fuera porque escriben a la misma tabla. Después de golpear un límite de ejecución de la plataforma, el trabajo fue terminado y se retrató automáticamente cinco veces en intervalos de 15 minutos, lo que dio lugar a un desembolso de 75 minutos. Para resolver el problema, implementamos una solución que decoupled logins de la cerradura. Luego implementamos una solución de seguimiento para una regresión introducida por el cambio de login, así como para el trabajo de archivo. ## ** What Happened** Un cambio previo movió la acción de "archive all users" de una solicitud web sincronizada y temporal en un trabajo de fondo sin límites. Cuando un grupo de usuarios grande fue archivado, esto provocó el nuevo trabajo de fondo. El trabajo cerró todas las filas de usuario afectadas en una sola transacción, realizando escritos por usuario y una llamada de servicio externo sincronizada antes de comprometerse. Los intentos de inicio de sesión, que se escriben a la misma mesa, fueron desconcertados detrás del trabajo bloqueado y con tiempo para los usuarios de Estados Unidos. Cuando el trabajo llegó a un límite de ejecución de la plataforma de 15 minutos, se rescindió a mitad de la transacción, la transacción volvió a rodar, y el trabajo fue entregado a la cola. Este ciclo ocurrió cinco veces, lo que dio lugar a un desembolso de 75 minutos. Cuando se detectaron fallos internamente a las 22:35 \(UTC\), se declaró un incidente y un ingeniero fue llamado a responder. La mitigación para decodificar la acción de escritura del flujo de inicio de sesión se desplegó en aproximadamente 23:44 \(UTC\). La mitigación en sí misma causó una regresión: cualquier usuario en cualquier región que anteriormente había mal tipificado una contraseña ya no podía iniciar sesión porque los reinicios para intentos fallidos de inicio de sesión trataron de escribir a una base de datos sólo lectura. Para 09:17 \(UTC\) el 18 de septiembre de 2026, la fijación para esta regresión fue implementada en regiones. El número de trabajo original de archivo sólo en EE.UU. recurrió dos veces más entre 13:45 y 14:05 \(UTC\) antes de que una solución permanente se desplegara aproximadamente a las 15:00 \(UTC\). El incidente fue resuelto completamente por 19:12 \(UTC\) el 18 de septiembre de 2026. ## ## Root Cause ## Un trabajo de fondo sin límites, de una sola transacción para el archivo de usuarios de grandes grupos mantuvo bloqueos exclusivos en muchas filas afectadas, bloqueando el propio texto del proceso de inicio de sesión. Un cambio previo para mover esta operación fuera de un tiempo de solicitud web y en un trabajo de fondo el único límite restante en su duración. El límite de ejecución de 15 minutos de la plataforma detonó ciclos automáticos de muerte y entrega, repitiendo la contención de bloqueo cinco veces y resultando en una ventana de 75 minutos de salida. ## **Findings and Mitigations** Encontramos que la transacción de archivo sin límites bloqueaba un gran número de filas de usuarios afectadas, bloqueando otras tablas escribe. Esto fue mitigado a corto plazo desvinculando la dependencia de escritura del proceso de inicio de sesión de la tabla afectada, y luego fijo a largo plazo corrigiendo el trabajo del archivo. También encontramos que la concurrencia obrera no coordinada amplifica la contención de bloqueo. This was mitigated in the short term by manually reducing worker concurrency. Se planea la solución a largo plazo para estancar y serializar estos trabajos. Finalmente, encontramos que la regresión de inicio de sesión-fix causó fallos de registro para los usuarios con intentos fallidos previos porque los escritos fueron rechazados por una base de datos sólo lectura. Esto se fijó mediante un cambio de código específico que se desplegó y verificó en todas las regiones. ## ** Medidas preventivas** Estamos mejorando nuestras operaciones de archivo de grandes grupos al obligarlas, procesarlas en lotes pequeños y comprometidos y mantener llamadas externas fuera de la transacción de la base de datos. También estamos añadiendo un cheque de cambio a un trabajador de fondo específico para saltar escritos que no cambian nada. Por último, estamos añadiendo alertas directas para la edad de transacción de bases de datos y demoras de purga, además de cheques indirectos periódicos. ## ** Impacto y recuperación del cliente** Las fallas de acceso duraron aproximadamente 75 minutos en la región de Estados Unidos. Dos breves recurrencias sólo estadounidenses ocurrieron la mañana siguiente y fueron limpiadas manualmente en cuestión de minutos. Algunas acciones de administración, como la gestión de usuarios, también se vieron afectadas. Los logins de pareja no fueron afectados. La regresión secundaria duró alrededor de 10 horas y afectó a todas las regiones para los usuarios que anteriormente habían fracasado en un intento de ingreso. Por la tarde del 18 de septiembre, se confirmó la recuperación total en todas las regiones, y la página de estado fue marcada como resuelta. No se produjeron pérdidas de datos como resultado de esta cuestión. Conclusión Una única transacción de fondo sin límites, combinada con un mecanismo de reingreso automático, causó un outage de inicio de sesión en la región estadounidense. El trabajo de activación específico y su comportamiento de reingreso han sido fijos, y el login ya no depende de la trayectoria de escritura contended. Una regresión del mismo incidente y dos recurrencias menores se resolvieron en horas. La labor preventiva restante, incluida la coordinación de los trabajadores y la supervisión de las transacciones de bases de datos, se hace un seguimiento más arriba.

Traducido automáticamente desde la actualización oficial del incidente.

1. 17 de septiembre de 2026 a las 22:44 UTCinvestigating

   Hemos recibido informes de que los usuarios no pueden acceder a la instancia estadounidense de KSAT. Estamos investigando este problema y actualizaremos esta página cuando tengamos más información.

2. 18 de septiembre de 2026 a las 1:28 UTCmonitoring

   Hemos implementado una solución y estamos monitoreando los resultados para asegurarnos de que no se produzcan más problemas.

3. 18 de septiembre de 2026 a las 14:02 UTCinvestigating

   Hemos recibido nuevos informes de usuarios que no pueden acceder a la instancia estadounidense de KSAT. Estamos investigando este problema y actualizaremos esta página cuando tengamos más información.

4. 18 de septiembre de 2026 a las 16:47 UTCresolved

   Este incidente ha sido resuelto.

5. 5 de octubre de 2026 a las 21:16 UTCpostmortem

   ## **Summary** El 17 de septiembre de 2026, un trabajo de fondo archivó un gran grupo de usuarios y funcionó como una única transacción de bases de datos sin límites. Esta transacción cerró un gran número de filas de usuarios, causando que los logins de la región de Estados Unidos a tiempo fuera porque escriben a la misma tabla. Después de golpear un límite de ejecución de la plataforma, el trabajo fue terminado y se retrató automáticamente cinco veces en intervalos de 15 minutos, lo que dio lugar a un desembolso de 75 minutos. Para resolver el problema, implementamos una solución que decoupled logins de la cerradura. Luego implementamos una solución de seguimiento para una regresión introducida por el cambio de login, así como para el trabajo de archivo. ## ** What Happened** Un cambio previo movió la acción de "archive all users" de una solicitud web sincronizada y temporal en un trabajo de fondo sin límites. Cuando un grupo de usuarios grande fue archivado, esto provocó el nuevo trabajo de fondo. El trabajo cerró todas las filas de usuario afectadas en una sola transacción, realizando escritos por usuario y una llamada de servicio externo sincronizada antes de comprometerse. Los intentos de inicio de sesión, que se escriben a la misma mesa, fueron desconcertados detrás del trabajo bloqueado y con tiempo para los usuarios de Estados Unidos. Cuando el trabajo llegó a un límite de ejecución de la plataforma de 15 minutos, se rescindió a mitad de la transacción, la transacción volvió a rodar, y el trabajo fue entregado a la cola. Este ciclo ocurrió cinco veces, lo que dio lugar a un desembolso de 75 minutos. Cuando se detectaron fallos internamente a las 22:35 \(UTC\), se declaró un incidente y un ingeniero fue llamado a responder. La mitigación para decodificar la acción de escritura del flujo de inicio de sesión se desplegó en aproximadamente 23:44 \(UTC\). La mitigación en sí misma causó una regresión: cualquier usuario en cualquier región que anteriormente había mal tipificado una contraseña ya no podía iniciar sesión porque los reinicios para intentos fallidos de inicio de sesión trataron de escribir a una base de datos sólo lectura. Para 09:17 \(UTC\) el 18 de septiembre de 2026, la fijación para esta regresión fue implementada en regiones. El número de trabajo original de archivo sólo en EE.UU. recurrió dos veces más entre 13:45 y 14:05 \(UTC\) antes de que una solución permanente se desplegara aproximadamente a las 15:00 \(UTC\). El incidente fue resuelto completamente por 19:12 \(UTC\) el 18 de septiembre de 2026. ## ## Root Cause ## Un trabajo de fondo sin límites, de una sola transacción para el archivo de usuarios de grandes grupos mantuvo bloqueos exclusivos en muchas filas afectadas, bloqueando el propio texto del proceso de inicio de sesión. Un cambio previo para mover esta operación fuera de un tiempo de solicitud web y en un trabajo de fondo el único límite restante en su duración. El límite de ejecución de 15 minutos de la plataforma detonó ciclos automáticos de muerte y entrega, repitiendo la contención de bloqueo cinco veces y resultando en una ventana de 75 minutos de salida. ## **Findings and Mitigations** Encontramos que la transacción de archivo sin límites bloqueaba un gran número de filas de usuarios afectadas, bloqueando otras tablas escribe. Esto fue mitigado a corto plazo desvinculando la dependencia de escritura del proceso de inicio de sesión de la tabla afectada, y luego fijo a largo plazo corrigiendo el trabajo del archivo. También encontramos que la concurrencia obrera no coordinada amplifica la contención de bloqueo. This was mitigated in the short term by manually reducing worker concurrency. Se planea la solución a largo plazo para estancar y serializar estos trabajos. Finalmente, encontramos que la regresión de inicio de sesión-fix causó fallos de registro para los usuarios con intentos fallidos previos porque los escritos fueron rechazados por una base de datos sólo lectura. Esto se fijó mediante un cambio de código específico que se desplegó y verificó en todas las regiones. ## ** Medidas preventivas** Estamos mejorando nuestras operaciones de archivo de grandes grupos al obligarlas, procesarlas en lotes pequeños y comprometidos y mantener llamadas externas fuera de la transacción de la base de datos. También estamos añadiendo un cheque de cambio a un trabajador de fondo específico para saltar escritos que no cambian nada. Por último, estamos añadiendo alertas directas para la edad de transacción de bases de datos y demoras de purga, además de cheques indirectos periódicos. ## ** Impacto y recuperación del cliente** Las fallas de acceso duraron aproximadamente 75 minutos en la región de Estados Unidos. Dos breves recurrencias sólo estadounidenses ocurrieron la mañana siguiente y fueron limpiadas manualmente en cuestión de minutos. Algunas acciones de administración, como la gestión de usuarios, también se vieron afectadas. Los logins de pareja no fueron afectados. La regresión secundaria duró alrededor de 10 horas y afectó a todas las regiones para los usuarios que anteriormente habían fracasado en un intento de ingreso. Por la tarde del 18 de septiembre, se confirmó la recuperación total en todas las regiones, y la página de estado fue marcada como resuelta. No se produjeron pérdidas de datos como resultado de esta cuestión. Conclusión Una única transacción de fondo sin límites, combinada con un mecanismo de reingreso automático, causó un outage de inicio de sesión en la región estadounidense. El trabajo de activación específico y su comportamiento de reingreso han sido fijos, y el login ya no depende de la trayectoria de escritura contended. Una regresión del mismo incidente y dos recurrencias menores se resolvieron en horas. La labor preventiva restante, incluida la coordinación de los trabajadores y la supervisión de las transacciones de bases de datos, se hace un seguimiento más arriba.

Traducido automáticamente desde la actualización oficial del incidente.

1. 16 de septiembre de 2026 a las 17:47 UTCidentified

   Hemos identificado un problema causando problemas de acceso y acceso para cuentas en nuestra instancia del Reino Unido.

2. 16 de septiembre de 2026 a las 18:16 UTCmonitoring

   Se ha aplicado una solución y estamos monitoreando los resultados.

3. 16 de septiembre de 2026 a las 20:58 UTCresolved

   Este incidente ha sido resuelto.

Traducido automáticamente desde la actualización oficial del incidente.

1. 11 de septiembre de 2026 a las 12:43 UTCresolved

   El 8 de Septermber nos dimos cuenta de que los correos electrónicos HTML entrantes se hicieron parcialmente o en blanco en Classic Outlook debido a una actualización rutinaria de la biblioteca HTML en el motor de recuperación de código dañino de Defend interactuando con el motor de renderización de Word de Classic Outlook. Nuevo Outlook y Outlook en la web no fueron afectados. Esto fue estrictamente un problema de visualización: ningún correo electrónico fue retrasado, perdido o comprometido, y la detección de amenazas seguía siendo plenamente activa. Engineering ha revertido la actualización para restaurar la renderización normal. Si usted deshabilita temporalmente la eliminación de códigos dañinos durante esta ventana, por favor vuelva a ser capaz de asegurar la protección completa.

Traducido automáticamente desde la actualización oficial del incidente.

1. 4 de septiembre de 2026 a las 10:53 UTCinvestigating

   Hemos recibido informes de un problema con la entrega de MFA de verificación de correo electrónico para el espacio de trabajo. Estamos investigando este problema y actualizaremos esta página cuando tengamos más información.

2. 4 de septiembre de 2026 a las 14:24 UTCmonitoring

   Hemos recibido informes de que la cuestión con la entrega de la verificación de correo electrónico MFA para Workspace ha sido mitigada por Microsoft, y estamos monitoreando los resultados.

3. 7 de septiembre de 2026 a las 8:25 UTCresolved

   Este incidente ha sido resuelto.

Traducido automáticamente desde la actualización oficial del incidente.

1. 26 de agosto de 2026 a las 16:19 UTCinvestigating

   Hemos identificado un problema donde los usuarios pueden experimentar retrasos en el procesamiento de mensajes, y nuestro equipo de ingeniería está buscando una solución.

2. 26 de agosto de 2026 a las 16:46 UTCmonitoring

   Nuestro equipo de ingeniería ha implementado una solución para la cuestión que causa retrasos en el procesamiento de mensajes en PhishER, y estamos monitoreando los resultados.

3. 26 de agosto de 2026 a las 19:51 UTCresolved

   Nuestro equipo de ingeniería ha implementado una solución para la cuestión que causa retrasos en el procesamiento de mensajes en PhishER.

4. 16 de octubre de 2026 a las 20:36 UTCpostmortem

   ## **Summary** Durante un despliegue rutinario el 26 de agosto de 2026, un marco de gestión de infraestructura removió inesperadamente tanto las colas primarias de procesamiento de mensajes como las colas secundarias que contienen mensajes que no podían ser procesados. Esto resultó en una interrupción temporal de la entrega de correo electrónico entrante a las bandejas de entrada de clientes de PhishER. No se produjeron pérdidas de datos como resultado de esta cuestión. ## ## Root Cause ## El 24 de agosto de 2026, un cambio de configuración interno dejó registros de configuración en vivo fuera de sincronización con nuestro código. Una actualización de código posterior no revertía esos registros. Cuando un despliegue de producción de rutina funcionó el 26 de agosto de 2026, el código de configuración activo no contenía los registros de recursos reubicados. Como resultado, el despliegue trató las colas activas como recursos no gestionados y las removió. ## **Mitigation and Remediation** El monitoreo automatizado nos alertó de una caída en el procesamiento de mensajes, y un equipo de respuesta a incidentes fue reunido. Encontramos que las colas habían sido eliminadas. Esto se mitigó a corto plazo reelaborando los trabajos de producción afectados para recrear las colas desaparecidas. Luego verificamos que el procesamiento de correo electrónico en tiempo real se había reanudado. Finalmente, repetimos las cargas de pago de correo electrónico sostenidas en almacenamiento en la nube durante el outage en las bandejas de entrada de los clientes. ## **Timeline** Todas las veces están en UTC. * 24 de agosto de 2026, 18:41* Un cambio interno de configuración escribió registros de recursos actualizados en configuración de producción en vivo. * ** 26 de agosto de 2026, 15:15:** Un despliegue de producción removió las colas de entrada y las colas que contienen mensajes que no podían procesarse en producción, deteniendo la entrega de correo electrónico en las bandejas de entrada de los clientes. * **26 de agosto de 2026, 15:59** Nuestro monitoreo automatizado alertó al equipo de ingeniería a cero mensajes que se procesan, y un equipo de respuesta a incidentes fue llamado. * **26 de agosto de 2026, 16:01:** Confirmamos que las colas habían sido eliminadas y verificadas que las cargas de pago entrantes de correo electrónico todavía se almacenaban con seguridad. * ** 26 de agosto de 2026, 16:15:** Identificamos el desajuste de configuración como la principal causa raíz. * **26 de agosto de 2026, 16:25** Nuestro equipo reanuda los trabajos de producción afectados, y las colas fueron recreadas. * **26 de agosto de 2026, 18:44** Nuestra repetición automatizada terminó entregando todos los correos electrónicos backlogged a las cajas de clientes. ## ** Medidas preventivas** Para evitar este tipo de problema en el futuro, hemos eliminado un paso de configuración en vivo de los controles previos a la fusión y la planificación del despliegue separado de los cambios de producción. También hemos añadido cheques automatizados para confirmar la salud de la cola después de que las versiones estén completas. ## ** Impacto del cliente** De 15:15 a 16:25 \(UTC\) el 26 de agosto de 2026, los correos electrónicos entrantes enviados a PhishER no fueron procesados en buzones de clientes. Las cargas de pago de correo electrónico entrantes fueron almacenadas con seguridad en el almacenamiento de la nube a lo largo de la interrupción. Después de que las colas fueron restauradas, una repetición automatizada entregó correos electrónicos mantenidos a las entradas de los clientes. Todos los mensajes backlogged fueron entregados por 18:44 \(UTC\). No se perdieron datos de correo electrónico de clientes como resultado de este problema.

Traducido automáticamente desde la actualización oficial del incidente.

1. 21 de agosto de 2026 a las 8:52 UTCinvestigating

   Hemos recibido informes de que el Gmail Phish Alert Button muestra el error "[reportPhishAttempt()] Ha ocurrido un error interno. Por favor inténtelo de nuevo". Estamos investigando este problema y actualizaremos esta página cuando tengamos más información.

2. 21 de agosto de 2026 a las 12:03 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

3. 21 de agosto de 2026 a las 13:08 UTCmonitoring

   Se ha aplicado una solución y estamos monitoreando los resultados.

4. 21 de agosto de 2026 a las 14:57 UTCresolved

   Este incidente ha sido resuelto.

5. 26 de agosto de 2026 a las 15:55 UTCpostmortem

   El viernes, 21 de agosto de 2026, de aproximadamente 05:20 a 12:55 \(UTC\), algunos clientes experimentaron fallos intermitentes al utilizar el complemento Gmail Phish Alert Button para informar correos electrónicos sospechosos, recibiendo el mensaje "Un error interno ha ocurrido" en lugar de una confirmación exitosa del informe. El problema afecta a los clientes de todas las regiones, con los mayores volúmenes de errores concentrados en las regiones de servicio UE-Oeste y Estados Unidos-Este. Este problema fue causado por una interrupción en un servicio de caché en la plataforma de Google Apps Script, que el add-in se basa en almacenar la configuración de sesión por usuario. El servicio comenzó a devolver intermitentemente los resultados vacíos al leer mientras todavía aceptaba nuevos escritos, causando que las presentaciones de informes afectados fallaran. KnowBe4 contrató a Google directamente y presentó un informe de error formal entre aproximadamente 12:19 y 12:39 \(UTC\). El volumen de error disminuyó bruscamente poco después de que la condición del lado del proveedor se aclarara, y el botón Gmail Phish Alert volvió a un rendimiento normal en aproximadamente 12:55 \(UTC\). Para evitar este tipo de problema en el futuro, seguimos trabajando con Google para seguir la resolución del defecto subyacente de caché. No se produjeron pérdidas de datos como resultado de esta cuestión.

Traducido automáticamente desde la actualización oficial del incidente.

1. 18 de agosto de 2026 a las 14:29 UTCinvestigating

   Estamos investigando un problema que hace que se devuelva un Informe No Delivery (NDR) cuando se reporta un mensaje a través del Botón de Alerta de Phish y "Envíenos una Copia" está habilitado en Configuración de Cuentas

2. 18 de agosto de 2026 a las 15:26 UTCmonitoring

   Se ha aplicado una solución y estamos monitoreando los resultados.

3. 18 de agosto de 2026 a las 20:14 UTCresolved

   Este incidente ha sido resuelto.

4. 30 de septiembre de 2026 a las 20:06 UTCpostmortem

   El martes 18 de agosto de 2026, de aproximadamente 14:10 a 14:55 \(UTC\), los clientes que utilizan el botón de alerta Phish \(PAB\) con la función **Envíenos una copia** habilitada recibió informes no entregados para el **Envíenos una copia** buzón de correo. Este problema fue causado por un cambio de configuración a la infraestructura de enrutamiento de correo electrónico compartida. Este cambio renombraba un componente de mensajería utilizado tanto por nuestros entornos de estadificación y producción. Debido a que una regla de producción dependía de este componente compartido, el renombre causó fallos de entrega al **Envíenos una copia** buzón de correo y lanzó informes sin entrega. Para resolver este problema, nuestro equipo actualizó la configuración afectada para hacer referencia al componente correcto, y la función **Envíenos una copia** devolvió al rendimiento normal por 14:55 \(UTC\). Para evitar este tipo de problema en el futuro, estamos separando configuraciones de correo electrónico de enrutamiento para nuestros entornos de estadificación y producción. También estamos conciliando configuraciones heredadas en nuestros estándares actuales de gestión de infraestructura. No se produjeron pérdidas de datos como resultado de esta cuestión.

Traducido automáticamente desde la actualización oficial del incidente.

1. 5 de agosto de 2026 a las 19:29 UTCinvestigating

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

2. 5 de agosto de 2026 a las 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 de agosto de 2026 a las 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 de agosto de 2026 a las 19:19 UTCidentified

   Hemos identificado un problema evitando que la configuración de la cuenta se cargue en la consola SAT.

2. 4 de agosto de 2026 a las 19:51 UTCmonitoring

   Se ha aplicado una solución y estamos monitoreando los resultados.

3. 5 de agosto de 2026 a las 12:17 UTCresolved

   Este incidente ha sido resuelto.

4. 28 de septiembre de 2026 a las 14:35 UTCpostmortem

   El martes 4 de agosto de 2026, de aproximadamente 18:22 a 19:43 \(UTC\), algunos clientes experimentaron problemas cargando la página **Account Settings** en la consola KnowBe4 en las regiones CA, DE, EU, UK y EE.UU. Esta cuestión se debió a una serie de cambios de aplicación que aumentaron la complejidad de una solicitud de GraphQL utilizada por la experiencia de Configuración de Cuentas. Cada cambio se mantuvo por debajo del umbral de complejidad configurado de la plataforma cuando se evaluó individualmente, pero combinado, la solicitud superó ese umbral e impidió la carga de la página. La ingeniería identificó el umbral de complejidad como el factor contribuyente y desplegó un cambio correctivo a partir de aproximadamente 19:14 \(UTC\). Después de que la fijación fue verificada en todas las regiones afectadas, la consola KnowBe4 volvió a un rendimiento normal alrededor de 19:43 \(UTC\). Para evitar esta cuestión en el futuro, hemos aumentado el umbral de complejidad. No se produjeron pérdidas de datos como resultado de esta cuestión.

Traducido automáticamente desde la actualización oficial del incidente.

1. 28 de julio de 2026 a las 20:00 UTCinvestigating

   Estamos investigando un problema relacionado con los correos electrónicos siendo cuarentena por PhishRIP de manera inesperada

2. 28 de julio de 2026 a las 20:35 UTCmonitoring

   Se ha implementado una solución para este problema y las consultas de PhishRIP ya no están cuarentenando mensajes inesperadamente. Todavía estamos investigando las consultas que pueden haber sido impactadas

3. 29 de julio de 2026 a las 18:58 UTCresolved

   Este incidente ha sido resuelto.

4. 30 de julio de 2026 a las 16:38 UTCpostmortem

   ## **Summary** El 28 de julio de 2026, una actualización del servicio de PhishRIP causó algunas consultas de búsqueda de PhishRIP para coincidir más ampliamente de lo que deberían tener. Los correos electrónicos benignos que no cumplieron los criterios de remitente configurados se cuarentenaron en algunas cuentas de clientes. Las entradas de monitorización automatizadas y asistencia al cliente surgieron rápidamente el problema. Engineering revertió el cambio en unos 25 minutos después de declarar el incidente y detuvo la cuarentena involuntaria. Ingeniería entonces restaurado manualmente los correos electrónicos incorrectamente cuarentena a las bandejas de entrada de los clientes. ### **Causa real** El 28 de julio de 2026, implementamos una actualización de mantenimiento al servicio de consulta detrás de PhishRIP. Esta actualización fue diseñada para mejorar el manejo de direcciones de remitente inválidas permitiendo que el sistema retroceda a buscar solamente la parte de dominio de la dirección. Sin embargo, la lógica de validación existente utilizó una expresión regular que requería un símbolo "@" en el campo del remitente. Cuando una consulta utilizó un dominio desnudo, como [example.com](http://example.com) sin nombre de usuario o símbolo "@", el regex insignia el dominio como inválido. Este conflicto entre la validación existente y la actualización del dominio-búsqueda causó que el sistema desplegue completamente los criterios del remitente. La consulta corrió contra las buzones usando sólo sus parámetros restantes, los correos electrónicos emparejantes y cuarentena bien fuera del remitente previsto. ## **Timeline** Todas las veces están en UTC. Silencio ** Tiempo** Silencioso** Silencio... TEN 19:36 TENIDO Nuestro monitoreo automatizado detectó patrones de ejecución anómalos de consultas y alertó a nuestros ingenieros, quienes inmediatamente comenzaron a investigar. Silencio Silencio 19:51 Silencio La cuestión se incrementó a un incidente de producción de alta intensidad, y se reunió un equipo de respuesta. Silencio Silencio 19:52 Silencio Nuestro equipo de soporte escala los primeros boletos de clientes que reportaron cuarentenas inesperadas, corroborando la alerta de monitoreo. TEN 19:54 TENIDO La causa raíz fue trazada a una reciente implementación de API de consultas, y la ingeniería comenzó a revertir el cambio. Silencio 20:00 Silencio Las comunicaciones por incidentes fueron publicadas en nuestra página de estado, con PhishRIP marcado como Degradado. Silencio Silencio 20:16 Silencio El despliegue fue completamente revertido. TEN 20:35 Las comprobaciones de producción TEN confirmaron que las consultas de materia y dominio coincidían de nuevo sólo con sus objetivos previstos, y que no se cuarenten otros mensajes en error. Nuestra página de estado fue actualizada en consecuencia. Silencio TEN 20:39 TENIDO Ingeniería comenzó a restaurar los correos electrónicos incorrectamente cuarentena. TEN 03:49 \(El próximo día\) Silencio Restorations se completó para todos los conjuntos de consultas del cliente conectados a través de nuestro equipo de soporte. ## **Mitigation and remediation** Revertir el código. Pesamos detener las operaciones activas de PhishRIP a mediados de carrera contra la reversión del código. La interrupción de las tareas de fondo habría perturbado los flujos de trabajo legítimos de seguridad para cada inquilino, por lo que la reversión era la mejor opción. El revertido de código se desplegó y verificó en producción en aproximadamente 40 minutos de escalada. **Rehabilitación por correo electrónico.** Para evitar la liberación de correos electrónicos genuinamente maliciosos de vuelta en entornos de clientes, los restauramos manualmente en lugar de en granel. Ingeniería usó herramientas internas de administración para restaurar correos electrónicos en lotes, y trabajó con Soporte para verificar cada ID de cuenta, ID de consulta y recibir la aprobación del cliente primero. Todas las cuentas reportadas fueron restauradas durante la noche. ## ** Medidas preventivas** * **Cobertura de regresión**: Estamos añadiendo pruebas de unidad e integración para las consultas de remitente de dominio único, no estándar y de proa para capturar estos casos de entrada antes del despliegue. *Query guardrails**: Estamos añadiendo un cheque en el motor de consulta que bloquea las consultas de ejecutar si sus parámetros de filtrado de núcleo se eliminan durante la evaluación. Conclusión Una única regla de validación causó esto: un regex que asumió cada campo del remitente contenía un `@`. Cuando las consultas utilizaron un dominio desnudo, esa suposición dejó caer el filtro del remitente y las consultas coincidieron mucho más correo de lo previsto. La solución fue directa una vez que la encontramos, y el revertido detuvo el daño en unos 25 minutos después de declarar el incidente. Restaurar el correo cuarentena fue un proceso más difícil: no podíamos restaurar correos electrónicos a granel sin arriesgar correos electrónicos genuinamente maliciosos volver a los buzones. Nuestro equipo eligió proceder con cuidado, cuenta de trabajo por cuenta con Support durante toda la noche. Dos medidas preventivas habrían atrapado esto antes: una prueba cubriendo sólo las consultas del remitente de dominios, y una correa que se niega a ejecutar una consulta cuando su filtro del remitente ha sido despojado. Ambos están planeados. Se resuelve la cuestión inmediata y se han restablecido todas las cuentas notificadas. ## **Glosario** *PhishRIP:** Una característica de PhishER que permite a los administradores buscar y cuarentena que coincida con correos electrónicos de phishing en cada buzón de usuario en una organización. * **Regex \(expresión regular\):** Un patrón utilizado en el software para buscar texto y validar la entrada, como comprobar que una dirección de correo electrónico está formateado correctamente. * **Code revertir:** Respaldar una actualización de software para volver a la versión estable anterior.

Traducido automáticamente desde la actualización oficial del incidente.

1. 17 de julio de 2026 a las 13:18 UTCinvestigating

   Estamos investigando usuarios que no pueden comprar licencias de protección en tienda.knowbe4.com. Actualizaremos esta página cuando tengamos más información.

2. 17 de julio de 2026 a las 18:55 UTCmonitoring

   Hemos implementado una solución y estamos monitoreando los resultados para asegurarnos de que no se produzcan más problemas.

3. 20 de julio de 2026 a las 18:24 UTCinvestigating

   Hemos recibido informes de que los clientes no pueden comprar licencias de protección en store.knowbe4.com. Estamos investigando este problema y actualizaremos esta página cuando tengamos más información.

4. 29 de julio de 2026 a las 18:40 UTCmonitoring

   Hemos implementado una solución para la tienda online y estamos monitoreando los resultados para asegurarnos de que no se produzcan más problemas.

5. 17 de agosto de 2026 a las 21:02 UTCmonitoring

   Seguimos monitoreando la solución implementada para la tienda online, para asegurar que no se produzcan más problemas.

6. 11 de septiembre de 2026 a las 15:04 UTCresolved

   Este incidente ha sido resuelto.

Traducido automáticamente desde la actualización oficial del incidente.