crítica

CVE

CVE-2026-48815

CWE

CWE-506, CWE-494, CWE-295, CWE-347, CWE-200, CWE-829

Sistemas afectados

  • RubyGems, Bundler, and Fastlane users who installed or loaded `git_credential_manager` 2.8.0-2.8.3, `Dendreo` 1.1.3-1.1.4, or `fastlane-plugin-run_tests_firebase_testlab` 0.3.2 on developer workstations
  • Windows hosts that installed and executed the malicious NuGet DotnetTool packages tied to the `pepesoft.exe` downloader and Google-Sheets-backed surveillance control plane
  • Node.js build, release, admission, or artifact-validation paths that relied on `sigstore <= 4.1.0` with `certificateOIDs` to narrow signer trust policy

Bienvenido al boletín semanal de Corgea. El boletín recoge los hallazgos y las investigaciones de seguridad más importantes de la semana.

Esta edición cubre las investigaciones publicadas desde el miércoles 15 de julio hasta el martes 21 de julio de 2026, excluyendo los elementos ya tratados en el boletín del 14 de julio.

Artículo principal

SleeperGem: cuentas inactivas de RubyGems secuestradas convirtieron require en una puerta trasera persistente para desarrolladores

La historia más importante de esta semana es SleeperGem, porque combina el secuestro de cuentas de mantenedores inactivos, una propagación transitiva de confianza y una puerta trasera activada en el momento de require() que persiste en las máquinas de los desarrolladores. Aikido merece el crédito de la primera divulgación pública por mapear el compromiso de cuentas inactivas y la evolución del cargador versión por versión, mientras que StepSecurity merece el crédito del análisis en tiempo de ejecución por demostrar que la cadena posterior derivó hacia la ejecución normal de carga de bibliotecas, evitó muchos entornos de CI y plantó persistencia bajo ~/.local/share/gcm/. Esa combinación convierte a SleeperGem en la continuación más clara del compromiso de AsyncAPI, el infostealer en tiempo de importación de jscrambler y la cadena de RAT de polyfill en Rollup: el límite de confianza ya no es la instalación del paquete, sino la carga ordinaria de la biblioteca dentro de un flujo de trabajo de desarrollo.

Lo importante que hay que recordar es que el atacante no se detuvo en una simple gema falsa recién creada. Secuestró la confianza de mantenedores inactivos, volvió a publicar paquetes antiguos para propagar la dependencia maliciosa hacia grafos de Bundler ya existentes y, después, orientó la carga útil hacia estaciones de trabajo de desarrolladores en lugar de hacia CI. Esa propagación transitiva es la razón por la que los suscriptores deberían leer SleeperGem junto con la propagación multiecosistema de PolinRider, el skimmer de producción de Braintree.Net y la campaña de vigilancia de Pepesoft en NuGet de esta semana: los atacantes siguen ganando terreno al ocultar la ejecución dentro de herramientas y dependencias que los equipos ya consideran infraestructura normal del proyecto.

Más noticias

11 herramientas maliciosas de NuGet disfrazadas de trucos para videojuegos despliegan pepesoft.exe y vigilancia de hosts respaldada por hojas de cálculo

Esto merece una atención especial porque convierte la excusa de “es solo una herramienta de desarrollador” en una historia completa de compromiso de host. Socket merece el crédito de la primera divulgación pública y del análisis de ingeniería inversa por agrupar los once paquetes maliciosos DotnetTool, el cargador compartido pepesoft.exe y el plano de control respaldado por Google Sheets, mientras que CyberPress y CybersecurityNews merecen crédito por ampliar la concienciación pública sobre la campaña. En términos prácticos, esto se sitúa junto al skimmer de tarjetas en producción de Braintree.Net, la ola de typosquatting de Paysafe, Skrill y Neteller y el manual de juego de TeamPCP: los atacantes están abusando de herramientas auxiliares distribuidas mediante paquetes para obtener acceso directo a estaciones de trabajo y credenciales.

Lo más relevante es que los paquetes maliciosos no necesitaban camuflarse en un árbol de dependencias transitivas de una aplicación para ser peligrosos. En cuanto un usuario ejecutaba el comando instalado, la herramienta descargaba cargas útiles fuera del registro, heredaba la configuración de la nube a través de variables de entorno y exponía funciones de captura de pantalla y telemetría capaces de filtrar cualquier cosa visible en el host. Esto convierte a Pepesoft en una lectura complementaria útil junto con la persistencia en estaciones de trabajo de SleeperGem, la cadena en tiempo de importación de jscrambler y los señuelos de editor y repositorio de PolinRider.

CVE-2026-48815: sigstore-js eliminó las comprobaciones de certificateOIDs, debilitando la política de verificación de artefactos en JavaScript

La divulgación de vulnerabilidad pura más importante de esta semana es CVE-2026-48815, porque socava un control de confianza que muchos equipos probablemente creían ya aplicado. El aviso de GitHub acredita a Jvr2022, Str1ckl4nd y Zyy0530 como reportantes, mientras que Brian DeHamer, colaborador de sigstore, merece el crédito de autoría de la corrección al publicar el parche 4.1.1. El fallo se sitúa junto al compromiso de AsyncAPI y la anterior ola de AntV Mini Shai-Hulud como recordatorio de que una procedencia con apariencia válida y una política de confianza segura no son lo mismo.

La lección operativa es que la verificación de artefactos puede fallar silenciosamente cuando un parámetro de política documentado nunca llega al verificador real. Si una puerta de firma en JavaScript dependía de certificateOIDs, las decisiones de aprobación históricas pueden haber aplicado un conjunto de firmantes más amplio de lo que los revisores esperaban. Los suscriptores deberían considerarlo como el gemelo, del lado de la verificación, de las historias de la cadena de suministro anteriores: ya sea que la debilidad esté en la aplicación de políticas de Sigstore, en la ruta de publicación comprometida de AsyncAPI o en la ejecución en tiempo de importación de jscrambler, el fallo común es una confianza mal ubicada en la ruta de publicación normal.

Otras noticias:

De la investigación a la remediación

Comprueba si este patrón existe en tu código

Convierte esta investigación en un flujo de remediación. Analiza dependencias y manifiestos para detectar riesgos similares en la cadena de suministro y prioriza las correcciones con contexto de alcanzabilidad.