jueves, 29 de octubre de 2026
Secure crew

Ciberseguridad con criterio

Vulnerabilidades y parches

Backstage corrige un bypass de URL en las reglas de su catálogo

·2 fuentes

Por SecureCrew Editorial · Criterios editoriales y correcciones

CVE-2026-115923 permite que usuarios autenticados con catalog.location.create hagan que una URL parezca confiable antes de normalizarse y se descargue desde otro origen; las correcciones están en 3.9.2 y 4.0.2.

Una persona coloca una carpeta de proyecto en un archivador físico junto a otros volúmenes; Securecrew aparece impreso en la cubierta del catálogo.

El catálogo de software de Backstage permitía eludir algunas reglas de confianza cuando recibía ubicaciones URL con segmentos codificados. La ficha de GitHub Advisory Database sobre CVE-2026-115923 se publicó allí el 28 de octubre, pero el proyecto había difundido su aviso el 21 y las versiones con la corrección salieron ese mismo día. Esa diferencia importa: el 28 corresponde al registro de GitHub, no a una nueva publicación del parche.

El fallo está en la comparación entre la dirección que se valida y la que se usa para recuperar el contenido. catalog.rules podía evaluar la URL sin normalizar, mientras que el lector de URL de Backstage la resolvía después en forma canónica. Una dirección con segmentos %2e%2e podía parecer que permanecía bajo un prefijo de confianza y, al normalizarse para descargarla, terminar fuera de ese ámbito.

-SecureCrew dice: Una política que mira una dirección antes de normalizarla está comprobando una versión de la historia que el lector de URL no necesariamente va a leer.-

Quién puede aprovechar la diferencia

El requisito de acceso acota el escenario: hace falta una cuenta autenticada con permiso catalog.location.create, usado para registrar ubicaciones en el catálogo. El problema no es que un visitante anónimo pueda enviar una URL desde cualquier página. Afecta a despliegues que usan patrones URL en catalog.rules para limitar qué fuentes se consideran confiables y conceden a usuarios la capacidad de registrar nuevas ubicaciones.

Cuando la comprobación se basa en el texto original pero la descarga usa la dirección normalizada, el contenido de un repositorio ajeno puede incorporarse como si procediera del origen permitido. Ese cruce de frontera de confianza es el impacto confirmado por el aviso. No demuestra por sí mismo ejecución de código, robo de credenciales ni una intrusión en todas las instalaciones: cualquier consecuencia posterior depende de los procesadores, integraciones y acciones que esa configuración aplique a las entidades incorporadas.

La corrección hace que las reglas comparen las ubicaciones URL en forma canónica, igual que el lector al recuperar el contenido. Los patrones que dependían de conservar caracteres codificados o puertos predeterminados pueden comportarse de otra manera tras el cambio y deben revisarse antes de desplegarlo. La nota de Backstage sobre 4.0.2 explica explícitamente ese ajuste de las reglas.

-SecureCrew dice: Si una actualización cambia qué URL considera equivalente, conviene revisar las reglas que se escribieron contando con la representación antigua.-

Versiones corregidas y contención

Backstage indica dos ramas corregidas para @backstage/plugin-catalog-backend: 3.9.2 para la línea anterior y 4.0.2 para la línea 4.x. La versión 4.0.1 publicada sigue dentro del rango afectado. El changelog de Backstage v1.56.1 incluye 4.0.2 y el cambio de comparar las reglas con una forma canónica; el aviso enlaza la otra corrección con la versión 3.9.2 de la release 1.54.10.

La acción principal es identificar qué versión del paquete usa cada backend y actualizar a la versión corregida de su rama. Restringir el permiso catalog.location.create reduce la superficie mientras se prepara el cambio, pero no reemplaza el arreglo en instalaciones que dependen de patrones de URL para separar fuentes confiables: el propio aviso no ofrece una mitigación completa para esa configuración.

Después del despliegue, comprueba que las reglas de ubicación sigan describiendo los orígenes que el equipo pretende aceptar y revisa las ubicaciones registradas por cuentas con ese permiso durante el periodo vulnerable, si hay registros disponibles. No hace falta convertir cada catálogo en una investigación de compromiso; el objetivo inmediato es confirmar la versión, la corrección aplicada y que no se incorporó una entidad desde una URL distinta de la esperada.

Diccionario de la Crew

URL canónica — Dirección normalizada para que representaciones equivalentes de una ruta se interpreten de forma consistente.

Ubicación de catálogo — Fuente URL o local que Backstage registra para incorporar entidades al catálogo de software.

catalog.location.create — Permiso de Backstage que habilita a una cuenta a registrar nuevas ubicaciones de catálogo.

Fuentes

Fuentes consultadas

También te puede interesar