alta

CVE

CVE-2026-25707

CWE

CWE-22

Sistemas afectados

  • `libzypp` before 17.38.10 and downstream distro builds that still ship the vulnerable parser behavior
  • openSUSE and SUSE systems that consume repositories through `zypper`, YaST, or other `libzypp`-based automation
  • Build systems, image pipelines, or Linux hosts that refresh or mirror less-trusted package repositories and process attacker-controlled `repomd.xml` or SuSE tags metadata

CVE-2026-25707 es un fallo de gestión de paquetes de Linux, pero pertenece al radar de AppSec porque convierte los metadatos de repositorio en una primitiva de colocación de archivos locales. Si tu modelo de amenaza todavía trata los metadatos de paquetes como “solo contabilidad de descargas”, esta divulgación es el contraejemplo: el parser confiaba lo suficiente en ubicaciones relativas como para que un repositorio hostil pudiera intentar reflejar archivos fuera de la raíz de caché prevista.

El componente afectado es libzypp, la biblioteca de gestión de paquetes detrás de herramientas como zypper y flujos de trabajo de paquetes adyacentes de SUSE / openSUSE. En la práctica, esto significa que el problema puede alcanzar tanto hosts orientados a desarrolladores como sistemas de automatización que actualizan o reflejan repositorios dentro de pipelines de compilación, imagen o actualización.

Componentes afectados y versiones corregidas

Los avisos públicos coinciden en el límite de versión principal de upstream:

  • libzypp anterior a 17.38.10 está afectado

Los detalles de empaquetado por distribución también importan:

  • openSUSE Tumbleweed corrigió el problema en 17.38.10-1.1
  • SUSE Linux Micro 6.1 recibió paquetes libzypp corregidos en la línea 17.38.11
  • conjuntos de paquetes posteriores, como las actualizaciones combinadas de Leap 16 / zypper, incluyen la corrección en 17.38.13

Operacionalmente, la pregunta de más alto nivel es más simple que la matriz de distribuciones: si un host procesó metadatos de repositorio no confiables con una libzypp vulnerable, el propio repositorio se convirtió en una fuente de entrada de path traversal.

El fallo es visible en el formato de metadatos del repositorio

La corrección en upstream añade un caso de prueba que captura todo el problema en una línea:

<data type="hostile">
  <location href="../hostile/to_be_discarded"/>
</data>

Ese ../ es el corazón del problema. El parser estaba dispuesto a aceptar entradas de metadatos de repositorio cuya ubicación de destino se normalizara fuera del área de caché local del repositorio. En otras palabras, la actualización del repositorio no solo decidía qué descargar, sino también en qué lugar del disco debía aterrizar el objeto reflejado.

Para los equipos de seguridad de aplicaciones, este es el límite importante:

el atacante controla los metadatos del repositorio
  -> el parser acepta traversal relativo en <location href=...>
  -> la ruta reflejada escapa del directorio de caché local del repositorio
  -> se vuelven posibles condiciones de sobrescritura de archivos locales / DoS / escalada de privilegios

Por eso el problema se lee más como una primitiva de escritura de archivos locales que como un simple fallo de parser de índice de paquetes.

Dos rutas del parser necesitaban refuerzo

El parche es especialmente útil porque muestra que el fallo no se corrigió con una capa genérica de “sanitizar todo en algún otro lugar”. Los mantenedores reforzaron los lectores de metadatos reales que convierten los documentos del repositorio en ubicaciones de descarga.

1. Rechazo de rutas en repomd.xml / metadatos YUM

En RepomdFileReader.cc, la corrección ahora rechaza valores href hostiles antes de que se conviertan en un OnMediaLocation:

Pathname location { reader_r->getAttribute("href").asString() };
if ( location.relativeDotDot() ) {
  JobReport::warning(
    str::sconcat(
      _repomdFile, ": data type ", _typeStr,
      ": hostile location ", location,
      " => discard data entry"
    )
  );
  _discardDataEntry = true;
  return true;
}
_location.setLocation( std::move(location), 1 );

Ese es el cambio crítico. Antes de la corrección, el parser aceptaba la ubicación y seguía adelante. Después de la corrección, las entradas que se normalizan fuera de la raíz del repositorio se descartan explícitamente.

2. Sanitización de metadatos de tags de SuSE

El mismo commit también refuerza ContentFileReader.cc, que procesa metadatos de contenido de tags de SuSE. El nuevo ayudante rechaza entradas que contienen traversal relativo:

std::string sanitizeEntry( Pathname path_r )
{
  if ( path_r.relativeDotDot() ) {
    JobReport::warning(
      str::sconcat(
        "Content file: hostile location ",
        path_r,
        " => discard data entry"
      )
    );
    return {};
  }
  return path_r.asString().substr( path_r.absolute() ? 1 : 2 );
}

También normaliza directorios de nivel superior como DESCRDIR y DATADIR mediante un sanitizador relacionado:

Pathname sanitize( Pathname path_r )
{
  Pathname ret = path_r.absolutename();
  if ( path_r.relativeDotDot() ) {
    JobReport::warning(
      str::sconcat(
        "Content file: hostile location ",
        path_r,
        " => ",
        ret
      )
    );
  }
  return ret;
}

Desde una perspectiva de AppSec, ese refuerzo doble importa porque indica que la superficie vulnerable no era una sola función auxiliar ni un único formato de empaquetado. Múltiples lectores de metadatos necesitaban dejar de confiar en segmentos de ruta relativos provenientes del contenido del repositorio.

Por qué esto importa más allá de la gestión de paquetes de escritorio

libzypp a menudo se ejecuta en contextos más sensibles que una simple actualización de paquetes en un portátil:

  • pipelines de compilación de imágenes doradas o de appliances
  • espejos internos o repositorios en staging
  • servicios de actualización para flotas Linux de borde, kiosco o embebidas
  • entornos de CI que arrancan raíces de compilación o imágenes de prueba desde repositorios
  • estaciones de trabajo de desarrolladores con ayudantes de gestión de paquetes privilegiados

En cada uno de esos casos, “los metadatos de repositorio controlan dónde se reflejan los archivos” es un límite de seguridad significativo. Si el repositorio es hostil o está comprometido, el gestor de paquetes puede convertirse en una ruta de escritura de archivos inesperada.

Por eso el lenguaje de NVD sobre denegación de servicio o escalada de privilegios es creíble. El resultado exacto depende de dónde aterrice la ruta reflejada y de qué haga el código o los permisos posteriores con ella, pero la primitiva en sí ya es peligrosa.

Alcance y detección

Primero, identifica si el host todavía está en una línea de paquetes vulnerable:

rpm -q libzypp zypper
zypper --version

Luego revisa el uso de repositorios y el contenido de la caché:

zypper lr -u
rg -n '<location href="\\.\\./|<location href="[^"]*/\\.\\./' /var/cache/zypp /var/cache/zypp/raw
rg -n '(^|[[:space:]])\\.\\./' /var/cache/zypp/raw

Las rutas exactas varían según la versión de la distribución y el tipo de repositorio, pero el objetivo de la revisión es consistente:

  1. ¿Qué repositorios estaban configurados durante la ventana de exposición?
  2. ¿Alguno de ellos era de terceros, de staging, interno, sin firmar, o cambió de forma inesperada?
  3. ¿Los metadatos o espejos en caché contenían ubicaciones con estilo ../?

Si operas espejos internos, revisa también los registros de pipeline o los jobs de mirror que ingieren metadatos externos antes de republicarlos a hosts descendentes. Un repositorio upstream hostil puede convertir una etapa de mirror en el primer lugar donde se ejecuta el traversal.

Remediación

Primero, aplica el parche:

  1. Actualiza libzypp a una compilación corregida para tu línea de distribución.
  2. Actualiza zypper y los componentes de gestión de paquetes relacionados si tu proveedor incluye la corrección en una actualización coordinada.
  3. Actualiza los metadatos de repositorio después de aplicar el parche.

Luego limpia el límite de confianza:

  1. Elimina o deshabilita los repositorios en los que no confíes explícitamente.
  2. Limpia los metadatos en caché de repositorios sospechosos y vuelve a sincronizar desde fuentes conocidas y confiables.
  3. Revisa los cambios en el sistema de archivos local si un host consumió repositorios de terceros o comprometidos durante la ventana vulnerable.
  4. Prefiere repositorios firmados, controlados por el proveedor y con procedencia revisada para la automatización.

Si tienes evidencia de que se usó realmente un repositorio hostil, no te detengas en las actualizaciones de paquetes. Revisa el host como un incidente de escritura de archivos locales, especialmente si el sistema tenía flujos de actualización privilegiados o automatización posterior a la actualización que pudiera haber actuado sobre archivos sobrescritos.

Qué deben recordar los defensores

La lección más útil de CVE-2026-25707 es arquitectónica: los metadatos de repositorio son datos de control ejecutables para un gestor de paquetes, incluso cuando no parecen código. En las versiones vulnerables de libzypp, esos datos de control alcanzaron decisiones de colocación de archivos con la suficiente fuerza como para que ../ en los metadatos se volviera relevante para la seguridad.

Para los equipos de AppSec y de plataforma, este es el tipo de vulnerabilidad de gestión de paquetes de Linux que merece más atención de la que sugiere su etiqueta centrada en el parser. Si tu cadena de suministro de software incluye mirroring de repositorios, repositorios personalizados, actualizaciones de raíces de compilación o flujos automatizados de zypper, un traversal de metadatos de repositorio no es solo un problema de la distribución. Forma parte de tu cadena de confianza de entrega de aplicaciones.

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.

Explorar el análisis de dependencias Solicitar demo

Referencias