PHP CVE-2026-14355 : corruption tas dans openssl_encrypt (CERTFR-2026-AVI-0843)

Le CERT-FR a publié le 7 juillet 2026 l'avis CERTFR-2026-AVI-0843, qui répercute la livraison amont des versions PHP 8.2.32, 8.3.32, 8.4.23 et 8.5.8 du 2 juillet 2026. Le correctif principal est CVE-2026-14355, une corruption du tas dans le module ext/openssl. La notice amont est publiée par le projet PHP dans GHSA-7jrw-539f-x6vr. Le dossier CVE.org confirme les périmètres de version côté source amont.

Score CVSS v3.1 : 5,6 (moyen), vecteur AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L. Classification CWE-122 (débordement du tas). Pas d'exploitation active recensée à ce jour selon la vulnrichissement CISA-ADP (Exploitation: none, Automatable: no).

Ce que fait le bug

Le mode AES-WRAP-PAD de l'extension OpenSSL de PHP alloue le buffer de sortie à partir de la seule taille du texte clair, sans tenir compte de l'expansion prescrite par RFC 5649 (padding + huit octets d'en-tête AIV). D'après la description CVE amont, verbatim :

The output buffer for the AES key-wrap-with-padding operation is sized from the plaintext length without accounting for RFC 5649 expansion. This may cause OpenSSL to write beyond allocated memory, corrupting heap metadata and triggering application abort.

En pratique, un appel openssl_encrypt($plaintext, 'aes-128-wrap-pad', $key, ..., $iv) sur une entrée non alignée fait écrire OpenSSL au-delà du buffer alloué par PHP. Résultat immédiat : abort processus (worker FPM tué, requête HTTP interrompue). Résultat potentiel — non démontré à ce jour publiquement : corruption exploitable du tas.

Le crédit va à Oleg Baturin (découverte) et à David Carlier (correctif) d'après le dossier CVE amont.

Périmètres concernés

Toutes les branches PHP encore supportées, dès qu'elles utilisent ext/openssl avec aes-*-wrap-pad :

• PHP 8.2.x < 8.2.32
• PHP 8.3.x < 8.3.32
• PHP 8.4.x < 8.4.23
• PHP 8.5.x < 8.5.8

Le module ext/openssl est compilé par défaut sur la quasi-totalité des paquets de distribution (Debian, Ubuntu, RHEL/AlmaLinux/Rocky, Alpine, Amazon Linux, image Docker officielle php:8.x-fpm). Le grep utile côté patrimoine PHP est aes-*-wrap-pad — hors CMS grand public, l'usage est essentiellement du chiffrement de clés symétriques (KMS custom, chiffrement d'attributs applicatifs, formats propriétaires de coffres). Un CMS standard sans mode wrap-pad n'a pas de chemin déclenchable ; en revanche, une application métier qui expose l'algorithme à un attaquant contrôlant la longueur du texte clair est vulnérable.

Un second CVE au passage : CVE-2026-12184

La même livraison inclut également CVE-2026-12184, un déni de service distant dans le wrapper HTTP/TLS de PHP. php_stream_url_wrap_http_ex() réinitialise le nom de pair après un échec de setup TLS alors que le flux a déjà été fermé et réinitialisé à NULL, ce qui fait planter le worker. Un serveur HTTPS malveillant (ou tout certificat expiré si votre application se connecte à un service tiers) suffit à provoquer le crash. CVSS v3.1 : 8,2 (élevé).

Toute application PHP qui fait un file_get_contents('https://…'), un fopen() sur URL HTTPS ou un wrapper HTTP côté SDK est concernée.

Statut de l'exploitation

Aucun PoC public, aucune exploitation observée pour CVE-2026-14355 au moment de l'avis CERT-FR. La vulnrichissement CISA-ADP du 6 juillet classe l'exploitation à none et l'automatisation à no. Le bulletin d'annonce Debian LTS du 4 juillet est référencé dans le dossier CVE amont pour ceux qui suivent le patrimoine LTS.

Ceci dit : une corruption de tas dans ext/openssl sur toutes les branches supportées est le type de primitive qui finit exploitée dans les mois qui suivent la divulgation. Le calendrier de patch amont est court — c'est la fenêtre où la posture défensive est encore gérable.

Que faire

1. Mettez à jour vers 8.2.32, 8.3.32, 8.4.23 ou 8.5.8 selon votre branche. Les paquets distribution suivent — Debian 12/13 via le canal security, RHEL/AlmaLinux via rhel-9-appstream, image Docker officielle sur le tag 8.x.
2. Auditez votre code applicatif pour openssl_encrypt(...) avec un algorithme aes-*-wrap-pad. Si vous en avez, vérifiez d'où vient le texte clair : entrée utilisateur directe, désérialisation, contenu tiers. Toute source non contrôlée est un chemin d'exploitation potentiel.
3. Traitez CVE-2026-12184 dans le même déploiement. Si vous utilisez file_get_contents() ou fopen() sur des URL HTTPS externes — API tierces, CDN, webhooks sortants — cette correction résout un DoS distant activable par un serveur malveillant que vous ne contrôlez pas.
4. Confirmez la version servie, pas seulement la version paquet : php -v en ligne de commande peut différer de phpversion() côté FPM si plusieurs SAPI cohabitent. Vérifiez PHP-FPM sur chaque pool.
5. Sur les hébergements mutualisés, obtenez de votre hébergeur la version PHP réelle exposée à chaque locataire. Les hébergeurs qui n'ont pas encore migré leurs images depuis le 2 juillet 2026 exposent leurs clients aux deux CVE simultanément.

Contexte

C'est la deuxième vague de correctifs OpenSSL/PHP en un semestre. Le module ext/openssl accumule des CVE bas-niveau parce qu'il est un pont fin entre l'API PHP haut-niveau et libcrypto : un décalage d'un octet côté allocation, et le patrimoine C prend le relais. La documentation de l'algorithme aes-*-wrap-pad est explicite sur l'expansion RFC 5649 ; le correctif de David Carlier applique simplement le calcul manquant. Le patrimoine à retenir : chaque openssl_encrypt sur un algorithme moins courant que AES-256-CBC mérite un test unitaire côté application pour vérifier que le buffer d'entrée est de taille attendue avant que PHP le passe à libcrypto.

Côté opérationnel : si vous administrez un parc PHP hétérogène (typique en France entre agences, hébergeurs mutualisés et applications internes), le point d'attention est la branche 8.5.x. Elle est jeune, encore peu déployée en production, mais présente sur les CI et les images latest. Une mise à jour uniformisée sur les quatre branches évite d'avoir à repasser dans deux semaines.