Inyección SQL en CakePHP, corregida en 5.4.4 (CVE-2026-119418)

TL;DR

• Dos fallos en los objetos de expresión de base de datos de CakePHP insertan cadenas controladas por el atacante en el SQL en lugar de vincularlas. VulnCheck los publicó el 30 de octubre de 2026 como CVE-2026-119418, offsets de ventana, y CVE-2026-119419, nombres de intercalación, acreditando a Abraxas Labs y Mark Story.
• Una aplicación solo queda expuesta cuando su propio código pasa datos de la petición a los parámetros afectados: offsets de ventana mediante range() o frame(), o nombres de intercalación mediante StringExpression e IdentifierExpression. El esqueleto de aplicación por defecto no expone ninguno de los dos en un formulario público.
• Ambos registros CVE llevan CVSS v4.0 9.2 y v3.1 8.1. No se conoce explotación, y ninguno de los dos CVE está en el catálogo KEV de CISA al 1 de noviembre de 2026. Hay laboratorios de prueba de concepto públicos desde el 12 de octubre de 2026.
• Actualice a CakePHP 5.4.4, 5.3.8 o 5.2.16, todas publicadas el 1 de noviembre de 2026. CakePHP 4.6.6 solo corrige el fallo de intercalación; vea «¿Cómo lo corrijo?» para la vía 4.x y la solución temporal de validación de entradas.

¿Estoy afectado?

Está expuesto cuando se cumplen todas estas condiciones:

• Su aplicación ejecuta CakePHP hasta 5.4.3, o una versión 5.x o 4.x sin versión corregida, según la tabla siguiente.
• Su propio código pasa un valor controlado por la petición a uno de los parámetros afectados. Estos son el $start o $end de WindowExpression::range(), los offsets o direcciones de frame(), y los nombres de intercalación pasados a new StringExpression(), new IdentifierExpression() o setCollation().
• Un atacante puede alcanzar por red la ruta de petición que construye esa consulta.

El modelo de víctima del investigador describe las dos formas realistas. Una es un generador de informes analíticos que pasa una entrada de «últimos N días» a range(). La otra es una aplicación que pasa un selector de configuración regional o de intercalación a los constructores de intercalación. El esqueleto oficial cakephp/app no pasa ninguna de las dos, por lo que el framework por sí solo no crea la exposición.

El fallo de ventanas solo está corregido en las tres primeras filas. El código fuente de 4.6.6 aún acepta offsets de ventana como cadenas sin procesar, verificado en su WindowExpression.php, y la última versión de la rama 4.5, 4.5.12 de agosto de 2026, es anterior a ambas correcciones. La misma serie de parches también valida parámetros vecinos que los registros CVE no describen: nombres de función en FunctionExpression, campos de ordenación de agregados en StringAggExpression, y las cadenas de partition() y orderBy().

Compruebe lo que ejecuta y luego audite el código que llama a la API afectada:

# Framework version (the package the official skeleton requires)
composer show cakephp/cakephp | grep -E '^(name|versions)'
# If the database package was installed on its own
composer show cakephp/database 2>/dev/null | grep -E '^(name|versions)'
# Lock file
grep -A1 '"name": "cakephp/cakephp"' composer.lock | grep '"version"'

# Locate window APIs; inspect every argument and trace request data manually
grep -rnE '\->(range|frame)\b' src/ templates/ 2>/dev/null
# Collation names reaching a constructor or setter
grep -rnE 'setCollation\(\s*\$|new StringExpression\(|new IdentifierExpression\(' src/ templates/ 2>/dev/null

Revise cada resultado del grep con una sola pregunta: ¿puede un parámetro de la petición llegar al argumento? El alcance es amplio. El registro de packagist.org para cakephp/cakephp muestra 21,425,059 instalaciones totales con 557,686 en el último mes. El paquete separado cakephp/database, que contiene estas clases, muestra 29,353,847 instalaciones totales con 857,825 en el último mes. Ambas cifras se comprobaron el 1 de noviembre de 2026.

¿Cómo lo corrijo?

1. Desde la raíz del proyecto, ejecute composer update cakephp/cakephp, o composer update cakephp/database si utiliza el paquete de base de datos independiente. Con una restricción 5.4.*, 5.3.* o 5.2.* esto alcanza 5.4.4, 5.3.8 o 5.2.16 respectivamente.
2. Si su composer.json fija una versión afectada exacta, súbala a la versión corregida de su rama y vuelva a ejecutar la actualización.
3. Despliegue el directorio vendor/ actualizado. Recargue los workers PHP web o invalide OPcache según su procedimiento de despliegue para evitar que las clases antiguas permanezcan en caché. Los procesos PHP de larga duración, como los workers de colas y los comandos demonizados, deben reiniciarse para descartar el código antiguo de la memoria.
4. En la rama 4.6, actualice a 4.6.6 con los mismos comandos; solo cierra el fallo de intercalación.
5. Espere un cambio de comportamiento: los offsets de ventana que contienen espacios, como los literales de intervalo, ahora lanzan InvalidArgumentException. Vea las preguntas frecuentes para el caso de los literales de intervalo.

Si todavía no puede actualizar, aplique la regla del código corregido en su propia frontera de llamada:

• Pase solo enteros, null, o objetos ExpressionInterface preconstruidos y de confianza como offsets de ventana.
• Envuelva usted mismo los literales de intervalo en new QueryExpression("'1 day'").
• En llamadas directas a frame(), use constantes del framework para el tipo de marco y ambas direcciones; nunca les pase cadenas de la petición.
• Restrinja los nombres de intercalación a una lista de permitidos definida por su aplicación.

Esta solución temporal solo cubre sus puntos de llamada. Cualquier código de terceros que llame a la misma API con datos de la petición sigue expuesto: trátela como un parche provisional para ambos CVE mientras se programa la actualización.

¿Cuál es la causa raíz?

Los objetos de expresión tratan varios argumentos del constructor de consultas como fragmentos SQL en lugar de valores: el binder aparece en cada firma pero nunca vincula estas cadenas.

El constructor de consultas de CakePHP separa los valores vinculados del SQL estructural, y en agosto de 2026 ya aprendió esta lección una vez. CVE-2026-79752 puso ensureSimpleString() en cuatro métodos de FunctionsBuilder cuyos argumentos eran fragmentos concatenados. Los offsets de ventana y los nombres de intercalación no estaban en esa lista, y Abraxas Labs encontró ambos restos en la pasada del 12 de octubre de 2026 que siguió al parche.

El fallo de ventanas reside en buildOffsetSql(), que ensambla la cláusula BETWEEN de la ventana OVER:

// src/Database/Expression/WindowExpression.php, before 5.4.4
protected function buildOffsetSql(
    ValueBinder $binder,
    ExpressionInterface|string|int|null $offset,
    string $direction,
): string {
    if ($offset === 0) {
        return 'CURRENT ROW';
    }

    if ($offset instanceof ExpressionInterface) {
        $offset = $offset->sql($binder);
    }

    return sprintf(
        '%s %s',
        $offset ?? 'UNBOUNDED',
        $direction,
    );
}

El $binder figura en la firma pero solo actúa cuando el offset ya es un objeto de expresión. Una cadena simple, incluida una proveniente de $request->getQuery('start'), pasa por sprintf() hacia RANGE BETWEEN ... PRECEDING dentro de la cláusula OVER.

Los métodos hermanos rows() y groups() toman un ?int y no pueden transportar esto. range() acepta una cadena porque los literales de intervalo se parecen a '1 day', y la propia prueba del framework afirmaba range("'1 day'", "'10 days'") antes del parche, como documentó el investigador.

El fallo de intercalación tiene la misma forma, con el valor vinculado a salvo y el segundo argumento sin procesar:

// src/Database/Expression/StringExpression.php, before 5.4.4
public function sql(ValueBinder $binder): string
{
    $placeholder = $binder->placeholder('c');
    $binder->bind($placeholder, $this->string, 'string');

    return $placeholder . ' COLLATE ' . $this->collation;
}

El valor de la cadena se vincula a un placeholder. La intercalación se concatena tras COLLATE, e IdentifierExpression::sql() la inserta igual. En Postgres, el envoltorio de identificadores del controlador es un recortar-y-envolver, '"' . trim($collation, '"') . '"' según el investigador: una comilla doble incrustada cierra el identificador antes de tiempo y todo lo que sigue escapa de la instrucción prevista.

¿Cómo se explota?

Los laboratorios de prueba de concepto públicos muestran ambos mecanismos de principio a fin:

1. El atacante identifica un parámetro de petición alcanzable que la aplicación pasa a range(), frame() o un constructor de intercalación. Esta es toda la condición previa; ningún punto de entrada del framework expone los parámetros por sí mismo.
2. Para el fallo de ventanas, una cadena de offset manipulada llega sin procesar entre RANGE BETWEEN y PRECEDING. El laboratorio del investigador muestra el fragmento apareciendo en el SQL compilado, sin vincular y sin entrecomillar. Es una demostración solo de compilación en SQLite, sin lectura de tabla demostrada.
3. Para el fallo de intercalación, el laboratorio Postgres del investigador ejecuta la inyección. El valor de control collation=C se compila como COLLATE "C". El payload C" AS text)) || (SELECT note FROM lab_secret LIMIT 1) -- es público en el análisis del investigador. Su comilla incrustada sale del recortar-y-envolver, y el comentario final consume el texto de cierre de Cake.
4. El SELECT inyectado devuelve una fila testigo, y el laboratorio informa del valor leído xCAKEPHP-COLLATE-SQLI-WITNESS con el placeholder vinculado conteniendo aún el literal simple. El primer argumento vinculado nunca fue el agujero; lo era el segundo.

Ambos laboratorios están en GitHub, enlazados en las referencias, y los análisis del investigador los describen como reproducciones solo en bucle local.

¿Cómo fluye el ataque?

En una frase: un parámetro de la petición llega a un constructor de expresión, el valor se concatena como fragmento SQL en lugar de vincularse, y la consulta se ejecuta con los privilegios de la base de datos de la aplicación.

¿Qué puede hacer un atacante?

• Ejecutar SQL con los privilegios de la conexión a la base de la aplicación. Ambos registros CVE puntúan un impacto total en confidencialidad, integridad y disponibilidad sobre los datos comprometidos.
• Leer datos. El laboratorio de intercalación en Postgres demuestra un SELECT que devuelve una fila de una tabla que la aplicación no pensaba exponer.
• Modificar datos. El investigador lo califica de inferido más que demostrado: la misma inyección se ejecuta con el rol de la conexión, así que las escrituras son posibles, pero el laboratorio solo prueba un oráculo de lectura.
• Fallar visiblemente con una entrada mal formada. Un payload que no se analiza produce un error de base de datos en esa petición, que es también lo que puede dejar un intento de sondeo.

Condiciones que necesita el atacante: una aplicación que pase datos de la petición a los parámetros afectados, accesibilidad por red de esa ruta, y nada más. Ninguna barrera de autenticación del framework se aplica a los parámetros en sí. Que el punto de entrada vulnerable esté autenticado depende por completo de la aplicación. También es por eso que el investigador puntúa los fallos con PR:L mientras los registros CVE puntúan PR:N con una complejidad de ataque alta.

¿Por qué funciona la corrección?

El commit 18de3e4c para la familia de ventanas y el commit ae8c354c para los constructores de intercalación añaden QueryExpression::ensureSimpleString() a cada argumento afectado: una cadena no simple lanza una excepción antes de construir cualquier SQL:

--- a/src/Database/Expression/WindowExpression.php
+++ b/src/Database/Expression/WindowExpression.php
@@ public function range(
     ExpressionInterface|string|int|null $start,
     ExpressionInterface|string|int|null $end = 0
 ) {
+    if (is_string($start)) {
+        QueryExpression::ensureSimpleString('start', $start);
+    }
+    if (is_string($end)) {
+        QueryExpression::ensureSimpleString('end', $end);
+    }
+
     return $this->frame(self::RANGE, $start, self::PRECEDING, $end, self::FOLLOWING);
 }

--- a/src/Database/Expression/StringExpression.php
+++ b/src/Database/Expression/StringExpression.php
@@ public function setCollation(string $collation): void
 {
+    QueryExpression::ensureSimpleString('collation', $collation);
     $this->collation = $collation;
 }

// src/Database/Expression/QueryExpression.php, 5.4.4
public static function ensureSimpleString(string $parameterName, string $value): void
{
    if (preg_match('/^(?:[\'"])?[a-zA-Z0-9_\.]+(?:[\'"])?$/', $value)) {
        return;
    }
    throw new InvalidArgumentException("Argument `{$parameterName}` must be an alphanumeric string");
}

La regla permite un token opcionalmente entrecomillado de letras, dígitos, guiones bajos y puntos, y nada más. Las cadenas no simples, como los literales de intervalo con espacios, ahora lanzan InvalidArgumentException. El validador aplica una lista de caracteres permitidos, no un filtro de palabras clave SQL. Las cadenas que necesitan estructura, como los literales de intervalo, deben llegar como objetos de expresión construidos deliberadamente por quien llama.

La corrección es completa para estos parámetros en las ramas 5.2, 5.3 y 5.4. La serie de parches también valida el nombre de FunctionExpression en su constructor y en setName(), StringAggExpression::setAggregateOrderBy(), WindowExpression::partition() y orderBy(), y ambos establecedores de intercalación. No es completa para las ramas 4.x. La versión 4.6.6 solo incorpora el trasplante de la corrección de intercalación, y sus WindowExpression::range(), frame() y buildOffsetSql() siguen aceptando y concatenando cadenas sin procesar, verificado en el código fuente de 4.6.6.

¿Cómo compruebo si he sido comprometido?

No hay indicadores de compromiso publicados para estos fallos, y no se ha informado de explotación en ningún lugar al 1 de noviembre de 2026. Un intento de inyección fallido puede no dejar rastro más allá de un error de sintaxis de base en el punto de entrada afectado.

La auditoría concreta es la revisión de código anterior. Los comandos grep son un punto de partida, no una auditoría completa: las llamadas multilínea, los alias y las llamadas indirectas requieren revisión manual. Cada resultado necesita una respuesta de una línea sobre si los datos de la petición llegan al argumento.

En los registros de la base, busque instrucciones de esos puntos de entrada cuya cláusula COLLATE o cláusula BETWEEN de ventana contenga comillas, comentarios o palabras clave inesperadas. Trate un resultado como una pista a investigar, no como prueba de compromiso.

Cronología

• 2026-08-27: CakePHP publica el aviso GHSA-vjqc-q4mp-2rvf para CVE-2026-79752, añadiendo ensureSimpleString() a cuatro métodos de FunctionsBuilder cuyos argumentos eran fragmentos concatenados.
• 2026-10-12: Abraxas Labs publica ambos análisis con laboratorios de prueba de concepto públicos, puntuando cada uno 8.1 High con un vector de condición previa autenticada.
• 2026-10-24: Se integran las correcciones para la familia de ventanas (pull request 19735) y los constructores de intercalación (pull request 19726), acreditando a abraxas, SunKimsroul y Akinlabi.
• 2026-10-25: Se escribe el trasplante de la corrección de intercalación a 4.x como pull request 19734.
• 2026-10-30: VulnCheck publica CVE-2026-119418 y CVE-2026-119419, cada uno con CVSS v4.0 9.2 y v3.1 8.1.
• 2026-11-01: CakePHP publica 5.4.4, 5.3.8 y 5.2.16 con ambas correcciones, y 4.6.6 solo con la corrección de intercalación.

Preguntas frecuentes

¿La aplicación CakePHP por defecto expone estos parámetros?

No. El esqueleto oficial cakephp/app no pasa ni offsets de ventana ni nombres de intercalación desde ningún formulario público, según la verificación del investigador. La exposición viene del código de la aplicación que pasa datos de la petición a estos métodos de expresión: el objetivo de la auditoría son sus propios controladores, servicios y generadores de informes.

Mi código pasa literales de intervalo como '1 day' a range(). ¿Lo rompe 5.4.4?

Sí, y el cambio es deliberado. Una cadena con un espacio falla ensureSimpleString() y lanza InvalidArgumentException: envuelva los literales de intervalo en un objeto de expresión, range(new QueryExpression("'1 day'"), new QueryExpression("'10 days'")). La propia suite de pruebas del framework cambió a exactamente esta forma en 5.4.4.

¿Por qué los registros CVE dicen 9.2 mientras el investigador dice 8.1 High?

Ambos coinciden en la puntuación v3.1 de 8.1 pero modelan la condición previa de forma distinta. Los registros CVE usan PR:N con complejidad de ataque alta y un valor de requisitos de ataque, tratando el código de reenvío de la aplicación como la barrera. El investigador usa PR:L con complejidad baja, puntuando la ruta de petición autenticada de una aplicación víctima realista. Ambos describen la misma condición previa: la aplicación debe pasar datos de la petición a los parámetros afectados.

¿Está afectado CakePHP 4.x?

Sí, parcialmente. El fallo de intercalación está corregido en 4.6.6, publicada el 1 de noviembre de 2026. El fallo de ventanas no tiene versión corregida en ninguna rama 4.x: el WindowExpression de 4.6.6 todavía concatena offsets como cadenas sin procesar, y la última versión de la rama 4.5, 4.5.12, es anterior a ambas correcciones. Las aplicaciones en 4.x que pasan datos de la petición a las ventanas deben validar las entradas ellas mismas, como se describe en «¿Cómo lo corrijo?».

¿Composer audit marcará estos CVE?

Todavía no. El comando audit de Composer lee la base de avisos FriendsOfPHP, que no contenía ninguno de los dos CVE al 1 de noviembre de 2026: la comprobación fiable esta semana es la consulta de versión anterior. La base de avisos de GitHub sí replica ambos registros, clasificados como críticos, como entradas no revisadas GHSA-h3r5-88vp-3qm7 y GHSA-6q38-2qcr-3x34.

¿Se está explotando el fallo en entornos reales?

Ninguna fuente informa de ataques al 1 de noviembre de 2026, y ninguno de los dos CVE está en el catálogo KEV de CISA, comprobado contra el canal JSON del catálogo en esa fecha. Los artefactos públicos son reproductores de laboratorio que hablan con el bucle local, no herramientas de ataque dirigidas a objetivos reales.

Encuentre las versiones antiguas del framework en sus repositorios con Ostorlab

El análisis de composición de software de Ostorlab mapea el árbol de dependencias de sus repositorios e imágenes de contenedor. Lista cada proyecto que sigue en CakePHP 5.4.3 o anterior, para programar la actualización a 5.4.4, 5.3.8 o 5.2.16 antes de que una prueba de concepto encuentre su generador de informes.

Referencias

• Registro CVE-2026-119418, CNA VulnCheck, CVSS v4.0 9.2 y v3.1 8.1, créditos a Abraxas Labs y Mark Story: https://www.cve.org/CVERecord?id=CVE-2026-119418 (comprobado el 1 de noviembre de 2026)
• Registro CVE-2026-119419, CNA VulnCheck, CVSS v4.0 9.2 y v3.1 8.1: https://www.cve.org/CVERecord?id=CVE-2026-119419 (comprobado el 1 de noviembre de 2026)
• Espejos en la base de avisos de GitHub, clasificados como críticos, no revisados: https://github.com/advisories/GHSA-h3r5-88vp-3qm7 y https://github.com/advisories/GHSA-6q38-2qcr-3x34 (comprobados el 1 de noviembre de 2026)
• Abraxas Labs, «CakePHP, WindowExpression range/frame SQL injection», 12 de octubre de 2026: https://abraxaslabs.tech/research/cakephp-window-sqli (comprobado el 1 de noviembre de 2026)
• Abraxas Labs, «CakePHP, COLLATE collation SQL injection», 12 de octubre de 2026: https://abraxaslabs.tech/research/cakephp-collate-sqli (comprobado el 1 de noviembre de 2026)
• Laboratorios de prueba de concepto de Abraxas Labs, públicos desde el 12 de octubre de 2026: https://github.com/abraxas/cakephp-window-sqli y https://github.com/abraxas/cakephp-collate-sqli (comprobados el 1 de noviembre de 2026)
• Commit de corrección de la familia de ventanas 18de3e4cdabba049269421bf43c2ccd1a7451565, ADmad, integrado el 24 de octubre de 2026, acreditando a abraxas, SunKimsroul y Akinlabi: https://github.com/cakephp/cakephp/commit/18de3e4cdabba049269421bf43c2ccd1a7451565 (comprobado el 1 de noviembre de 2026)
• Commit de corrección de intercalación ae8c354cf825aeb7090ea4b48ce98142446f3ac9, Mark Story, integrado el 24 de octubre de 2026: https://github.com/cakephp/cakephp/commit/ae8c354cf825aeb7090ea4b48ce98142446f3ac9 (comprobado el 1 de noviembre de 2026)
• Commit de trasplante de la corrección de intercalación a 4.x 21951faea40060dcc5cc1da3159056df66816d3c, escrito el 25 de octubre de 2026: https://github.com/cakephp/cakephp/commit/21951faea40060dcc5cc1da3159056df66816d3c (comprobado el 1 de noviembre de 2026)
• Notas de la versión CakePHP 5.4.4, 1 de noviembre de 2026, nombrando 5.2.16 y 5.3.8 como las otras versiones de corrección de seguridad: https://github.com/cakephp/cakephp/releases/tag/5.4.4 (comprobadas el 1 de noviembre de 2026)
• Comparación de 4.6.5 a 4.6.6, que muestra los archivos de intercalación modificados y ningún cambio en WindowExpression: https://github.com/cakephp/cakephp/compare/4.6.5...4.6.6 (comprobada el 1 de noviembre de 2026)
• WindowExpression antes de la corrección, en el commit citado por el registro CVE: https://github.com/cakephp/cakephp/blob/6f3dd91371ac0698b64024ddb21d57def9fbba91/src/Database/Expression/WindowExpression.php (comprobado el 1 de noviembre de 2026)
• El validador corregido ensureSimpleString() en 5.4.4: https://github.com/cakephp/cakephp/blob/5.4.4/src/Database/Expression/QueryExpression.php (comprobado el 1 de noviembre de 2026)
• La suite de pruebas corregida que envuelve los literales de intervalo en QueryExpression, en 5.4.4: https://github.com/cakephp/cakephp/blob/5.4.4/tests/TestCase/Database/Expression/WindowExpressionTest.php (comprobada el 1 de noviembre de 2026)
• Aviso predecesor GHSA-vjqc-q4mp-2rvf, CVE-2026-79752, publicado el 27 de agosto de 2026: https://github.com/cakephp/cakephp/security/advisories/GHSA-vjqc-q4mp-2rvf (comprobado el 1 de noviembre de 2026)
• Estadísticas de instalación de Packagist para cakephp/cakephp, 21,425,059 en total y 557,686 al mes: https://packagist.org/packages/cakephp/cakephp (comprobadas el 1 de noviembre de 2026)
• Estadísticas de instalación de Packagist para cakephp/database, 29,353,847 en total y 857,825 al mes: https://packagist.org/packages/cakephp/database (comprobadas el 1 de noviembre de 2026)
• Base de avisos de seguridad FriendsOfPHP, que lee composer audit, sin ninguno de los dos CVE a la fecha de comprobación: https://github.com/FriendsOfPHP/security-advisories (comprobada el 1 de noviembre de 2026)
• Canal JSON del catálogo KEV de CISA, comprobado para ambos CVE el 1 de noviembre de 2026 (no incluidos): https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (comprobado el 1 de noviembre de 2026)
• Requisitos de despliegue de PHP OPcache cuando la validación de marcas de tiempo está desactivada: https://www.php.net/manual/en/opcache.configuration.php#ini.opcache.validate-timestamps (comprobado el 1 de noviembre de 2026)