La aparición de una vulnerabilidad crítica en PHP ha puesto en alerta a administradores de sistemas, proveedores de hosting y responsables de páginas web de todo el mundo. El 21 de octubre de 2026, el Centro Criptológico Nacional (CCN-CERT) publicó una alerta de seguridad advirtiendo de dos fallos graves que podrían permitir la ejecución remota de código en servidores vulnerables.
Las vulnerabilidades, identificadas como CVE-2026-109618 y CVE-2026-109619, han recibido una puntuación de gravedad de 9,2 y afectan al propio intérprete de PHP, una tecnología utilizada por millones de páginas web y aplicaciones.
Y aquí está precisamente el problema: tener WordPress, PrestaShop o cualquier otra aplicación actualizada no garantiza que el servidor esté protegido frente a estas vulnerabilidades.
Llevo más de dos décadas trabajando con servidores, administrando alojamientos web y resolviendo incidencias de seguridad. Si algo he aprendido durante todos estos años es que un servidor puede funcionar perfectamente y, aun así, estar expuesto a problemas de seguridad importantes.
En HostingTG, empresa que fundamos en 2004, hemos actuado ante esta alerta actualizando nuestros servidores con los últimos parches de seguridad disponibles y revisando las versiones de PHP instaladas.
En este artículo voy a explicar qué ha sucedido, qué versiones de PHP están afectadas, cuáles incorporan las correcciones y qué deberías comprobar para saber si tu página web está realmente protegida.
Alerta por dos vulnerabilidades críticas en PHP: qué ha ocurrido
El 21 de octubre de 2026, el CCN-CERT publicó la alerta CCN-CERT AL 11/26, clasificando como crítico el riesgo asociado a dos vulnerabilidades descubiertas en PHP.
La advertencia no afecta únicamente a páginas web con una determinada aplicación o plugin. Estamos ante errores de seguridad en el propio entorno que ejecuta el código PHP.
Esto resulta especialmente preocupante porque PHP es una de las tecnologías más utilizadas para desarrollar páginas web dinámicas, tiendas online, plataformas de gestión y aplicaciones empresariales.
WordPress, WooCommerce, PrestaShop, WHMCS y numerosos desarrollos personalizados dependen de PHP para funcionar.
Por tanto, un fallo en este componente puede afectar a servicios muy diferentes, incluso cuando sus aplicaciones están correctamente actualizadas.
El CCN-CERT recomienda identificar los sistemas afectados, aplicar inmediatamente las actualizaciones de seguridad y aislar los servicios expuestos a Internet que no sean indispensables cuando no sea posible corregir el problema.
Desde mi punto de vista, esta recomendación resume perfectamente cómo debemos afrontar una alerta de estas características: identificar, actualizar y comprobar.
No basta con saber que existe una vulnerabilidad. Hay que verificar si afecta a nuestra infraestructura y tomar las medidas necesarias.
La alerta del CCN-CERT del 21 de octubre de 2026
El aviso oficial del Centro Criptológico Nacional tiene un mensaje claro: las organizaciones deben actuar cuanto antes para reducir su exposición.
La gravedad de estas vulnerabilidades está relacionada con la posibilidad de que un atacante pueda ejecutar código de forma remota, bajo determinadas condiciones, sin disponer previamente de credenciales válidas.
Eso no significa que cualquier página web pueda ser comprometida automáticamente.
La explotación depende de factores como la versión de PHP, la configuración del servidor, el modo de ejecución utilizado y las condiciones que hacen posible activar cada fallo.
Sin embargo, cuando existe una vulnerabilidad conocida que puede comprometer un servidor, retrasar las actualizaciones supone asumir un riesgo innecesario.
Durante años he visto cómo algunas empresas posponen este tipo de intervenciones porque sus páginas web siguen funcionando correctamente.
El problema es que la ausencia de errores visibles no demuestra que un sistema sea seguro.
Una web puede cargar rápidamente, recibir pedidos y funcionar con total normalidad mientras utiliza componentes vulnerables.
Por eso considero fundamental prestar atención a las alertas de seguridad incluso cuando aparentemente no sucede nada.
Qué son CVE-2026-109618 y CVE-2026-109619
Las dos vulnerabilidades afectan a mecanismos internos de gestión de memoria y procesamiento de solicitudes de PHP.
Aunque presentan diferencias técnicas, ambas pueden provocar situaciones peligrosas en sistemas vulnerables.
CVE-2026-109618 está relacionada con la gestión de errores cuando PHP se queda sin memoria durante el procesamiento de determinadas solicitudes. En esas circunstancias, algunos datos internos pueden quedar parcialmente inicializados y provocar un tratamiento incorrecto durante la limpieza de la solicitud.
CVE-2026-109619 afecta al tratamiento de información interna asociada a solicitudes anteriores. Determinados datos pueden seguir siendo utilizados después de que la memoria que los contenía haya sido liberada, provocando un comportamiento inseguro.
Estos problemas pertenecen a una categoría de fallos de memoria especialmente delicada, porque pueden comprometer la integridad del proceso que ejecuta una aplicación.
La consecuencia más grave es la posibilidad de ejecución remota de código, conocida como RCE (Remote Code Execution).
En otras palabras, un atacante podría llegar a ejecutar instrucciones no autorizadas dentro del contexto del proceso PHP vulnerable.
El alcance real dependerá de los permisos de ese proceso, de las medidas de aislamiento y de la configuración de seguridad del servidor.
Qué es PHP2Shell y por qué estos fallos son tan peligrosos
El término PHP2Shell se ha utilizado para identificar públicamente esta alerta de seguridad relacionada con las dos vulnerabilidades críticas del intérprete PHP.
Aunque el nombre pueda recordar a determinadas técnicas de ataque contra páginas web, el aspecto realmente importante es que los fallos afectan a un componente situado por debajo de aplicaciones como WordPress o PrestaShop.
Esto cambia considerablemente la forma de afrontar el problema.
Cuando aparece una vulnerabilidad en un plugin, normalmente podemos resolverla actualizando ese complemento, desactivándolo temporalmente o sustituyéndolo por otro.
Cuando la vulnerabilidad afecta al intérprete PHP, la solución requiere intervenir sobre los paquetes y servicios del servidor.
Y esa tarea no siempre está al alcance del propietario de una página web.
En alojamientos compartidos, por ejemplo, suele ser el proveedor de hosting quien administra las versiones de PHP y distribuye las actualizaciones correspondientes.
Por eso es tan importante elegir un servicio de alojamiento que mantenga su infraestructura actualizada y responda con rapidez cuando aparecen nuevas amenazas.
Cómo funciona la ejecución remota de código
La ejecución remota de código permite que un atacante llegue a ejecutar instrucciones en un sistema vulnerable desde una ubicación externa.
No debemos confundir este concepto con el acceso normal de un usuario a una aplicación.
En condiciones habituales, un visitante solicita una página y el servidor ejecuta únicamente las operaciones previstas por el desarrollador.
Sin embargo, una vulnerabilidad de ejecución remota de código puede alterar ese comportamiento y permitir acciones que nunca deberían estar disponibles para una persona no autorizada.
Dependiendo de cómo esté configurado el servidor, las consecuencias pueden incluir el acceso a archivos, la modificación de información, la ejecución de procesos o el compromiso de las aplicaciones alojadas.
Eso sí, conviene explicar algo importante: ejecutar código mediante una vulnerabilidad no significa necesariamente obtener privilegios de administrador o controlar automáticamente todo el servidor.
El daño potencial depende, entre otras cosas, de los permisos disponibles y del aislamiento existente entre usuarios, aplicaciones y servicios.
Precisamente por eso utilizamos diferentes capas de protección en los entornos de alojamiento.
Pero esas medidas complementarias no sustituyen a los parches de seguridad.
Qué consecuencias puede tener para un servidor vulnerable
Las consecuencias de una vulnerabilidad crítica en PHP pueden variar enormemente entre dos servidores aparentemente similares.
Un entorno correctamente aislado puede limitar el alcance de una intrusión, mientras que una configuración inadecuada puede facilitar que el incidente afecte a otros componentes.
Entre los riesgos que debemos contemplar se encuentran:
- Compromiso de páginas web: modificación de archivos o ejecución de código malicioso.
- Acceso a información sensible: exposición de datos a los que tenga acceso el proceso afectado.
- Interrupción del servicio: errores, caídas o comportamientos inesperados.
- Manipulación de aplicaciones: alteraciones en el funcionamiento de tiendas online y aplicaciones empresariales.
- Persistencia del atacante: posibilidad de introducir modificaciones que faciliten accesos posteriores.
No significa que todas estas situaciones vayan a producirse ni que todos los servidores vulnerables hayan sido atacados.
Pero cuando administramos una infraestructura conectada permanentemente a Internet, debemos valorar el riesgo antes de que aparezcan las consecuencias.
Una de las ideas que siempre intento transmitir es que resulta mucho más razonable dedicar tiempo a una actualización preventiva que tener que recuperar un servidor después de una intrusión.
Qué versiones de PHP están afectadas y cuáles incorporan los parches
Una de las primeras preguntas que surgen ante esta alerta es qué versiones de PHP son vulnerables.
Según la información técnica publicada el 21 de octubre de 2026, las vulnerabilidades afectan a versiones de PHP comprendidas entre la rama 5.4 y PHP 8.5.11.
El proyecto PHP ha publicado correcciones en las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12.
Sin embargo, hay un aspecto que debemos tener muy presente: no todas las instalaciones utilizan directamente los paquetes oficiales del proyecto PHP.
Muchos servidores funcionan con paquetes mantenidos por distribuciones Linux o fabricantes como cPanel y CloudLinux.
Esto significa que una rama antigua puede recibir un parche de seguridad específico sin cambiar necesariamente al último número de versión publicado por PHP.
Versiones corregidas de PHP 8.2, 8.3, 8.4 y 8.5
La siguiente tabla muestra las versiones corregidas publicadas por el proyecto PHP para estas vulnerabilidades.
| Rama de PHP | Primera versión corregida |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Estas versiones incorporan las correcciones correspondientes a CVE-2026-109618 y CVE-2026-109619.
Si administras un servidor con alguna de estas ramas, debes comprobar que tienes instalada la versión corregida o una actualización posterior que conserve dichos parches.
Pero tampoco debemos limitar la comprobación al resultado de php -v.
En muchos servidores existen varias versiones de PHP instaladas simultáneamente, y la versión utilizada desde la consola puede ser distinta de la empleada por una página web.
Además, podemos tener aplicaciones ejecutándose mediante PHP-FPM, LiteSpeed u otros mecanismos.
Por eso la comprobación debe realizarse sobre la versión utilizada realmente por cada aplicación.
Qué ocurre con PHP 7.4, 8.0, 8.1 y el soporte extendido
Aquí aparece uno de los problemas más habituales que encontramos en el alojamiento web.
Todavía existen aplicaciones que dependen de versiones antiguas de PHP por motivos de compatibilidad.
Puede tratarse de una tienda online que utiliza un módulo sin mantenimiento, una aplicación empresarial desarrollada hace años o un proyecto que no se ha actualizado por miedo a provocar errores.
El proyecto PHP ya no proporciona correcciones oficiales para las ramas 8.1 y anteriores.
Sin embargo, determinados fabricantes y servicios de soporte extendido sí pueden distribuir parches específicos.
Por ejemplo, cPanel ha publicado actualizaciones de EasyApache 4 para distintas ramas antiguas, mientras que CloudLinux dispone de mecanismos de distribución y mantenimiento de versiones PHP adaptadas a entornos de hosting.
Aquí quiero insistir en una cuestión importante:
No debemos confundir una versión antigua con una versión necesariamente desprotegida, ni una versión aparentemente reciente con una instalación correctamente parcheada.
Lo que realmente importa es comprobar el paquete utilizado, su procedencia y si incorpora la corrección de seguridad correspondiente.
Esto no significa que recomiende permanecer indefinidamente en versiones antiguas.
Al contrario.
En mi opinión, los parches de soporte extendido deben entenderse como una solución para reducir riesgos mientras se trabaja en la modernización de las aplicaciones.
La compatibilidad es importante, pero no debería convertirse en una excusa permanente para renunciar a mejorar la seguridad.
¿Puede una web con WordPress o PrestaShop actualizado seguir siendo vulnerable?
Sí. Una página web completamente actualizada puede continuar expuesta si utiliza un intérprete PHP vulnerable y se cumplen las condiciones necesarias para explotar el fallo.
Esta es probablemente una de las cuestiones más importantes de toda la alerta.
Muchos propietarios de páginas web creen que mantener actualizados WordPress, sus plugins y sus temas es suficiente para evitar cualquier problema de seguridad.
Y aunque esas actualizaciones son fundamentales, solo representan una parte del mantenimiento.
Una página web depende de diferentes componentes que funcionan conjuntamente.
Tenemos la aplicación, sus extensiones, las bases de datos, el servidor web, el sistema operativo y, en este caso, el intérprete PHP.
Cada uno de esos elementos puede presentar vulnerabilidades independientes.
Durante mis años administrando servidores he comprobado que esta distinción no siempre resulta evidente para los usuarios.
Es perfectamente comprensible: quien tiene una tienda online normalmente quiere vender productos, no convertirse en especialista en administración de sistemas.
Precisamente por eso es importante que el proveedor de alojamiento asuma las tareas de mantenimiento que correspondan a su infraestructura.
La diferencia entre actualizar una aplicación y proteger PHP
Imaginemos una tienda WooCommerce con WordPress y todos sus plugins actualizados.
El propietario ha seguido las recomendaciones habituales y no tiene ninguna actualización pendiente en su panel de administración.
Sin embargo, el servidor continúa ejecutando una compilación de PHP afectada por CVE-2026-109618 o CVE-2026-109619.
En ese escenario, las actualizaciones de WordPress no corrigen el fallo existente en el intérprete.
La aplicación puede seguir expuesta si la configuración utilizada permite activar la vulnerabilidad.
Esto demuestra por qué debemos diferenciar dos responsabilidades.
Por una parte, el mantenimiento de la propia aplicación y sus componentes.
Por otra, la seguridad de la infraestructura sobre la que se ejecuta.
Ambas son necesarias.
Lo mismo sucede con PrestaShop, WHMCS y los desarrollos PHP personalizados.
Actualizar una aplicación nunca debería interpretarse como una garantía de que todos los componentes del servidor están protegidos.
Por qué los plugins de seguridad y los firewalls no son suficientes
Los plugins de seguridad, los cortafuegos de aplicaciones web y otras herramientas de protección pueden ayudar a reducir la superficie de ataque.
Algunos permiten bloquear solicitudes sospechosas, detectar modificaciones en archivos o limitar determinados comportamientos.
Son herramientas útiles y, en muchos casos, recomendables.
Pero tienen una limitación evidente: no eliminan por sí mismas un error de programación existente en el intérprete PHP.
Un firewall puede dificultar determinadas formas de explotación o bloquear patrones conocidos.
Sin embargo, no debemos considerarlo una solución definitiva cuando existe un parche que corrige la vulnerabilidad.
Por eso, cuando aparece un fallo crítico, mi prioridad es comprobar si existe una actualización del fabricante y verificar su instalación.
Las demás medidas deben complementar esa corrección, no sustituirla.
Cómo comprobar si tu servidor PHP está protegido
Una de las recomendaciones más importantes que puedo hacer es no dar nunca por hecho que un servidor está protegido simplemente porque tiene activadas las actualizaciones automáticas.
Las actualizaciones son esenciales, pero también hay que comprobar que se han descargado, instalado y aplicado correctamente.
Además, en entornos con diferentes versiones de PHP puede ocurrir que algunas aplicaciones utilicen paquetes distintos.
Por eso, ante una alerta como esta, conviene realizar una revisión ordenada.
Comprobar la versión y los paquetes de seguridad instalados
El primer paso consiste en identificar qué versiones de PHP están realmente en uso.
En un servidor Linux podemos consultar la versión utilizada desde la consola con el siguiente comando:
php -vEste comando permite conocer la versión correspondiente al ejecutable PHP invocado desde la terminal.
Sin embargo, no demuestra por sí solo qué versión utiliza cada página web ni confirma que todos los paquetes estén corregidos.
También debemos revisar los intérpretes empleados por el servidor web y las aplicaciones alojadas.
En sistemas basados en RPM, los administradores pueden consultar los paquetes instalados mediante el gestor correspondiente.
Por ejemplo:
rpm -qa | grep -E 'php|ea-php|alt-php'El resultado debe compararse con los avisos oficiales del fabricante o de los repositorios utilizados.
En distribuciones basadas en Debian también debemos revisar los paquetes instalados y su historial de actualizaciones mediante las herramientas de gestión correspondientes.
Lo fundamental es no basar toda la comprobación en un único número de versión.
Una compilación puede incorporar correcciones de seguridad adicionales mediante parches específicos del distribuidor.
Cómo verificar los parches en cPanel, CloudLinux y Linux
Los servidores administrados con cPanel y CloudLinux merecen especial atención porque pueden utilizar diferentes mecanismos de distribución de PHP.
En cPanel, por ejemplo, encontramos PHP en los paquetes de EasyApache 4, además de componentes internos utilizados por el propio panel.
Por eso debemos revisar ambas partes.
cPanel ha publicado versiones de seguridad de cPanel & WHM y paquetes EasyApache corregidos específicamente para estas vulnerabilidades.
En el caso de EasyApache, las referencias publicadas incluyen:
| Rama | Versión corregida de EasyApache |
|---|---|
| PHP 7.4 | ea-php7.4.33-19 |
| PHP 8.0 | ea-php8.0.30-12 |
| PHP 8.1 | ea-php8.1.34-5 |
| PHP 8.2 | ea-php82 8.2.35 |
| PHP 8.3 | ea-php83 8.3.36 |
| PHP 8.4 | ea-php84 8.4.27 |
| PHP 8.5 | ea-php85 8.5.12 |
En servidores CloudLinux hay que verificar igualmente los paquetes alt-php y ea-php que corresponda utilizar, consultando las publicaciones y los repositorios del fabricante.
La disponibilidad de una corrección puede depender del sistema operativo, la rama de PHP y el repositorio configurado.
Por eso considero un error limitarse a observar qué versión aparece en el selector de PHP del panel.
Lo importante es verificar que el paquete concreto instalado contiene el parche que soluciona las vulnerabilidades.
En HostingTG hemos prestado especial atención a estas comprobaciones durante la actualización de nuestros servidores.
No basta con ejecutar una actualización y asumir que todo está solucionado.
Hay que comprobar qué paquetes se han instalado y asegurarse de que las correcciones se encuentran realmente presentes.
Revisar registros, servicios y posibles indicios de compromiso
Después de aplicar los parches, conviene revisar el estado de los servicios y los registros del sistema.
Los administradores deben comprobar que PHP funciona correctamente, que las aplicaciones responden con normalidad y que no aparecen errores nuevos relacionados con la actualización.
También es recomendable revisar los registros de acceso y error del servidor web, los eventos de seguridad disponibles y los indicadores de actividad anómala.
Entre las situaciones que pueden justificar una investigación adicional encontramos:
- Solicitudes inusuales dirigidas a aplicaciones PHP.
- Errores repetidos o comportamientos inesperados de procesos PHP.
- Modificaciones no autorizadas de archivos.
- Procesos desconocidos o actividades que no se corresponden con el funcionamiento habitual.
- Alertas generadas por sistemas de detección o protección.
Conviene recordar que ninguno de estos indicios demuestra automáticamente que se haya explotado una de las vulnerabilidades.
Del mismo modo, no encontrar errores en los registros tampoco garantiza que no haya ocurrido una intrusión.
Si existen sospechas fundadas, la revisión debe formar parte de un procedimiento de respuesta a incidentes, preservando la información necesaria para investigar lo sucedido.
Cómo solucionar la vulnerabilidad crítica de PHP
La medida principal para corregir CVE-2026-109618 y CVE-2026-109619 es instalar los paquetes de seguridad que incluyen las correcciones publicadas.
Puede parecer una respuesta sencilla, pero en la práctica requiere algo más que pulsar un botón de actualización.
En una infraestructura con múltiples servidores y aplicaciones, debemos comprobar versiones, dependencias, compatibilidad y funcionamiento.
Además, resulta fundamental identificar quién es responsable de administrar cada componente.
En un alojamiento compartido, normalmente será el proveedor quien mantenga los paquetes PHP del servidor.
En un servidor dedicado o VPS no administrado, esa responsabilidad puede corresponder al propio cliente o a su administrador de sistemas.
Aplicar las actualizaciones de seguridad correspondientes
El procedimiento que recomiendo ante este tipo de situaciones comienza identificando las versiones de PHP instaladas y los servicios que las utilizan.
Después debemos consultar los avisos oficiales del fabricante y comprobar qué paquetes corrigen las vulnerabilidades.
Antes de intervenir en sistemas críticos, conviene disponer de copias de seguridad recientes y, cuando sea posible, de un procedimiento de recuperación.
Una vez identificadas las actualizaciones, debemos instalarlas mediante los repositorios y herramientas oficiales correspondientes.
En servidores cPanel, el fabricante documenta la actualización de los paquetes EasyApache mediante herramientas como:
/scripts/rpmupEste comando debe ejecutarse únicamente por administradores autorizados, tras revisar su aplicación al entorno concreto.
En otros sistemas utilizaremos los procedimientos recomendados por el fabricante o la distribución Linux.
También debemos comprobar si es necesario reiniciar servicios o procesos para que comiencen a utilizar las bibliotecas y los intérpretes corregidos.
Un paquete instalado en disco no garantiza que todos los procesos existentes estén ejecutando inmediatamente el código actualizado.
La intervención debe terminar comprobando que los servicios funcionan y que las aplicaciones siguen respondiendo correctamente.
Qué hacer cuando no es posible actualizar inmediatamente
No siempre es posible instalar una nueva versión de PHP sin comprobar antes la compatibilidad de las aplicaciones.
Hay desarrollos antiguos que dependen de funciones eliminadas o modificadas en versiones posteriores.
En esos casos, actualizar directamente a una rama moderna puede provocar errores.
Entiendo perfectamente esta preocupación porque llevo años trabajando con aplicaciones que requieren configuraciones específicas.
Sin embargo, mantener una versión vulnerable expuesta a Internet tampoco debería considerarse una solución aceptable.
Si no podemos realizar una migración inmediata, debemos estudiar las alternativas disponibles.
Una posibilidad es recurrir a paquetes de soporte extendido que incorporen específicamente las correcciones necesarias.
Otra medida temporal puede ser restringir el acceso a servicios afectados, reducir su exposición o desactivar aquellos que no sean indispensables.
El CCN-CERT recomienda precisamente aislar las aplicaciones expuestas cuando no sea posible aplicar los parches inmediatamente.
Estas actuaciones deben valorarse caso por caso.
Lo que no recomiendo es confiar indefinidamente en medidas temporales y abandonar la actualización definitiva.
Cuando una aplicación impide mantener PHP correctamente, probablemente haya llegado el momento de plantearse su modernización.
Comprobar compatibilidad, funcionamiento y copias de seguridad
La seguridad no termina cuando finaliza el proceso de actualización.
Después hay que verificar que los servicios continúan funcionando con normalidad.
En un servidor que aloja tiendas online, por ejemplo, no basta con comprobar que la página principal carga correctamente.
También debemos revisar operaciones importantes como el acceso a usuarios, la finalización de pedidos, los pagos, el envío de correos y las integraciones externas.
Lo mismo sucede con las aplicaciones empresariales.
Una actualización puede ser técnicamente correcta y, sin embargo, poner de manifiesto incompatibilidades que deben resolverse.
Por eso siempre considero importante combinar las actualizaciones de seguridad con verificaciones posteriores.
También debemos mantener copias de seguridad y comprobar periódicamente que pueden restaurarse.
Una copia que nunca se ha probado puede ofrecer una sensación de seguridad que no siempre se corresponde con la realidad.
Actualizar, verificar y disponer de mecanismos de recuperación son partes de un mismo proceso de mantenimiento.
Cómo hemos actuado en HostingTG ante esta alerta
Ante la publicación de estas vulnerabilidades críticas, en HostingTG hemos procedido a actualizar todos nuestros servidores con los últimos parches de seguridad disponibles.
Hemos prestado especial atención a las versiones de PHP instaladas, las actualizaciones publicadas por los fabricantes y los paquetes utilizados en nuestra infraestructura.
Para nosotros, estas intervenciones forman parte del trabajo habitual de administración y mantenimiento.
No se trata simplemente de reaccionar ante una noticia de seguridad.
Se trata de asumir que mantener servidores conectados a Internet exige supervisión, actualizaciones y capacidad de respuesta.
Desde que fundamos HostingTG en 2004 he tenido claro que ofrecer alojamiento web implica bastante más que proporcionar espacio en disco, memoria RAM o potencia de procesamiento.
Un servicio de hosting también necesita una infraestructura mantenida y profesionales capaces de actuar cuando aparecen problemas que pueden afectar a las aplicaciones de los clientes.
Actualización de servidores y verificación de parches
En esta ocasión, una de las cuestiones más importantes ha sido comprobar que las correcciones de seguridad estaban disponibles para los paquetes utilizados en nuestros servidores.
Como he explicado anteriormente, los fabricantes pueden incorporar parches sin modificar necesariamente el número principal de versión de PHP.
Por eso, la versión que aparece en un panel de control no siempre permite determinar por sí sola si una instalación está protegida.
Es necesario revisar los paquetes y contrastarlos con la información publicada por el proveedor.
También debemos tener en cuenta que actualizar un componente no debería provocar la interrupción innecesaria de otros servicios.
La administración de servidores exige mantener ese equilibrio entre seguridad, estabilidad y compatibilidad.
Cuando aparece una vulnerabilidad crítica, la prioridad debe ser corregirla, pero sin olvidar las comprobaciones que permiten asegurar que las aplicaciones continúan funcionando.
Esa es la filosofía que seguimos en HostingTG.
Por qué la seguridad de un hosting requiere mantenimiento continuo
Hay una frase que resume bastante bien mi forma de entender la seguridad informática:
La seguridad no es algo que se configura una vez y se olvida. Es un trabajo diario.
Durante estos años he visto cómo evoluciona Internet, cómo cambian los ataques y cómo aparecen vulnerabilidades en tecnologías que utilizamos constantemente.
Ningún administrador ni proveedor de alojamiento puede garantizar que jamás se descubrirá un nuevo fallo de seguridad.
Sería una afirmación poco realista.
Lo que sí podemos hacer es mantener una política de actualizaciones, prestar atención a las alertas de seguridad y actuar con rapidez cuando se publican nuevas correcciones.
También podemos reducir los riesgos mediante una correcta configuración de los servicios, permisos adecuados, mecanismos de aislamiento y supervisión continua.
En mi opinión, la calidad de un proveedor de hosting no se mide únicamente cuando todo funciona perfectamente.
También se demuestra cuando aparece una alerta importante y hay que reaccionar.
Es en esas situaciones cuando adquiere especial valor contar con una infraestructura administrada y con profesionales que se ocupen de su mantenimiento.
La importancia de anticiparse a los problemas de seguridad
Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 vuelven a recordarnos que la seguridad de una página web depende de mucho más que mantener actualizado su gestor de contenidos.
Podemos tener WordPress, PrestaShop o WooCommerce completamente al día y continuar expuestos si el intérprete PHP utiliza paquetes vulnerables.
Por eso, ante esta alerta, mi recomendación es comprobar qué versión de PHP utiliza realmente cada aplicación, verificar los parches disponibles y asegurarse de que las correcciones se han aplicado correctamente.
Si utilizas un servicio de alojamiento compartido, pregunta a tu proveedor si sus servidores están actualizados frente a estas vulnerabilidades.
Si administras tus propios servidores, consulta los avisos oficiales de los fabricantes y revisa los paquetes instalados.
Y si todavía dependes de versiones antiguas de PHP, considera seriamente modernizar tus aplicaciones o disponer de un servicio de mantenimiento extendido que cubra los fallos identificados.
En HostingTG ya hemos actuado actualizando nuestros servidores con los últimos parches de seguridad disponibles.
Lo hemos hecho porque, después de más de dos décadas trabajando en este sector, sigo convencido de que resulta mucho más razonable prevenir una incidencia que tener que afrontar sus consecuencias.
La seguridad de un servidor no depende únicamente de cómo esté configurado hoy, sino también de cómo se mantiene y se protege cada día.
Y cuando aparece una vulnerabilidad crítica en PHP, actuar a tiempo puede marcar la diferencia.
Dudas de la comunidad
¿La vulnerabilidad afecta a todas las páginas web?
No necesariamente. Estas vulnerabilidades afectan a determinadas versiones del intérprete PHP y su explotación depende de las condiciones y configuraciones presentes en cada servidor.
Las páginas web que utilizan otros lenguajes o entornos no quedan afectadas directamente por estos fallos de PHP, aunque pueden utilizar otros componentes vulnerables.
¿Es suficiente con actualizar WordPress?
No. Actualizar WordPress, sus temas y sus plugins es fundamental, pero no corrige una vulnerabilidad existente en el intérprete PHP del servidor.
Para solucionar estos fallos es necesario que el entorno PHP utilizado por la aplicación incorpore las correcciones de seguridad correspondientes.
¿Cómo sé si mi proveedor de hosting ha aplicado los parches?
Lo más recomendable es solicitar confirmación directamente al proveedor de alojamiento.
Puedes preguntar si las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 están corregidas en los servidores y qué versiones o paquetes de seguridad se han instalado.
El proveedor debería poder confirmar el estado de las actualizaciones utilizadas en su infraestructura.
¿Qué hago si mi aplicación necesita una versión antigua de PHP?
Debes comprobar si existe un paquete con soporte extendido que incluya específicamente las correcciones de seguridad necesarias.
Si no está disponible, conviene estudiar medidas temporales para reducir la exposición y planificar la actualización de la aplicación.
Mantener indefinidamente un sistema vulnerable no es una solución recomendable.
¿Qué versiones de PHP corrigen CVE-2026-109618 y CVE-2026-109619?
Las primeras versiones corregidas publicadas por el proyecto PHP son 8.2.35, 8.3.36, 8.4.27 y 8.5.12.
Algunos fabricantes también proporcionan parches específicos para determinadas versiones anteriores, por lo que debes consultar siempre la documentación correspondiente a tu sistema.
¿Las vulnerabilidades permiten acceder automáticamente a todo el servidor?
No. Aunque estos fallos pueden permitir ejecución remota de código, el alcance de una explotación depende de la configuración, los permisos del proceso afectado y las medidas de aislamiento implementadas.
Esto no reduce la importancia de la alerta: estamos ante problemas críticos que deben corregirse cuanto antes.
¿Cómo puedo saber si mi página web ha sido atacada?
No existe una comprobación sencilla que permita garantizarlo únicamente mirando la versión de PHP.
Si sospechas de una intrusión, es recomendable analizar los registros, revisar modificaciones no autorizadas, investigar procesos sospechosos y solicitar ayuda a un profesional de seguridad.
Actualizar PHP elimina las vulnerabilidades corregidas en los nuevos paquetes, pero no elimina automáticamente posibles modificaciones introducidas durante una intrusión anterior.
