Injection SQL dans CakePHP, corrigée dans 5.4.4 (CVE-2026-119418)

TL;DR

• Deux failles dans les objets d’expression de base de données de CakePHP insèrent des chaînes contrôlées par l’attaquant dans le SQL au lieu de les lier. VulnCheck les a publiées le 30 octobre 2026 sous les références CVE-2026-119418, décalages de fenêtre, et CVE-2026-119419, noms de classement, en créditant Abraxas Labs et Mark Story.
• Une application n’est exposée que si son propre code transmet des données de requête aux paramètres concernés : des décalages via range() ou frame(), ou des noms de classement via StringExpression et IdentifierExpression. Le squelette d’application par défaut n’expose ni les uns ni les autres sur un formulaire public.
• Les deux enregistrements CVE affichent un score CVSS v4.0 de 9,2 et v3.1 de 8,1. Aucune exploitation n’est connue, et aucun des deux CVE n’est dans le catalogue KEV de la CISA au 1er novembre 2026. Des laboratoires de preuve de concept publics sont disponibles depuis le 12 octobre 2026.
• Passez à CakePHP 5.4.4, 5.3.8 ou 5.2.16, toutes publiées le 1er novembre 2026. CakePHP 4.6.6 ne corrige que la faille de classement ; consultez « Comment corriger ? » pour la voie 4.x et la solution de contournement par validation des entrées.

Suis-je concerné ?

Vous êtes exposé quand toutes ces conditions sont réunies :

• Votre application exécute CakePHP jusqu’à 5.4.3, ou une version 5.x ou 4.x sans version corrigée, selon le tableau ci-dessous.
• Votre propre code transmet une valeur contrôlée par la requête à l’un des paramètres concernés. Il s’agit de $start ou $end de WindowExpression::range(), des décalages ou directions de frame(), et des noms de classement passés à new StringExpression(), new IdentifierExpression() ou setCollation().
• Un attaquant peut atteindre par le réseau le chemin de requête qui construit cette requête SQL.

Le modèle de victime du chercheur décrit les deux formes réalistes. La première est un générateur de rapports d’analytique qui transmet une entrée « N derniers jours » à range(). La seconde est une application qui transmet un sélecteur de langue ou de classement aux constructeurs de classement. Le squelette officiel cakephp/app ne transmet aucun des deux : le framework seul ne crée pas l’exposition.

La faille des fenêtres n’est corrigée que dans les trois premières lignes du tableau. Le code source de 4.6.6 accepte encore des décalages de fenêtre sous forme de chaînes brutes, vérifié dans son WindowExpression.php, et la dernière version de la ligne 4.5, 4.5.12 d’août 2026, précède les deux correctifs. La même série de correctifs valide aussi des paramètres voisins que les enregistrements CVE ne décrivent pas : les noms de fonction dans FunctionExpression, les champs de tri d’agrégation dans StringAggExpression, et les chaînes de partition() et orderBy().

Vérifiez ce que vous exécutez, puis auditez le code qui appelle l’API concernée :

# 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

Examinez chaque résultat du grep avec une seule question : un paramètre de requête peut-il atteindre l’argument ? La portée est large. L’enregistrement packagist.org de cakephp/cakephp indique 21 425 059 installations au total et 557 686 sur le dernier mois. Le paquet séparé cakephp/database, qui porte ces classes, indique 29 353 847 installations au total et 857 825 sur le dernier mois. Les deux chiffres ont été vérifiés le 1er novembre 2026.

Comment corriger ?

1. À la racine du projet, exécutez composer update cakephp/cakephp, ou composer update cakephp/database si vous utilisez le paquet de base de données séparé. Avec une contrainte 5.4.*, 5.3.* ou 5.2.*, cela atteint respectivement 5.4.4, 5.3.8 ou 5.2.16.
2. Si votre composer.json épingle une version concernée exacte, montez-la à la version corrigée de votre ligne et relancez la mise à jour.
3. Déployez le répertoire vendor/ mis à jour. Rechargez les workers PHP web ou invalidez OPcache selon votre procédure de déploiement pour éviter de conserver les anciennes classes en cache. Les processus PHP durables, comme les workers de files et les commandes daemonisées, doivent être redémarrés pour évacuer l’ancien code de la mémoire.
4. Sur la ligne 4.6, mettez à jour vers 4.6.6 avec les mêmes commandes ; elle ne corrige que la faille de classement.
5. Attendez-vous à un changement de comportement : les décalages de fenêtre contenant des espaces, comme les littéraux d’intervalle, lèvent désormais une InvalidArgumentException. Consultez la FAQ pour le cas des littéraux d’intervalle.

Si vous ne pouvez pas encore mettre à jour, appliquez la règle du code corrigé à votre propre frontière d’appel :

• Ne passez que des entiers, null, ou des objets ExpressionInterface prédéfinis et de confiance comme décalages de fenêtre.
• Enveloppez vous-même les littéraux d’intervalle dans new QueryExpression("'1 day'").
• Pour les appels directs à frame(), utilisez des constantes du framework pour le type de fenêtre et les deux directions ; ne leur transmettez jamais des chaînes de requête.
• Restreignez les noms de classement à une liste d’autorisation définie par votre application.

Cette solution de contournement ne couvre que vos points d’appel. Tout code tiers appelant la même API avec des données de requête reste exposé : traitez-la comme un dépannage pour les deux CVE en attendant la mise à jour planifiée.

Quelle est la cause racine ?

Les objets d’expression traitent plusieurs arguments du constructeur de requête comme des fragments SQL plutôt que comme des valeurs : le binder figure dans chaque signature mais ne lie jamais ces chaînes.

Le constructeur de requêtes de CakePHP sépare les valeurs liées du SQL structurel, et en août 2026 il a déjà appris cette leçon une fois. CVE-2026-79752 a placé ensureSimpleString() sur quatre méthodes de FunctionsBuilder dont les arguments étaient des fragments concaténés. Les décalages de fenêtre et les noms de classement ne figuraient pas sur cette liste, et Abraxas Labs a trouvé les deux reliquats dans la passe du 12 octobre 2026 qui a suivi le correctif.

La faille des fenêtres se situe dans buildOffsetSql(), qui assemble la clause BETWEEN de la fenêtre 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,
    );
}

Le $binder figure dans la signature mais n’agit que si le décalage est déjà un objet d’expression. Une chaîne simple, y compris une issue de $request->getQuery('start'), passe par sprintf() dans RANGE BETWEEN ... PRECEDING à l’intérieur de la clause OVER.

Les méthodes sœurs rows() et groups() prennent un ?int et ne peuvent pas transporter cela. range() prend une chaîne parce que les littéraux d’intervalle ressemblent à '1 day', et le propre test du framework affirmait range("'1 day'", "'10 days'") avant le correctif, comme le chercheur l’a documenté.

La faille de classement a la même forme, avec la valeur liée sûre et le second argument brut :

// 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;
}

La valeur de la chaîne est liée à un placeholder. Le classement est concaténé après COLLATE, et IdentifierExpression::sql() l’insère de la même façon. Sous Postgres, l’enveloppement des identifiants du pilote est un rogner-puis-envelopper, '"' . trim($collation, '"') . '"' selon le chercheur : un guillemet double imbriqué referme donc l’identifiant trop tôt, et tout ce qui suit échappe à l’instruction prévue.

Comment la faille est-elle exploitée ?

Les laboratoires de preuve de concept publics montrent les deux mécanismes de bout en bout :

1. L’attaquant identifie un paramètre de requête atteignable que l’application transmet à range(), frame() ou un constructeur de classement. C’est toute la condition préalable ; aucun point de terminaison du framework n’expose ces paramètres de lui-même.
2. Pour la faille des fenêtres, une chaîne de décalage forgée arrive telle quelle entre RANGE BETWEEN et PRECEDING. Le laboratoire du chercheur montre le fragment apparaissant dans le SQL compilé, non lié et non quoté. C’est une démonstration de compilation seule sur SQLite, sans lecture de table démontrée.
3. Pour la faille de classement, le laboratoire Postgres du chercheur exécute l’injection. La valeur de contrôle collation=C se compile en COLLATE "C". Le payload C" AS text)) || (SELECT note FROM lab_secret LIMIT 1) -- est public dans l’article du chercheur. Son guillemet imbriqué sort du rogner-puis-envelopper, et le commentaire final absorbe le texte de fermeture de Cake.
4. Le SELECT injecté renvoie une ligne témoin, et le laboratoire rapporte la valeur lue xCAKEPHP-COLLATE-SQLI-WITNESS avec le placeholder lié contenant encore le littéral simple. Le premier argument lié n’a jamais été le trou ; c’était le second.

Les deux laboratoires sont sur GitHub, liés dans les références, et les articles du chercheur les décrivent comme des reproductions en boucle locale uniquement.

Comment se déroule l’attaque ?

En une phrase : un paramètre de requête atteint un constructeur d’expression, la valeur est concaténée comme fragment SQL au lieu d’être liée, et la requête s’exécute avec les privilèges de la base de données de l’application.

Que peut faire un attaquant ?

• Exécuter du SQL avec les privilèges de la connexion à la base de l’application. Les deux enregistrements CVE notent un impact intégral en confidentialité, intégrité et disponibilité sur les données compromises.
• Lire des données. Le laboratoire de classement sur Postgres démontre un SELECT qui renvoie une ligne d’une table que l’application ne comptait pas exposer.
• Modifier des données. Le chercheur le qualifie d’inféré plutôt que de démontré : la même injection s’exécute sous le rôle de la connexion, donc des écritures sont possibles, mais le laboratoire ne prouve qu’un oracle de lecture.
• Échouer visiblement sur une entrée malformée. Un payload qui ne s’analyse pas produit une erreur de base sur cette requête, ce qui est aussi ce qu’une tentative de sondage peut laisser derrière elle.

Conditions nécessaires à l’attaquant : une application qui transmet des données de requête aux paramètres concernés, l’accessibilité réseau de ce chemin, et rien d’autre. Aucune barrière d’authentification du framework ne s’applique aux paramètres eux-mêmes. Le caractère authentifié ou non du point de terminaison vulnérable dépend de l’application. C’est aussi pourquoi le chercheur note les failles avec PR:L tandis que les enregistrements CVE notent PR:N avec une complexité d’attaque élevée.

Pourquoi le correctif fonctionne-t-il ?

Le commit 18de3e4c pour la famille des fenêtres et le commit ae8c354c pour les constructeurs de classement ajoutent QueryExpression::ensureSimpleString() à chaque argument concerné : une chaîne non simple lève une exception avant toute construction de 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 règle autorise un jeton éventuellement quoté fait de lettres, chiffres, tirets bas et points, et rien d’autre. Les chaînes non simples, comme les littéraux d’intervalle contenant des espaces, lèvent une InvalidArgumentException. Le validateur applique une liste de caractères autorisés, pas un filtre de mots-clés SQL. Les chaînes qui ont besoin de structure, comme les littéraux d’intervalle, doivent arriver sous forme d’objets d’expression que l’appelant a construits délibérément.

Le correctif est complet pour ces paramètres sur les lignes 5.2, 5.3 et 5.4. La série de correctifs valide aussi le nom de FunctionExpression dans son constructeur et setName(), StringAggExpression::setAggregateOrderBy(), WindowExpression::partition() et orderBy(), et les deux passeurs de classement. Il n’est pas complet pour les lignes 4.x. La version 4.6.6 ne porte que le report du correctif de classement, et ses WindowExpression::range(), frame() et buildOffsetSql() acceptent et concatènent encore des chaînes brutes, vérifié dans le code source de 4.6.6.

Comment vérifier si j’ai été compromis ?

Aucun indicateur de compromis n’est publié pour ces failles, et aucune exploitation n’a été signalée nulle part au 1er novembre 2026. Une tentative d’injection échouée peut ne laisser aucune trace au-delà d’une erreur de syntaxe de base sur le point de terminaison concerné.

L’audit concret est la revue de code ci-dessus. Les commandes grep sont un point de départ, pas un audit complet : les appels sur plusieurs lignes, les alias et les appels indirects exigent une revue manuelle. Chaque résultat exige une réponse en une ligne sur la question de savoir si des données de requête atteignent l’argument.

Dans les journaux de base, cherchez des instructions issues de ces points de terminaison dont la clause COLLATE ou la clause BETWEEN de fenêtre contient des guillemets, des commentaires ou des mots-clés inattendus. Traitez un résultat comme une piste à investiguer plutôt que comme une preuve de compromis.

Chronologie

• 2026-08-27 : CakePHP publie l’avis GHSA-vjqc-q4mp-2rvf pour CVE-2026-79752, ajoutant ensureSimpleString() à quatre méthodes de FunctionsBuilder dont les arguments étaient des fragments concaténés.
• 2026-10-12 : Abraxas Labs publie les deux articles techniques avec des laboratoires de preuve de concept publics, notant chacun 8,1 High avec un vecteur à précondition authentifiée.
• 2026-10-24 : Les correctifs sont intégrés pour la famille des fenêtres (requête de tirage 19735) et les constructeurs de classement (requête de tirage 19726), en créditant abraxas, SunKimsroul et Akinlabi.
• 2026-10-25 : Le report du correctif de classement vers 4.x est rédigé comme requête de tirage 19734.
• 2026-10-30 : VulnCheck publie CVE-2026-119418 et CVE-2026-119419, chacune avec un score CVSS v4.0 9,2 et v3.1 8,1.
• 2026-11-01 : CakePHP publie 5.4.4, 5.3.8 et 5.2.16 avec les deux correctifs, et 4.6.6 avec le seul correctif de classement.

FAQ

L’application CakePHP par défaut expose-t-elle ces paramètres ?

Non. Le squelette officiel cakephp/app ne transmet ni décalages de fenêtre ni noms de classement depuis un formulaire public, selon la vérification du chercheur. L’exposition vient du code applicatif qui passe des données de requête à ces méthodes d’expression : la cible de l’audit est donc vos propres contrôleurs, services et générateurs de rapports.

Mon code passe des littéraux d’intervalle comme '1 day' à range(). La 5.4.4 le casse-t-elle ?

Oui, et le changement est délibéré. Une chaîne contenant une espace échoue à ensureSimpleString() et lève une InvalidArgumentException : enveloppez donc les littéraux d’intervalle dans un objet d’expression, range(new QueryExpression("'1 day'"), new QueryExpression("'10 days'")). La propre suite de tests du framework est passée à exactement cette forme en 5.4.4.

Pourquoi les enregistrements CVE indiquent 9,2 alors que le chercheur indique 8,1 High ?

Les deux s’accordent sur le score v3.1 de 8,1 mais modélisent la précondition différemment. Les enregistrements CVE utilisent PR:N avec une complexité d’attaque élevée et une valeur d’exigences d’attaque, traitant le code de transmission de l’application comme la barrière. Le chercheur utilise PR:L avec une complexité faible, en notant le chemin de requête authentifié d’une application victime réaliste. Les deux décrivent la même précondition : l’application doit transmettre des données de requête aux paramètres concernés.

CakePHP 4.x est-il concerné ?

Oui, partiellement. La faille de classement est corrigée dans 4.6.6, publiée le 1er novembre 2026. La faille des fenêtres n’a aucune version corrigée dans aucune ligne 4.x : le WindowExpression de 4.6.6 concatène encore des décalages en chaînes brutes, et la dernière version de la ligne 4.5, 4.5.12, précède les deux correctifs. Les applications 4.x qui transmettent des données de requête aux fenêtres doivent valider les entrées elles-mêmes, comme décrit dans « Comment corriger ? ».

Composer audit signalera-t-il ces CVE ?

Pas encore. La commande audit de Composer lit la base d’avis FriendsOfPHP, qui ne portait aucun des deux CVE au 1er novembre 2026 : la vérification fiable cette semaine est donc la requête de version ci-dessus. La base d’avis GitHub duplique toutefois les deux enregistrements, classés critiques, comme entrées non relues GHSA-h3r5-88vp-3qm7 et GHSA-6q38-2qcr-3x34.

La faille est-elle exploitée dans la nature ?

Aucune source ne rapporte d’attaque au 1er novembre 2026, et aucun des deux CVE ne figure dans le catalogue KEV de la CISA, vérifié contre le flux JSON du catalogue à cette date. Les artefacts publics sont des reproducteurs de laboratoire qui parlent en boucle locale, pas des outils d’attaque visant des cibles réelles.

Trouvez les anciennes versions du framework dans vos dépôts avec Ostorlab

L’analyse de la composition logicielle d’Ostorlab cartographie l’arbre de dépendances de vos dépôts et images de conteneurs. Elle liste chaque projet encore sur CakePHP 5.4.3 ou antérieur, pour planifier la mise à jour 5.4.4, 5.3.8 ou 5.2.16 avant qu’une preuve de concept ne trouve votre générateur de rapports.

Références

• Enregistrement CVE-2026-119418, CNA VulnCheck, CVSS v4.0 9,2 et v3.1 8,1, crédits à Abraxas Labs et Mark Story : https://www.cve.org/CVERecord?id=CVE-2026-119418 (vérifié le 1er novembre 2026)
• Enregistrement CVE-2026-119419, CNA VulnCheck, CVSS v4.0 9,2 et v3.1 8,1 : https://www.cve.org/CVERecord?id=CVE-2026-119419 (vérifié le 1er novembre 2026)
• Miroirs dans la base d’avis GitHub, classés critiques, non relus : https://github.com/advisories/GHSA-h3r5-88vp-3qm7 et https://github.com/advisories/GHSA-6q38-2qcr-3x34 (vérifiés le 1er novembre 2026)
• Abraxas Labs, « CakePHP, WindowExpression range/frame SQL injection », 12 octobre 2026 : https://abraxaslabs.tech/research/cakephp-window-sqli (vérifié le 1er novembre 2026)
• Abraxas Labs, « CakePHP, COLLATE collation SQL injection », 12 octobre 2026 : https://abraxaslabs.tech/research/cakephp-collate-sqli (vérifié le 1er novembre 2026)
• Laboratoires de preuve de concept d’Abraxas Labs, publics depuis le 12 octobre 2026 : https://github.com/abraxas/cakephp-window-sqli et https://github.com/abraxas/cakephp-collate-sqli (vérifiés le 1er novembre 2026)
• Commit de correctif de la famille des fenêtres 18de3e4cdabba049269421bf43c2ccd1a7451565, ADmad, intégré le 24 octobre 2026, créditant abraxas, SunKimsroul et Akinlabi : https://github.com/cakephp/cakephp/commit/18de3e4cdabba049269421bf43c2ccd1a7451565 (vérifié le 1er novembre 2026)
• Commit de correctif de classement ae8c354cf825aeb7090ea4b48ce98142446f3ac9, Mark Story, intégré le 24 octobre 2026 : https://github.com/cakephp/cakephp/commit/ae8c354cf825aeb7090ea4b48ce98142446f3ac9 (vérifié le 1er novembre 2026)
• Commit de report du correctif de classement vers 4.x 21951faea40060dcc5cc1da3159056df66816d3c, rédigé le 25 octobre 2026 : https://github.com/cakephp/cakephp/commit/21951faea40060dcc5cc1da3159056df66816d3c (vérifié le 1er novembre 2026)
• Notes de version de CakePHP 5.4.4, 1er novembre 2026, nommant 5.2.16 et 5.3.8 comme les autres versions de correctif de sécurité : https://github.com/cakephp/cakephp/releases/tag/5.4.4 (vérifiées le 1er novembre 2026)
• Comparaison de 4.6.5 à 4.6.6, montrant les fichiers de classement modifiés et aucune modification de WindowExpression : https://github.com/cakephp/cakephp/compare/4.6.5...4.6.6 (vérifiée le 1er novembre 2026)
• WindowExpression avant le correctif, au commit cité par l’enregistrement CVE : https://github.com/cakephp/cakephp/blob/6f3dd91371ac0698b64024ddb21d57def9fbba91/src/Database/Expression/WindowExpression.php (vérifié le 1er novembre 2026)
• Le validateur corrigé ensureSimpleString() en 5.4.4 : https://github.com/cakephp/cakephp/blob/5.4.4/src/Database/Expression/QueryExpression.php (vérifié le 1er novembre 2026)
• La suite de tests corrigée enveloppant les littéraux d’intervalle dans QueryExpression, en 5.4.4 : https://github.com/cakephp/cakephp/blob/5.4.4/tests/TestCase/Database/Expression/WindowExpressionTest.php (vérifiée le 1er novembre 2026)
• Avis prédécesseur GHSA-vjqc-q4mp-2rvf, CVE-2026-79752, publié le 27 août 2026 : https://github.com/cakephp/cakephp/security/advisories/GHSA-vjqc-q4mp-2rvf (vérifié le 1er novembre 2026)
• Statistiques d’installation Packagist pour cakephp/cakephp, 21 425 059 au total et 557 686 par mois : https://packagist.org/packages/cakephp/cakephp (vérifiées le 1er novembre 2026)
• Statistiques d’installation Packagist pour cakephp/database, 29 353 847 au total et 857 825 par mois : https://packagist.org/packages/cakephp/database (vérifiées le 1er novembre 2026)
• Base d’avis de sécurité FriendsOfPHP, lue par composer audit, ne portant aucun des deux CVE à la date de vérification : https://github.com/FriendsOfPHP/security-advisories (vérifiée le 1er novembre 2026)
• Flux JSON du catalogue KEV de la CISA, vérifié pour les deux CVE le 1er novembre 2026 (absents) : https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (vérifié le 1er novembre 2026)
• Exigences de déploiement PHP OPcache lorsque la validation des horodatages est désactivée : https://www.php.net/manual/en/opcache.configuration.php#ini.opcache.validate-timestamps (vérifié le 1er novembre 2026)