En resumen: Quien quiere encargar una actualización de PHP necesita algo más que paquetes nuevos: lo decisivo son el estado correcto del paquete, el reinicio de todos los procesos de PHP y una prueba de ello. Eso es justo lo que ofrece nuestro servicio de parcheo de PHP. Recibirá un justificante por escrito de cada servidor, que podrá presentar internamente o ante terceros.
Por qué una actualización de PHP por sí sola a menudo no basta
Desde el 21/10/2026 existen parches para las vulnerabilidades de PHP2Shell CVE-2026-109618 y CVE-2026-109619. El BSI (Oficina Federal alemana para la Seguridad de la Información) recomienda actualizar de inmediato. En la práctica vemos tres obstáculos típicos.
En primer lugar, el número de versión no siempre muestra el estado real. Las distribuciones y los proveedores de hosting incorporan en ocasiones backports; entonces Plesk, por ejemplo, sigue indicando 8.2.34 aunque el estado del paquete esté parcheado. En segundo lugar, tras la instalación suelen seguir en ejecución procesos antiguos de PHP. Los archivos nuevos en el disco no protegen mientras los workers antiguos sigan trabajando en memoria. En tercer lugar, en un mismo servidor suelen ejecutarse varias versiones de PHP en paralelo, y una de ellas se olvida.
Actualizar PHP por encargo: las versiones corregidas
| Rama | Corregido desde | Estado anterior | Observación |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.11 | además, comprobar fatal_error_backtraces |
| PHP 8.4 | 8.4.27 | 8.4.26 | |
| PHP 8.3 | 8.3.36 | 8.3.35 | |
| PHP 8.2 | 8.2.35 | 8.2.34 | el soporte termina el 31/12/2026 |
| PHP 8.1 y anteriores | sin actualizaciones oficiales | – | solo backports mínimos de código fuente para 7.4, 8.0, 8.1 |
En los paquetes de distribuciones o de proveedores de hosting no cuenta el número que sigue a «PHP», sino el estado del paquete que el proveedor confirma como parcheado. Cómo comprobarlo usted mismo se explica en Comprobar correctamente la versión de PHP y el estado del parche.
¿Cómo ayuda PHP SOS en concreto?
- Inventario: registramos todas las instalaciones de PHP del servidor, el modo de ejecución (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) y qué sitio web usa qué versión.
- Instalar la actualización: instalamos las versiones corregidas desde el repositorio de su distribución, de su panel o del proyecto oficial. Para los contenedores, construimos con usted imágenes nuevas.
- Reinicio de todos los procesos: reiniciamos por completo PHP-FPM, Apache, LiteSpeed o los workers correspondientes y comprobamos que ningún proceso es anterior a la actualización. Los antecedentes figuran en Reiniciar PHP-FPM y todos los workers.
- Prueba de funcionamiento: abrimos las páginas y funciones más importantes, como la página de inicio, el inicio de sesión, los formularios y la caja, y revisamos los registros de errores.
- Justificante: recibirá, por cada servidor, un protocolo con la versión, el estado del paquete, el momento del reinicio y los puntos pendientes.
Una comprobación típica tras el reinicio tiene este aspecto:
# Versión de la CLI de PHP y del binario FPM (la ruta depende del sistema)
php -v
php-fpm8.3 -v
# Hora de inicio de los procesos FPM: debe ser posterior a la actualización
ps -o pid,lstart,cmd -C php-fpm8.3
Casos especiales: paneles, contenedores y varias versiones de PHP
En los servidores con Plesk o cPanel, las versiones de PHP suelen proceder de los repositorios del panel y no de la distribución. Allí revisamos cada versión instalada por separado, también las que en ese momento no están asignadas a ningún sitio web. Las versiones antiguas sin uso las eliminamos previo acuerdo, para que no se reactiven por error.
En entornos Docker y Kubernetes no basta con actualizar el host. PHP está en la imagen, y solo una imagen reconstruida con una base parcheada y desplegada en todos los contenedores en ejecución cierra la vulnerabilidad. Comprobamos además si siguen utilizándose imágenes más antiguas en registros o despliegues. Los detalles figuran en Parchear PHP en contenedores Docker.
Con mod_php, PHP se ejecuta directamente dentro del proceso de Apache. El equipo de PHP considera que allí el riesgo es el más alto. Por eso, tras la actualización hay que reiniciar Apache por completo; un simple reinicio de la configuración no basta en todos los casos.
Lo que recibe de nosotros
- un protocolo de parcheo por servidor: paquetes instalados, versiones, origen, momento
- la prueba de que se han reiniciado todos los procesos de PHP
- una lista de los sitios web y funciones revisados
- indicaciones sobre los sistemas que no se pudieron parchear, con su motivo
- una recomendación para el camino a seguir, por ejemplo con PHP 8.2 por la proximidad del fin del soporte
Lo que necesitamos de usted
- Acceso: SSH con permisos de administrador o acceso al panel (Plesk, cPanel u otro similar)
- Ventana de mantenimiento: cuándo puede hacerse un breve reinicio
- Persona de contacto: para consultas y para la conformidad tras la prueba de funcionamiento
- Copias de seguridad: confirmación de que existe una copia actual, o el encargo de crear una antes
- Indicaciones sobre desarrollos propios: extensiones de PHP o configuraciones especiales que deban tenerse en cuenta
En el hosting compartido sin acceso propio al servidor no podemos parchear nosotros mismos. En ese caso le ayudamos a plantear las preguntas adecuadas a su proveedor de hosting y a valorar la respuesta.
Lo que no prometemos
El servicio de parcheo cierra la vulnerabilidad conocida. No responde a la pregunta de si el servidor ya estaba comprometido antes de la actualización y no elimina el software malicioso que se haya introducido. Si quiere saberlo, el encargo adecuado es la ayuda inmediata con PHP2Shell, que incluye la búsqueda de rastros.
Para PHP 8.1 y anteriores ya no hay actualizaciones oficiales. En ese caso aplicamos medidas provisionales y recomendamos la migración a una versión con soporte. No damos una garantía de compatibilidad para su CMS de memoria, sino que la comprobamos con los requisitos del sistema del fabricante.
Preguntas frecuentes
¿Por qué mi servidor sigue mostrando la versión antigua de PHP tras la actualización?
Puede haber dos motivos. O bien la distribución ha incorporado un backport, y entonces el número de versión sigue igual aunque el estado del paquete esté parcheado; o bien siguen en memoria procesos antiguos de PHP que hay que reiniciar.
¿Qué versiones de PHP cierran PHP2Shell?
La vulnerabilidad está corregida en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, publicadas el 21/10/2026. En los paquetes de distribuciones cuenta el estado del paquete que el proveedor confirma como parcheado.
¿Puede la actualización dejar mi sitio web inoperativo?
Una actualización dentro de la misma versión principal, por ejemplo de 8.3.35 a 8.3.36, suele ser poco problemática. Sin embargo, es necesario un breve reinicio de los procesos de PHP. Acordamos con usted la ventana de tiempo y revisamos las páginas después.
¿Con el parche ya está todo hecho?
Para la vulnerabilidad en sí, sí, en cuanto se hayan reiniciado todos los procesos. Si alguien había entrado antes del parche, el parche no lo muestra. Para eso hace falta una revisión propia.