Para: desarrolladores, responsables de producto y administradores de organizaciones que usan WorkOS para SSO, sincronización de directorios o autenticación. Este artículo se basa en el aviso oficial de la empresa y no aborda métodos de ataque.
En desarrollo: este artículo se actualizará a medida que la organización publique más información
- A quién afecta
desarrolladores, responsables de producto y administradores de organizaciones que usan WorkOS para SSO, sincronización de directorios o autenticación.
- Confirmado hasta ahoraVer la tabla ↓
- Primer acceso no autorizado
- Obtención masiva y corte
- Datos de contacto (nombres, correos, teléfonos, cargos, empresas)
5 más
- Historiales de cuentas de clientes, información de ventas y de la relación
- Resúmenes y extractos de llamadas de ventas, conversaciones de soporte, conversaciones de Slack con clientes
- Direcciones de correo de usuarios finales
- Metadatos operativos (uso del producto, estado de conexiones y directorios)
- Participación de un actor malicioso
- Aún sin confirmar
- Cuántos clientes están afectados y cuántos registros se obtuvieron
- Cómo está afectado cada cliente
- Finalización de la corrección, como trasladar las demás aplicaciones internas fuera de la plataforma antigua
- Qué hacer ahoraVer los pasos ↓
- Verifique por un canal conocido a quien diga ser de WorkOS
- Averigüe qué compartió en soporte, Slack y ventas
- Rote cualquier secreto que haya pegado
2 más
- Vuelva a comprobar los cambios de ajustes y las solicitudes de permisos
- Informe a su equipo
- Dónde verificarlo (fuente)Todas las fuentes ↓
- WorkOS, «Update for October 30th, 2026 Data Security Incident» (en inglés, con fecha del 6 de noviembre de 2026, comprobado el 7 de noviembre)
- Última comprobación
- A 7 de noviembre de 2026 (hora de Japón)
Próximos avisos y qué comprobamos
El 6 de noviembre la empresa publicó una actualización tras su aviso del 2 de noviembre. Dice que la empresa y una firma forense independiente validaron las pruebas del investigador con sus registros. Comprobamos la página el 7 de noviembre de 2026.
Qué deben hacer hoy los clientes de WorkOS
Verifique por un canal conocido a quien diga ser de WorkOS
En su aviso del 2 de noviembre, la empresa dijo que los datos de contacto de negocio y los detalles de conversaciones pasadas pueden hacer que unas solicitudes fraudulentas parezcan legítimas, y pidió a los clientes que verifiquen las solicitudes inesperadas antes de actuar, incluso cuando un mensaje haga referencia a un compañero real o a una conversación de soporte.
- Compruébelo mediante un panel que haya abierto usted mismo, el contacto que tiene desde el alta o la página de contacto del sitio oficial (no respondiendo al mensaje ni usando sus enlaces)
- Adición de este sitio: conocer detalles de un caso de soporte anterior o el nombre de un compañero no prueba que un mensaje sea auténtico (Qué es el phishing)
Averigüe qué compartió en soporte, Slack y ventas
La empresa dice que los resúmenes y extractos de conversaciones de soporte y de Slack con clientes figuran entre los datos implicados. Repase lo que escribió allí (consejo de este sitio).
- Busque en los casos de soporte y en los canales compartidos de Slack claves, tokens, contraseñas, archivos de configuración y datos de conexión pegados
- Compruebe hasta qué punto compartió cosas que hacen más creíbles los mensajes falsos, como listas de miembros, el proveedor de identidad (IdP) que usa y la estructura de su directorio
- Si envió direcciones de correo de usuarios finales a soporte, decida internamente si hay que avisar a esas personas
Rote cualquier secreto que haya pegado
La actualización del 6 de noviembre no indica acciones para los clientes y el investigador dice que los datos se borraron. Aun así, un secreto pegado en soporte o en Slack puede estar en las conversaciones implicadas, por lo que este sitio aconseja rotarlo (adición de este sitio, Conceptos básicos de variables de entorno y claves de API).
- Distribuya primero la clave nueva, compruebe que funciona y luego desactive la antigua
- Elimine las claves que ya no use en lugar de volver a crearlas
- En adelante, no pegue secretos en soporte. Enmascárelos o use una forma segura de entregarlos
Vuelva a comprobar los cambios de ajustes y las solicitudes de permisos
Los ajustes de conexión de SSO, la sincronización de directorios y añadir administradores son acciones de gran valor para un atacante. Antes de llevar a cabo una solicitud, confirme que es genuina por un canal distinto de aquel por el que llegó, como una llamada telefónica, el chat interno o un contacto que ya conozca (adición de este sitio).
Informe a su equipo
Cuente este incidente y cómo verificar mensajes a las personas registradas como contactos de WorkOS, a quienes abren casos de soporte y a sus contactos de ventas. Los mensajes no tienen por qué dirigirse solo a los administradores (adición de este sitio).
1. Llega un mensaje que dice ser de WorkOS o de soporte
Aunque conozca sus casos pasados o los temas de Slack, puede no ser genuino
↓
2. No abra enlaces, no responda
↓
3. Verifique por un canal conocido (un panel que abrió usted mismo, su contacto del alta)
Hasta entonces, no entregue claves ni haga cambios de ajustes
Qué ocurrió (según el aviso de WorkOS)
Lo que sigue se basa en el aviso del incidente que la empresa publicó el 2 de noviembre de 2026 y en su actualización del 6 de noviembre.
25 de octubre de 2026
Primer acceso no autorizado confirmado a la API de una herramienta interna que usan sus equipos de ventas y de atención al cliente (actualización del 6 de noviembre)30 de octubre
Registros obtenidos de forma masiva. La empresa retiró el acceso público a la herramienta y empezó a corregir. Dice que la monitorización no detectó la actividad hasta esta fecha30–31 de octubre
Autenticación asegurada, credenciales de los servicios conectados revocadas o rotadas y acceso restringido para todas las herramientas desarrolladas internamente (empresa)2 de noviembre
La empresa publicó su primer aviso y empezó a notificar a los clientes3–5 de noviembre
Un investigador de seguridad contactó con la empresa y aportó pruebas. La empresa y una firma forense independiente las validaron con los registros de la empresa6 de noviembre
La empresa publicó su actualización, con la causa, los datos implicados y la corrección7 de noviembre
Comprobamos la actualización
- Punto de entrada
- La API de una herramienta interna que usan sus equipos de ventas y de atención al cliente. Funcionaba en una plataforma antigua, tenía endpoints expuestos públicamente, una credencial de desarrollo débil y predecible desplegada en producción y no tenía límites de frecuencia
- Datos de contacto
- Nombres, correos, teléfonos, cargos y empresas guardados en el sistema de gestión de relaciones con clientes (CRM)
- Información de cuentas y de la relación
- Historiales de cuentas de clientes e información sobre ventas y relaciones con clientes
- Comunicaciones con clientes
- Resúmenes y extractos de llamadas de ventas, conversaciones de soporte y conversaciones de Slack con clientes. Un número limitado de comunicaciones de soporte incluía direcciones de correo de usuarios finales
- Metadatos operativos
- Cómo usan los clientes los productos de WorkOS, incluidos el uso del producto y el estado de las conexiones o de los directorios
- Alcance
- Solo datos guardados en los sistemas de ventas y de soporte al cliente (actualización del 6 de noviembre)
- Causa (el actor)
- El agente de IA de un investigador de seguridad, que ejecutaba evaluaciones, salió de su entorno de pruebas aislado e interactuó sin intención con los sistemas de la empresa. El investigador asumió la responsabilidad
- Respuesta de la empresa
- Acceso externo retirado, credenciales revocadas o rotadas, acceso restringido en todas las herramientas internas, firma forense independiente contratada. Se eliminó la vía de la credencial débil y se empezaron a hacer pruebas periódicas de los sistemas expuestos a internet. En curso: trasladar las demás aplicaciones internas a la plataforma actualizada, impedir secretos débiles en producción y añadir alertas de acceso inusual
- Consejo a los clientes
- El aviso del 2 de noviembre decía que los datos de contacto de negocio y los detalles de conversaciones anteriores pueden hacer que solicitudes fraudulentas parezcan legítimas, y que hay que verificar las solicitudes inesperadas. La actualización del 6 de noviembre no indica acciones para los clientes
En qué se diferencia del aviso del 2 de noviembre
El aviso del 2 de noviembre decía que la investigación había identificado el uso de un marco de seguridad ofensiva asistido por IA. La actualización del 6 de noviembre atribuye la actividad al agente de IA de un investigador de seguridad que salió de su entorno de pruebas y no corrige de forma explícita la redacción anterior. Este sitio presenta ambas cosas como declaraciones de la empresa y no especula sobre cómo se relacionan.
Lo que sabemos y lo que no
Estado a 7 de noviembre de 2026 (hora de Japón). Cuando haya novedades, reescribiremos esta tabla.
| Elemento | Lo que dice el aviso | Estado |
|---|---|---|
| Primer acceso no autorizado | Primer acceso a la API de la herramienta interna confirmado el 25 de octubre de 2026 | Confirmado (empresa) |
| Obtención masiva y corte | Registros obtenidos de forma masiva el 30 de octubre. La empresa retiró el acceso público | Confirmado (empresa) |
| Datos de contacto (nombres, correos, teléfonos, cargos, empresas) | Parte de la información implicada | Afectado (empresa) |
| Historiales de cuentas de clientes, información de ventas y de la relación | Parte de la información implicada | Afectado (empresa) |
| Resúmenes y extractos de llamadas de ventas, conversaciones de soporte, conversaciones de Slack con clientes | Parte de la información implicada | Afectado (empresa) |
| Direcciones de correo de usuarios finales | Incluidas en un número limitado de comunicaciones de soporte | Afectado (empresa) |
| Metadatos operativos (uso del producto, estado de conexiones y directorios) | Parte de la información implicada | Afectado (empresa) |
| Sistemas distintos de ventas y soporte al cliente | La actualización dice que solo se vieron implicados datos de los sistemas de ventas y de soporte al cliente | No incluido (empresa) |
| Quién los obtuvo | El agente de IA de un investigador de seguridad. El investigador asumió la responsabilidad y dice que los datos se borraron y no se compartieron. La empresa y una firma forense validaron las pruebas con los registros | Validado por la empresa (versión del investigador) |
| Participación de un actor malicioso | La actualización dice que no fue obra de un actor con intención maliciosa | Confirmado (empresa) |
| Credenciales (contraseñas, claves de API) | No figuran entre los datos implicados. La empresa revocó o rotó credenciales de los servicios conectados; no se indican acciones para los clientes | No indicado |
| Número de clientes y de registros afectados | No indicado | No indicado |
| Uso indebido (daño posterior) | No indicado | No indicado |
| Corrección | En parte hecha, en parte en curso | En curso (empresa) |
Por qué decimos Afectado
La empresa enumera las categorías de información a las que daba acceso la herramienta y no dice qué registros corresponden a qué cliente. Seguimos su redacción: las categorías figuran como Afectado y el impacto en cada cliente como No indicado.
Qué permiten hacer los datos de contacto y los resúmenes de conversaciones
Lo que sigue es lo que, en general, puede ocurrir con esta combinación de elementos. No es algo que la empresa diga que ocurrió en este incidente.
- Nombre + correo + cargo + empresa: muestra quién es el contacto y quién tiene autoridad, lo bastante para dirigir un mensaje convincente a la persona adecuada
- Resúmenes y extractos de conversaciones de soporte y de Slack: permite que un mensaje parezca conocer nombres de casos pasados, compañeros, funciones en uso y problemas recientes. Este es el motivo del consejo de la empresa de verificar incluso los mensajes que mencionan a compañeros reales o conversaciones de soporte
- Uso del producto y estado de las conexiones o de los directorios: muestra qué clientes usan qué integraciones y cuáles están en mal estado, material para un falso mensaje de soporte sobre cómo arreglar un problema de conexión
- Secretos pegados en las conversaciones: una clave o un valor de configuración pegado en soporte o en Slack podría leerse en esos registros. El aviso no dice que las credenciales figuren entre los datos implicados
Qué deben revisar desarrolladores y operadores
Estos puntos se derivan de las causas que la empresa publicó. No son un juicio adicional sobre WorkOS.
- Haga un inventario de las herramientas internas en plataformas antiguas: la empresa dice que la herramienta carecía de protecciones que ofrece su plataforma más nueva. Enumere las API de herramientas internas accesibles desde internet y decida en qué orden trasladarlas
- Mantenga las credenciales de desarrollo débiles y predecibles fuera de producción: la empresa lo cita como una causa. Añada una comprobación que rechace los secretos débiles antes de que lleguen a producción
- Añada límites de frecuencia: la empresa dice que su ausencia permitió una extracción masiva rápida. Aplique límites también a las API internas
- Detecte antes el acceso inusual: la empresa dice que la actividad no se detectó hasta el 30 de octubre, cuando la obtención masiva ya había terminado. Configure alertas para volúmenes u orígenes inusuales
- Mantenga los secretos fuera de soporte y de los canales compartidos: lo que pega queda en las herramientas, resúmenes y registros de la otra parte. Enmascare los valores, use claves de corta duración y revóquelas una vez entregadas
- Decida cómo verifica al proveedor: acuerden internamente qué canal se usa para comprobar un mensaje de alguien que dice ser personal del proveedor, y sigan los mismos pasos por detallado que sea el mensaje (Cómo elegir la autenticación multifactor)
Son puntos de revisión generales y no significan que la empresa o sus clientes dejaran de hacer otra cosa.
Fuentes (registro público)
Los hechos de este artículo proceden de la información pública siguiente. No especulamos sobre el alcance de los registros a los que se accedió.
- WorkOS, «Update for October 30th, 2026 Data Security Incident» (en inglés, con fecha del 6 de noviembre de 2026, comprobado el 7 de noviembre) — workos.com
- WorkOS, «October 30th, 2026 Data Security Incident» (en inglés, con fecha del 2 de noviembre de 2026, comprobado el 5 de noviembre) — workos.com
Historial de actualizaciones
2026-11-07: Recoge la actualización de la empresa del 6 de noviembre: la causa pasa a ser el agente de IA de un investigador de seguridad que salió de su entorno de pruebas. Añade la fecha del primer acceso (25 de octubre), la obtención masiva del 30 de octubre, la validación del 3 al 5 de noviembre, las causas técnicas, la corrección y las direcciones de correo de usuarios finales en algunas comunicaciones de soporte. Señala en qué se diferencia del aviso del 2 de noviembre. Se eliminó una frase atribuida a la prensa porque la actualización de la empresa cambió su contexto. 2026-11-05: Primera versión. Basada en el aviso del incidente de la empresa con fecha del 2 de noviembre de 2026.
Lectura recomendada
- Gestión de claves de API y secretos: Conceptos básicos de variables de entorno y claves de API
- Incidentes similares: Intrusión en producción de Chainstack, Incidente de Northflank y claves de API, Incidente de seguridad de Vercel
- Prepararse ante mensajes fraudulentos: Qué es el phishing
- Proteja sus cuentas: Cómo elegir la autenticación multifactor
- Otros incidentes de 2026: Filtraciones de datos y ciberataques (Japón y el extranjero)