needhelp
← Retour au blog

NGINX Rift (CVE-2026-42945) : Un dépassement de tas vieux de 18 ans dans le module de réécriture

par xingwangzhe
NGINX
CVE
Sécurité
RCE
Dépassement de Tas
Serveur Web

NGINX Rift (CVE-2026-42945, CVSS 9.2) : Un dépassement critique de tampon dans le tas dans le module de réécriture de NGINX, découvert de manière autonome par le système d’analyse IA de depthfirst. Introduit en 2008 et affectant 18 ans de versions de NGINX, il permet à un attaquant non authentifié d’exécuter du code à distance avec une seule requête HTTP manipulée.

La Vulnerabilité Qui Était Cachée à la Vue de Tous

Le 13 mai 2026, F5 et depthfirst ont divulgué conjointement CVE-2026-42945 — un dépassement critique de tampon dans le tas dans le module ngx_http_rewrite_module de NGINX. La vulnérabilité était présente dans le code source depuis 2008, introduite dans NGINX 0.6.27, affectant chaque version ultérieure jusqu’à 1.30.0.

Ce qui rend cette découverte particulièrement remarquable est comment elle a été trouvée : non pas par un chercheur humain auditant manuellement le code, mais par le système autonome d’analyse de vulnérabilités de depthfirst. Le système d’IA a été pointé vers le code source de NGINX, et en six heures, il a signalé le problème de dépassement de tas qui avait échappé à la détection humaine pendant 18 ans.

MétriqueValeur
CVECVE-2026-42945
CVSS v4.09.2 (Critique)
Découvert pardepthfirst (analyse IA autonome)
Introduit2008 (NGINX 0.6.27)
Caché pendant18 ans
Type de vulnérabilitéDépassement de tampon dans le tas (divergence de longueur en deux passes)
Authentification requiseAucune
ImpactExécution de code à distance (RCE) ou crash du worker (DoS)
Version corrigéeNGINX 1.31.0 / 1.30.1

Versions Affectées

La vulnérabilité touche presque toutes les gammes de produits NGINX :

ProduitVersions Affectées
NGINX Open Source0.6.27 jusqu’à 1.30.0
NGINX PlusR32 jusqu’à R36
NGINX Instance Manager2.16.0 jusqu’à 2.21.1
F5 NGINX App Protect WAF4.9.0–4.16.0, 5.1.0–5.8.0
NGINX Ingress Controller3.5.0–3.7.2, 4.0.0–4.0.1, 5.0.0–5.4.1
NGINX Gateway Fabric1.3.0–1.6.2, 2.0.0–2.5.1

Étant donné que NGINX alimente environ un tiers de tous les sites Web dans le monde, le rayon d’explosion de cette vulnérabilité est énorme.

Analyse Technique Approfondie

La Conception en Deux Passes

Pour comprendre le bug, vous devez comprendre le moteur de scripts de NGINX. Lorsque NGINX évalue une directive rewrite ou set, il fonctionne en deux passes :

  1. Passe de longueur (ngx_http_script_len_code) : Calcule la taille totale du tampon nécessaire pour contenir la sortie finale
  2. Passe de copie (ngx_http_script_run / ngx_http_script_copy_code) : Alloue un tampon de cette taille et écrit les données réelles

Le contrat est simple : la passe 1 vous dit exactement combien d’octets allouer, la passe 2 écrit exactement ce nombre d’octets. Si les deux ne correspondent pas — vous obtenez un dépassement de tas.

Cause Racine : Le Drapeau is_args Orphelin

La vulnérabilité se trouve dans src/http/ngx_http_script.c. Lorsque la chaîne de remplacement d’une directive rewrite contient un point d’interrogation (?), la fonction ngx_http_script_start_args_code définit un drapeau sur le moteur de scripts :

e->is_args = 1;

Ce drapeau signale que les composants URI ultérieurs doivent être traités comme des arguments de requête et échappés URI (ex. + → %2B, & → %26).

Le problème : ce drapeau n’est jamais réinitialisé. Il reste défini sur le moteur de scripts principal (e) pour le reste du traitement de la requête.

La Divergence

Lorsqu’une directive set ultérieure référence un groupe de capture regex (ex. $1), le moteur de scripts l’évalue. Pendant la passe de longueur, ngx_http_script_complex_value_code crée un sous-moteur frais remis à zéro (le) :

ngx_http_script_len_code_ctx_t  le;
ngx_memzero(&le, sizeof(ngx_http_script_len_code_ctx_t));

Puisque le.ip et le.is_args sont tous deux nuls, la fonction de calcul de longueur ngx_http_script_copy_capture_len_code prend la branche else — elle retourne la longueur de capture brute, non échappée.

Pendant la passe de copie, le code s’exécute sur le moteur principal (e), où e->is_args est toujours 1. La fonction de copie ngx_http_script_copy_capture_code entre dans une branche différente :

if (e->is_args) {
    // Échappe l'URI : étend + % & de 1 octet à 3 octets
    n = ngx_escape_uri(NULL, src, len, NGX_ESCAPE_ARGS);
    // ...alloue et écrit la version échappée
}

Chaque caractère échappable dans l’URI contrôlée par l’attaquant (+, %, &) passe de 1 octet à 3 octets. Le tampon a été dimensionné pour la longueur brute (non échappée) — l’écriture dépasse l’allocation.

// La passe de longueur mesure :  raw_len octets
// La passe de copie écrit :      raw_len + 2*N octets  (où N = caractères échappables)
//                                 ↑↑↑  DÉPASSEMENT DE TAS

C’est une violation classique du contrat en deux passes, rendue possible parce que l’état is_args a été défini par une directive rewrite complètement non liée et n’a jamais été nettoyé.

Exploitation

Les chercheurs de depthfirst ont développé une preuve de concept fonctionnelle démontrant une RCE non authentifiée contre NGINX avec ASLR désactivé. Les propriétés clés qui rendent l’exploitation pratique :

PropriétéDétail
Taille du dépassementEntièrement contrôlée par l’attaquant (nombre de +, &, % dans l’URI)
Données du dépassementContrôlées par l’attaquant (contenu URI échappé)
ReproductibilitéDéterministe — la même requête dépasse toujours de la même façon
Budget de tentativesInfini — les workers plantés réapparaissent avec la même disposition de tas
AuthentificationAucune requise — accessible depuis l’internet public

Le budget de tentatives infini est particulièrement important pour contourner ASLR. L’exploitation moderne contre ASLR nécessite généralement une fuite d’informations ou du force brute. Parce que NGINX génère des workers de remplacement avec une disposition de tas identique après chaque plantage, un attaquant peut faire des tentatives illimitées sans coût.

Les chercheurs décrivent une technique théorique : en écrasant progressivement des octets de pointeur à travers des requêtes répétées, un attaquant peut rediriger le flux d’exécution vers une charge utile contrôlée, contournant ASLR sans étape explicite de fuite d’informations.

Condition de Déclenchement : Êtes-Vous Affecté ?

La vulnérabilité n’est atteignable que si votre configuration NGINX contient un motif spécifique :

# Motif vulnérable :
# 1. Un rewrite avec ? dans le remplacement ET des groupes de capture sans nom
# 2. Suivi d'un autre rewrite, if, ou set dans le même scope

rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;

Le ? dans /profile.php?id=$1&tab=$2 définit is_args = 1. Les captures sans nom $1, $2 déclenchent le chemin de code vulnérable lorsqu’une directive ultérieure les évalue.

Vérifiez Votre Configuration

grep -rn 'rewrite.*\?.*\$[0-9]' /etc/nginx/

Si cela retourne des correspondances, votre configuration est affectée.

Atténuation

Immédiat : Mettre à Jour

VersionAction
NGINX Open SourceMettre à jour vers 1.31.0 ou 1.30.1
NGINX Plus R36Appliquer R36 P4
NGINX Plus R32Appliquer R32 P6

Solution de Contournement : Groupes de Capture Nommés

Si vous ne pouvez pas mettre à jour immédiatement, remplacez les captures sans nom par des captures nommées dans chaque directive rewrite affectée :

# Vulnérable — captures sans nom avec ? dans le remplacement
rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;

# Atténué — les captures nommées contournent le chemin de code vulnérable
rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;

Les captures nommées ((?<name>...)) ne passent pas par la logique d’échappement vulnérable, car la fonction ngx_http_script_copy_capture_code n’applique l’échappement URI qu’aux captures sans nom. Ce changement de configuration supprime la surface d’attaque sans mise à jour binaire.

Vérifier la Correction

# Vérifier la version
nginx -v

# Après la mise à jour, vérifier : doit être 1.31.0 ou 1.30.1+
nginx -v 2>&1 | grep -E '1\.31\.0|1\.30\.[1-9]'

Chronologie

DateÉvénement
2008Vulnérabilité introduite dans NGINX 0.6.27 (commit d’initialisation du module de réécriture)
2026-04Le système autonome de depthfirst scanne le code source de NGINX, signale le dépassement de tas en 6 heures
2026-04-24F5 confirme le problème et coordonne la divulgation
2026-05-13F5 publie NGINX 1.31.0 / 1.30.1 avec le correctif ; CVE-2026-42945 publié
2026-05-14Cet article publié

Implications Plus Larges : Vulnérabilités Découvertes par l’IA

CVE-2026-42945 est remarquable non seulement pour sa gravité, mais pour comment il a été découvert. Un système d’IA autonome a trouvé un bug dans un code source qui a été audité par des milliers d’ingénieurs, chercheurs en sécurité et contributeurs open source pendant 18 ans — en six heures.

Cela suit un modèle que nous avons vu s’accélérer en 2026 :

VulnérabilitéDécouvert parTemps de découverte
Copy Fail (LPE noyau Linux)Xint Code (IA)~1 heure
Dirty Frag (LPE noyau Linux)Humain (Hyunwoo Kim)Audit manuel
CVE-2026-42945 (NGINX Rift)depthfirst (IA autonome)6 heures
CVE-2026-42946 (sur-lecture NGINX)depthfirst (IA autonome)Même scan

L’écart entre ce qu’un système d’IA déterminé peut trouver et ce que les réviseurs humains ont historiquement détecté se creuse rapidement. Pour les mainteneurs d’infrastructures critiques, cela signifie :

  1. Supposez qu’il y a plus de bugs non découverts dans vos dépendances — ceux trouvés jusqu’à présent ne sont que ce que la génération actuelle d’outils d’IA peut attraper
  2. Minimisez la surface d’attaque — supprimez les modules inutilisés, désactivez les fonctionnalités inutiles, utilisez le principe de moindre fonctionnalité
  3. Défense en profondeur — même si un composant est compromis, d’autres couches devraient limiter le rayon d’explosion

NGINX lui-même est un cas intéressant : il est connu pour son code source propre et son solide bilan de sécurité. Et pourtant, une RCE critique de 18 ans était cachée à la vue de tous. Si NGINX n’est pas à l’abri de cette classe de bug, aucun code source en C ne l’est.

Conclusion

CVE-2026-42945 (NGINX Rift) est un dépassement critique de tas dans l’un des projets logiciels les plus déployés sur internet. Il ne nécessite pas d’authentification, peut être déclenché depuis internet public, et donne à un attaquant une exécution complète de code dans le processus worker de NGINX.

Si vous exécutez NGINX, supposez que vous êtes affecté — à moins que vous ayez vérifié que votre configuration ne contient pas le motif de rewrite vulnérable, ou que vous ayez mis à jour vers 1.31.0 / 1.30.1.

La durée de vie de 18 ans de ce bug est un rappel frappant : notre infrastructure est maintenue par du code qui n’a jamais été audité de manière exhaustive par des outils modernes. L’ère de l’IA dans la découverte de vulnérabilités ne fait que commencer, et nous devrions nous attendre à plus de révélations comme celle-ci — pas moins.

Références

Infographie

Diagramme de dépassement de tas NGINX Rift

Figure 1 : NGINX Rift — comment la divergence de longueur du tampon en deux passes produit un dépassement de tas

Partager cette page