Versiones y parches de PHP: cómo mantenerlo al día

Versiones de PHP y parches: qué ramas siguen recibiendo correcciones y hasta cuándo, cómo saber qué versión usa de verdad tu servidor, por qué el número que ves puede engañar, cómo actualizar en cada sistema y qué enseñan los fallos reales de los últimos años.

Puedes escribir un código impecable y tener la aplicación expuesta porque el PHP que la ejecuta, o una de sus bibliotecas, tiene un fallo conocido. Pasó en octubre de 2026 con PHP2Shell: dos fallos críticos en el propio PHP que se atacaban antes incluso del parche y que la agencia de ciberseguridad de Estados Unidos acabó dando por explotados. Ninguna buena práctica de programación protegía de eso; solo actualizar. Esta página explica cómo hacerlo bien.

Cuánto dura cada versión

PHP saca una versión nueva cada noviembre, y cada una tiene dos años de soporte activo, en los que recibe correcciones de todo tipo, y dos más solo de parches de seguridad, hasta el 31 de diciembre del cuarto año. Después, nada: los fallos que se descubran ya no se corrigen.

Si tu servidor usa PHP 8.2, tienes dos meses para pasar a una rama más nueva. Si usa 8.1, 7.4 o algo más antiguo, ya está sin parches del proyecto PHP, salvo que tu distribución o tu proveedor los siga dando por su cuenta (lo vemos más abajo). Este programa hace la cuenta por ti; la fecha está fijada para que la salida sea reproducible, pero en tu servidor usarías la de hoy:

<?php
declare(strict_types=1);

// Fechas de php.net/supported-versions.php: [fin del soporte activo, fin de los parches de seguridad]
const RAMAS = [
    '8.2' => ['2024-12-31', '2026-12-31'],
    '8.3' => ['2025-12-31', '2027-12-31'],
    '8.4' => ['2026-12-31', '2028-12-31'],
    '8.5' => ['2027-12-31', '2029-12-31'],
];

function estado(string $rama, DateTimeImmutable $hoy): string
{
    if (!isset(RAMAS[$rama])) {
        return 'sin soporte: no recibe parches';
    }
    [$activo, $seguridad] = array_map(fn(string $f) => new DateTimeImmutable($f), RAMAS[$rama]);
    $dias = $hoy->diff($seguridad)->days;
    return match (true) {
        $hoy <= $activo => "soporte activo; parches hasta el {$seguridad->format('d/m/Y')}",
        $hoy <= $seguridad => "solo seguridad; quedan $dias días de parches",
        default => 'sin soporte: no recibe parches',
    };
}

$hoy = new DateTimeImmutable('2026-10-27');   // en tu servidor: new DateTimeImmutable('today')
$mia = PHP_MAJOR_VERSION . '.' . PHP_MINOR_VERSION;

echo "Este PHP es el ", PHP_VERSION, ": ", estado($mia, $hoy), "\n";
foreach (['8.4', '8.3', '8.2', '8.1', '7.4'] as $rama) {
    echo "PHP $rama: ", estado($rama, $hoy), "\n";
}

Probar en el editor →

salidaEste PHP es el 8.5.12: soporte activo; parches hasta el 31/12/2029
PHP 8.4: soporte activo; parches hasta el 31/12/2028
PHP 8.3: solo seguridad; quedan 430 días de parches
PHP 8.2: solo seguridad; quedan 65 días de parches
PHP 8.1: sin soporte: no recibe parches
PHP 7.4: sin soporte: no recibe parches

Qué versión tienes de verdad

En un mismo servidor puede haber varios PHP, y el de la terminal no tiene por qué ser el que atiende la web. Hay tres que mirar:

php -v

salidaPHP 8.5.12 (cli) (built: Oct 21 2026 15:48:53) (NTS)
Copyright (c) The PHP Group
Built by https://github.com/docker-library/php
Zend Engine v4.5.12, Copyright (c) Zend Technologies
    with Zend OPcache v8.5.12, Copyright (c), by Zend Technologies

php-fpm -v      # en algunas distribuciones: php-fpm8.3 -v

salidaPHP 8.5.12 (fpm-fcgi) (built: Oct 21 2026 15:49:51) (NTS)
Copyright (c) The PHP Group
Built by https://github.com/docker-library/php
Zend Engine v4.5.12, Copyright (c) Zend Technologies
    with Zend OPcache v8.5.12, Copyright (c), by Zend Technologies

Fíjate en lo que va entre paréntesis: cli es el de la terminal y fpm-fcgi el que sirve las páginas con Nginx o Apache. Aquí coinciden, pero es habitual que no. El tercero es el que de verdad responde a la web, y se ve de dos formas: la cabecera X-Powered-By de las respuestas (si no la has ocultado con expose_php = Off) o un archivo temporal con <?php phpinfo();, que debes borrar en cuanto lo mires, porque enseña toda la configuración del servidor a quien lo abra.

Por qué el número de versión engaña

Las distribuciones de Linux con soporte largo no suben la versión de PHP durante la vida de la distribución: toman los parches de seguridad de las versiones nuevas y los aplican a la que ya traían. Se llama backporting. Estas son las versiones que ofrecían los repositorios oficiales de Debian 12 y Ubuntu 24.04 el día que escribimos esto:

apt-cache policy php8.2-cli   (Debian 12)php8.2-cli:
  Installed: (none)
  Candidate: 8.2.35-1~deb12u1

apt-cache policy php8.3-cli   (Ubuntu 24.04)php8.3-cli:
  Installed: (none)
  Candidate: 8.3.6-0ubuntu0.24.04.13

Debian 12 sigue la versión oficial, la 8.2.35. Ubuntu 24.04 dice 8.3.6, cuando la rama oficial ya va por la 8.3.36… y sin embargo está parcheada. Su registro de cambios lo demuestra:

registro de cambios de php8.3 8.3.6-0ubuntu0.24.04.13php8.3 (8.3.6-0ubuntu0.24.04.13) noble-security; urgency=medium

  * SECURITY UPDATE: Remote RCE via state corruption issue
    - debian/patches/CVE-2026-109618_109619.patch: Avoid state corruption via

Es el parche de PHP2Shell, aplicado sobre la 8.3.6. Consecuencias prácticas: un escáner que solo mire el número dirá que ese servidor es vulnerable a fallos que no tiene, y al revés, un número moderno no garantiza nada si no se han instalado las actualizaciones. Para saber si tu paquete tiene un parche concreto, consulta el seguimiento de seguridad de tu distribución (security-tracker.debian.org, ubuntu.com/security/CVE-…, las erratas de Red Hat) con el número de CVE.

Cómo actualizar en cada sistema

Tres errores habituales después de actualizar:

• No reiniciar. PHP-FPM y Apache con mod_php siguen ejecutando la versión vieja hasta que se reinician: sudo systemctl restart php8.3-fpm (el nombre del servicio cambia según el sistema).
• Actualizar la terminal y no la web, o al revés, cuando hay dos PHP instalados. Comprueba los tres de la sección anterior.
• Olvidar las imágenes de Docker. Una imagen construida hace meses lleva el PHP de hace meses aunque la etiqueta 8.5 ya apunte a uno nuevo. Hay que reconstruir y volver a desplegar.

Pasar a una rama nueva sin sustos

Los parches dentro de una rama (de 8.3.35 a 8.3.36) no cambian el comportamiento y se aplican sin pensarlo. Cambiar de rama (de 8.2 a 8.4) sí puede romper cosas, porque cada versión elimina lo que la anterior marcó como obsoleto. El camino seguro:

1. Lee las guías de migración de php.net de cada versión intermedia (para ir de 8.2 a 8.4, la de 8.3 y la de 8.4).
2. Activa los avisos Deprecated en desarrollo con la versión actual y corrígelos primero: son exactamente lo que dejará de funcionar.
3. Ejecuta tus pruebas y PHPStan con la versión nueva (lección 6), y actualiza la restricción "php" de tu composer.json.
4. Actualiza las dependencias: composer update en desarrollo, revisando qué cambia.
5. Despliega primero en un entorno de pruebas igual que el de producción.

Las dependencias también cuentan

Una aplicación moderna tiene decenas de bibliotecas, y cualquiera puede tener un fallo. Composer te protege de dos formas que vimos en la lección 6: desde la versión 2.9 se niega a instalar versiones con avisos de seguridad publicados, y composer audit revisa lo que ya tienes. Añade composer audit a tu integración continua para que avise en cuanto se publique un fallo, y usa un servicio como Dependabot o Renovate que proponga las actualizaciones por ti. Lo mismo vale para WordPress: núcleo, temas y plugins se actualizan igual que PHP.

Lo que enseñan los fallos de verdad

Cinco casos reales, de 2012 a 2026, y lo que cada uno dice sobre mantener PHP:

2012: PHP como CGI (CVE-2012-1823)

Cuando PHP funcionaba como CGI, una forma de servirlo muy común entonces, ciertas peticiones hacían que el servidor pasara partes de la URL a PHP como si fueran opciones de su línea de órdenes, y con ello se podía ejecutar código. Afectaba a las versiones anteriores a 5.3.12 y 5.4.2, y el primer parche fue incompleto: el arreglo definitivo llegó con 5.3.13 y 5.4.3. Diez años después, en 2022, la agencia de ciberseguridad de Estados Unidos lo añadió a su catálogo de fallos explotados. Lección: los servidores sin actualizar duran muchísimo, y un primer parche puede no ser el último.

2019: PHP-FPM y Nginx (CVE-2019-11043)

Un fallo en PHP-FPM solo se podía aprovechar con una configuración concreta de Nginx, bastante habitual. Se corrigió en PHP 7.1.33, 7.2.24 y 7.3.11, y a los pocos días de publicarse ya circulaba una prueba de concepto. Lección: la configuración del servidor web forma parte de la seguridad de PHP. Copiar una configuración de un tutorial sin entenderla es un riesgo; por eso la del proyecto solo deja ejecutar index.php.

2021: una puerta trasera en el código de PHP

El 28 de marzo de 2021 aparecieron en el repositorio oficial de PHP dos cambios firmados con los nombres de Rasmus Lerdorf y Nikita Popov, presentados como la corrección de una errata. Escondían una puerta trasera. Los detectaron y revirtieron enseguida, solo llegaron a la rama de desarrollo y no a ninguna versión publicada, y el origen fue el propio servidor git del proyecto. PHP lo abandonó y pasó a usar GitHub como repositorio oficial. Lección: la cadena de suministro también se ataca. Instala PHP y las bibliotecas desde fuentes oficiales, y desconfía de copias de origen dudoso.

2024: PHP-CGI en Windows (CVE-2024-4577)

Doce años después del caso de 2012, un fallo parecido volvió a aparecer en Windows: una conversión de caracteres del sistema operativo permitía, otra vez, que partes de la URL llegaran a PHP-CGI como opciones. Lo descubrió la empresa DEVCORE, tenía una puntuación de 9.8 sobre 10 y se corrigió en PHP 8.1.29, 8.2.20 y 8.3.8. En pocos días se estaba explotando, también por grupos de ransomware. Lección: las configuraciones antiguas, como PHP en modo CGI, siguen vivas en instalaciones que nadie revisa, por ejemplo paquetes de desarrollo como XAMPP expuestos a internet.

2026: PHP2Shell

Dos fallos en el núcleo de PHP permitían ejecutar código en el servidor sin iniciar sesión. El parche salió el 21 de octubre de 2026, el fallo se filtró antes de lo previsto, Amazon vio intentos de ataque cuatro días antes del parche y, una semana después, había ataques documentados. Lo contamos en tres noticias: el parche, los ataques previos y la confirmación de CISA. Lección: el tiempo entre un parche y su explotación ya se mide en horas. Hay que poder actualizar PHP el mismo día, y eso exige tenerlo preparado de antemano: saber qué versión tienes, cómo se actualiza y cómo comprobar que funcionó.

Lista para tu servidor

Y para el código, la otra mitad del trabajo: Los fallos de seguridad típicos de PHP.

Los programas se ejecutaron con PHP 8.5.12 y las versiones de los paquetes se consultaron en los repositorios oficiales de Debian 12 y Ubuntu 24.04 el 27 de octubre de 2026. Las fechas de soporte son las de php.net.