Vulnerabilidades PHP críticas: qué versiones actualizar hoy y cómo proteger tu web

El 21 de octubre de 2026, el equipo de PHP publicó un aviso de seguridad urgente sobre dos vulnerabilidades PHP críticas que pueden permitir la ejecución remota de código sin autenticación. En lenguaje sencillo: un atacante podría tomar control del servidor donde funciona una página web sin necesidad de usuario ni contraseña. La solución oficial es actualizar PHP a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, según la rama que utilice tu sitio.

El fallo no está en un plugin, un tema ni una plantilla concreta, sino en el propio motor de PHP. Por eso afecta a sitios en WordPress, tiendas en WooCommerce, sistemas a la medida y cualquier aplicación web que dependa de PHP. Si tienes un negocio en línea o administras sitios de clientes, esta es una actualización para revisar hoy, no en el próximo mantenimiento mensual.

Vulnerabilidades PHP del 21 de octubre: en pocas palabras

• PHP corrigió dos fallos críticos identificados como CVE-2026-109618 y CVE-2026-109619, ambos con una puntuación CVSS 4.0 de 9,2 sobre 10.
• Pueden permitir que un atacante ejecute código en el servidor sin iniciar sesión.
• Afectan a instalaciones de PHP que atienden peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.
• Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
• PHP 8.1 y versiones anteriores ya no reciben actualizaciones oficiales del proyecto PHP.
• Las medidas temporales reducen la exposición, pero según el propio aviso oficial no hacen segura una instalación: actualizar es la única solución completa.

Qué vulnerabilidades PHP se publicaron hoy

PHP es el lenguaje que hace funcionar una gran parte de los sitios web del mundo, incluido WordPress. Cada vez que alguien abre una página, envía un formulario o sube un archivo, PHP procesa esa petición en el servidor. Las dos vulnerabilidades publicadas afectan justamente esa etapa de procesamiento.

Resumen de las vulnerabilidades PHP publicadas el 21 de octubre de 2026

Identificador	Nombre oficial	Gravedad	Qué significa en la práctica
CVE-2026-109618	RCE via OOM corruption	Crítica (CVSS 9,2)	Cuando PHP se queda sin memoria en un momento delicado, puede dejar datos internos en mal estado y abrir la puerta a ejecutar código remoto.
CVE-2026-109619	RCE via stale global state	Crítica (CVSS 9,2)	Información de una visita anterior puede quedar «olvidada» en memoria y ser reutilizada por error en la siguiente petición, lo que también puede terminar en ejecución remota de código.

CVE-2026-109618: el fallo por falta de memoria

PHP limita la memoria que puede consumir cada visita para proteger el servidor. El problema aparece cuando ese límite se alcanza mientras PHP todavía está preparando los datos de la petición, por ejemplo al recibir un formulario con archivos adjuntos. En ese punto, la limpieza posterior puede tratar como válida información incompleta. Según el aviso técnico, una persona malintencionada puede provocar esa situación a propósito con peticiones especialmente construidas.

CVE-2026-109619: el fallo por información residual

Los servidores reutilizan los mismos procesos de PHP para atender muchas visitas seguidas. Este fallo ocurre cuando un error grave interrumpe una petición antes de que PHP limpie cierta información interna. La siguiente visita atendida por ese mismo proceso puede encontrarse con esos restos y usarlos antes de que el sistema los reinicie. Con la preparación adecuada, eso puede convertirse en ejecución remota de código.

En algunos reportes de seguridad estas fallas aparecen con el nombre informal «PHP2Shell». El aviso oficial de PHP no utiliza ese nombre; las referencias correctas para buscar parches y confirmar con tu proveedor son los dos identificadores CVE.

Quién está en riesgo por estas vulnerabilidades PHP

El aviso oficial señala que están expuestas todas las instalaciones de PHP que atienden peticiones web. Eso incluye las formas más comunes de ejecutar PHP en servidores y planes de hosting: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.

El equipo de PHP considera que el riesgo es mayor en Apache con mod_php, porque demostró un ataque en el que una sola petición sin autenticación puede activar el fallo antes de que se ejecute cualquier código de la aplicación. Dicho de otro modo, tener WordPress, plugins y temas al día no protege frente a este problema si la versión de PHP del servidor sigue siendo vulnerable. En términos de seguridad WordPress, la prioridad hoy no está en el escritorio del sitio, sino en el servidor.

Para un negocio, el riesgo no es solo técnico. Un servidor comprometido puede terminar en robo de datos de clientes, redirecciones a sitios fraudulentos, envío de spam desde tu dominio, páginas caídas en plena campaña o advertencias de seguridad en los buscadores que afectan tu reputación y tu posicionamiento.

Versiones de PHP afectadas y versiones corregidas

Versiones corregidas de PHP por rama y acción recomendada

Rama de PHP	Versión vulnerable	Versión corregida	Acción recomendada
PHP 8.5	Anterior a 8.5.12	8.5.12	Actualizar de inmediato
PHP 8.4	Anterior a 8.4.27	8.4.27	Actualizar de inmediato
PHP 8.3	Anterior a 8.3.36	8.3.36	Actualizar de inmediato
PHP 8.2	Anterior a 8.2.35	8.2.35	Actualizar de inmediato y planear el paso a una rama más reciente
PHP 8.1, 8.0, 7.4 y anteriores	Sin soporte oficial	Sin versión oficial nueva	Migrar a una rama con soporte o confirmar un parche del proveedor
PHP 8.6.0 (versiones de prueba)	Compilaciones previas a RC4	8.6.0 RC4	No usar en sitios en producción

Por la gravedad del caso, el equipo de seguridad de PHP publicó parches mínimos en código fuente para PHP 7.4, 8.0 y 8.1. Sin embargo, están pensados para quienes compilan PHP por su cuenta; no sustituyen una versión con soporte. Si tu sitio sigue en una de esas ramas, el problema de fondo es mayor que estas dos vulnerabilidades. Te explicamos los motivos en la guía sobre por qué mantener actualizada la versión de PHP de tu servidor.

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

Para saber si las vulnerabilidades PHP afectan a tu sitio, el primer dato que necesitas es la versión instalada. No hacen falta conocimientos técnicos para hacer esa revisión. Si tu sitio funciona con WordPress:

1. Entra al escritorio de WordPress con un usuario administrador.
2. Ve a Herramientas > Salud del sitio.
3. Abre la pestaña Información.
4. Despliega la sección Servidor y busca el dato Versión de PHP.

Si tu sitio no usa WordPress, revisa el panel de control de tu plan de hosting, donde normalmente aparece un selector o indicador de la versión de PHP, o pregunta directamente a tu proveedor o a la persona que administra el servidor.

Si el número de versión no cambió, no siempre significa que sigas expuesto

El aviso oficial indica que las distribuciones de Linux y los proveedores con soporte extendido recibieron los parches por adelantado. Algunos de ellos aplican la corrección sobre su propia versión empaquetada sin cambiar el número principal. Por eso, si ves una versión anterior a las corregidas, la pregunta correcta para tu proveedor no es solo «¿qué versión tengo?», sino «¿mi servidor ya incluye la corrección para CVE-2026-109618 y CVE-2026-109619?».

Cómo actualizar PHP para corregir las vulnerabilidades

La forma de actualizar depende de quién administra el servidor. En la mayoría de planes de hosting compartido o administrado, la actualización de seguridad de PHP la aplica el proveedor. En servidores propios, VPS o servidores en la nube, la responsabilidad suele ser de tu equipo técnico.

1. Identifica la versión actual: anota la rama y la versión exacta de PHP de cada sitio.
2. Confirma una copia de seguridad reciente: verifica que incluya archivos y base de datos, y que se pueda restaurar. Si tienes dudas, revisa la diferencia entre copias de seguridad web y almacenamiento.
3. Pide o aplica la actualización: solicita a tu proveedor la versión corregida de tu misma rama, o actualiza los paquetes del sistema si administras el servidor.
4. Reinicia los procesos de PHP: el servicio debe reiniciarse para que la versión corregida empiece a atender las visitas. Confirma que este paso se haya realizado.
5. Verifica el resultado: vuelve a revisar la versión en Salud del sitio o pide confirmación escrita del parche.
6. Prueba lo que genera ingresos: formularios de contacto, inicio de sesión, carrito, pagos, buscador, carga de imágenes y páginas principales.

Actualizar dentro de la misma rama, por ejemplo de 8.3.35 a 8.3.36, suele ser un cambio de bajo impacto para la compatibilidad, porque corrige fallos sin cambiar el funcionamiento del lenguaje. Saltar de rama, por ejemplo de 8.1 a 8.4, sí requiere más cuidado: lo ideal es probarlo antes en un entorno de pruebas o staging para detectar plugins o temas incompatibles.

Qué hacer si no puedes actualizar PHP de inmediato

El aviso oficial incluye medidas temporales para reducir algunos caminos de ataque mientras se programa la actualización. Están dirigidas a quien administra el servidor y el propio equipo de PHP advierte que reducen la exposición, pero no hacen segura la instalación.

• Desactivar el seguimiento del progreso de carga en las sesiones (session.upload_progress.enabled=0) desde la configuración principal del servidor y reiniciar todos los procesos de PHP.
• Reducir el tamaño máximo permitido de los envíos (post_max_size), especialmente en sitios que no necesitan recibir archivos.
• Poner límites en el servidor web o en el proxy al tamaño de las peticiones, la cantidad de campos y las partes de los formularios con archivos.
• En PHP 8.5, desactivar las trazas en errores fatales (fatal_error_backtraces=0) y reiniciar los procesos.
• Corregir errores fatales y tiempos de ejecución agotados que un visitante pueda provocar, por ejemplo en importaciones o cargas de archivos.

El aviso también aclara que ocultar los mensajes de error no ayuda y que algunos ajustes deben aplicarse en la configuración principal del servidor, no desde archivos de configuración por carpeta. Por eso, si no tienes acceso técnico al servidor, la medida práctica es la misma: pedir a tu proveedor la actualización y una confirmación por escrito.

Checklist para agencias que administran sitios de clientes

Una agencia de marketing o desarrollo web puede tener decenas de sitios en distintos servidores, planes y proveedores. Ante una alerta de vulnerabilidades PHP como esta, el orden importa más que la velocidad improvisada.

1. Haz un inventario: lista cada sitio, su proveedor de hosting, la versión de PHP y quién tiene acceso técnico al servidor.
2. Prioriza por exposición: atiende primero tiendas en línea, sitios con formularios, áreas de clientes, sistemas de reservas y cualquier web que reciba archivos.
3. Abre solicitudes con cada proveedor: pide la versión corregida y la confirmación explícita de los parches para los dos CVE.
4. Revisa sitios en versiones sin soporte: PHP 8.1 o anteriores necesitan un plan de migración, no solo un parche.
5. Comunica de forma clara a tus clientes: explica qué pasó, qué se revisó, qué se actualizó y si queda alguna acción pendiente, sin alarmar ni minimizar.
6. Documenta la evidencia: guarda fecha, versión anterior, versión nueva y resultado de las pruebas de cada sitio.
7. Vigila señales extrañas: usuarios administradores desconocidos, archivos recientes sin explicación, redirecciones o picos de envío de correos.

Este tipo de alerta también muestra la diferencia entre tener un plan de hosting y contar con un servicio de mantenimiento. Si tus clientes no tienen claro quién se encarga de estas tareas, la guía de mantenimiento web frente a hosting te ayuda a explicarlo.

Qué deben revisar las tiendas online

Una tienda en línea maneja datos personales, pedidos y, en muchos casos, integraciones con pasarelas de pago. Por eso es uno de los tipos de sitio donde las vulnerabilidades PHP del servidor tienen mayor impacto. Después de actualizar PHP, revisa el proceso completo de compra sin finalizar un pago real, confirma que los correos de pedidos se envían y que el panel de administración funciona con normalidad.

Si tu tienda usa WooCommerce, complementa esta revisión con las recomendaciones para proteger una tienda virtual de ataques.

Errores frecuentes frente a estas vulnerabilidades PHP

• Pensar que basta con actualizar WordPress y los plugins: el fallo está en PHP, no en WordPress.
• Suponer que un sitio pequeño no es objetivo: los ataques automatizados recorren internet buscando servidores vulnerables sin importar el tamaño del negocio.
• Confiar solo en las medidas temporales: el aviso oficial dice que no sustituyen la actualización.
• Instalar PHP 8.6.0 RC4 en producción: es una versión de prueba y PHP pide no usarla en sitios reales.
• No confirmar el reinicio de los procesos: una actualización sin reinicio puede dejar la versión anterior atendiendo visitas.
• Quedarse en PHP 8.1 o anteriores: esas ramas ya no reciben correcciones oficiales.

Fuentes oficiales

La información de este artículo procede del aviso de seguridad publicado por PHP, de los avisos técnicos GHSA-w8hw-w9fx-j79w (CVE-2026-109618) y GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), y de la página de versiones de PHP con soporte.

Preguntas frecuentes sobre las vulnerabilidades PHP

¿Mi sitio en WordPress está afectado?

Puede estarlo si el servidor usa una versión de PHP sin la corrección. El fallo está en PHP, así que afecta a WordPress aunque el núcleo, los plugins y el tema estén actualizados. Revisa la versión en Herramientas > Salud del sitio y confirma el parche con tu proveedor.

¿Qué versión de PHP es segura frente a estos fallos?

Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, o versiones posteriores de esas ramas. También puede estar protegida una versión empaquetada por tu distribución o proveedor si este confirma que incluye la corrección.

¿Un plugin de seguridad me protege de estas vulnerabilidades PHP?

No como solución completa. Según el aviso oficial, en el escenario de mayor riesgo el ataque puede activarse antes de que se ejecute el código de la aplicación, incluido WordPress y sus plugins. Un firewall o un plugin pueden sumar capas a la seguridad WordPress, pero no reemplazan la actualización de PHP.

¿Actualizar PHP puede romper mi sitio?

Una actualización dentro de la misma rama tiene bajo riesgo de incompatibilidad. El riesgo aumenta cuando se cambia de rama, por ejemplo de 8.1 a 8.4. En ese caso conviene hacer una copia de seguridad, probar en staging y revisar los plugins y el tema antes de aplicar el cambio en el sitio real.

¿Qué pasa si mi sitio usa PHP 8.1 o una versión anterior?

Esas ramas ya no reciben actualizaciones oficiales del proyecto PHP. Algunos proveedores ofrecen parches propios, pero lo recomendable es planear la migración a una rama con soporte lo antes posible.

Conclusión: actualizar PHP hoy es la decisión correcta

Las vulnerabilidades PHP publicadas el 21 de octubre de 2026 son de las más serias que puede recibir un sitio web: permiten ejecutar código en el servidor sin autenticación y afectan al motor que hace funcionar WordPress y millones de aplicaciones. La respuesta no requiere pánico, sino un orden claro: revisar la versión, confirmar una copia de seguridad, actualizar a la versión corregida, reiniciar PHP y probar las funciones clave del negocio.

Si administras tu propio sitio, empieza hoy por la revisión de Salud del sitio y una consulta a tu proveedor. Si eres una agencia, convierte esta alerta en un procedimiento repetible: inventario, prioridades, evidencia y comunicación clara con cada cliente. Esa rutina es la que marca la diferencia la próxima vez que aparezca una alerta crítica.