PHP 8.1 en fin de vie : checklist technique pour sécuriser votre stack immédiatement

PHP 8.1 est officiellement abandonné — votre stack est-elle encore sûre ?

Depuis le 31 décembre 2025, PHP 8.1 a atteint sa fin de vie officielle. Concrètement : aucun correctif de sécurité ne sera plus publié par l'équipe core PHP pour cette branche. Pas de période de grâce, pas de patch d'urgence exceptionnel — c'est une coupure nette. Toute vulnérabilité découverte après cette date restera définitivement non corrigée.

Le chiffre qui doit alerter : plus de 55 % des sites PHP parmi le million les plus visités tournent encore sur des versions hors support. Si votre application fait partie de cette statistique, vous exposez vos utilisateurs et votre infrastructure à des exploits pour lesquels aucun fix officiel n'arrivera.

Cet article est une checklist technique directement actionnable pour auditer et sécuriser votre stack PHP — avec les commandes concrètes à exécuter maintenant.

Source originale : Proven PHP Hosting Security Risk Factors to Protect Sites — MonsterMegs via DEV Community.

1. Audit de version : savoir exactement où vous en êtes

Avant toute action, cartographiez votre parc. Une version PHP non identifiée dans un container secondaire ou un job Cron oublié suffit à ouvrir une brèche.

Vérification locale et serveur :

# Version active sur le serveur
php -v

# Version utilisée par PHP-FPM (si applicable)
php-fpm8.1 -v 2>/dev/null || php-fpm -v

# Toutes les versions installées sur le système
update-alternatives --list php 2>/dev/null || ls /usr/bin/php*

Dans un environnement Docker/PHP-FPM :

# Lister toutes les images PHP utilisées dans vos services
grep -r 'image: php' docker-compose*.yml
grep -r 'FROM php' Dockerfile*

# Vérifier la version dans un container en cours d'exécution
docker exec mon_container php -v

Vérification des contraintes Composer :

# Afficher la version PHP déclarée dans composer.json
cat composer.json | grep '"php"'

# Vérifier les contraintes effectives de toutes les dépendances
composer check-platform-reqs

Si composer check-platform-reqs retourne des erreurs après migration, vous avez des dépendances bloquantes à résoudre avant de pousser en production.

2. Mise à jour des contraintes et rebuild des images

Une fois l'inventaire fait, la migration vers PHP 8.2 ou 8.3 (versions actuellement supportées) se déroule en plusieurs étapes coordonnées.

Mise à jour de composer.json :

{
  "require": {
    "php": ">=8.2"
  }
}

Puis mettez à jour vos dépendances en vérifiant la compatibilité :

composer update --dry-run
composer update

Si des packages bloquent sur PHP 8.1, identifiez-les :

composer why-not php 8.2

Rebuild des images Docker :

# Avant
FROM php:8.1-fpm-alpine

# Après
FROM php:8.3-fpm-alpine

Pour les extensions PECL, vérifiez systématiquement la compatibilité avec la nouvelle version cible :

# Dans votre Dockerfile, lister les extensions installées
php -m

# Tester le build sur la nouvelle image avant de déployer
docker build --no-cache -t mon-app:php83-test .
docker run --rm mon-app:php83-test php -m

⚠️ Point d'attention extensions PECL : certaines extensions (imagick, redis, xdebug) publient leurs propres cycles de compatibilité. Vérifiez leur support PHP 8.2/8.3 avant de migrer.

3. Matrice CI multi-PHP et tests de régression

Une migration PHP sans filet de sécurité automatisé est un pari risqué. La bonne pratique est de configurer une matrice CI qui teste simultanément sur plusieurs versions PHP avant tout merge.

Exemple GitHub Actions :

jobs:
  tests:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        php-version: ['8.2', '8.3']
    steps:
      - uses: actions/checkout@v4
      - name: Setup PHP ${{ matrix.php-version }}
        uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php-version }}
          extensions: mbstring, intl, pdo_pgsql
      - run: composer install --no-interaction
      - run: php bin/phpunit

Cette configuration garantit que votre code tourne correctement sur les versions supportées et vous alerte immédiatement si une dépendance casse la compatibilité.

Pour Symfony spécifiquement, profitez-en pour activer la détection des dépréciations :

# Lancer les tests avec le bridge de dépréciations Symfony
SYMFONY_DEPRECATIONS_HELPER=disabled php bin/phpunit
# Puis progressivement durcir :
SYMFONY_DEPRECATIONS_HELPER=999 php bin/phpunit

4. Plan de rollback et monitoring post-déploiement

Même avec des tests solides, un plan de retour arrière est indispensable avant toute migration en production.

Stratégie de rollback Docker :

Conservez toujours votre image précédente taguée explicitement :

# Taguer l'image actuelle avant migration
docker tag mon-app:latest mon-app:php81-backup-$(date +%Y%m%d)

# En cas de problème, rollback immédiat
docker-compose down
docker tag mon-app:php81-backup-20250101 mon-app:latest
docker-compose up -d

Monitoring des CVE post-migration :

Une fois sur PHP 8.2 ou 8.3, mettez en place une veille automatique sur les nouvelles CVE :

# Audit Composer des dépendances connues vulnérables
composer audit

# À intégrer dans votre pipeline CI comme étape bloquante
composer audit --no-dev

Abonnez-vous également aux flux officiels : php.watch/versions publie les dates de fin de vie et les CVE actives par branche — un signet à ne pas négliger.

Conclusion : la dette de version coûte plus cher que la migration

Rester sur PHP 8.1 en 2025 n'est pas un choix de confort — c'est une exposition au risque calculée. Les attaquants scannent activement les versions hors support, et un CVE critique sur PHP 8.1 publié demain ne recevra aucun patch officiel.

La migration vers PHP 8.2 ou 8.3 est un investissement qui se planifie : audit de version, mise à jour des contraintes Composer, rebuild des images, matrice CI, plan de rollback. Chaque étape réduit mécaniquement la surface d'attaque.

Chez MulerTech, nos projets Symfony tournent sur des images Docker versionnées explicitement, avec un pipeline CI multi-PHP systématique. C'est la baseline minimale pour opérer sereinement sur un stack PHP en production.