El 21 de octubre de 2026 el equipo de PHP corrigió dos vulnerabilidades graves, CVE-2026-109618 y CVE-2026-109619, que permiten ejecutar código en el servidor y afectan a casi todas las versiones de PHP, incluidas las antiguas.
Desde entonces muchas guías recomiendan revisar el número de versión de PHP en el panel o con un archivo info.php. Ese método sirve para saber qué versión usas, pero no dice si tu sitio tiene la corrección. En muchos hostings el número de versión no cambia al aplicar el parche.
Respuesta corta
Si tu hosting usa CloudLinux, la corrección se instala sin cambiar el número de versión: tu panel puede seguir diciendo PHP 7.4.33 o 8.1 y aun así estar corregido. Al revés, ver "8.2" o "8.3" tampoco garantiza nada si el proveedor no instaló la actualización. La única forma confiable de saberlo es que tu proveedor lo confirme (o revisarlo tú mismo si administras tu propio servidor).
Qué pasó con PHP en octubre de 2026
• 20 de octubre: el proyecto PHP anunció una actualización de seguridad crítica (puntaje 9,2 de 10).
• 21 de octubre: publicó las versiones corregidas 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Para PHP 8.1 y anteriores ya no publica versiones nuevas.
• 21 y 22 de octubre: CloudLinux, el sistema que usan muchos hostings compartidos, publicó la corrección para todas las versiones de PHP desde la 5.2 hasta la 8.5, incluidas las que el proyecto PHP ya no mantiene. Lo detalla en su aviso oficial.
Los proveedores recibieron los parches antes del anuncio público, así que algunos alcanzaron a instalarlos el mismo día.
Por qué el número de versión engaña
Cuando una versión de PHP ya no recibe actualizaciones del proyecto oficial, los fabricantes de sistemas para servidores (como CloudLinux o las distribuciones de Linux) copian solo la corrección dentro de la versión antigua. El paquete queda corregido, pero sigue llamándose igual: PHP 7.4.33 sigue diciendo 7.4.33.
Por eso, comparar el número de tu panel con la lista de versiones corregidas de php.net lleva a dos errores:
• Falsa alarma: crees que estás expuesto porque ves 7.4 u 8.1, cuando tu proveedor ya aplicó la corrección.
• Falsa tranquilidad: crees que estás protegido porque usas 8.3, cuando tu proveedor todavía no instaló la actualización.
Cómo saberlo según el servicio que tienes
| Tu servicio | ¿Quién instala la corrección? | Cómo confirmarlo |
|---|---|---|
Hosting compartido | Tu proveedor | Busca su aviso público sobre CVE-2026-109618 y CVE-2026-109619, o pídele una confirmación por escrito a soporte. |
Hosting de revendedor | Tu proveedor | Igual que el hosting compartido. Tus clientes dependen de esa respuesta. |
VPS o servidor dedicado administrado | Tu proveedor | Pide la confirmación y el detalle del paquete instalado. |
VPS o servidor dedicado que administras tú | Tú o tu equipo técnico | Actualiza los paquetes de PHP y reinicia PHP. En CloudLinux, el registro de cambios del paquete debe mencionar los dos códigos CVE. |
Qué preguntarle a tu proveedor de hosting
• ¿Instalaron la corrección para CVE-2026-109618 y CVE-2026-109619 en la versión de PHP que usa mi sitio?
• ¿Reiniciaron PHP después de instalarla? Una de las fallas vive en los procesos que siguen corriendo, así que instalar sin reiniciar no basta.
• ¿Pueden darme una constancia por escrito con el paquete instalado? Sirve si tu empresa tiene auditoría o un equipo de seguridad.
Un buen proveedor responde estas preguntas sin rodeos y, en un caso tan masivo, publica un aviso con fechas. Por ejemplo, las marcas de Grupo Hosting (Hosting.cl, PlanetaHosting, HostingCenter, iHost, NinjaHosting y FreeHost) publicaron el suyo en grupohosting.cl.
Lo que no te recomendamos
• Crear un archivo info.php público. Muestra rutas, módulos y configuración del servidor a cualquiera que lo encuentre, y hay robots que buscan ese archivo todos los días. Si lo creas, bórralo de inmediato.
• Fiarte de la fecha de compilación ("Build Date"). Un paquete corregido puede tener una fecha anterior al anuncio, porque los fabricantes recibieron el parche antes, y un paquete recompilado sin el parche puede tener una fecha nueva.
• Cambiar de versión de PHP a la carrera. Saltar de 7.4 a 8.3 sin revisar plugins y tema puede botar tu sitio. Si tu proveedor ya corrigió tu versión actual, planifica el cambio con calma.
¿Y si mi sitio usa una versión antigua de PHP?
Esta vez, los hostings con CloudLinux corrigieron incluso PHP 5.x y 7.x. Pero eso depende de que tu proveedor use paquetes con parches propios: el proyecto PHP ya no mantiene PHP 8.1 ni las versiones anteriores, y PHP 8.2 deja de recibir correcciones el 31 de diciembre de 2026.
Lo recomendable es planificar el paso a PHP 8.3 o superior. En WordPress, la herramienta Salud del sitio (Herramientas → Salud del sitio) te muestra la versión que usas y avisa si hay plugins incompatibles.
Resumen
El número de versión de PHP no dice si tu sitio tiene la corrección.
CloudLinux corrigió PHP 5.2 a 8.5 manteniendo el número de versión.
En hosting compartido, la confirmación la da tu proveedor, no un archivo info.php.
Un buen proveedor publica un aviso con fechas y te da una constancia si la pides.
Planifica el paso a PHP 8.3 o superior: la 8.2 pierde soporte el 31 de diciembre de 2026.
Preguntas frecuentes
Mi panel dice PHP 7.4 (o 8.1). ¿Mi sitio está expuesto?
No necesariamente. Los servidores con CloudLinux recibieron la corrección para PHP 5.2 a 8.5 sin cambiar el número de versión. El número que ves en el panel no dice si la corrección está instalada: eso solo lo puede confirmar tu proveedor (o tú, si administras tu propio servidor).
¿Qué versiones de PHP corrigen estas vulnerabilidades?
El equipo de PHP publicó el 21 de octubre de 2026 las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12. PHP 8.1 y anteriores no reciben versiones nuevas del proyecto PHP; ahí la corrección llega solo si tu proveedor usa paquetes con parches propios, como los de CloudLinux.
¿Sirve crear un archivo info.php y revisar la fecha de compilación?
No lo recomendamos. La fecha de compilación no prueba que el parche esté incluido, y el archivo info.php deja expuesta la configuración del servidor a cualquiera mientras esté publicado.
¿Qué le pregunto a mi proveedor de hosting?
Tres cosas: si ya instaló la corrección para CVE-2026-109618 y CVE-2026-109619 en la versión de PHP que usa tu sitio, si reinició PHP después de instalarla, y si puede darte una constancia por escrito con el paquete instalado.
¿Debo cambiar de versión de PHP igual?
Para esta corrección no es obligatorio si tu proveedor la aplicó. Pero PHP 8.1 y anteriores ya no tienen soporte oficial y PHP 8.2 lo pierde el 31 de diciembre de 2026, así que conviene planificar el paso a PHP 8.3 o superior, revisando antes que tus plugins y tu tema sean compatibles.