Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- En diciembre de 2025, un paquete publicado en un segmento de espacio de nombres distinto al de Jackson proporcionó Cobalt Strike desde Maven Central; no hubo ningún CVE relacionado.
- Maven Central verifica el control del dominio o la cuenta de alojamiento de un espacio de nombres, no ninguna relación con el proyecto al que se asemeja.
- Los artefactos publicados a través de Maven Central incluyen firmas PGP, y Maven no las verifica de forma predeterminada.
- En noviembre de 2025, un paquete npm comprometido llegó automáticamente a Maven Central a través del sistema de réplicas de mvnpm.
La mayor parte del debate sobre la cadena de suministro de Java desde el caso Log4Shell se ha centrado en un tipo concreto de problema: una vulnerabilidad presente en código legítimo. Pero, en diciembre de 2025, surgió algo diferente. Un ataque de suplantación de espacio de nombres introdujo un cargador de Cobalt Strike en Maven Central utilizando coordenadas que sustituían un único segmento de las coordenadas reales de Jackson.
No se aprovechó nada. No hubo ninguna vulnerabilidad. Alguien registró un espacio de nombres, publicó un artefacto y esperó a que se copiaran las coordenadas erróneas.
La seguridad de Maven Central no se limita únicamente a la falta de verificación de firmas, como suele pensarse. También supone un problema de espacios de nombres, y la mayoría de las herramientas de Java no detectan ninguno de los dos.
¿Qué ocurrió realmente con el paquete falso de Jackson?
El funcionamiento es tan sencillo que se puede explicar en una sola frase, y precisamente por eso funcionó.
Jackson 2.x se publica bajo com.fasterxml.jackson.core:jackson-databind. Aikido Security, que detectó el paquete el 25 de diciembre, documentó el artefacto malicioso como org.fasterxml.jackson.core con el mismo jackson-databind artifactId, por lo que toda la cadena de coordenadas presentaba un desfase de tres caracteres. Se supone que la nomenclatura de dominio inverso evita esto y, en sí misma, cumplió lo que prometía. Maven Central confirmó que el editor controlaba un dominio que coincidía con el espacio de nombres. Ese dominio era fasterxml.org, registrado a través de GoDaddy el 17 de diciembre de 2025, ocho días antes del análisis, y prácticamente idéntico al verdadero fasterxml.com. La verificación de la titularidad funcionó correctamente. Simplemente verificó lo que no debía.
La carga útil no consistía en un simple ataque rápido para robar datos. Una vez desofuscada, se descubrió que la clase era una configuración automática falsa de Spring Boot, y los investigadores que la examinaron ha encontrado un diseño de varias etapas: Cadenas de configuración cifradas con AES que se desbloquean con una clave predefinida, un @Configuration clase anotada con @ConditionalOnClass(ApplicationRunner.class) para que Spring lo registrara y ejecutara la carga útil una vez cargado el contexto de la aplicación: un marcador de persistencia camuflado como un archivo de IntelliJ y la identificación de la plataforma antes de que se enviara ningún tráfico de comando y control. Los hosts de Windows descargaron svchosts.exe, un «typosquat» del verdadero svchost.exe proceso. Los equipos con Linux y macOS contenían archivos binarios que casi todos los motores de análisis de VirusTotal identificaron como balizas de Cobalt Strike, el marco comercial de «red team» cuyas versiones filtradas son ampliamente utilizadas por los operadores de ransomware y los grupos APT.
Una vez que se denunció el paquete, Maven Central lo retiró en unos noventa minutos, lo cual supone una respuesta rápida para un registro público. Esa rapidez no ayuda a los proyectos que lo detectaron mientras estaba activo, y no dice nada sobre cómo funcionaría una versión más discreta del mismo truco. Una baliza de Cobalt Strike muy llamativa acaba siendo detectada. Algo diseñado para permanecer inactivo y extraer información lentamente podría permanecer en su sitio mucho más tiempo.
Cómo funciona la suplantación de espacio de nombres en Maven Central
Maven identifica las dependencias mediante tres coordenadas: groupId, artifactId y version.
La norma establece que el «groupId» es un dominio invertido controlado por el editor, y Maven Central garantiza el cumplimiento de esta norma en el momento del registro exigiendo una prueba de control sobre el dominio o sobre la cuenta de alojamiento de código vinculada a él. Esa verificación es real y funciona exactamente como se ha diseñado.
Simplemente no hace lo que la gente cree que hace. Demostrar que se tiene el control de un dominio no dice nada sobre si el editor tiene alguna relación con el proyecto al que se asemeja el nombre de dominio. Solo confirma el control de un dominio, y un dominio similar cuesta unos pocos dólares.
El espacio de nombres real de Jackson junto a tres patrones que cualquiera podría registrar, ninguno de los cuales es el que se utiliza aquí.
| Estampado a rayas | Parece legítimo porque | ¿Qué es lo que realmente se verifica? |
|---|---|---|
com.fasterxml.jackson.core |
Es el espacio de nombres real | Control de dominios mediante FasterXML |
io.fasterxml.jackson |
El dominio inverso «.io» es habitual en el software libre | El control del dominio recae en quien lo haya comprado |
com.fasterxml-jackson.core |
Un guion; a simple vista se lee igual | El control del dominio recae en quien lo haya comprado |
org.jackson.databind |
Coincide con el nombre del proyecto | El control del dominio recae en quien lo haya comprado |
En io.fasterxml.jackson, com.fasterxml-jackson.core, y org.jackson.databind Todas las variantes son accesibles de forma legítima, sin que se vea comprometido nada en ningún momento. En el incidente de Jackson se utilizó una versión más limitada de la misma idea: no se empleó un guion ni un TLD diferente, sino que se cambió un único segmento de primer nivel, pasando de «com» a «org», junto con un dominio registrado específicamente para que ese cambio superara la verificación.
Las coordenadas suelen copiarse de respuestas de Stack Overflow, entradas de blog y fragmentos generados por IA, en lugar de escribirse de memoria, lo cual es una de las razones por las que esto resulta más difícil de detectar en Java que en los paquetes de npm. Un desarrollador que haya instalado axios cincuenta veces se da cuenta inmediatamente de que hay un «axois». Casi nadie se sabe de memoria el groupId de Jackson, y son aún menos los que se darían cuenta de que falta un segmento en una cadena de cuarenta caracteres que están pegando en lugar de leer.
Copiar las coordenadas de una página de resultados de búsqueda en lugar de la propia documentación del proyecto abre otra puerta a la confusión con los espacios de nombres. Vale la pena romper con ese hábito, independientemente de cómo se haya desarrollado este incidente en concreto.
La brecha de seguridad de Maven Central que nadie comprueba
Esta es la parte que sorprende a los desarrolladores de Java que no lo han analizado con detenimiento, y se trata de un problema distinto al anterior.
Maven Central no aceptará ninguna versión que no cuente con una firma PGP. Todos los artefactos publicados a través de Central incluyen una .asc el archivo que hay junto a él, además de las sumas de comprobación, y los requisitos de publicación son más estrictos que los de npm o PyPI. Eso es una auténtica ventaja.
Maven no verifica esas firmas de forma predeterminada.
Ejecutar mvn install En un proyecto con doscientas dependencias transitivas, Maven descarga doscientos archivos JAR y compara las sumas de comprobación que se encuentran junto a ellos. Por defecto, una discrepancia solo genera una advertencia; para que la compilación falle por una sola discrepancia se necesita -C, o un checksumPolicy de error en el repositorio. En cualquier caso, el .asc Los archivos que se encuentran junto a esos JAR nunca se modifican, a menos que un complemento los solicite.
La validación de la suma de comprobación y la verificación de la firma se tratan como si fueran intercambiables, pero no lo son. Una suma de comprobación confirma que el archivo recibido coincide con el que ofrece el repositorio. Una firma válida demuestra que el artefacto se firmó con una clave privada concreta, y se necesita una asignación de claves de confianza para vincular esa clave a un editor en el que se pueda confiar. Maven realiza lo primero de forma predeterminada y omite por completo lo segundo.
Esto es importante para determinar qué habría ayudado y qué no en este caso. El atacante controlaba fasterxml.org y podía firmar con su propia clave, por lo que la verificación de la firma también habría superado el control en el paquete malicioso. La comprobación de la firma demuestra que un archivo no ha sufrido modificaciones desde que fue firmado por el titular de dicha clave. No dice nada sobre si ese editor es quien indica el espacio de nombres. Dos problemas, dos soluciones.
Gradle lleva la delantera a Maven en este aspecto, y la mayoría de los equipos aún no lo han activado.
./gradlew --write-verification-metadata sha256,pgp helpEso inicia un verification-metadata.xml archivo a partir de lo que resuelva Gradle, y el proceso de arranque es la parte por la que merece la pena ralentizar el proceso. Es deliberadamente optimista. Las claves que se verifican correctamente se añaden automáticamente a la lista de confianza, los artefactos sin firma válida recurren a las sumas de comprobación, y cualquier elemento ya comprometido en tu árbol se aprueba durante el proceso. Lee las sumas de comprobación y las claves de confianza generadas antes de confirmar el archivo. Una vez revisada esa línea de base, Gradle rechaza la compilación ante cualquier elemento que deje de coincidir, lo que supone un control riguroso y no supone una carga excesiva en un proyecto sencillo.
Maven no tiene ningún equivalente en el núcleo. La verificación requiere un complemento.
mvn org.simplify4u.plugins:pgpverify-maven-plugin:1.19.1:checkEsto verifica las firmas de las dependencias y admite una lista explícita de claves, de modo que solo las claves de firma que se especifiquen se considerarán de confianza. Funciona, y no es lo que se obtiene por defecto.
El problema «artefacto frente a código fuente» subyace en ambos controles, ya que un JAR es el resultado de una compilación y nada obliga a que coincida con el repositorio de código fuente al que está vinculado un proyecto. Un escáner que lee el binario publicado ve lo que el editor haya decidido incluir en él, esté firmado o no. Recompilar a partir del código fuente verificado es lo que te proporciona una verificación independiente de lo que se ha incluido en un artefacto, en lugar de confiar en el binario del editor, y SecureChain for Java se basa precisamente en esa premisa.
MavenGate y el problema de las coordenadas abandonadas
MavenGate, publicado por investigadores de Oversecured en enero de 2024, describía una vía diferente para alcanzar un resultado similar, y podría decirse que es la más preocupante, ya que no requiere suplantación de identidad alguna.
Esta técnica se centra en las dependencias abandonadas. Una biblioteca publicada hace años bajo com.oldcompany.util se encuentra en miles de árboles de dependencias. La empresa quiebra, el dominio caduca y nadie se da cuenta, porque el artefacto sigue resolviéndose perfectamente desde Maven Central.
Lo que ocurre a continuación no es tan automático como parece. Cuando ninguna cuenta gestiona ese «groupId» en un repositorio concreto, quienquiera que sea el propietario actual del dominio puede reclamarlo mediante un registro TXT de DNS. Cuando el «groupId» ya está registrado, hacerse con él implica convencer al equipo de soporte de ese repositorio para que transfiera el acceso, y Oversecured dejó claro que no disponía de información sobre cómo funcionan esas transferencias. Gran parte del riesgo proviene también de proyectos que se resuelven a través de varios repositorios, en los que una versión maliciosa introducida en otro punto de la lista sigue llegando bajo coordenadas en las que la compilación ya confía. Los proyectos que utilizan rangos de versiones, o que se actualizan a la versión del atacante, la recogen sin llegar a ver nunca un nombre desconocido.
La magnitud del problema es más fácil de determinar que su mecánica. Oversecured convirtió los «groupIds» de Maven Central en dominios y comprobó cuáles se podían adquirir fácilmente; de los 26 163 dominios, 3 710 (el 14,18 %) resultaron estar a la venta. Si ampliamos esto a los espacios de nombres respaldados por GitHub y a los repositorios privados que los investigadores pudieron encontrar, el 18,18 % de un conjunto de datos de 33 938 identificadores parecía estar expuesto.
Sonatype cuestionó la viabilidad del ataque, dada la automatización existente, y a continuación desactivó las cuentas vinculadas a dominios caducados, reforzó la verificación de los espacios de nombres y corrigió una regresión en la validación de claves públicas que había permitido el paso de artefactos firmados con claves que nunca se habían publicado en ningún sitio. La respuesta de Oversecured fue que ningún registro por sí solo puede solucionar esto, ya que el ataque se dirige a proyectos que resuelven desde varios repositorios públicos a la vez, y que lo máximo que puede hacer cualquier propietario de un repositorio es rechazar las reclamaciones automáticas sobre espacios de nombres ya señalados como vulnerables.
La política habitual de Maven Central consiste en que las versiones publicadas sean inmutables, por lo que el editor no puede modificarlas ni retirarlas discretamente; las retiradas por motivos de seguridad, como la de Jackson, constituyen una excepción muy concreta. Esto resulta útil para la reproducibilidad. También significa que las dependencias abandonadas siguen siendo resolubles y permanecen en lo más profundo de los árboles de dependencias mucho tiempo después de que el dominio o la cuenta detrás del espacio de nombres haya dejado de recibir mantenimiento, pareciendo idénticas a las que funcionan correctamente desde el interior de un pom.xml.
Qué ocurre con esas bibliotecas cuando se publica un CVE es una pregunta para la que no hay una respuesta clara. No hay ninguna versión parcheada a la que actualizarse, y al incorporar una biblioteca Java relevante para la seguridad en tu propio repositorio, tu equipo pasa a ser responsable de sus CVE, independientemente de si se cuenta o no con personal para ello.
Cómo un paquete de npm comprometido llegó a Maven Central
Lo que la mayoría de los equipos de Java pasan por alto es que esto puede ocurrir sin que nadie del equipo tenga que utilizar npm.
En noviembre de 2025, la segunda ola de la El gusano «Shai-Hulud» de npm ha llegado a Maven Central mediante la duplicación automática de mvnpm. mvnpm vuelve a publicar los paquetes de npm como artefactos de Maven, de modo que los proyectos web en Java puedan obtener las bibliotecas de front-end a través de su proceso de compilación habitual sin necesidad de una cadena de herramientas de JavaScript independiente. La duplicación está automatizada, y las nuevas versiones de npm se sincronizan a medida que se publican, lo cual constituye el objetivo principal de la herramienta y, precisamente, la forma en que el paquete comprometido logró colarse. Una versión maliciosa del npm posthog-node El paquete se ha vuelto a compilar en Maven Central como org.mvnpm:posthog-node:4.18.1, con el mismo setup_bun.js cargador y bun_environment.js carga útil como la Campaña «Shai-Hulud» en npm.
Socket informó del artefacto, y Maven Central confirmó que la versión comprometida procedía del proceso automatizado de mvnpm y eliminó todas las copias en los servidores espejo ese mismo día. PostHog no publica nada en Maven. No hay pruebas de que el gusano se haya propagado por sí mismo dentro del ecosistema de Maven, solo existe ese único artefacto duplicado. Esa distinción es importante a la hora de valorar si se trata de un patrón real en la cadena de suministro de Maven o de un caso aislado. Fue real y automático, y ningún responsable del mantenimiento de Java tuvo que volver a publicar nada para que una versión comprometida de npm estuviera disponible para las compilaciones de Java, pero no se comportó como un gusano una vez que llegó allí.
Lo que sí demuestra es que la replicación automática desplaza un límite de confianza sin que nadie haya decidido hacerlo. Una empresa que utiliza Java y que nunca ha utilizado npm puede acabar ejecutando un paquete de npm comprometido porque un servicio puente lo ha convertido en un archivo JAR en su nombre.
| Ruta de acceso a una compilación de Java | Es necesario que el equipo utilice npm | Aparece en pom.xml |
|---|---|---|
| Dependencia directa de npm a través de una cadena de herramientas de JavaScript | Sí | No |
| Artefacto npm duplicado desde un servicio puente | No | Sí, como un archivo JAR normal |
| Dependencia transitiva de Java que recupera un artefacto duplicado | No | Solo en el caso de que dependency:tree |
Comprueba directamente la ruta transitiva en lugar de deducir lo que debería haber ahí. Averigua qué hay realmente en tu árbol.
mvn dependency:tree -DoutputFile=deps.txtPues léelo. Un servicio de Spring de tamaño medio puede resolver fácilmente varios cientos de artefactos a partir de unas dos docenas de dependencias declaradas. Los paquetes duplicados sí aparecen en esa salida, bajo org.mvnpm coordenadas, lo cual es una pista clara siempre y cuando alguien del equipo sepa que ese espacio de nombres hace referencia al código de npm reempaquetado para Maven.
Qué cambiar en tu compilación este mes
Empieza con la herramienta de compilación que ya estés utilizando, ya que ambos métodos no suponen el mismo esfuerzo. Gradle puede iniciar rápidamente la verificación de dependencias con --write-verification-metadata sha256,pgp, entonces solo hay que revisar los hash y las claves generados antes de que el archivo se guarde. Maven no tiene un equivalente nativo, por lo que hay que añadir un complemento y fijar las versiones en pluginManagement, lo cual requiere más preparación, pero sigue siendo una tarea de una semana, no de un trimestre.
A continuación, fíjate en el hábito que, de hecho, permitió que se aprobara el paquete de Jackson. Las coordenadas se copian de dondequiera que se encuentren, en lugar de contrastarlas con la documentación del propio proyecto, y eso es más fácil de solucionar con una norma que con una herramienta. Comprueba cualquier groupId que tu equipo no haya utilizado antes cotejándolo con las coordenadas del repositorio oficial del proyecto o con la documentación antes de que se acerque siquiera a un pom.xml, sobre todo cualquier contenido extraído de un resultado de búsqueda o de un fragmento generado por IA.
Las dependencias abandonadas requieren un tipo diferente de decisión discrecional, y MavenGate es la razón. Un artefacto sin versiones recientes y sin un responsable de mantenimiento activo es candidato a ser asumido, independientemente de si tiene o no un CVE abierto en este momento, ya que el riesgo no reside en el código, sino en si alguien sigue controlando el dominio o la cuenta que hay detrás de ese espacio de nombres.
Un proyecto de Gradle iniciado en los últimos dos años puede incorporar la verificación en un solo día. En cambio, una compilación de Maven con varios módulos, de hace diez años, con un POM principal personalizado y cuarenta complementos, es un tema más complejo, y el esfuerzo de implementación realmente varía mucho entre ambos casos.
Dónde encaja SecureChain
Maven Central comprueba la propiedad del espacio de nombres al recibir los archivos, y Maven compara las sumas de comprobación del repositorio al descargarlos. Nada en la ruta predeterminada confirma que el binario que se resuelve coincida con lo que el proyecto ha compilado realmente. SecureChain para Java sustituye esa ruta de resolución, recompilando cada paquete a partir de código fuente verificado, detectando comportamientos maliciosos antes de que lleguen a tu compilación y aplicando parches de forma continua, incluso después de que finalice el soporte del desarrollador original. Tu flujo de trabajo actual con Maven o Gradle se mantiene tal cual: dirígelo a TuxCare y sigue compilando.
Descubre qué abarca SecureChain for OSS o suscríbete al boletín para recibir análisis de incidentes como este a medida que se produzcan.
PREGUNTAS FRECUENTES
¿Qué es la suplantación de espacio de nombres en Maven Central?
Publicar un artefacto con un `groupId` creado para parecerse al espacio de nombres de un proyecto legítimo. Maven Central verifica que el editor controle el dominio o la cuenta de alojamiento correspondiente, lo que confirma el control de ese espacio de nombres, pero no dice nada sobre ninguna relación con el proyecto que se está imitando.
¿Verifica Maven las firmas PGP?
No de forma predeterminada. Maven Central exige firmas PGP en los artefactos publicados, y Maven compara las sumas de comprobación del repositorio, pero no verifica dichas firmas ni sus asignaciones de claves de confianza de forma predeterminada. Para la verificación se necesita un complemento como pgpverify-maven-plugin.
¿Cómo puedo activar la verificación de dependencias en Gradle?
Ejecutar ./gradlew --write-verification-metadata sha256,pgp help para iniciar un verification-metadata.xml archivo, revisa las sumas de comprobación y las claves de confianza generadas y, a continuación, confirma esa línea de base. A partir de ese momento, Gradle dará por fallida la compilación de cualquier artefacto cuya suma de comprobación o firma deje de coincidir.
¿Qué es MavenGate?
Una técnica de apropiación, publicada por los investigadores de Oversecured en enero de 2024, que se centra en las dependencias abandonadas. Quien adquiera el dominio caducado o la cuenta asociada a un «groupId» antiguo podría reclamar ese espacio de nombres en un repositorio en el que nadie lo gestione, o intentar obtener acceso a un registro ya existente; de este modo, los proyectos que resuelven en varios repositorios podrían acabar aceptando artefactos maliciosos bajo coordenadas que les resulten familiares.
¿Puede un paquete npm comprometido afectar a un proyecto de Java?
Sí. Los servicios puente que vuelven a publicar automáticamente paquetes de npm como artefactos de Maven pueden introducir una versión de npm comprometida en Maven Central, donde se traduce en una compilación de Java como un archivo JAR normal en org.mvnpm coordenadas. Esas coordenadas dan nombre al puente, pero un equipo que no reconozca el espacio de nombres tratará el artefacto como cualquier otra dependencia. Eso es exactamente lo que ocurrió cuando Shai-Hulud 2.0 llegó a Maven Central a través de mvnpm en noviembre de 2025.
¿Cómo puedo saber si mi compilación de Java ha incluido una biblioteca de Java maliciosa?
Ejecutar mvn dependency:tree o ./gradlew dependencies y compara cada «groupId» desconocido con la propia documentación del proyecto de origen, en lugar de con un resultado de búsqueda. En el caso de cualquier proyecto abandonado, considera el riesgo de apropiación como algo independiente del estado del CVE. Al final, todo se reduce a ese tipo de examen manual, ya que la verificación del espacio de nombres de Maven Central comprueba el control de un dominio o una cuenta de alojamiento, en lugar de la afiliación a un proyecto con un nombre similar, y Maven no autentica las firmas de las dependencias de forma predeterminada.
¿Existe en Java algún equivalente a los scripts de postinstalación de npm?
No es para la instalación de dependencias, aunque las compilaciones de Java siguen ejecutando código no fiable. Los complementos de Maven se ejecutan durante el ciclo de vida de la compilación, los procesadores de anotaciones se ejecutan dentro del compilador y los scripts de compilación de Gradle son programas ejecutables, en lugar de simples archivos de configuración. El paquete Jackson falso utilizaba un truco similar en tiempo de ejecución, permitiendo que Spring detectara su clase de configuración e iniciara la carga útil en su nombre.
