PHP 8.4.6 : patch de sécurité et checklist Symfony en production

Le 10 avril 2025, la core team PHP publie simultanément des correctifs de sécurité sur les quatre branches actives : 8.1.32, 8.2.28, 8.3.20 et 8.4.6. Une release coordonnée sur l'ensemble des branches en même temps, c'est rare — ça signifie que les vecteurs corrigés traversent le moteur entier et que l'impact est jugé suffisamment sérieux pour contraindre toutes les équipes à agir sans délai. Si ton infrastructure Symfony tourne encore sur l'image PHP 8.4.5 — ou sur une 8.3.x non patchée —, tu es dans le périmètre d'exposition. Voici ce qui change, ce que ça expose concrètement, et la procédure exacte pour upgrader sans casser ton pipeline CI.

Ce que corrige PHP 8.4.6 — les vecteurs réels

Cinq CVE sont corrigées dans cette vague coordonnée. Deux concernent directement les stream wrappers HTTP : CVE-2025-1217 (injection d'en-têtes HTTP lors de redirections via le wrapper http://) et CVE-2025-1734 (validation insuffisante des wrappers de flux, permettant à des données non filtrées de transiter vers des systèmes aval). CVE-2025-1219 touche les flux libxml qui utilisaient un content-type incorrect, ouvrant la voie à du parsing XML inattendu — vecteur particulièrement sournois dans les apps qui consomment des flux Atom ou des API SOAP. CVE-2025-1736 corrige une validation manquante des Basic Constraints dans les certificats X.509 côté PHP. Enfin, CVE-2025-1861 adresse un use-after-free dans la gestion des streams, exploitable dans des contextes multi-threadés ou via des extensions tierces chargées dynamiquement.

• CVE-2025-1217 — Injection d'en-têtes HTTP via le wrapper http:// sur les redirections
• CVE-2025-1219 — Content-type incorrect dans les flux libxml, parsing XML déviant
• CVE-2025-1734 — Validation insuffisante des stream wrappers en amont du traitement
• CVE-2025-1736 — Basic Constraints non validées dans les certificats X.509
• CVE-2025-1861 — Use-after-free dans stream_get_contents, contextes multi-threadés

Ce qui expose réellement tes projets Symfony

Les CVE liées aux stream wrappers (1217, 1734) concernent tout code qui ouvre des URLs distantes via les fonctions natives PHP : file_get_contents(), fopen(), ou les composants Symfony qui s'appuient sur le transport natif PHP plutôt que curl. Concrètement : HttpClient en mode native_http, Mailer avec des pièces jointes distantes chargées via wrapper, ou encore des bundles qui consomment des flux RSS ou Atom sans passer par le composant HttpClient de Symfony. Si une commande console ou un listener d'événement exécute un file_get_contents('https://...') quelque part dans le code, tu es dans le périmètre. Pour CVE-2025-1736, l'exposition est plus étroite mais plus critique : elle concerne les projets qui valident des certificats X.509 côté PHP directement — LDAP avec vérification SSL stricte, clients mTLS custom, ou extensions OpenSSL appelées hors Symfony. Les apps Symfony 7.2 standard utilisant HttpClient avec le transport curl ne sont pas directement exposées au vecteur principal, mais le moteur PHP sous-jacent l'est dès lors que d'autres entrées font appel aux wrappers natifs.

Checklist de mise à jour Symfony en production

L'ordre d'opération est critique : mettre à jour l'image PHP en premier, valider en staging, puis toucher à Composer. Faire l'inverse — updater les dépendances Composer avant de changer le runtime — peut installer des versions incompatibles avec l'ancien moteur et casser le déploiement en production de manière silencieuse, sans erreur explicite lors du push.

# 1. Pull la nouvelle image PHP 8.4.6 (pinning explicite, jamais 'latest')
docker pull php:8.4.6-fpm-alpine

# Si tu builds une image maison, rebuild sans cache
docker build --no-cache -t myapp/php:8.4.6 -f docker/php/Dockerfile .

# 2. Vérifier la version et les extensions critiques dans le nouveau conteneur
docker run --rm myapp/php:8.4.6 php -v
# PHP 8.4.6 (cli) (built: Apr  9 2025 ...)

docker run --rm myapp/php:8.4.6 php -m | grep -E 'pdo|intl|opcache|redis|apcu'

# docker/php/Dockerfile — pinning explicite sur le tag de sécurité
FROM php:8.4.6-fpm-alpine

# Dépendances système nécessaires à Symfony 7.2
RUN apk add --no-cache icu-dev libzip-dev \
    && docker-php-ext-install pdo pdo_mysql intl zip opcache \
    && docker-php-ext-enable opcache

# Copier la config opcache de prod
COPY docker/php/opcache.ini /usr/local/etc/php/conf.d/opcache.ini
COPY docker/php/php.ini      /usr/local/etc/php/conf.d/custom.ini

WORKDIR /app
COPY --chown=www-data:www-data . .

# Installer les dépendances Composer dans l'image finale
COPY --from=composer:2 /usr/bin/composer /usr/bin/composer
RUN composer install --no-dev --no-interaction --optimize-autoloader --classmap-authoritative

# 3. Lancer Composer update dans le conteneur 8.4.6 (pas depuis l'hôte)
docker run --rm \
  -v $(pwd):/app \
  -w /app \
  myapp/php:8.4.6 \
  composer update --no-interaction --prefer-dist --optimize-autoloader

# 4. Suite de tests dans le nouveau runtime
docker run --rm \
  -v $(pwd):/app \
  -w /app \
  --env APP_ENV=test \
  myapp/php:8.4.6 \
  php bin/phpunit --testsuite unit,integration

# 5. Déploiement en prod (rolling restart docker compose)
docker compose pull php
docker compose up -d --no-deps php

# Ou avec docker swarm
docker service update --image myapp/php:8.4.6 myapp_php

# 6. Nettoyage des images obsolètes
docker image prune -f

• Dockerfile mis à jour avec le tag php:8.4.6-fpm-alpine (ou supérieur si disponible dans ton registry)
• docker build --no-cache obligatoire — les layers cachés peuvent masquer l'ancien runtime
• php -v et php -m validés dans le conteneur avant tout déploiement
• Composer update exécuté dans le conteneur 8.4.6, pas depuis le système hôte
• Suite PHPUnit verte sous le nouveau runtime (unit + integration au minimum)
• Déploiement staging avant prod, avec health check PHP-FPM et nginx validés
• docker image prune après rotation pour libérer l'espace disque sur les nodes

La fenêtre qui suit une release de sécurité coordonnée est précisément la période où les scanners automatisés frappent le plus fort : l'exploit est documenté, le patch est public, mais la majorité des instances de production ne sont pas encore à jour. Plus tu tardes à appliquer le correctif, plus tu entres dans la zone rouge. Si tu veux un audit de ton stack Symfony avant la prochaine vague — ou accélérer une migration vers PHP 8.4 sans risquer la stabilité en prod —, le Bear Upgrade est fait pour ça.