Ubuntu annule à nouveau son correctif nginx pour CVE-2026-42533

Ubuntu a publié deux avis nginx le 19 août 2026, faciles à mal interpréter si l'on ne fait que scanner à la recherche du mot « corrigé ». D'abord, USN-8563-3 a annoncé qu'Ubuntu disposait d'un meilleur correctif pour CVE-2026-42533 après une régression précédente. Plus tard le même jour, USN-8563-4 a indiqué que cette mise à jour introduisait elle aussi une régression, et Ubuntu a de nouveau annulé le correctif de CVE-2026-42533 pendant que l'enquête se poursuit.

Pour les équipes qui font tourner nginx via les paquets standards d'Ubuntu sur 22.04 LTS, 24.04 LTS ou 26.04 LTS, ce n'est pas un simple avis « faites un apt upgrade et n'y pensez plus ». Le vrai travail consiste à confirmer quelle version de paquet tourne sur chaque hôte, à tester le retour arrière dans les environnements qui utilisent des modules nginx tiers, et à déterminer si votre configuration nginx exploite réellement le motif vulnérable.

Ce qui s'est passé

La série concernée est la lignée USN-8563. USN-8563-1, publié le 20 juillet, couvrait trois problèmes nginx : CVE-2026-42533, CVE-2026-56434 et CVE-2026-60005. Celui qui compte le plus pour cette mise à jour est CVE-2026-42533, décrit comme un dépassement de tampon impliquant des directives map avec correspondance par expression régulière et variables de capture.

Le premier suivi d'Ubuntu, USN-8563-2, avait annulé le correctif de CVE-2026-42533 parce que le patch pouvait provoquer une régression. Le 19 août, USN-8563-3 a annoncé qu'Ubuntu disposait d'un meilleur correctif pour ce CVE et a listé de nouvelles versions de paquets pour 26.04 LTS, 24.04 LTS et 22.04 LTS.

Puis USN-8563-4 est arrivé plus tard le 19 août. Cet avis indique que USN-8563-3 avait introduit une régression dans certains environnements et que la mise à jour annule le correctif de CVE-2026-42533 en attendant une enquête plus approfondie. Les versions de paquets dans USN-8563-4 sont plus récentes que celles de USN-8563-3 : 1.28.3-2ubuntu1.10 pour Ubuntu 26.04 LTS, 1.24.0-2ubuntu7.17 pour Ubuntu 24.04 LTS, et 1.18.0-6ubuntu14.20 pour Ubuntu 22.04 LTS.

Ce mouvement de version est le piège. Un numéro de paquet plus récent ne signifie pas que le correctif de CVE-2026-42533 est présent. Dans ce cas précis, l'avis d'Ubuntu lui-même indique que la mise à jour la plus récente annule ce correctif spécifique.

Le motif vulnérable

L'avis de sécurité amont de nginx décrit CVE-2026-42533 comme un « dépassement de tampon lors de l'utilisation de map et d'expressions régulières », avec une sévérité qualifiée de majeure. En amont, les versions nginx Open Source 1.31.3+ et 1.30.4+ sont marquées comme non vulnérables, et les versions de 0.9.6 à 1.31.2 comme vulnérables.

La page CVE d'Ubuntu donne la condition opérationnellement utile : le problème implique une directive map utilisant une correspondance par expression régulière, où une expression de type chaîne référence les variables de capture regex du map avant de référencer la variable de sortie du map. Elle mentionne aussi un chemin alternatif impliquant une variable non mise en cache dans une expression de type chaîne, sous certaines conditions. L'impact décrit est un dépassement de tampon de tas dans le processus worker, pouvant entraîner un redémarrage, avec une possibilité d'exécution de code lorsque l'ASLR est désactivé ou contourné.

Cela ne signifie pas que tous les hôtes nginx sous Ubuntu sont exposés de la même manière. Un serveur de fichiers statiques sans usage pertinent de map en regex est très différent d'un proxy d'edge complexe truffé de configuration générée, de modules tiers et de variables templatées. Mais cela signifie que « nous faisons tourner le paquet nginx d'Ubuntu » n'est pas une réponse suffisante.

Pourquoi cela mérite votre attention

C'est le genre de cycle de correctifs qui déjoue les tableaux de bord habituels. Votre scanner de vulnérabilités peut voir un paquet Ubuntu plus récent et en déduire un progrès. Votre système de gestion du changement peut voir « mise à jour de sécurité appliquée ». Le propriétaire du service peut voir nginx toujours en fonctionnement et considérer que le travail est terminé.

La réalité est plus nuancée : Ubuntu privilégie l'annulation d'une régression plutôt que le maintien de ce correctif CVE en particulier, du moins temporairement. C'est peut-être le bon compromis pour l'archive côté éditeur, mais cela renvoie l'évaluation du risque à l'opérateur.

Si vous n'utilisez que des modules nginx standards avec une configuration simple, la régression ne vous a peut-être jamais concerné. Si vous utilisez nginx-extras, des modules dynamiques, des modules personnalisés, ou des modules fournis par un éditeur tiers compilés contre l'ABI nginx d'Ubuntu, l'historique de la régression compte davantage. Les notes CVE d'Ubuntu mentionnent spécifiquement que les correctifs précédents ont modifié l'ABI et pouvaient casser les modules tiers.

Ce que cela change en pratique

Commencez par inventorier les versions de paquets, pas seulement le statut CVE. Sur les hôtes concernés, exécutez :

apt-cache policy nginx nginx-core nginx-full nginx-extras nginx-light
nginx -V

Si vous voyez les versions de USN-8563-4, considérez CVE-2026-42533 comme annulé selon l'avis actuel d'Ubuntu. Si vous voyez les versions de USN-8563-3, testez soigneusement la régression ayant causé le retour arrière ultérieur. Si vous faites tourner nginx en amont plutôt que les paquets Ubuntu, comparez avec les versions non vulnérables de l'amont plutôt qu'avec le versionnage des paquets Ubuntu.

Ensuite, recherchez dans la configuration le motif qui compte :

grep -R "map .*~" /etc/nginx /usr/share/nginx 2>/dev/null
grep -R "\$[0-9]" /etc/nginx /usr/share/nginx 2>/dev/null
grep -R "map" /etc/nginx/sites-enabled /etc/nginx/conf.d 2>/dev/null

Ces commandes sont volontairement larges. Elles ne prouvent pas l'exposition. Elles vous donnent une liste des endroits où l'usage de map en regex et des variables de capture mérite une revue.

Validez ensuite le rechargement et le comportement des modules avant tout déploiement à grande échelle :

nginx -t
systemctl reload nginx
journalctl -u nginx --since "30 minutes ago"

Pour les proxys de production, ajoutez un petit test synthétique qui sollicite des noms d'hôtes, chemins, en-têtes et routes amont représentatifs dépendant de map. Le pire scénario d'échec ici n'est pas seulement « nginx ne démarre pas ». C'est un chemin de configuration qui fonctionne en pré-production jusqu'à ce qu'une expansion de variable rarement utilisée ou un chemin de module tiers soit sollicité.

Si vous ne pouvez pas attendre le prochain correctif d'Ubuntu et que le motif de configuration concerné est présent, envisagez des mesures d'atténuation réduisant la dépendance à la forme risquée de map. Cela peut signifier réécrire un map regex en clés explicites, éviter la réutilisation de variables de capture dans des expressions de type chaîne, ou déplacer la logique en amont, dans le routage applicatif, où elle peut être testée avec une couverture de tests unitaires et d'intégration classique. Je ne me précipiterais pas vers une compilation de nginx depuis les sources sur chaque serveur, sauf si vous disposez déjà d'un chemin de packaging maîtrisé ; cela crée souvent un problème de maintenance pire que le mal qu'on cherche à éviter.

Surveillez le prochain avis, pas seulement le scanner

Cette histoire rappelle que les avis de sécurité des distributions sont des machines à états, pas des événements isolés. USN-8563-3 et USN-8563-4 ont tous deux été publiés le 19 août, et le second change la portée pratique du premier.

Pour l'instant, je classerais ceci comme un suivi nginx ciblé pour les parcs Ubuntu LTS. Confirmez les versions. Passez en revue l'usage de map en regex. Exercez les rechargements et les chemins de modules. Gardez un œil sur le prochain avis Ubuntu concernant CVE-2026-42533 avant de clore le ticket comme entièrement corrigé.

Sources

• Ubuntu Security Notice USN-8563-4: nginx regression
• Ubuntu Security Notice USN-8563-3: nginx vulnerability
• Ubuntu CVE-2026-42533 tracker
• nginx security advisories
• LWN: Ubuntu alert USN-8563-4
• LWN: Security updates for Thursday
• Vulners: USN-8563-4 nginx regression