Actualización crítica de seguridad de PHP: qué hacer si tu web está en un hosting

El equipo de seguridad de PHP ha publicado hoy, 21 de octubre de 2026, las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Corrigen dos vulnerabilidades críticas, con una puntuación de 9,2 sobre 10 en la escala CVSS v4.0, que permiten a un atacante ejecutar código en el servidor sin necesidad de usuario ni contraseña. La recomendación oficial es actualizar de inmediato.

PHP es el lenguaje con el que funcionan WordPress, WooCommerce, PrestaShop, Dolibarr, Moodle y buena parte de las webs corporativas. Si tu web usa alguno de ellos, este aviso te afecta. Y si la tienes en un hosting, la actualización no depende de ti sino de tu proveedor.

Qué ha publicado PHP

El aviso de seguridad, publicado en php.net, recoge lo siguiente:

• Versiones corregidas: 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
• Quién está en riesgo: cualquier instalación de PHP que sirva páginas web, sea con PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP o LiteSpeed. El equipo de PHP considera que el riesgo es mayor con mod_php, donde ya han demostrado un ataque que se ejecuta con una simple petición, antes de que llegue a cargarse el código de la web.
• Los dos fallos: CVE-2026-109618, relacionado con cómo PHP gestiona la falta de memoria a mitad de una petición, y CVE-2026-109619, en el que datos internos de una petición pueden reutilizarse en la siguiente que atiende el mismo proceso. Los dos acaban permitiendo ejecutar código.
• Distribuciones de Linux: recibieron los parches por adelantado, así que los paquetes actualizados de Debian, Ubuntu, Red Hat y similares deberían estar disponibles ya o en pocas horas.

El aviso se había anunciado el día anterior para las 14:00 UTC, y PHP lo ha publicado unos minutos antes. Que avise con antelación y publique detalles técnicos el mismo día indica la gravedad: desde hoy cualquiera puede estudiar los fallos para atacar servidores que no se hayan actualizado.

Por qué el riesgo está en el hosting

Cuando PHP publica una versión corregida, tu web no queda protegida automáticamente. Lo queda cuando el servidor donde está alojada instala esa versión y reinicia PHP. En un servidor propio eso lo hace tu equipo técnico. En un hosting compartido o gestionado lo hace el proveedor, y cada uno tiene su ritmo: algunos actualizan en horas, otros esperan a que lleguen los paquetes de su distribución o de su panel (cPanel, Plesk y similares), y otros tardan días o semanas.

Durante ese intervalo la web está expuesta a un fallo que permite tomar el control del servidor sin credenciales. Es el periodo más peligroso, y en un hosting compartido el problema no se limita a tu web: afecta a todas las que comparten máquina.

Un detalle que conviene conocer: el propio aviso de PHP pide a quien use el repositorio de paquetes de Remi (rpms.remirepo.net, muy habitual en servidores con CentOS, AlmaLinux o Rocky Linux) que pase a los paquetes de la distribución o compile desde el código fuente, porque ese repositorio no tendrá la actualización hoy. Si tu proveedor lo usa, puede tardar más de lo normal.

Cómo saber qué versión de PHP usa tu web

• Panel del hosting: en cPanel, Plesk o el panel propio del proveedor suele haber un apartado «Versión de PHP» o «Configuración de PHP» por dominio.
• WordPress: en Herramientas → Salud del sitio → Información → Servidor aparece la versión de PHP.
• Dolibarr: en Herramientas de administración → Información del sistema → PHP (hace falta un usuario administrador).
• Preguntando al soporte del hosting, que es lo más fiable si tienes varias webs o no tienes acceso al panel.

Apunta el número completo, por ejemplo 8.3.35, no solo 8.3. Tu web está protegida si usa 8.5.12, 8.4.27, 8.3.36, 8.2.35 o una versión posterior de su rama. Ten en cuenta que algunas distribuciones de Linux aplican el parche sin cambiar el número de versión, así que en ese caso solo el proveedor puede confirmarte si está corregida.

Qué pedirle hoy a tu proveedor de hosting

Si tienes la web en un hosting, merece la pena escribir hoy mismo al soporte con estas tres preguntas:

1. ¿Habéis instalado ya la actualización de seguridad de PHP del 21 de octubre de 2026 (CVE-2026-109618 y CVE-2026-109619) en el servidor donde está mi web? Si no, ¿cuándo lo vais a hacer?
2. ¿Qué versión de PHP usa mi web ahora mismo y cuál tendrá después de la actualización?
3. Si mi web usa una versión sin soporte (8.1 o anterior), ¿vais a aplicar algún parche o tengo que cambiar de versión?

Si el proveedor no responde o no tiene fecha, tómalo como una señal de que tu web puede quedarse expuesta más tiempo del razonable.

Qué hacer si tu web funciona con PHP 8.1 o anterior

PHP 8.1 y anteriores ya no reciben actualizaciones oficiales. Por la gravedad del caso, el equipo de PHP ha publicado parches mínimos para PHP 7.4, 8.0 y 8.1, pero solo como código fuente para quien compila PHP por su cuenta. Algunas distribuciones y proveedores con soporte extendido los aplicarán a sus paquetes, aunque en un hosting compartido lo normal es que no ocurra.

Lo recomendable es pasar a PHP 8.3 o 8.4 lo antes posible. En la mayoría de paneles el cambio de versión es un desplegable, pero antes hay que comprobar que la web funciona con la nueva: plugins de WordPress antiguos, módulos de PrestaShop o WooCommerce sin mantener y desarrollos propios escritos hace años son lo que más suele fallar.

La forma segura de hacerlo es probar en una copia de la web (muchos hostings ofrecen un entorno de pruebas), corregir lo que falle y después cambiar la versión en producción. Si no hay tiempo para eso, al menos haz una copia de seguridad completa (ficheros y base de datos) antes de cambiar la versión, para poder volver atrás.

Ten en cuenta también que PHP 8.2 deja de recibir parches de seguridad el 31 de diciembre de 2026. Si vas a migrar, no merece la pena quedarse en 8.2.

Si gestionas tu propio servidor

• Instala la versión corregida desde los repositorios de tu distribución, o desde php.net si compilas PHP. Algunas distribuciones aplican el parche sobre su propio número de versión, así que revisa sus avisos de seguridad.
• Reinicia PHP-FPM o Apache después de actualizar. Hasta que no se reinicia, el servidor sigue ejecutando la versión anterior.
• Comprueba la versión que sirve realmente la web, no solo la de la línea de comandos (el comando «php -v» puede no coincidir con la versión de PHP-FPM).
• Si usas contenedores Docker, reconstruye las imágenes con la nueva versión y vuelve a desplegar.

Medidas provisionales si no puedes actualizar hoy

PHP insiste en que solo la actualización resuelve el problema. Aun así, su aviso incluye algunas medidas que reducen la exposición mientras tanto. Requieren acceso a la configuración del servidor (php.ini o la configuración de PHP-FPM o Apache), así que en un hosting compartido normalmente solo puede aplicarlas el proveedor:

• Desactivar session.upload_progress.enabled (ponerlo a 0) y reiniciar todos los procesos de PHP. Tiene que hacerse en php.ini o en la configuración del servidor: según el aviso, no sirve hacerlo desde la propia aplicación ni desde un fichero .user.ini.
• Reducir post_max_size a 8M si la web no recibe subidas de ficheros, o a 32M si las necesita, con upload_max_filesize por debajo.
• En PHP 8.5, poner fatal_error_backtraces a 0 y reiniciar los procesos.
• Limitar en el servidor web o el proxy el tamaño de las peticiones, el número de campos y el número de partes de los formularios.

Ninguna de estas medidas deja el servidor seguro: cortan algunas vías de ataque conocidas, pero no todas. Un cortafuegos de aplicaciones web (WAF) puede ayudar cuando sus fabricantes publiquen reglas para estos fallos, pero tampoco sustituye a la actualización.

Resumen

• PHP ha publicado hoy, 21 de octubre de 2026, las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen dos fallos que permiten ejecutar código en el servidor sin credenciales.
• Si tu web está en un hosting, el parche depende de tu proveedor: pregúntale si ya lo ha aplicado y, si no, cuándo lo hará.
• Si tu web usa PHP 8.1 o anterior, lo normal es que no reciba corrección en un hosting: hay que migrar a 8.3 o 8.4.

Si no sabes qué versión usa tu web o necesitas ayuda para migrarla sin que se rompa, escríbenos. Revisamos webs en WordPress, WooCommerce, PrestaShop, Dolibarr y desarrollos a medida, y hacemos el cambio de versión probando antes en una copia (más información en servicios).