En bref : la Zend Engine est le noyau de PHP. Elle traduit le code PHP en opcodes, les exécute dans une machine virtuelle et gère au passage les variables et la mémoire. Elle est présente dans toute installation de PHP depuis PHP 4. Comme les failles PHP2Shell se trouvent dans ce noyau, ni les plugins ni les mises à jour du CMS n'aident : seul un PHP mis à jour, suivi d'un redémarrage, y remédie.
Qu'est-ce que la Zend Engine ?
La Zend Engine est la partie de PHP qui fait le travail proprement dit. Tout le reste, comme la liaison avec le serveur web ou les extensions pour les bases de données, s'appuie sur elle. On peut la comparer au moteur d'une voiture : la carrosserie et l'équipement diffèrent, mais le moteur entraîne tout.
Selon le manuel PHP, le nom est formé des prénoms des développeurs Zeev Suraski et Andi Gutmans. Le moteur a été présenté à la mi-1999 et est devenu le noyau de PHP à partir de PHP 4.0, paru en mai 2000. Il a depuis été profondément remanié à plusieurs reprises.
| Version de PHP | Moteur | Changement principal selon le manuel et les RFC |
|---|---|---|
| PHP 4.0 (2000) | Zend Engine | premier noyau commun, meilleures performances |
| PHP 5.0 (2004) | Zend Engine 2.0 | nouveau modèle objet |
| PHP 7.0 (2015) | Zend Engine 3.0 | PHPNG : structures de données plus compactes, AST |
| PHP 8.0 (2020) | évolution | compilateur JIT intégré à OPcache |
Les composants : compilateur, machine virtuelle, mémoire
Le moteur travaille en étapes clairement séparées. Depuis PHP 7, selon le RFC sur l'arbre syntaxique abstrait, il y a trois phases jusqu'au bytecode :
- Lexer : décompose le code source en tokens, par exemple des mots-clés, des noms de variables et des chaînes de caractères.
- Parseur : construit à partir des tokens un arbre syntaxique abstrait (AST), qui reflète la structure du programme.
- Compilateur : produit à partir de l'AST des op arrays, c'est-à-dire des listes d'opcodes, un par fichier et par fonction.
- Exécuteur (Zend VM) : traite les opcodes. Selon le RFC sur le JIT, chaque opcode correspond à une fonction de traitement (handler) qui l'exécute.
- Gestion de la mémoire : réserve et libère la mémoire de chaque requête et surveille au passage la limite définie par
memory_limit.
Les tokens d'un script peuvent être rendus visibles avec l'extension Tokenizer. C'est inoffensif et instructif :
<?php
$code = '<?php $summe = 2 + 3; echo $summe;';
foreach (token_get_all($code) as $token) {
if (is_array($token)) {
echo token_name($token[0]), ': ', trim($token[1]), "\n";
} else {
echo 'Zeichen: ', $token, "\n";
}
}
La sortie affiche des entrées comme T_VARIABLE: $summe ou T_LNUMBER: 2. C'est précisément avec ces éléments que le parseur poursuit son travail.
Comment la Zend Engine gère-t-elle les variables ?
Selon le manuel, chaque variable PHP se trouve dans un conteneur appelé zval. Il contient le type et la valeur ainsi que des informations de gestion, dont un compteur de références (refcount). Ce compteur indique combien de noms de variables pointent vers le même conteneur.
<?php
$a = str_repeat('x', 10);
$b = $a; // pas de copie, les deux pointent vers la même valeur
$b .= 'y'; // ce n'est qu'ici que la copie a lieu (copy on write)
unset($a); // le compteur baisse, la mémoire est libérée s'il atteint 0
Lorsque le compteur atteint zéro, le moteur libère la mémoire. Pour les références circulaires entre objets, il existe en outre un ramasse-miettes (garbage collector). Plus de détails dans l'article Gestion de la mémoire en PHP.
La refonte PHPNG pour PHP 7 visait précisément ce point. Selon le RFC de Dmitry Stogov et Zeev Suraski, il s'agissait de structures de données plus compactes et d'une représentation plus habile des valeurs. Le RFC faisait état de gains de performance de 20 à 110 pour cent dans des applications réelles.
OPcache et JIT : des extensions du moteur
Sans cache, le moteur retraduit chaque script à chaque requête. OPcache tient les opcodes terminés à disposition dans la mémoire partagée. Depuis PHP 8.0, il existe en outre un compilateur JIT. Selon le RFC, il repose sur DynASM, un outil issu du projet LuaJIT, et produit du code machine directement à partir du bytecode. La machine virtuelle reste inchangée ; le JIT ne remplace que les points d'entrée des handlers.
Pour les exploitants, cela signifie : OPcache et JIT accélèrent le moteur, mais ne changent rien à son comportement en cas d'erreur. Une faille dans le noyau subsiste même avec un cache actif.
Pourquoi les failles dans le moteur pèsent particulièrement lourd
Les deux failles PHP2Shell se situent dans le noyau de PHP. Avec CVE-2026-109618, un état de mémoire insuffisante (out of memory) peut interrompre le moteur alors que les données de la requête ne sont que partiellement initialisées ; lors du nettoyage, des données invalides sont alors traitées comme valides. Avec CVE-2026-109619, un état interne subsiste après la libération de la mémoire et peut être utilisé par une requête ultérieure dans le même worker.
Selon le manuel PHP, les versions corrigées 8.5.12, 8.4.27, 8.3.36 et 8.2.35 modifient aussi le comportement de la limite de mémoire : memory_limit y est une limite souple, et un nouveau paramètre memory_hard_limit_percent fixe un plafond strict. Le manuel précise qu'une version qui ne connaît pas ce paramètre est concernée par les failles. Pour les distributions avec rétroportages, le journal des modifications du paquet compte en plus.
Le moteur est chargé dans chaque processus PHP. Après la mise à jour, il faut donc redémarrer tous les workers PHP-FPM, les processus Apache avec mod_php et les autres services PHP.
Ce qui se passe à l'intérieur en cas de manque de mémoire est décrit dans l'article memory_limit et out-of-memory. L'analyse de la faille elle-même figure sous CVE-2026-109618.
Comment PHP SOS aide-t-il concrètement ?
- Vérifier la version et l'état des paquets : nous déterminons quel état du moteur tourne réellement, y compris les rétroportages de votre distribution.
- Mettre à jour et redémarrer : via le service de correctifs PHP, nous installons la mise à jour et contrôlons qu'aucun processus avec l'ancien code ne subsiste.
- Définir judicieusement les limites de mémoire : nous ajustons
memory_limit, la nouvelle limite stricte et les limites cgroup à votre application. - Examiner les anomalies : nous évaluons les plantages de workers ou les processus avec le statut de sortie 137 et vérifions si une attaque peut en être la cause.
Questions fréquentes
D'où vient le nom de la Zend Engine ?
Le nom est formé des prénoms de ses développeurs : Zeev Suraski et Andi Gutmans. Selon le manuel PHP, le moteur a été présenté à la mi-1999 et est devenu le noyau de PHP à partir de PHP 4.0, en mai 2000.
La Zend Engine est-elle un produit distinct que je dois installer ?
Non. La Zend Engine fait partie intégrante de toute installation de PHP. Qui met à jour PHP met automatiquement à jour le moteur. Cela n'a rien à voir avec les produits commerciaux de la société Zend.
Qu'est-ce qu'un opcode ?
Un opcode est une instruction unique pour la machine virtuelle de PHP, par exemple une addition, un appel de fonction ou une affectation. Le compilateur traduit chaque script en une suite de telles instructions, que le moteur exécute ensuite.
Quel rapport entre la Zend Engine et memory_limit ?
Le moteur gère la mémoire de chaque requête et veille à la limite définie par memory_limit. Depuis les versions de sécurité du 21/10/2026, cette limite est, selon le manuel, une limite souple, complétée par une limite stricte via memory_hard_limit_percent.