dependency management
7 artículos con esta etiqueta
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.
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.
osv-scanner en la práctica: pnpm, ignorar CVE, modo sin conexión y los errores que te encuentras
Solo las preguntas del segundo día, respondidas según la documentación oficial. pnpm-lock.yaml está soportado; las exclusiones van en osv-scanner.toml bajo IgnoredVulns y pueden llevar fecha de caducidad; el modo sin conexión son tres opciones con tres funciones distintas. La visión de este sitio: un escáner informa de vulnerabilidades conocidas y no dice nada de que una versión que fijaste tú mismo se haya quedado antigua; para eso hace falta otro mecanismo.
Seguridad de Express (Node.js) — una referencia de hardening para producción
Express es minimalista — casi no protege nada por defecto, así que las defensas las añades tú. Esta es una referencia práctica: (1) una lista de comprobación de hardening ordenada por prioridad (P0–P2), (2) guía por área — cabeceras de seguridad (helmet) + desactivar x-powered-by, CVE de dependencias npm, validación de entrada e inyección (SQL/operador NoSQL), autenticación y autorización acotada al propietario, limitación de tasa y topes de tamaño, sesiones/cookies/CSRF, SSRF, manejo de errores en producción (sin exponer la pila), NODE_ENV, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.
Seguridad de Next.js — una referencia de endurecimiento para producción
Los valores por defecto de Next.js son bastante seguros, pero los incidentes ocurren en la frontera servidor/cliente. Esta es una referencia de trabajo: (1) una lista de verificación de endurecimiento ordenada por prioridad (P0–P2), (2) guía por área — la frontera y las variables de entorno (NEXT_PUBLIC_), los CVE de dependencias (incluido RCE del núcleo), autorización + validación de entrada en Server Actions / Route Handlers, SSRF en las peticiones del lado servidor, cabeceras de seguridad/CSP, autenticación/sesión/cookies, limitación de tasa, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.
Seguridad en Ruby on Rails — una referencia de endurecimiento para producción
Rails trae convenciones y valores por defecto seguros (protección CSRF, Strong Parameters, un ORM), pero los incidentes de producción vienen de la operación. Esta es una referencia de trabajo: (1) una lista de endurecimiento ordenada por prioridad (P0–P2), (2) guía por área — secretos y credentials (master key/secret_key_base), configuración de producción (force_ssl, sin exposición de excepciones), CVE de gems, Strong Parameters/Mass Assignment, autorización (Pundit, alcance de propietario), inyección y métodos peligrosos (interpolación en where/send/constantize), sesiones/cookies/CSRF, SSRF/subidas, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.
Seguridad de Spring Boot — una referencia de hardening para producción
Spring Boot es un framework estable, pero los incidentes vienen de las dependencias, la configuración y la autorización. Esta es una referencia práctica: (1) una lista de comprobación de hardening ordenada por prioridad (P0–P2), (2) guía por área — CVE de dependencias (de tipo Log4Shell, juzgados por la versión en ejecución), configuración de producción y secretos externalizados, autorización con Spring Security (denegación por defecto/seguridad a nivel de método/comprobaciones de propietario), reducción de la exposición de Actuator/gestión, deserialización insegura, inyección, cabeceras/CSRF/sesión, SSRF, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.