InfoOn a lu la doc

Struts : l'étiquette dit « modéré », la notice ne met pas la condition au même endroit

Le bulletin S2-075, mis à jour le 2 octobre, note CVE-2026-104711 comme modéré : une injection OGNL dans l'ancien action mapper REST, avec une exécution de code possible. Le mail du 5 octobre répète « moderate ». Sa liste de versions 7 ne réécrit pas la condition d'allowlist que le paragraphe, et le tableau du wiki, portent.

L'étiquette sur le flacon est courte. Elle dit modéré. Tu la lis au comptoir, et tu ranges le flacon avec les autres qui ne crient pas. La notice, dépliée, parle d'une exécution de code possible, d'un mapper que tout le monde n'utilise pas, et d'une condition qui n'est pas imprimée sur toutes les lignes de version. Si tu ne déplies rien, tu as le mot de l'étiquette. Tu n'as pas l'endroit où la condition est écrite, ni l'endroit où elle manque.

Le bulletin S2-075 a été créé par Lukasz Lenart, dernière mise à jour le 2 octobre 2026. L'objet : une injection OGNL dans l'ancien action mapper REST, qui peut mener à une exécution de code à distance. Le 5 octobre 2026, à 07 h 11 min 49 s UTC, le même Lukasz Lenart envoie le mail à oss-security. Objet : CVE-2026-104711. Les deux papiers parlent du même numéro. Ils ne rangent pas la condition au même endroit, et ils ne donnent pas le même mode d'emploi.

Le mot sur l'étiquette

Le tableau du wiki a une case, « Maximum security rating », et le mot dedans est Moderate. L'impact, dans la case d'à côté : Possible Remote Code Execution vulnerability. Le mail, lui, ouvre par Severity: moderate. Pas de score. Pas de vecteur. Je n'en colle pas un par-dessus. Le mot choisi par Apache, des deux côtés, est modéré. La phrase d'impact, des deux côtés, parle d'une exécution de code possible, pas certaine, et pas pour n'importe quelle application.

Le problème, dans le wiki : si l'application est configurée pour utiliser l'ancien action mapper REST, une requête fabriquée peut injecter une expression OGNL, qui peut mener à une exécution de code. Le mail reprend la formulation du CVE, un peu plus longue : mauvaise neutralisation d'éléments spéciaux dans un énoncé de langage d'expression. Le nom de classe est dans le mail. Le geste décrit est le même. Le rapporteur, des deux côtés : LeaveSong. Le wiki dit « Reporters ». Le mail dit « finder ».

Qui n'est pas concerné est écrit en note sur le wiki, et dans le paragraphe du mail. Les applications qui utilisent le mapper par défaut, le mapper restful2, ou le plugin REST de Struts, ne sont pas touchées. Struts 7 n'est pas touché dans sa configuration par défaut, là où l'allowlist OGNL est activée. Le wiki le met dans la note. Le mail le met dans la description. Jusque-là, les deux notices concordent. C'est la liste, plus haut dans le mail, qui ne répète pas tout.

La ligne 7, selon la page

Le tableau du wiki nomme quatre plages, et il qualifie la dernière. Struts 2.0.0 à 2.3.37, marqués EOL. Struts 2.5.0 à 2.5.33, marqués EOL. Struts 6.0.0 à 6.11.0. Struts 7.0.0 à 7.3.0, seulement quand l'allowlist OGNL est désactivée. La condition est dans la cellule, sur la même ligne que les numéros.

Le mail a aussi une liste, avant le paragraphe. Quatre puces. Les mêmes bornes : 2.0.0 à 2.3.37, 2.5.0 à 2.5.33, 6.0.0 à 6.11.0, 7.0.0 à 7.3.0. Pas de EOL sur les puces. Pas de « seulement si » sur la puce 7. La condition d'allowlist arrive plus bas, dans la description : Struts 7 n'est touché que lorsque l'allowlist est désactivée, et elle est activée par défaut. Si tu lis les puces et que tu t'arrêtes, la ligne 7 a l'air aussi nue que la ligne 6. Le paragraphe, et le tableau du wiki, disent autre chose. Je ne recolle pas la puce au tableau. Je les pose l'une sous l'autre.

Les branches marquées EOL sur le wiki n'ont pas, dans ces deux documents, un numéro de correctif dans leur propre série. Les numéros qui corrigent, nommés, sont plus haut.

La notice a un contournement, le mail a une mise à jour

La recommandation du wiki : monter au moins à Struts 7.4.0, ou au moins à Struts 6.12.0 sur la ligne de maintenance 6, ou quitter l'ancien action mapper REST. L'ordre imprime 7.4.0 d'abord. Le mail, lui, dit que les utilisateurs sont invités à passer à la version 6.12.0 ou 7.4.0, qui corrige le problème. Pas de « at least » dans cette phrase. Pas de « ou migrer » dans le corps du mail. Le 6.12.0 y est cité en premier.

Le contournement est une section du wiki, pas un paragraphe du mail. Utiliser le mapper par défaut, restful2, ou le plugin REST, à la place de l'ancien. Les anciens mappers REST sont dépréciés, écrit le wiki dans la solution, et il suggère de migrer vers le plugin. Le mail ne déprécie pas. Il pointe vers le bulletin, vers struts.apache.org, et vers la fiche CVE.

Une autre section du wiki n'a pas d'équivalent dans le mail : la rétrocompatibilité. Le changement est compatible pour les applications qui utilisent des noms d'actions conventionnels. Je laisse la phrase sur le wiki. Je ne la fais pas dire par le mail du 5 octobre.

✍️ À toi : le mapper que ton application charge vraiment, et si tu es sur une 7 avec l'allowlist encore allumée. L'étiquette dit modéré pour tout le monde. Ta config, elle, est dans un fichier.

Les deux papiers disent modéré, et les deux décrivent une exécution de code possible si l'ancien mapper REST est celui qui est branché. Struts 7, par défaut, est écarté, parce que l'allowlist est activée. Cette condition est dans le tableau du 2 octobre et dans le paragraphe du 5. Elle n'est pas sur la puce du mail. Le contournement, lui, est écrit sur la notice. Le mail, ce jour-là, ne te tend que les deux numéros de version.