Las noticias de ciberseguridad de septiembre de 2026 estuvieron dominadas por tokens falsificados, sesiones reproducidas y claves de API filtradas que seguían funcionando después de cambiar la contraseña o que nunca la necesitaron. Dos vulnerabilidades ya figuran en el catálogo Known Exploited Vulnerabilities de CISA, y una clave de proveedor filtrada puso en riesgo a más de 100 000 sitios.
- Cisco ISE: CVE-2026-76460, una omisión de autenticación con explotación activa confirmada (Cisco).
- EvilTokens: Microsoft desmanteló un servicio de phishing por código de dispositivo vinculado a más de 12 000 bandejas de entrada comprometidas en más de 10 000 organizaciones (Microsoft).
- Brevo y Cloudflare: una clave de API comprometida puso en riesgo potencial a más de 100 000 sitios (Sansec).
- JFrog Artifactory: un fallo explotado en honeypots para generar tokens de administrador (SecurityWeek).
- Cleo Harmony: un exploit público para un fallo en el token de actualización JWT (SecurityWeek).
- CyberArk: 10 boletines de seguridad en cuatro fechas, incluido uno crítico (CyberArk).
- Claves de aplicaciones de GitHub: GitGuardian determinó que 474 de 4802 claves privadas filtradas seguían siendo válidas, autenticando como 440 aplicaciones (GitGuardian).
- NIST IR 8587: guía final sobre la protección de tokens y aserciones, publicada el 15 de septiembre (NIST).
Cada caso a continuación muestra una forma distinta en que una credencial sigue funcionando después de que debería haberse detenido: falsificada, reproducida, filtrada o generada a demanda. A continuación se detallan las versiones afectadas y las soluciones, con una breve lista de acciones a nivel de equipo al final.
Explotación activa de una omisión de autenticación en Cisco Identity Services Engine (CVE-2026-76460)
Cisco publicó un aviso el 16 de septiembre de 2026 sobre el CVE-2026-76460, una vulnerabilidad crítica de omisión de autenticación no autenticada en una API de Identity Services Engine (ISE). Cisco la califica con CVSS 3.1 Base 10.0 (Crítico) y confirmó la explotación activa. CISA añadió el CVE a su catálogo Known Exploited Vulnerabilities el mismo día.
Qué ocurrió: una solicitud manipulada al endpoint de API afectado permite a un atacante omitir la interfaz de administración web de ISE y obtener acceso no autorizado a un dispositivo ISE o ISE-PIC afectado, sin credenciales válidas. El PSIRT de Cisco confirmó que tenía conocimiento de ataques en entornos reales. No se ha revelado la fecha exacta en que comenzó la explotación.
Por qué importa: ISE es una plataforma de políticas de acceso a la red. El acceso no autorizado podría crear un riesgo grave específico de cada implementación para las operaciones de administración y de políticas, pero las fuentes disponibles no establecen que se hayan alterado las decisiones de RBAC o MFA posteriores de todos los clientes. El impacto depende de cómo tenga implementado ISE cada organización.
La conclusión defensiva: Cisco afirma que no existe ninguna solución alternativa para el fallo. Actualizar a una versión corregida es la solución completa. Como mitigación temporal, Cisco recomienda ACL de infraestructura (iACL) que permitan únicamente el tráfico de administración y de plano de control necesario hacia el dispositivo afectado. Revise el access.log de cada nodo en busca de nombres de usuario sospechosos y coteje los registros de red y de firewall fuera del propio dispositivo. Son pasos de detección y respuesta, no un sustituto de la aplicación de parches.
Microsoft desmantela EvilTokens, un servicio de phishing por código de dispositivo OAuth
El 22 de septiembre de 2026, la Unidad de Delitos Digitales de Microsoft, en colaboración con socios, desmanteló la infraestructura que sustentaba a EvilTokens, una plataforma de phishing como servicio vinculada a más de 12 000 bandejas de entrada comprometidas en más de 10 000 organizaciones de todo el mundo.
Qué ocurrió: EvilTokens abusaba de los flujos de autorización por código de dispositivo de OAuth 2.0, el mecanismo diseñado para dispositivos sin navegador, como televisores inteligentes o herramientas de línea de comandos, para engañar a los usuarios y hacerles aprobar un inicio de sesión en nombre del atacante. Microsoft reveló por separado actividad de ingeniería social con temática de passkeys observada desde mayo de 2026. En una de las secuencias investigadas, un anzuelo de passkey condujo a un phishing por código de dispositivo. En otros patrones investigados, los atacantes usaron pretextos de mesa de ayuda o registraron métodos de autenticación controlados por el atacante. Los informes de Microsoft no establecen que todas las secuencias combinaran estos pasos en una sola cadena de ataque.
Por qué importa: el phishing por código de dispositivo evita las partes de la autenticación que reciben más atención defensiva. No hay una página de inicio de sesión falsa que detectar ni una contraseña escrita en el sitio del atacante. La víctima aprueba el inicio de sesión a través de la página legítima de Microsoft, creyendo que es un trámite rutinario. Aun así, una víctima sin una sesión activa de Microsoft puede recibir igualmente una solicitud de contraseña real y un desafío de MFA, por lo que esta técnica no elimina universalmente todos los pasos de autenticación.
La conclusión defensiva: deshabilite los flujos de autenticación por código de dispositivo para los usuarios que no los necesiten operativamente, y supervise los volúmenes anómalos de inicio de sesión por código de dispositivo como señal de detección. Donde el flujo sea realmente necesario, protéjalo con una política de acceso condicional.
Fuentes: Microsoft; Microsoft (actividad con temática de passkeys)
Una sola clave de API de Cloudflare con permisos excesivos puso en riesgo a más de 100 000 sitios
El 14 de septiembre de 2026, los atacantes usaron una clave de API de Cloudflare comprometida y con permisos amplios, perteneciente a la plataforma de correo electrónico y marketing Brevo, para desplegar un Cloudflare Worker malicioso que alteró los recursos de Brevo incrustados en los sitios de los clientes.
Qué ocurrió: la telemetría de Sansec registró que el Worker malicioso sirvió contenido desde las 16:05 hasta las 20:13 UTC del 14 de septiembre, aproximadamente cuatro horas. El informe del incidente de Brevo describe el Worker como activo durante unas cinco horas y media, una ventana más larga que la observada directamente por Sansec. Sansec estimó que más de 100 000 sitios que utilizaban componentes afectados de Brevo pudieron haber estado expuestos a contenido malicioso durante ese periodo.
Por qué importa: una sola clave de API de Cloudflare de larga duración y con permisos totales, vinculada a un proveedor de automatización de marketing, se convirtió en un canal de distribución de código malicioso en un gran número de sitios de terceros. Las claves de API en la nube con alcances amplios y sin caducidad son exactamente el tipo de credencial que la política de contraseñas tradicional no cubre.
La conclusión defensiva: limite las claves de API al conjunto mínimo de permisos que realmente necesita una integración, establezca caducidades incluso en las claves a nivel de servicio, y ejecute un escaneo continuo de secretos en repositorios y canalizaciones de despliegue, no solo en las bóvedas de contraseñas de los empleados. Supervisar los despliegues inesperados de Workers o los cambios de enrutamiento probablemente habría detectado esto más rápido que una auditoría manual.
Un fallo de JFrog Artifactory se usa para generar tokens de administrador (CVE-2026-82329)
JFrog publicó una corrección para el CVE-2026-82329 el 28 de agosto de 2026. El 1 de septiembre, WatchTowr informó de actividad en honeypots compatible con atacantes que explotaban el fallo para generar tokens de administrador.
Qué ocurrió: los honeypots de WatchTowr capturaron intentos de explotación contra un pequeño número de IP de origen, algunos de los cuales parecían ser actividad de mera verificación y no ataques completos. Es una prueba de que la vulnerabilidad es explotable y está siendo sondeada. No establece un escaneo amplio en internet ni una explotación masiva confirmada de instancias de clientes.
Por qué importa: los repositorios de artefactos se sitúan cerca del centro de la cadena de suministro de software. Mantienen relaciones de confianza federada con otros repositorios y a menudo contienen credenciales incrustadas para sistemas posteriores. Un atacante que puede generar un token de administrador no necesita robar uno: crea acceso válido a demanda.
La conclusión defensiva: para instalaciones autogestionadas de Artifactory, actualice a la versión corregida de su rama: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 o 7.161.20. JFrog afirma que los entornos en la nube afectados ya estaban reforzados. Si los registros muestran explotación o emisión sospechosa de tokens, revoque y reemita los tokens de administrador potencialmente expuestos y audite las configuraciones de federación. Los informes disponibles respaldan una explotación observada en honeypots, no una vulneración confirmada de instancias de clientes.
Fuentes: JFrog; SecurityWeek
Exploit público para un fallo en el token de actualización JWT de Cleo Harmony (CVE-2026-84115)
Se informó de un exploit público para el CVE-2026-84115 el 2 de septiembre de 2026, poco después de que se publicara el registro del CVE el 1 de septiembre.
Qué ocurrió: el fallo afecta a las versiones de Cleo Harmony hasta la 5.8.1.10 y está corregido en Harmony 5.8.1.11. El registro del CVE describe un problema explotable de forma remota en el gestor de tokens de actualización JWT de /api/connections: manipular el argumento Bearer provoca una gestión incorrecta de privilegios. SecurityWeek describe el mismo problema como causante de una omisión de autenticación y una elevación de privilegios. Los informes disponibles establecen la explotabilidad pública y la reproducción por parte de investigadores. No establecen una explotación confirmada de sistemas de clientes, ni que un token manipulado persista más allá de la caducidad de la sesión original.
Por qué importa: los tokens de actualización están pensados para prolongar una sesión de forma discreta, sin forzar un nuevo inicio de sesión. Un fallo en la forma en que se valida uno convierte esta función de comodidad en un riesgo potencial de persistencia, motivo suficiente para aplicar el parche incluso sin explotación confirmada.
La conclusión defensiva: actualice a Harmony 5.8.1.11 cuanto antes. Si se sospecha exposición, siga las indicaciones actuales de Cleo, revise los cambios de autenticación y de privilegios de la ventana correspondiente, y revoque los tokens de actualización pendientes donde la implementación admita ese control. La existencia de un exploit público no confirma por sí sola una vulneración ni un acceso persistente.
Fuentes: NVD; SecurityWeek
CyberArk publica diez boletines de seguridad en toda su línea de productos PAM
CyberArk publicó 10 boletines de seguridad en septiembre de 2026, en cuatro lotes con distintas fechas.
Qué ocurrió: CyberArk publicó 10 boletines de seguridad en cuatro lotes durante septiembre de 2026, que abordan problemas de gravedad alta en agentes de gestión de privilegios de endpoints, componentes de puerta de enlace y bóveda autogestionados, analítica de acceso privilegiado y gestión de credenciales de bases de datos, además de un problema crítico —CA26-44— que afecta a determinadas versiones autogestionadas de Password Vault Web Access (PVWA).
Por qué importa: los sistemas PAM a menudo gestionan o dan acceso a credenciales privilegiadas e infraestructura sensible. Un conjunto concentrado de actualizaciones de seguridad es un recordatorio de que estos entornos requieren gestión continua de parches, una gobernanza de accesos clara y una capacidad de auditoría fiable. Los avisos no indican, por sí mismos, explotación activa.
La conclusión defensiva: las organizaciones que usan los productos afectados deben revisar los avisos y priorizar la corrección según la gravedad, la exposición y el impacto potencial en los sistemas relacionados con credenciales. De forma más general, los equipos de seguridad deben mantener visibilidad sobre quién puede acceder a las credenciales sensibles y poder revisar ese acceso cuando sea necesario.
Fuente: CyberArk; CyberIAM bulletin board
Las claves privadas filtradas de aplicaciones de GitHub siguen funcionando mucho después de su exposición
GitGuardian probó 4802 claves privadas filtradas de aplicaciones de GitHub encontradas en fuentes públicas y descubrió que 474 seguían autenticándose como 440 aplicaciones activas distintas.
Qué ocurrió: una clave privada de una aplicación de GitHub no tiene caducidad automática y puede permanecer utilizable hasta que se revoque o elimine manualmente. De las 474 claves aún válidas que probó GitGuardian, 207 tenían permiso de escritura de contenido en repositorios, 40 podían administrar ejecutores autogestionados, 98 podían controlar flujos de trabajo y 44 tenían privilegios de administración de la organización. Una clave confirmada hace años aún puede autenticarse si no se ha revocado o eliminado.
Un patrón relacionado surgió en un fallo de gestión de API de WSO2, el CVE-2026-5430. El aviso data de mayo de 2026 y el CVE se publicó en agosto. La noticia de septiembre fue un informe de explotación, no una nueva divulgación. Un atacante puede crear un JWT con un algoritmo de firma no admitido y aprovechar la validación defectuosa de WSO2 para omitir la autenticación. El servicio no necesita generar un token por sí mismo. El honeypot de WatchTowr capturó JWT falsificados con privilegios de administrador contra el servicio el 13 de septiembre, y CISA añadió el CVE a su catálogo Known Exploited Vulnerabilities el 24 de septiembre. Se informó de que las credenciales de backend, las claves de consumidor o los secretos eran potencialmente accesibles, no que se hubieran robado de forma confirmada.
Por qué importa: una filtración pública crea un acceso potencialmente persistente hasta que se revoca o elimina la clave. No prueba por sí sola que la clave se usara o que se accediera a los datos. El caso de WSO2 muestra un patrón relacionado una capa más abajo en la pila: un atacante ni siquiera necesita una clave filtrada si la propia lógica de validación puede ser engañada para aceptar una falsificada.
La conclusión defensiva: mantenga un responsable y un proceso documentado de rotación/revocación para cada clave de aplicación de GitHub. Si se sospecha o se confirma la exposición, genere un reemplazo y revoque o elimine la clave antigua cuanto antes; la rotación periódica reduce el tiempo de exposición, aunque GitHub no prescribe un calendario universal. Para las implementaciones de WSO2, aplique la corrección del proveedor, revise los registros de la ventana de explotación de septiembre y rote las credenciales a las que tenía acceso la capa de gestión de API.
Fuentes: GitGuardian; GitHub docs; WSO2 advisory; The Hacker News
NIST y CISA finalizan la guía sobre la protección de tokens de identidad y de acceso
NIST y CISA finalizaron el IR 8587 el 15 de septiembre de 2026, tras un borrador público inicial fechado el 22 de diciembre de 2025.
Qué ocurrió: la guía de implementación está escrita principalmente para agencias federales y los proveedores de servicios en la nube que utilizan, y abarca tokens de identidad, tokens de acceso y aserciones en escenarios de SSO, federación y acceso a API. Sus recomendaciones resumen prácticas de gestión de claves, verificación de tokens, ciclo de vida (incluida la vigencia y la revocación) y supervisión continua, con responsabilidades divididas entre proveedores, agencias consumidoras y clientes en la nube.
Por qué importa: varios de los fallos descritos anteriormente —JWT falsificados, tokens de administrador generados mediante fallos de validación, claves de API sin caducidad— entran dentro de las categorías que aborda este informe: brechas de verificación, controles de ciclo de vida inexistentes y responsabilidad poco clara entre proveedor y cliente respecto a la revocación. Esa coincidencia es útil incluso para organizaciones fuera del ámbito federal.
La conclusión defensiva: use el NIST IR 8587 como lista de verificación práctica frente a las prácticas actuales: confirme que la vigencia de los tokens está limitada, que las rutas de revocación se prueban y no solo se documentan, y que el registro de sesiones capture suficiente detalle para reconstruir un incidente basado en tokens después de que ocurra.
CloudSEK detalla BigBear 2.0, un servicio de adversario en el medio que reproduce sesiones de Microsoft 365 después de la MFA
CloudSEK publicó su investigación sobre BigBear 2.0 el 7 de septiembre de 2026. Su equipo TRIAD descubrió la operación en junio, lo que no establece cuándo comenzó toda la actividad de la campaña.
Qué ocurrió: el servicio de adversario en el medio, basado en Evilginx2, interceptaba los inicios de sesión de Microsoft 365. Capturaba las credenciales y la cookie de sesión emitida por Microsoft después de que las víctimas completaran la MFA, y luego permitía a los atacantes reproducir las sesiones autenticadas. El panel de CloudSEK contenía 4148 registros de cookies de sesión y 474 autenticaciones completadas con omisión de MFA. BleepingComputer informó de que 258 organizaciones distintas tuvieron al menos una vulneración completada de este tipo, mientras que 461 organizaciones aparecían en el conjunto de datos de objetivos más amplio. La cifra de 4148 es un recuento de registros de cookies, no un recuento confirmado de víctimas únicas. (CloudSEK; BleepingComputer)
Por qué importa: la MFA que la víctima completa en una página proxificada no protege nada una vez que se roba la cookie de sesión. El atacante hereda una sesión ya autenticada. Los códigos y las aprobaciones push no detienen este patrón.
La conclusión defensiva: priorice métodos resistentes al phishing, como las passkeys y las llaves de seguridad FIDO2, para administradores y usuarios de alto riesgo. Revise las políticas de acceso condicional que vinculan las sesiones a dispositivos conformes. Genere alertas cuando la dirección IP o el dispositivo de una sesión cambien poco después de la MFA.
Fuentes: CloudSEK; BleepingComputer
Okta analiza un volcado de infostealer con 44 791 JWT únicos; 1843 tokens seguían siendo válidos en el momento de su publicación
Okta publicó una investigación el 9 de septiembre de 2026 sobre un volcado de infostealer de 7 GB publicado en Telegram el 2 de agosto.
Qué ocurrió: el volcado contenía datos de 5871 máquinas infectadas. Okta identificó 44 791 JWT únicos, incluidos 555 probablemente relacionados con la autenticación de servicios de IA, además de 2937 JWE relacionados con la autenticación. En el momento de la publicación del volcado, 1843 JWT y JWE no habían caducado. Okta afirmó que los secretos de sesión no caducados podrían reproducirse potencialmente para omitir la autenticación basada en credenciales. La investigación no informó de una reproducción exitosa ni de una toma de control de cuenta confirmada. Que la reproducción funcione depende del servicio y de controles como la vinculación de tokens o las listas blancas de IP. (Okta)
Por qué importa: los infostealers se llevan todo lo que hay en el endpoint, y los tokens forman parte de ese botín. La vigencia del token determina cuánto tiempo sigue siendo útil un secreto robado. Los tokens de servicios de IA presentes en el conjunto muestran que la exposición alcanza ya a herramientas más recientes que los equipos a menudo adoptan fuera de la gestión central de identidades.
La conclusión defensiva: reduzca la vigencia de los tokens donde el servicio lo permita, y vincule los tokens a un dispositivo o red donde sea posible. Tras una infección de infostealer, revoque las sesiones y rote los secretos, no se limite a restablecer la contraseña. Incluya las cuentas de servicios de IA en su inventario de tokens y claves de API.
Fuente: Okta
La extensión de Twitch JeetBot reenviaba tokens de OAuth a través de proxies controlados por el operador
La extensión de navegador maliciosa para Twitch JeetBot tuvo aproximadamente 30 500 instalaciones desde las tiendas de Chrome y Firefox (una estimación de instalaciones, no un recuento confirmado de vulneraciones).
Qué ocurrió: Socket descubrió que capturaba tokens de OAuth de Twitch con alcance de cuenta y los reenviaba en un parámetro de consulta &auth= a través de proxies controlados por el operador. Los informes no establecen que los tokens se usaran para actividad no autorizada. La versión 85.8.7 de Firefox (16 de septiembre) y la versión 85.8.9 de Chrome (informada el 25 de septiembre) detuvieron el reenvío. El operador rechazó calificar la extensión de maliciosa, pero reconoció problemas de seguridad y de divulgación. (Socket)
La conclusión defensiva: audite las extensiones de navegador instaladas y trate cualquier token que haya aparecido en una URL como expuesto. Los usuarios de JeetBot deben revocar el acceso de la aplicación a su cuenta de Twitch.
Fuente: Socket
Microsoft Entra comienza a habilitar automáticamente las passkeys antes de la retirada de la MFA por SMS y voz
Microsoft Entra comenzó a habilitar automáticamente las passkeys el 1 de septiembre de 2026 para los usuarios de la nube pública ya habilitados para MFA por SMS o voz en la política de métodos de autenticación de Entra o en la configuración heredada.
Qué ocurrió: cuando estos usuarios inician sesión la siguiente vez y completan la MFA, se les invita a registrar una passkey. Por lo general, el aviso puede posponerse, y hay disponible una exclusión temporal a nivel de inquilino hasta el 1 de febrero de 2027. La entrega de SMS y voz proporcionada por Microsoft se retira el 1 de febrero de 2027 para la mayoría de los usuarios, y el 1 de julio de 2027 para los administradores globales y los usuarios externos. Las organizaciones con una necesidad legítima pueden seguir usando SMS o voz a través de un proveedor de telefonía compatible. Esa opción de configuración está prevista para el 30 de octubre de 2026.
Por qué importa: el cambio aleja el valor predeterminado de los factores basados en teléfono, el tipo que la campaña BigBear 2.0 descrita arriba demuestra que puede interceptarse. Los inquilinos que no hagan nada verán ahora avisos de registro y perderán la entrega de SMS y voz proporcionada por Microsoft en 2027.
La conclusión defensiva: inventaríe qué usuarios y procesos de servicio aún dependen de SMS o voz. Comience el registro de passkeys con los administradores y los usuarios externos, cuyo plazo vence antes. Decida antes del 1 de febrero de 2027 si necesita un proveedor de telefonía o puede retirar estos métodos por completo.
Fuente: Microsoft Learn
Qué significa esto para su equipo
La mayoría de los casos de este mes se reducen a credenciales que siguieron funcionando después de que deberían haberse detenido. Seis pasos que su equipo puede tomar para evitar problemas similares:
- Inventaríe las credenciales no humanas. Liste las claves de API, los tokens de cuentas de servicio, las claves privadas de aplicaciones de GitHub y los secretos de CI/CD de la misma forma en que lista las cuentas de usuario. Asigne a cada una un responsable designado y un plan documentado de caducidad o rotación. Tanto el caso de Brevo como el de las claves de aplicaciones de GitHub implicaron claves que nadie estaba rastreando.
- Limite el alcance y establezca caducidades. Conceda a cada clave solo los permisos que la integración realmente necesita, y establezca una caducidad siempre que el proveedor lo admita. Donde no lo admita, programe una rotación manual.
- Pruebe la revocación antes de necesitarla. Para cada proveedor, confirme qué hace realmente revocar una sesión, un JWT, una concesión de OAuth o un token de actualización. Después de un incidente, ejecute la ruta de revocación de principio a fin en lugar de confiar en la documentación. Revoque las sesiones y rote los secretos, no se limite a restablecer la contraseña.
- Cierre las brechas de OAuth y de sesión. Deshabilite los flujos de código de dispositivo para los usuarios que no los necesiten, y traslade a los administradores a passkeys o llaves FIDO2 antes de la retirada de SMS y voz de Microsoft en 2027. Donde sea posible, vincule las sesiones a los dispositivos.
- Aplique primero los parches a la infraestructura de identidad expuesta. Cisco ISE, JFrog Artifactory, Cleo Harmony y WSO2 emiten o validan el acceso para todo lo que hay detrás de ellos. Trate sus actualizaciones como una prioridad por encima de los parches rutinarios.
- Registre lo suficiente para reconstruir un incidente. Mantenga registros de sesiones y tokens con el detalle suficiente para mostrar quién se autenticó, desde dónde y con qué token. El NIST IR 8587 es una lista de verificación práctica para esto y para los puntos anteriores.
Para más información relacionada, consulte nuestras guías sobre el ciclo de vida de la rotación de secretos y los secretos codificados.
Passwork Team
Passwork Team
Alex Muntyan
Tabla de contenidos
- Explotación activa de una omisión de autenticación en Cisco Identity Services Engine (CVE-2026-76460)
- Microsoft desmantela EvilTokens, un servicio de phishing por código de dispositivo OAuth
- Una sola clave de API de Cloudflare con permisos excesivos puso en riesgo a más de 100 000 sitios
- Un fallo de JFrog Artifactory se usa para generar tokens de administrador (CVE-2026-82329)
- Exploit público para un fallo en el token de actualización JWT de Cleo Harmony (CVE-2026-84115)
- CyberArk publica diez boletines de seguridad en toda su línea de productos PAM
- Las claves privadas filtradas de aplicaciones de GitHub siguen funcionando mucho después de su exposición
- NIST y CISA finalizan la guía sobre la protección de tokens de identidad y de acceso
- CloudSEK detalla BigBear 2.0, un servicio de adversario en el medio que reproduce sesiones de Microsoft 365 después de la MFA
- Okta analiza un volcado de infostealer con 44 791 JWT únicos; 1843 tokens seguían siendo válidos en el momento de su publicación
- La extensión de Twitch JeetBot reenviaba tokens de OAuth a través de proxies controlados por el operador
- Microsoft Entra comienza a habilitar automáticamente las passkeys antes de la retirada de la MFA por SMS y voz
- Qué significa esto para su equipo
Tabla de contenidos
- Explotación activa de una omisión de autenticación en Cisco Identity Services Engine (CVE-2026-76460)
- Microsoft desmantela EvilTokens, un servicio de phishing por código de dispositivo OAuth
- Una sola clave de API de Cloudflare con permisos excesivos puso en riesgo a más de 100 000 sitios
- Un fallo de JFrog Artifactory se usa para generar tokens de administrador (CVE-2026-82329)
- Exploit público para un fallo en el token de actualización JWT de Cleo Harmony (CVE-2026-84115)
- CyberArk publica diez boletines de seguridad en toda su línea de productos PAM
- Las claves privadas filtradas de aplicaciones de GitHub siguen funcionando mucho después de su exposición
- NIST y CISA finalizan la guía sobre la protección de tokens de identidad y de acceso
- CloudSEK detalla BigBear 2.0, un servicio de adversario en el medio que reproduce sesiones de Microsoft 365 después de la MFA
- Okta analiza un volcado de infostealer con 44 791 JWT únicos; 1843 tokens seguían siendo válidos en el momento de su publicación
- La extensión de Twitch JeetBot reenviaba tokens de OAuth a través de proxies controlados por el operador
- Microsoft Entra comienza a habilitar automáticamente las passkeys antes de la retirada de la MFA por SMS y voz
- Qué significa esto para su equipo
Gestor de contraseñas autohospedado para su empresa
Passwork ofrece la ventaja de un trabajo en equipo eficaz con contraseñas corporativas en un entorno totalmente seguro
Más información