gestión de secretos
19 artículos con esta etiqueta
Incidente de seguridad de Fireworks AI (octubre de 2026): afectados datos de facturación y, en algunas cuentas, conjuntos de datos y pesos de modelos incompletos; la empresa dice que intervino una brecha de un proveedor de nube. Qué deben hacer los clientes
Fireworks AI, que ofrece infraestructura de inferencia de modelos de IA, publicó el 9 de noviembre de 2026 una actualización del incidente de seguridad que comunicó por primera vez el 9 de octubre. Según la empresa, del incidente original, detectado el 6 de octubre, solo se sabía que afectaba a secretos almacenados en Fireworks (como los usados en trabajos de evaluación); desde entonces ha hallado impacto en información de cuenta y de facturación y, en un conjunto limitado de cuentas, en secretos, conjuntos de datos y pesos de modelos incompletos. En su relato, un proveedor de nube de terceros que alojaba sus máquinas de I+D sufrió un incidente de seguridad el 23 de octubre, y el 24 de octubre un tercero no autorizado lo usó para llegar a máquinas de desarrollo de Fireworks y ejecutar una carga de trabajo no autorizada, lo que causó un impacto adicional en datos de clientes. La empresa lo detectó ese mismo día y, a 25 de octubre, no había detectado más pruebas de acceso no autorizado con éxito a la plataforma que usan los clientes. Dice que las pruebas indican vínculos con un grupo cibercriminal con motivación económica. La empresa no almacena números de tarjeta de pago y no se vieron afectados. No se ha detectado impacto en Inference, Training SDK ni Nexus, que por defecto no retienen datos. Las subidas y descargas de conjuntos de datos por autoservicio están desactivadas durante la investigación. Nuestra opinión: los clientes deben inventariar y rotar lo que guardaron en la plataforma; los operadores deben mantener los entornos de desarrollo separados de los sistemas de facturación y de datos de clientes.
Vulneración de NEAR AI por un fallo del motor de inferencia (datos de cuenta de unos 100 usuarios): qué se ha confirmado y qué deben hacer los usuarios y los operadores de infraestructura de IA
NEAR AI, que ofrece chat y agentes de IA, comunicó en una entrada oficial de su blog fechada el 9 de noviembre de 2026 un acceso no autorizado a parte de su infraestructura. Según la empresa, la causa fue un fallo de ejecución remota de código en SGLang, el motor de inferencia de código abierto que funciona en sus servidores; el atacante ejecutó código en un servidor de inferencia y desde allí llegó a otra infraestructura. Lo que confirmó: datos de cuenta de unos 100 usuarios (direcciones de correo, nombres y, en algunas cuentas, información de plan y saldo) tomados de un sistema interno situado detrás del servicio Private Chat, ya retirado; el historial de chat, los ajustes y los registros de 18 agentes heredados que no se ejecutaban en su entorno de computación confidencial (TEE); y, por separado, claves de API de NEAR AI Cloud de dos clientes de Cloud que quedaron expuestas en registros (revocadas; el informe no dice que se las llevaran). El 8 de noviembre el atacante pudo además observar las solicitudes de los usuarios que se procesaban en el servidor comprometido, incluidas las del modo confidencial. La empresa no halló indicios de que se accediera a las conversaciones almacenadas de Private Chat ni a los archivos subidos. Dice que ha sustituido las credenciales, corregido el fallo y restablecido el acceso a NEAR AI Cloud (Private Chat sigue sin conexión). El informe oficial no da número CVE. Nuestra opinión: para los operadores de infraestructura de IA, lo esencial es mantener los servidores de inferencia separados de los sistemas internos, no dejar entornos heredados atrás y mantener los secretos fuera de los registros.
bee-js 13.3.0 de Ethersphere y Swarm Desktop 0.56.2 distribuyeron malware (noviembre de 2026): versiones afectadas y qué deben hacer los usuarios
La versión 13.3.0 del paquete npm @ethersphere/bee-js, de Ethersphere, el desarrollador de la red de almacenamiento descentralizado Swarm, contenía código malicioso. Un aviso de GitHub (GHSA-hh7j-5m3j-23pf) publicado el 9 de noviembre de 2026 enumera la 13.3.0 como la única versión afectada y dice que no hay versión corregida. Dice que cualquier ordenador que tenga el paquete instalado o en ejecución debe considerarse totalmente comprometido, y que todos los secretos y claves que contenga deben rotarse de inmediato desde otro ordenador. Eliminar el paquete puede no borrar todo el software malicioso que causó la instalación. En cuanto a Swarm Desktop, las notas de versión de Ethersphere dicen que la versión 0.56.3, publicada el 9 de noviembre, sustituye a la 0.56.2 comprometida. Según el análisis de una empresa de seguridad, bee-js 13.3.0 apareció en npm hacia las 00:09 UTC del 9 de noviembre (09:09 hora de Japón) y se retiró unos 75 minutos después. Swarm Desktop 0.56.2 estuvo público unas 8,5 horas y además se entregó por actualización automática a Windows x64 y Apple Silicon. Se informa de que bee-js 13.2.0 y anteriores, y Swarm Desktop 0.56.1, no están afectados. El mismo análisis dice que se apuntó al archivo de configuración del nodo Bee (que guarda una contraseña en texto plano) y a su clave de monedero, y que se abusó de credenciales usadas por la automatización oficial de publicación. Nuestra conclusión: reconstruya cualquier máquina o entorno de CI que instalara una versión afectada, mueva el monedero a una clave nueva y los fondos con él, y rote las credenciales desde otra máquina.
Explotado un fallo en el servidor MCP de mittwald, 56 proyectos de clientes comprometidos (noviembre de 2026): la cronología publicada y qué deben hacer los usuarios y los operadores de integraciones de IA
La empresa alemana de alojamiento web mittwald dijo en una entrada oficial de su blog que se explotó un fallo en su servidor MCP, que conecta los asistentes de IA de los clientes con su panel de control mStudio, y que 56 proyectos de clientes quedaron comprometidos. Según la empresa, el atacante probó el fallo por primera vez el 21 de octubre, empezó a actuar como un usuario normal con cuentas de prueba desde el 23 de octubre y explotó el fallo a las 15:03 del 27 de octubre usando otra cuenta. La empresa trata como comprometidos todos los datos desde el 27 de octubre en adelante. El 4 de noviembre se halló un comportamiento inusual y ese mismo día la empresa identificó el servidor MCP como punto de entrada y lo apagó. El 6 de noviembre examinó forensemente los 56 proyectos comprometidos y el servidor MCP, no halló más proyectos comprometidos y dice que actualmente no puede detectar actividad del atacante. No se leyeron contraseñas; lo que se leyó fueron los tokens de sesión de los usuarios, todos ellos revocados, dice. El centro de clientes y los sitios web gestionados allí no se vieron afectados. El servidor MCP sigue desconectado, y si vuelve se decidirá tras la investigación. La empresa dice que la velocidad del atacante sugiere el uso de herramientas de IA; es una sospecha de la empresa. Dice que publicará un relato detallado la semana siguiente. Nuestra opinión: en los servidores MCP que conectan asistentes de IA con entornos de alojamiento o de producción, lo esencial son tokens de alcance estrecho y corta duración y una supervisión capaz de detectar la fase de sondeo.
Incidente de seguridad de Trigger.dev (noviembre de 2026): claves de API root y variables de entorno al alcance del atacante en el 0,66 % de los clientes; regenere claves y rote secretos
Trigger.dev, una plataforma para ejecutar trabajos en segundo plano y agentes de IA, divulgó un incidente de seguridad el 1 de noviembre de 2026 y publicó un informe de seguimiento el 6 de noviembre. La empresa dice que las alertas de la infraestructura señalaron actividad anómala el 1 de noviembre, que la juzgó maliciosa y que bloqueó al atacante. El incidente afectó al 0,66 % de todos los clientes. El atacante obtuvo claves de API root de algunos entornos de clientes; una clave root da acceso total a la configuración de un entorno, incluidas sus variables de entorno. En algunos entornos el atacante también listó ejecuciones, despliegues y programaciones recientes, lo que devolvió ID, nombres de tareas, claves de idempotencia de ejecuciones, estado de las ejecuciones, etiquetas, metadatos y errores de despliegues, ID externos de programaciones y metadatos de ejecuciones. La empresa dice que no encontró pruebas de que se accediera a otros datos de clientes, a otros servicios, a sus propias bases de datos de producción ni a cuentas del panel de clientes. No revela el vector de ataque, para proteger la investigación y a los clientes. Los clientes afectados fueron contactados por correo (el 1 y el 2 de noviembre) y mediante un banner en el panel (sin indicar cuándo), y se revocaron las claves de API potencialmente afectadas. Los clientes afectados deben regenerar sus claves de API y rotar las credenciales de los entornos afectados, como contraseñas de bases de datos y claves de API de terceros, revocando las antiguas en el proveedor. La empresa dice que los clientes que no recibieron aviso de impacto no se vieron afectados, que los secretos de firma de webhooks no quedaron expuestos y que los despliegues autoalojados no se vieron afectados. Opinión de este sitio: compruebe primero el correo y el banner del panel y, si está afectado, regenere las claves y rote las credenciales como indica la empresa.
Incidente de seguridad de Northflank (octubre de 2026): variables de entorno almacenadas que se deben dar por descifradas y uso indebido de claves de API de IA
El 30 de octubre de 2026 (UTC), la plataforma de despliegue en la nube Northflank publicó un incidente de seguridad en su página de estado. Una alerta de amenaza de un proveedor de seguridad llegó a las 11:43 UTC; la empresa desplegó parches desde las 12:02 UTC, indicó a los clientes que rotaran las variables de entorno a las 13:40 UTC y, a las 13:58 UTC, que supusieran que todas las variables de entorno habían sido descifradas. A las 15:12 UTC su página de estado ya señalaba que varios usuarios informaban de que sus claves de IA se habían usado y, a las 23:38 UTC, decía que usuarios habían informado del uso no autorizado de claves de API de IA almacenadas en la plataforma. El 31 de octubre habilitó los registros de auditoría para todos los clientes y fue publicando la rotación de secretos de los complementos, un tipo cada vez. En una actualización del 2 de noviembre (11:09 UTC, estado Monitoring) dijo que cree haber contenido el ataque en la hora siguiente a la primera alerta, que las cargas de trabajo en ejecución no se vieron afectadas y que no ha visto señales de que se accediera a las cargas de trabajo ni a sus datos, y que el ataque parecía centrado en los secretos del plano de control. Auditores forenses independientes lo están revisando, revocó tokens de acceso, sesiones, integraciones con sistemas de control de versiones (VCS) y roles IAM entre cuentas (por lo que los usuarios deben volver a iniciar sesión y reconectar las integraciones), y prometió un análisis de causa raíz cuando se confirmen los hallazgos. En una actualización del 6 de noviembre (10:09 UTC) dijo que el primer descifrado conocido de secretos ocurrió entre las 02:39 y las 03:08 UTC del 30 de octubre, antes de su primera alerta de las 11:43 UTC; que el exploit se parcheó en los 60 minutos siguientes al aviso y que se notificó a los clientes en dos horas; que no ha encontrado pruebas de que se accediera a las cargas de trabajo de los clientes ni a sus datos; y que ha trabajado con proveedores previos para revocar credenciales cuando fue posible. La revisión forense sigue en curso. No se han revelado el número de clientes afectados, cómo entró el atacante ni qué proveedores de IA estuvieron implicados. Opinión de este sitio: revoque todos los secretos que guardó en Northflank en el servicio que los emitió, luego revise el uso y la facturación de cada proveedor de IA y fije límites de gasto.
Brecha de OpenCode Console (octubre de 2026, 1,4 % de los usuarios de Console): claves de API de proveedores de IA posiblemente expuestas, y qué hacer
El 17 de octubre de 2026, OpenCode, el agente de programación con IA de código abierto, dijo en su cuenta oficial de X que la noche anterior había sufrido una brecha de seguridad, relacionada con un ataque de destilación a gran escala, que afectó al 1,4 % de los usuarios de OpenCode Console. Dijo que esa mañana había enviado un correo a todos los usuarios afectados, que los usuarios que no recibieron el correo no estaban afectados y que los afectados eran un subconjunto que tenía proveedores externos vinculados. La empresa dijo que el incidente seguía en curso, que no podía dar más detalles y que estaba trabajando con los proveedores de IA implicados. Según informaciones de prensa sobre el correo y sobre declaraciones de la empresa, las claves de API de proveedores de IA externos que los usuarios habían guardado en workspaces de Console pueden haber quedado expuestas a través de un sistema antiguo, y se indicó a los usuarios afectados que revocaran y sustituyeran esas claves directamente con cada proveedor. Un cofundador dijo que la app de código abierto y la herramienta de línea de comandos no se vieron afectadas. La opinión de este sitio: si recibió el correo, o tenía claves de proveedores de IA vinculadas en OpenCode Console y no está seguro, revóquelas hoy en el panel de cada proveedor y revise el uso y la facturación desde el 17 de octubre.
Incidente de seguridad de Zeabur (octubre de 2026, 3,22 millones de variables de entorno leídas): qué secretos rotar y qué deben hacer los usuarios
El 19 de octubre de 2026, la plataforma de despliegue de aplicaciones Zeabur publicó un informe preliminar sobre un incidente de seguridad ocurrido el 14 y 15 de octubre (UTC). La empresa afirma que un atacante usó credenciales internas filtradas de Zeabur para entrar en su clúster compartido, en algunos Dedicated Servers y en sistemas internos, y que finalmente leyó la base de datos de la plataforma entre las 16:10 y las 16:47 UTC del 15 de octubre. Confirmó que se leyeron 3.218.965 registros de variables de entorno (nombres y valores) y datos de 321.810 cuentas (correo electrónico, nombre de usuario, número de teléfono y más), además de 566 claves de API de zSend, que ha revocado. La empresa dice que la causa de fondo es responsabilidad de Zeabur: credenciales de administración de larga duración se almacenaban en texto claro y podían usarse desde internet. Pide a todos los usuarios que sustituyan todas las contraseñas y claves almacenadas en Zeabur, aunque ya las hubieran sustituido tras otro incidente en agosto. Zeabur había anunciado el 17 de octubre que cerrará el 31 de diciembre de 2026, y el 22 de octubre fijó el 30 de noviembre de 2026 como plazo para reclamar pérdidas causadas por el incidente. La opinión de este sitio: trate cualquier secreto que haya puesto alguna vez en una variable de entorno de Zeabur como conocido por otra persona, revóquelo primero en el servicio que lo emitió y revise facturas y registros desde el 14 de octubre.
Posible exposición de variables de entorno en Railway (octubre de 2026, hasta el 1,85 % de los workspaces): qué secretos rotar y qué deben hacer los usuarios
El 21 de octubre de 2026 (UTC), Railway anunció que había detectado actividad anómala en los sistemas que almacenan las variables de entorno de los clientes, y que un tercero no autorizado pudo haber accedido a variables de entorno cifradas y, en el caso de algunas, haber obtenido su contenido descifrado. Según el informe preliminar fechado el 22 de octubre (disponible a las 16:38 UTC del 23 de octubre, según la página de estado), el ataque se extendió desde las 13:58 UTC del 20 de octubre hasta las 03:32 UTC del 22 de octubre. Comenzó con intentos de escalada de privilegios en la infraestructura de compilación; el 21 de octubre se usaron credenciales del entorno de CI y se descifró un subconjunto de variables de entorno cifradas. Como máximo el 1,85 % de todos los workspaces (unos 100 000 workspaces, según la empresa) tuvo algunas variables de entorno potencialmente comprometidas. La empresa afirma que no se accedió a ninguna cuenta de usuario de Railway y no ha descartado el acceso al código fuente hasta su informe final. Al parecer, el atacante buscaba claves de API de proveedores de IA. Railway recomienda que todos los usuarios roten los secretos almacenados antes del 21 de octubre, eliminen el acceso de red público a las bases de datos y revisen los registros de auditoría de GitHub y de registros de contenedores (como Docker Hub). Conclusión de este sitio: aunque no le hayan contactado, trate como expuestos los secretos almacenados en Railway, vuelva a emitirlos en su origen y vuelva a desplegar antes de revocar los valores antiguos.
LiteLLM 1.107.0 distribuyó un ladrón de credenciales (octubre de 2026): versión afectada en PyPI e imágenes de Docker, y qué deben hacer los usuarios
El 21 de octubre de 2026 (UTC), BerriAI, la empresa detrás de LiteLLM, anunció que su canal de publicación de versiones había sido comprometido y que se había publicado una v1.107.0 con malware que roba credenciales y carga herramientas de ejecución remota de código. Los afectados fueron litellm==1.107.0 en PyPI (de 11:39 a 13:23 UTC) y las etiquetas v1.107.0, latest, main-latest y main-stable en Docker Hub (de 11:46 a 14:20 UTC) y en GHCR (desde las 11:46 UTC hasta que se retiraron, a más tardar a las 13:51 UTC, unas dos horas). La etiqueta oficial v1.107.0 del código fuente en GitHub no contiene los archivos maliciosos; los artefactos se compilaron desde un repositorio imitación controlado por el atacante. Todas las versiones anteriores quedan fuera de esta vulneración, y la empresa pide a los usuarios fijar 1.106.2 u otra versión anterior explícita. El 24 de octubre (UTC) la empresa publicó 1.103.8, 1.104.6, 1.105.4 y 1.106.3, y desde estas versiones las imágenes de Docker y los charts de Helm se firman con una nueva clave de cosign (la clave anterior ya no las verifica). El 23 de octubre la empresa publicó un análisis de causa raíz y corrigió su primera hipótesis de que los tokens se habían obtenido de los registros de un despliegue interno de LiteLLM. Según el análisis, un archivo de configuración subido por error a un repositorio público el 27 de mayo contenía la clave maestra de una plataforma interna de agentes; la confirmación se sobrescribió, pero la clave nunca se revocó. El 10 de octubre el atacante usó esa clave para llamar a la API de la plataforma y obtuvo el token de GitHub CLI de un propietario de la organización de GitHub configurado allí. Con él, el atacante extrajo secretos de CI para obtener los tokens de otros dos mantenedores, y el 21 de octubre desactivó la protección de ramas, modificó el flujo de trabajo de publicación y aprobó la versión. Conclusión de este sitio: reconstruya todo entorno que haya instalado o iniciado 1.107.0 durante el periodo y rote todas las claves a las que pudo acceder, incluidas las claves de proveedores de LLM, la clave maestra del proxy, la contraseña de la base de datos y los roles en la nube.
Gusanos en la cadena de suministro de npm: cómo roban credenciales durante la instalación y cómo defenderse
Añadir una dependencia significa ejecutar código ajeno con tus privilegios, así que la defensa debe estar en el momento de la instalación. La opinión de este sitio: las firmas y la procedencia no detuvieron esta campaña, así que no pueden ser la base de la confianza. Lo que funciona es desactivar por defecto los scripts de instalación, dejar pasar unos días antes de adoptar una versión nueva y usar tokens de vida corta y alcance reducido. Y si sospechas una infección, el orden en que revocas importa.
Detén los secretos antes de hacerles commit con gitleaks: atrapa fugas de claves de API antes del push
Los secretos no se pueden «borrar después de que se filtran». Una vez con commit, un secreto se queda en el historial de Git, y una vez con push debe tratarse como filtrado — la clave necesita revocarse/rotarse. gitleaks es una herramienta gratuita que escanea todo el repo y el historial de commits con regex/entropía para encontrar claves de API, claves privadas y tokens. El núcleo de la defensa son dos comprobaciones: un hook de pre-commit que lo detiene localmente antes del push, y CI/cron que atrapa lo que se cuela. .gitignore solo evita el nuevo seguimiento — no puede detectar, así que aún necesitas un escáner.
¿Son seguros los gestores de contraseñas? Cómo funcionan, nube vs local y cómo elegir
Un gestor de contraseñas ayuda a usar una contraseña robusta y distinta para cada servicio. El cifrado de conocimiento cero está diseñado para proteger el contenido incluso si se filtran datos cifrados del proveedor, pero la seguridad también depende de la fortaleza de la contraseña maestra, la configuración de cifrado y la seguridad del dispositivo. Usa MFA para evitar accesos no autorizados y elige nube o local según el uso.
¿Dejaste un archivo de secretos en un directorio público? Audita tu webroot
Cualquier cosa en tu webroot puede descargarse por URL por cualquiera. Un JSON de token/credenciales olvidado, un .env o una copia de seguridad significa exposición instantánea — y si vino de una plantilla compartida, todos los sitios tienen el mismo archivo. Solución: coloca en el directorio público solo cosas compartibles públicamente, mantén los secretos fuera del webroot con permisos 600, y una vez que encuentres uno, audita cada sitio y servidor.
La base de seguridad para desarrolladores independientes y pequeños operadores: controles estándar en orden de prioridad
La base no es 'todo igual de importante'. El orden de prioridad de este sitio: 1) cuentas de administración, dominio y correo (MFA), 2) secretos y código, 3) la propia app, 4) parchear, detectar, recuperar. Con tiempo finito, complétala de arriba abajo. La mayoría de las brechas graves no vienen de ataques novedosos sino de que falta un control básico.
Inventario de seguridad: 7 comprobaciones que pasan por alto quienes operan varios servidores
Para operadores solos/pequeños, los incidentes vienen menos de controles ausentes que de estado sin seguimiento. La frontera es el PC que guarda tus claves. Prioriza el 2FA según qué cuenta permite recuperar las demás (el correo primero), anota qué clave SSH abre qué servidor y borra las claves duplicadas, las que no se usan y los registros sobrantes, quita las contraseñas en texto plano de la nube, remedia de forma reversible una a una, y mantén los secretos fuera del registro. Inventario antes de añadir herramientas.
Git autoalojado vs GitHub: ¿cuál es realmente más seguro?
Autoalojar Git no te hace 'más seguro' — reubica el riesgo. La clase de exposición pública accidental desaparece, pero parchear el servidor, las copias de seguridad y la detección de secretos pre-commit pasan a ti. La decisión correcta si sigues haciendo ese trabajo; peor que GitHub si lo descuidas. La visión de este sitio: el autoalojamiento solo funciona acompañado de sus controles compensatorios.
¿Es seguro guardar tus contraseñas en Google Drive? Cómo conservarlas correctamente
Guardar contraseñas en un Documento/Hoja de Google en texto plano es peligroso: una cuenta de Google se convierte en el punto único de fallo de cada contraseña — la toma de la cuenta, una app conectada maliciosa o el phishing las filtran todas de golpe. La opción más segura es un gestor de contraseñas dedicado (el contenido sigue cifrado incluso al sincronizar). Si debes usar Drive, guarda solo un archivo de bóveda cifrado y pon MFA resistente al phishing en la cuenta.
Filtración de Codecov (2021) — cuando una herramienta de CI fue manipulada y se filtraron secretos
Una herramienta de confianza del CI (el Bash Uploader curl|bash) fue alterada en origen. Como tu propio código quedó intacto, pasó ~2 meses inadvertida mientras se filtraban secretos del CI; una verificación de checksum lo detectó. En tu CI: verifica los artefactos descargados, secretos de mínimo privilegio, rotación, monitorización de salida.