Parche crítico de PHP: ¿sabes qué versión usa tu web?

El 21 de octubre de 2026 el proyecto PHP publicó una actualización de seguridad de las que conviene aplicar sin esperar. Corrige dos vulnerabilidades críticas que, en determinadas condiciones, permiten a alguien ajeno ejecutar su propio código en el servidor de una web sin necesidad de contraseña. Si tu tienda online o la web de tu negocio está hecha con WordPress, WooCommerce, PrestaShop, Magento o Shopware, funciona con PHP. Te contamos qué ha pasado, cómo lo hemos resuelto en los servidores que mantenemos y qué conviene comprobar en tu web esta semana.

Qué ha pasado

PHP (PHP: Hypertext Preprocessor) es el lenguaje de programación sobre el que funcionan WordPress y todas las plataformas de tienda online que acabamos de citar. Ese día se publicaron las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir dos vulnerabilidades registradas como CVE-2026-109618 y CVE-2026-109619. CVE (Common Vulnerabilities and Exposures) es el catálogo público que asigna un número único a cada fallo de seguridad conocido.

Según el aviso oficial de PHP, los dos fallos pueden permitir la ejecución remota de código sin autenticación, lo que en inglés se abrevia como RCE (Remote Code Execution). Dicho de forma sencilla: un atacante podría ejecutar instrucciones en tu servidor sin haber iniciado sesión. El aviso añade que están en riesgo todas las instalaciones de PHP que sirven páginas web, y que el riesgo más alto lo tienen los servidores con Apache y mod_php, donde ya existe un ataque demostrado que se dispara antes de que la propia web llegue a ejecutarse. El anuncio de PHP 8.4.27, por ejemplo, la presenta como versión de seguridad y recomienda actualizar a todos los usuarios de esa rama.

La gravedad se mide con el CVSS (Common Vulnerability Scoring System), una escala de 0 a 10. Las dos vulnerabilidades tienen un 9,2 en la versión 4 de esa escala, que es nivel crítico. La PHP Foundation explica que el 20 de octubre empezaron a circular por foros y redes sociales los números de los dos fallos con una puntuación equivocada de 10,0, y que por eso la publicación se adelantó un día, al 21 de octubre a las 14:00 en tiempo universal coordinado (UTC). No se filtraron detalles técnicos. El Centro Nacional de Ciberseguridad de los Países Bajos (NCSC-NL, Nationaal Cyber Security Centrum) mantiene una página de seguimiento llamada php2shell con los programas afectados y el estado de cada fabricante.

Por qué no se arregla desde el panel de WordPress

Como recuerda Wordfence, una de las empresas de seguridad de referencia en WordPress, el fallo está en PHP y no en WordPress, en un plugin o en un tema. Por eso las actualizaciones automáticas de WordPress no lo corrigen: PHP se actualiza en el servidor. Si tu web está en un alojamiento gestionado, le toca a tu proveedor. Si está en un servidor propio o en un VPS (servidor privado virtual), le toca a quien lo administre. Y si nadie tiene esa tarea asignada, lo más probable es que siga pendiente.

Cómo lo aplicamos nosotros

El mismo día que se publicó el parche, 3 minutos después, ya habíamos actualizado todos los servidores que mantenemos. Subimos PHP 8.2, 8.3, 8.4 y 8.5 a sus versiones corregidas y, en la misma intervención, actualizamos también nginx, el servidor web, OpenSSL, la librería que cifra las conexiones, y el resto de librerías del sistema que tenían actualizaciones pendientes. Después reiniciamos los servicios y comprobamos que todas las webs respondían bien.

No lo contamos para presumir de rapidez. Que bastaran unos minutos se explica por tres cosas que ya estaban hechas antes del aviso: los servidores usaban versiones de PHP con soporte, sabíamos qué versión usa cada web y el procedimiento de actualización estaba probado. Cuando falta alguna de las tres, el mismo parche puede llevar días o, directamente, no poder aplicarse.

Lo que más importa: las versiones sin soporte

El proyecto PHP solo ha publicado versiones corregidas de PHP 8.2, 8.3, 8.4 y 8.5. El mismo aviso oficial deja claro que PHP 8.1 y las versiones anteriores ya no reciben actualizaciones del proyecto PHP. Dada la gravedad, el equipo de seguridad de PHP dejó unos parches mínimos para 7.4, 8.0 y 8.1 pensados para quien compila PHP por su cuenta, y algunos repositorios de distribución los han adaptado a sus paquetes. Por ejemplo, el repositorio de Remi Collet, que mantiene los paquetes de PHP de Fedora y Red Hat y cuyo repositorio se usa mucho en AlmaLinux y Rocky Linux, publicó el 21 de octubre el arreglo de estos dos fallos para PHP 7.4, 8.0 y 8.1.

Así que, si tu web usa una versión antigua, puede que tu proveedor haya instalado un parche adaptado, pero no está garantizado: depende de dónde salga el PHP de tu servidor y de que alguien lo haya actualizado. Y aunque lo tenga, esas versiones siguen fuera del soporte oficial, así que el próximo fallo puede quedarse sin arreglo. Hay que comprobarlo y planificar la migración.

La lista oficial de versiones sin soporte pone fechas: PHP 8.1 dejó de tenerlo el 31 de diciembre de 2025, PHP 8.0 el 26 de noviembre de 2023 y PHP 7.4 el 28 de noviembre de 2022. En la práctica, si tu web funciona con PHP 7.x, 8.0 u 8.1 y nadie se ocupa del servidor, lo más probable es que hoy esté expuesta a estos dos fallos, y con cada fallo nuevo dependerá de que alguien adapte el arreglo.

Hay otra fecha que conviene apuntar. Según la tabla de versiones con soporte, PHP 8.2 recibe correcciones de seguridad solo hasta el 31 de diciembre de 2026, es decir, durante dos meses más. PHP 8.3 las tendrá hasta el 31 de diciembre de 2027, 8.4 hasta finales de 2028 y 8.5 hasta finales de 2029. Si hay que migrar, tiene sentido ir directamente a 8.4 o a 8.5.

Qué hacer con tu web

1. Comprueba qué versión de PHP usa. En WordPress aparece en Herramientas, Salud del sitio, pestaña Información, apartado Servidor, la ruta que indica Wordfence. En otras plataformas suele estar en el panel del alojamiento.
2. Compárala con las versiones corregidas: 8.5.12, 8.4.27, 8.3.36, 8.2.35 o posteriores. Si tu PHP viene de los paquetes de una distribución de Linux, el número puede no cambiar aunque el parche esté aplicado, así que en ese caso confírmalo con tu proveedor.
3. Si tu versión tiene soporte pero no está al día, pide la actualización a tu alojamiento o a quien administre el servidor, con una copia de seguridad hecha antes.
4. Si tu versión ya no tiene soporte, pregunta a tu proveedor si ha instalado el parche adaptado y, aunque lo tenga, planifica la migración a una versión actual. Antes hay que comprobar que el tema, los plugins y los desarrollos a medida funcionan con ella, en una copia de la web y no directamente en la tienda en marcha.
5. Deja por escrito quién se encarga de estas actualizaciones a partir de ahora, para que el próximo aviso no dependa de que alguien se acuerde.

Nuestra recomendación

Haz hoy la comprobación del primer punto, que lleva un par de minutos. Si tu versión está al día, perfecto. Si no lo está, o si descubres que nadie tenía asignada esta tarea, es buen momento para resolverlo con calma y antes del siguiente aviso. En nuestro servicio de mantenimiento y crecimiento nos ocupamos de que la web siga rápida y segura después del lanzamiento, y eso incluye tener el servidor al día.