TL; DR
Entre el 6 y el 7 de mayo de 2026, un único editor de npm, pelavelle, impulsó ocho paquetes sin dependencias utilizando nombres que seguían el mismo patrón de apariencia interna: 24712-pl*.
Los paquetes incluían 24712-pl3469, 24712-pl4712, 24712-pl5006, 24712-plv2, y 24712-plv3. El prefijo numerado sugiere fuertemente un ataque de confusión de dependencias de npm en contra de un espacio de nombres de paquete interno o un esquema de ID de paquete.
Los ocho paquetes hermanos ya habían sido retirados de npm por el editor entre 2026-05-06T21:52Z y 2026-05-07T00:31ZLos metadatos del registro directo confirmaron que los archivos tar ahora devuelven HTTP 404.
Sin embargo, el clúster sigue siendo importante.
La muestra canónica, 24712-pl5006:0.0.1, contiene una postinstall.js script que se ejecuta durante npm installEn lugar de robar variables de entorno genéricas, busca específicamente AWS_LAMBDA_RUNTIME_API, la variable de entorno utilizada por los entornos de ejecución de AWS Lambda.
Si el script encuentra AWS_LAMBDA_RUNTIME_API, llama al punto final de la API de Lambda Runtime:
Esa llamada intenta consumir el siguiente evento de invocación de Lambda pendiente antes de que el controlador de Lambda legítimo pueda procesarlo.
El evento capturado, que incluye encabezados, ID de solicitud, contexto de cuenta y hasta 8 KB de cuerpo de solicitud, se envía a un punto final de comunicación remota controlado por el atacante a través del script. phoneHome() función.
El sistema de alerta temprana de malware (MEW) de Xygeni clasificó la muestra canónica como probablemente maliciosa con una puntuación de 91.3/100.
Estamos haciendo un seguimiento de esto como un ataque de confusión de dependencias de npm con comportamiento de secuestro de tiempo de ejecución de AWS Lambda.
El clúster: ocho paquetes, un editor
La cuenta del editor pelavelle Se utilizó la dirección de correo electrónico:
La cuenta tenía un correo electrónico no verificado, no SCM verificación y una baja puntuación de reputación de 5.
El editor lanzó ocho paquetes relacionados en un breve lapso entre el 6 de mayo de 2026 a las 20:45Z y las 22:36Z. Los nombres de los paquetes siguen todos el mismo formato:
Este patrón es la señal clave. No parece una utilidad pública para desarrolladores. Más bien, parece un esquema interno de nomenclatura de paquetes.
| # | PREMIUM | Versión maliciosa | Creado, UTC | Sin publicar, UTC | Carga útil confirmada | Instalar gancho |
|---|---|---|---|---|---|---|
| 1 | explorador del cosmos | 1.1.3 | 2026-05-01T18:26Z | 2026-05-01T19:01Z | Inferido, mismo editor/clúster | preinstalación, presumida |
| 2 | SignalSDK-web | de 1.0.0 | 2026-05-04T13:57Z | 2026-05-04T18:51Z | Inferido | preinstalación, presumida |
| 3 | ms.analytics-web | de 99.0.0 | 2026-05-04T18:47Z | 2026-05-05T10:07Z | Inferido | preinstalación, presumida |
| 4 | iconos.generados | 99.9.13 | 2026-05-05T10:02Z | 2026-05-05T12:57Z | Inferido | preinstalación, presumida |
| 5 | seguimiento de latencia | 99.9.0 | 2026-05-05T11:57Z | 2026-05-05T12:57Z | Inferido | preinstalación, presumida |
| 6 | seguimiento de latencia interno | Versiones eliminadas del registro | 2026-05-06T06:02Z | 2026-05-06T08:35Z | Inferido | preinstalación, presumida |
| 7 | aplicación carbonita | 99.9.0 | 2026-05-06T05:49Z | 2026-05-06T08:35Z | Sí, flujo de código de escáner completo | preinstalación: node index.js |
| 8 | carbonita interna | 99.9.0 | 2026-05-06T06:14Z | 2026-05-06T08:36Z | Sí, flujo de código de escáner completo | preinstalación: node index.js |
Versiones totales en todo el clúster: 19 tuplas de paquete de versión.
La muestra canónica, 24712-pl5006:0.0.1, fue publicado el 06-05-2026T22:36:34Z y escaneado por MEW de Xygeni pipeline antes del evento de despublicación.
Contenía cuatro archivos, entre ellos: package/postinstall.js, con un total de 3,335 bytes de código fuente.
El canonico commit El hash era:
Por qué importa el patrón del nombre
Los nombres de los paquetes son el indicador más fiable de la intención.
Todos empiezan con el mismo prefijo:
Luego añaden sufijos numéricos o similares a versiones:
Esto no se parece a la nomenclatura pública habitual de npm. Parece un prefijo de espacio de nombres interno o un esquema de identificador de paquete interno.
Eso hace que el grupo sea consistente con un ataque de confusión de dependencias de npm.
En un ataque de confusión de dependencias, el atacante publica un paquete público con un nombre que coincide, o parece coincidir, con una dependencia interna. Si el gestor de paquetes o el entorno de compilación del objetivo resuelve el paquete público en lugar del privado, el código controlado por el atacante se ejecuta dentro del entorno objetivo.
OWASP describe la confusión de dependencias como un vector de ataque que engaña a los gestores de paquetes y a los servidores proxy para que descarguen un paquete público malicioso en lugar del paquete interno previsto del mismo nombre.
Para obtener un contexto más profundo sobre cómo funciona esta clase de ataque, consulte la guía de Xygeni sobre falta de fijación de versiones y confusión de dependencias y nuestra publicación sobre identificar y gestionar ataques de dependencia de software.
¿Qué sucede durante la instalación?
El paquete canónico declara un postinstall gancho:
El postinstall El ciclo de vida forma parte del sistema de scripts de paquetes de npm. La documentación de npm explica que los paquetes pueden definir scripts de ciclo de vida en package.json, incluyendo eventos integrados del ciclo de vida de la instalación.
El || true es importante.
Ignora los errores, por lo que la instalación se completa con éxito incluso si el secuestro falla. Esto ayuda a que el paquete no interrumpa la compilación y reduce la probabilidad de que los desarrolladores o los sistemas de integración continua detecten el comportamiento malicioso a través de una instalación fallida.
La carga útil se ejecuta durante npm installNo se requiere ninguna importación por parte del desarrollador. Ninguna ruta de la aplicación tiene que llamar al paquete.
La instalación en sí es suficiente.
Comportamiento de la carga útil: Secuestro del entorno de ejecución de Lambda
El postinstall.js El script ejecuta una secuencia específica.
Primero, lee el entorno del proceso padre desde Linux. /proc:
Luego extrae el punto final de ejecución de AWS Lambda:
Si se encuentra la API de tiempo de ejecución, el script la almacena:
A continuación, envía una primera baliza a través de phoneHome():
Esa primera señal filtra el punto final de la API de tiempo de ejecución de Lambda.
A continuación, el script analiza el host y el puerto de la API de tiempo de ejecución:
Finalmente, llama a la ruta de la API de AWS Lambda Runtime que se utiliza para recuperar la siguiente invocación:
Esa es la esencia del ataque.
El script intenta consumir el siguiente evento de invocación de Lambda antes de que el controlador de Lambda legítimo pueda procesarlo. La guía de tiempo de ejecución personalizado de AWS también describe el paso de "obtener un evento" como una llamada a la API de siguiente invocación.
¿Qué se exfiltra?
Si el script detecta una invocación, envía el resultado al punto final de comunicación remota controlado por el atacante.
Los campos exfiltrados incluyen:
| Campo | Significado |
|---|---|
step | Etapa de ejecución, como por ejemplo: waiting, next_error, o captured |
runtimeApi | Punto final de la API de tiempo de ejecución de Lambda |
accountSid | Contexto de la cuenta de AWS capturado |
requestId | ID de solicitud de invocación de Lambda |
isOwnAccount | Comparación booleana con el valor de cuenta configurado en el script. |
statusCode | Estado de respuesta de la API en tiempo de ejecución |
headers | Encabezados de respuesta de invocación |
body | Cuerpo de invocación capturado, dividido en 8,000 caracteres. |
La llamada de exfiltración clave es la phoneHome(data) función que codifica los datos en formato JSON y los envía mediante una solicitud HTTP POST.
La URL exacta de destino de la comunicación con el servidor de origen no se conservó en la evidencia truncada disponible. Por lo tanto, npm debería conservar internamente el archivo tarball no publicado para que se pueda extraer el literal del host C2 antes de que se finalice la eliminación.
¿Por qué esto es peligroso?
Esto no es una baliza genérica de npm.
La carga útil está diseñada en torno a AWS Lambda modelo de ejecución.
Si se instala un paquete vulnerable dentro de un entorno de ejecución de Lambda, como durante la creación de una imagen de despliegue, la instalación de una capa de Lambda o un proceso de envoltura de inicialización, el entorno puede quedar expuesto. AWS_LAMBDA_RUNTIME_API.
Una vez que el script tenga ese valor, podrá llamar a:
Ese punto final devuelve el siguiente evento de invocación pendiente.
Como resultado, el atacante podría capturar:
- Órganos de solicitud
- Cabezales
- Identificadores de solicitud
- Contexto de la cuenta de AWS
- Datos de solicitud firmada
- PII del cliente
- Datos de eventos S3
- Cargas útiles específicas de la aplicación
- Contexto de servicio interno
Es posible que el gestor legítimo nunca vea el evento consumido.
Eso convierte un script de instalación de npm en una primitiva de intercepción de eventos de Lambda.
Aunque el paquete nunca se implemente en un entorno Lambda real, su comportamiento aún puede filtrar contexto útil de los sistemas de desarrollo o CI. /proc/<pid>/environ puede exponer variables de entorno presentes en los procesos principales, que pueden incluir claves de AWS, URL de bases de datos, tokens de CI o credenciales de implementación.
Por eso, el análisis de dependencias no puede limitarse a las vulnerabilidades CVE conocidas. Los equipos también necesitan detección de paquetes maliciosos, análisis de scripts de instalación y aplicación de políticas de registro. Para obtener orientación relacionada, consulte Por qué el análisis de dependencias es importante para los equipos de DevOps y Protección contra malware: ¿Por qué los antivirus no pueden detener los ataques a la cadena de suministro?.
Clasificación MEW de Xygeni
Xygeni MEW escaneó la muestra canónica 24712-pl5006:0.0.1 antes del evento de despublicación.
El escáner devolvió:
Las pruebas incluían tres elementos críticos y un elemento de alta prioridad que confirmaban el flujo de datos de secuestro en tiempo de ejecución de Lambda.
| Gravedad | Evidencia | Significado |
|---|---|---|
| Critical | /proc/<pid>/environ read | Lee el entorno del proceso padre |
| Critical | AWS_LAMBDA_RUNTIME_API Extracción | Punto final de tiempo de ejecución de Lambda de destino |
| Critical | /runtime/invocation/next solicita | Intenta consumir un evento de invocación Lambda real. |
| Alto | postinstall guión | Se ejecuta durante la instalación de npm. |
El comportamiento es muy específico y de gran impacto. El paquete no necesita características de malware generales, ya que el punto final de ejecución de Lambda ya es un objetivo potente.
Xygeni MEW está diseñado para este tipo de casos: detectar comportamientos sospechosos y maliciosos de paquetes antes de que se conviertan en un incidente posterior. Para una visión más amplia de los patrones de amenazas actuales de npm y PyPI, consulte Una mirada más cercana a los ataques a la cadena de suministro de software en 2025.
Por qué importa el patrón de autodespublicación
Los ocho paquetes fueron retirados del mercado por la editorial en un breve plazo de tiempo.
Ese comportamiento resulta sospechoso en este contexto.
El clúster aparecía, se ejecutaba si se seleccionaba mediante una ruta de resolución de dependencias vulnerable y luego desaparecía. Esto concuerda con la estrategia de limpieza que realiza el atacante tras una prueba de concepto exitosa o fallida, o después de que la organización objetivo detectara el problema.
La eliminación de la publicación crea una brecha de visibilidad para los defensores.
Es posible que los datos públicos de npm ya no incluyan los archivos tar. Algunas versiones de paquetes no se pueden volver a descargar. Sin embargo, los entornos afectados aún pueden tener copias en caché, referencias a archivos de bloqueo, registros de CI o artefactos del gestor de paquetes.
Por eso es importante la preservación en el registro.
npm debería conservar internamente los archivos tar no publicados el tiempo suficiente para extraer la URL exacta de conexión remota, confirmar la identidad de la carga útil relacionada y facilitar la respuesta ante incidentes.
Indicadores de compromiso y detección
Editor y cuenta
| Campo | Valor |
|---|---|
| nombre de usuario de npm | pelavelle |
| Correo electrónico del editor de npm | pelavelle@clovercode.com |
| Correo Electrónico Verificado | No |
| SCM verificadas | No |
| Puntuación de reputación del editor | 5 |
| Patrón de nomenclatura de paquetes | ^24712-pl[0-9a-z]+$ |
| prefijo de espacio de nombres interno | 24712-pl |
Nombres de paquetes afectados
Muestra canónica
| Campo | Valor |
|---|---|
| PREMIUM | 24712-pl5006 |
| Versión | 0.0.1 |
| Publicado | 2026-05-06T22:36:34Z |
| Commit hachís | 83e0efbfd110abb2398a06196fb698565a3f6cc6 |
| UUID de escaneo de Xygeni | f80e4244-86d2-4a58-be59-7c56988a0f9f |
| Puntuación | 91.3 / 100 |
| Veredicto | probablyMalicious |
Instalar gancho
Indicadores de tiempo de ejecución de Lambda
Campos de carga útil exfiltrada
El texto se divide en 8,000 caracteres.
Notas de detección
Varias reglas pueden detectar esto ataque de confusión de dependencias de npm y posibles variantes.
Primero, marque los scripts de instalación de npm que leen el entorno del proceso padre desde /proc:
Ese comportamiento rara vez es legítimo para una dependencia de npm durante la instalación.
Segundo, alertar sobre los scripts de instalación de paquetes que hacen referencia a:
Esta variable de entorno no debe ser accedida por paquetes npm de terceros durante la instalación.
En tercer lugar, bloquee o revise los scripts de instalación que llaman a:
Este es el punto final de la API de AWS Lambda Runtime para recibir la siguiente invocación. Un script de instalación de dependencias no tiene ninguna razón legítima para consumirlo.
En cuarto lugar, busque referencias en los archivos de bloqueo a los nombres de los paquetes afectados:
Cualquier coincidencia debería desencadenar una revisión de posibles conflictos de dependencias.
Quinto, alerta sobre la expresión regular del nombre del paquete:
especialmente cuando la editorial es pública, tiene poca reputación, no está verificada o está fuera del registro interno previsto.
Finalmente, agregue CI/CD guardrails alrededor de los scripts de instalación. Esto es especialmente importante porque los scripts del ciclo de vida de npm pueden ejecutarse durante la instalación del paquete, antes de que los desarrolladores importen algo. Para obtener más información sobre CI/CD patrones de detección, ver Xygeni Los 10 principales indicadores de compromiso en CI/CD Pipelines y Seguridad Guardrails por la CI/CD Pipelines.
Acciones sugeridas para el registro
Este grupo de datos ya no estaba publicado en el momento de la elaboración del informe, pero su publicación no elimina el riesgo.
Acciones recomendadas en npm:
- Confirme si las eliminaciones de publicaciones fueron una limpieza iniciada por el atacante o una acción legítima del mantenedor.
- Suspender o bloquear la cuenta del editor.
pelavelle. - Agregar
pelavelle@clovercode.com, los nombres de los paquetes y la expresión regular del nombre del paquete para el abuso de npm y las listas negras de la cadena de suministro. - Conserve los archivos comprimidos no publicados en un almacén interno para su análisis forense.
- Extraer el exacto
phoneHome()URL de destino de los archivos tarball del paquete conservado. - Confirme si todos los paquetes hermanos comparten la misma carga útil.
- Notifique a las organizaciones afectadas si la telemetría de descarga o instalación del paquete indica exposición.
Lista de verificación de respuesta ante un compromiso
Si aparece algún paquete afectado en los archivos de bloqueo, los registros de CI, las cachés de paquetes, las capas de Lambda, las imágenes de implementación o los artefactos de compilación, considérelo como un posible evento de ejecución de confusión de dependencias.
Respuesta recomendada:
- Identifique dónde se instaló el paquete: estación de trabajo local, ejecutor de CI, compilación de la capa Lambda, imagen de implementación o entorno de ejecución.
- Conservar los archivos de bloqueo, la caché de npm, los registros de compilación, los artefactos de despliegue y las capas de imágenes de contenedores.
- Compruebe si la instalación se produjo dentro de un entorno donde
AWS_LAMBDA_RUNTIME_APIse estableció. - Revise los registros HTTP salientes para detectar información desconocida.
phoneHome()destinos durante la ventana de instalación. - Revisa los registros de invocación de Lambda para detectar eventos descartados, faltantes o anómalos.
- Rotar los secretos expuestos al entorno de instalación, especialmente las claves de AWS, los tokens de CI, las credenciales de implementación y las URL de la base de datos.
- Revise las capas Lambda y las imágenes de implementación para las copias en caché del paquete.
- Imponga la fijación de registros privados para prefijos de paquetes internos.
- Bloquear la resolución pública de npm para nombres de paquetes de apariencia interna.
- Agregar guardrails por la
preinstall,install, ypostinstallscripts.
Cómo Xygeni ayuda a detectarlo antes
Esta campaña es precisamente el tipo de caso en el que los equipos de seguridad necesitan algo más que el escaneo de vulnerabilidades tradicional.
Puede que no haya CVEEs posible que no exista ninguna versión vulnerable conocida. Es posible que no haya ningún paquete de larga duración que inspeccionar después de que el editor realice la limpieza.
En cambio, los equipos necesitan visibilidad en tiempo real del comportamiento de los paquetes.
Xygeni ayuda combinando:
- Detección temprana de malware en registros públicos.
- Detección de dependencias sospechosas para evitar confusiones de dependencias y typosquatting.
- Análisis del script de instalación para
preinstall,install, ypostinstallcomportamientos - CI/CD guardrails para bloquear los paquetes de riesgo antes de que lleguen a los entornos de compilación o implementación.
- Visibilidad de la cadena de suministro de software en todas las dependencias, pipelines y artefactos.
- Aplicación de políticas para nombres de paquetes internos y paquetes públicos no confiables.
Eso importa porque el impacto de un ataque de confusión de dependencias de npm No se limita a los portátiles de los desarrolladores. Puede llegar a los ejecutores de CI, imágenes de compilación, capas Lambda, contenedores de despliegue y entornos adyacentes al tiempo de ejecución.
Para obtener un contexto más amplio sobre seguridad de aplicaciones y cadena de suministro, consulte Beyond SCA: Cómo proteger su cadena de suministro de software y Software Supply Chain Security Automatización .
Lo que los defensores deben tener en cuenta
Esta campaña demuestra cómo la confusión en las dependencias puede ir más allá de las balizas básicas de prueba de ejecución.
La carga útil no se limita a confirmar que npm install Se ejecutó. Intenta interactuar con la API de AWS Lambda Runtime y capturar un evento de invocación real.
Eso supone una escalada significativa.
Para los equipos que utilizan arquitecturas sin servidor, la resolución de dependencias forma parte del modelo de amenazas en tiempo de ejecución. Un paquete npm público con un nombre que parezca interno puede convertirse en una puerta de entrada al contexto de ejecución de Lambda, los datos de la solicitud y los metadatos de la cuenta en la nube.
La lección principal es clara: los prefijos de paquetes internos deben estar protegidos, delimitados y anclados a registros de confianza. Los scripts de instalación deben tratarse como una superficie de ataque ejecutable, especialmente en CI/CDcompilaciones de contenedores, capas Lambda y despliegue pipelines.
CISLas directrices de A para la cadena de suministro de software enfatizan la necesidad de proteger el software, aplicar controles de seguridad y responder a las vulnerabilidades de forma continua a lo largo del proceso de desarrollo. En este caso, esto significa tratar la resolución de paquetes, los scripts de paquetes y los entornos de compilación sin servidor como controles de seguridad de primera clase.
Se ha informado a npm para la aplicación de las normas a nivel de cuenta, la inclusión en listas negras y la preservación de los archivos tar no publicados.
