Vulnerabilidades críticas de PHP: lo que los propietarios de sitios WordPress deben saber.

English version: Critical PHP Vulnerabilities: What WordPress Site Owners Need to Know

PHP publicó correcciones para dos vulnerabilidades críticas el 21 de octubre de 2026. Actualizar WordPress o los plugins no las soluciona. Aprende cómo comprobar si tu entorno de alojamiento está afectado y qué pasos debes seguir.

En resumen: lo que sucedió

El 21 de octubre de 2026, el proyecto PHP publicó correcciones para dos vulnerabilidades críticas en el entorno de ejecución de PHP, CVE-2026-109618 y CVE-2026-109619, ambas con una calificación de 9.2 según CVSS v4.0. Bajo ciertas condiciones, permiten que un atacante no autenticado ejecute código en el servidor web. Estas vulnerabilidades se encuentran en PHP, no en el núcleo, los temas ni los complementos de WordPress, por lo que la solución debe provenir de una versión de PHP parcheada instalada en el servidor.

Acción recomendada: Solicite a su proveedor de alojamiento que confirme que la versión de PHP que aloja su sitio web está actualizada para corregir ambas vulnerabilidades. Si usted mismo administra el servidor, instale un paquete de PHP actualizado y reinicie PHP.

Las advertencias del proyecto PHP las denominan RCE por corrupción de OOM (CVE-2026-109618) y RCE por estado global obsoleto (CVE-2026-109619). En ambos casos, una solicitud que falla en el momento equivocado puede dejar datos internos en un estado inválido que PHP utilizará posteriormente.

Un ataque exitoso ejecuta código con los privilegios de la cuenta con la que se ejecuta PHP. Dependiendo de la configuración del servidor, esto podría permitir que un atacante lea wp-config.php y las credenciales de la base de datos que contiene, acceda o modifique la base de datos, o altere los archivos y el contenido del sitio. Un proceso PHP comprometido no otorga automáticamente al atacante acceso de administrador al servidor.

Estado de explotación (a fecha de 21 de octubre de 2026)

La Fundación PHP declaró que su equipo de seguridad no había encontrado ninguna vulnerabilidad funcional en el código de prueba de concepto (PoC) publicado antes del lanzamiento, pero que el desarrollo de PoC se había acelerado. El 21 de octubre, Cloudflare, que denomina a las vulnerabilidades "php2shell", informó haber detectado tráfico de ataque dirigido a sus clientes y que los atacantes estaban modificando sus payloads para intentar eludir sus protecciones. Ninguna de las fuentes reporta un ataque exitoso confirmado. El tráfico de ataque demuestra que los atacantes están intentándolo activamente, pero no confirma por sí solo que se haya producido una brecha de seguridad en ningún sitio. Actualizaremos esta sección a medida que la situación evolucione.

¿Quiénes son los potencialmente afectados?

Potencialmente, cualquier sitio web que utilice una compilación de PHP sin parchear se verá afectado, independientemente de las versiones de WordPress, temas y complementos que ejecute. El aviso del proyecto PHP abarca todas las instalaciones de PHP que gestionan solicitudes web, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.

El proyecto PHP considera que el riesgo es mayor en mod_php, donde se ha demostrado una vulnerabilidad que permite que una solicitud no autenticada se active antes de que se ejecute cualquier código de la aplicación. Esto no significa que otras configuraciones sean seguras. Todas las instalaciones de PHP que gestionan solicitudes web necesitan la corrección.

Cómo comprobar la versión de PHP y el estado de los parches.

En el panel de WordPress, ve a Herramientas → Salud del sitio → Información y expande la sección Servidor . Allí verás la versión de PHP y la API del servidor (SAPI) de PHP que aloja tu sitio. La mayoría de los paneles de control de alojamiento web muestran la misma información. Si usas WP Cerber, en WP Cerber → Herramientas → Diagnóstico también se muestran la versión de PHP y la API del servidor.

Las siguientes versiones publicadas por el proyecto PHP contienen las correcciones:

Importante: estas son versiones upstream, no una prueba universal de versión mínima. Las distribuciones de Linux y los proveedores de soporte a largo plazo (LTS) comerciales pueden incorporar las correcciones en compilaciones que mantengan un número de versión anterior, incluidas las compilaciones de las ramas 8.2, 8.3 y 8.4 compatibles. Por ejemplo, Ubuntu 24.04 LTS mantiene sus paquetes PHP 8.3 bajo una cadena de versión basada en 8.3.6 y distribuye ambas correcciones en la versión del paquete 8.3.6-0ubuntu0.24.04.13. Site Health por sí solo no puede determinar si la compilación de un proveedor contiene ambas correcciones. Consulte el aviso de seguridad del proveedor o el registro de cambios del paquete, o pregunte a su proveedor de alojamiento. No cambie a un repositorio de paquetes PHP de terceros solo porque su número de versión sea inferior a la versión upstream corregida.

PHP 7.4, 8.0 y 8.1. Las compilaciones parcheadas de estas ramas, basadas en los backports del código fuente del proyecto PHP, abordan ambas vulnerabilidades con una mitigación mínima para las versiones que han llegado al final de su ciclo de vida, la cual es más limitada que la solución completa incluida en la versión 8.2 y posteriores. Con esta mitigación, un proceso PHP que se queda sin memoria se termina inmediatamente, por lo que un sitio que exceda su límite de memoria puede mostrar un error genérico del servidor en lugar de la pantalla de error crítico de WordPress. En dichas compilaciones, la herramienta Salud del sitio puede mostrar el mismo número de versión antes y después de la actualización, por lo que se recomienda confirmar la solución con su proveedor de alojamiento o en el registro de cambios del paquete. Se sigue recomendando actualizar a una rama compatible.

El soporte para PHP 8.2 finalizará pronto. El soporte de seguridad del proyecto PHP para PHP 8.2 termina el 31 de diciembre de 2026. Si actualiza desde PHP 7.4, 8.0 u 8.1, elija PHP 8.3 o posterior, haga una copia de seguridad del sitio primero y verifique que su tema y complementos sean compatibles. Como alternativa, solicite a su proveedor de alojamiento una versión parcheada de su rama actual.

Por qué debe aplicarse la solución en el servidor

El código vulnerable forma parte del entorno de ejecución de PHP que ejecuta WordPress, no forma parte de WordPress en sí.

• Actualizar WordPress no soluciona estas vulnerabilidades de PHP. Actualizar el núcleo, los temas o los complementos de WordPress no modifica el entorno de ejecución de PHP.
• Los complementos de seguridad no pueden solucionar el problema de tiempo de ejecución. Algunas rutas de explotación pueden ejecutarse antes de que WordPress se cargue, por lo que ningún complemento tiene la oportunidad de inspeccionar la solicitud. Las reglas del firewall de aplicaciones web (WAF) a nivel de alojamiento o de red pueden reducir ciertas rutas de ataque, pero no sustituyen por completo la aplicación de parches.
• Modificar la configuración desde dentro del sitio no es una solución fiable. El aviso del proyecto PHP advierte sobre los riesgos de usar ini_set() o los archivos ` .user.ini de FPM para aplicar sus medidas de mitigación de configuración, y lo mismo se aplica a la configuración de PHP modificada en wp-config.php o mediante un plugin. Incluso las medidas a nivel de servidor descritas en el aviso solo reducen la exposición a rutas de ataque específicas y no garantizan la seguridad de la instalación.

Nota para los usuarios de WP Cerber: WP Cerber se ejecuta dentro de WordPress. No puede parchear PHP ni inspeccionar una solicitud que active una de estas vulnerabilidades antes de que WordPress se cargue. Por la misma razón, los registros de WP Cerber podrían no registrar dicho intento, por lo que un registro sin entradas sospechosas no prueba que el sitio no haya sido atacado. WP Cerber sigue protegiendo WordPress a nivel de aplicación, pero no sustituye la actualización de PHP.

¿Qué hacer ahora?

Si usted no administra el servidor

Esto se aplica al alojamiento compartido y administrado, donde su proveedor es responsable del mantenimiento del entorno de ejecución de PHP. Pídales que confirmen que la compilación de PHP que sirve a su sitio web contiene correcciones para ambas vulnerabilidades. Puede enviar esta pregunta tal cual:

¿La versión de PHP que sirve a mi sitio web está parcheada contra las vulnerabilidades CVE-2026-109618 y CVE-2026-109619? ¿Se han reiniciado los procesos de PHP correspondientes para cargar la versión parcheada?

Si administra un servidor VPS o dedicado

1. Actualiza PHP. Instala la versión parcheada original o un paquete de distribución o proveedor cuyo aviso o registro de cambios confirme que contiene ambas correcciones.
2. Reinicia PHP. Reinicia o recarga PHP-FPM, Apache o cualquier otro servicio que ejecute PHP para tus sitios. Los procesos en ejecución seguirán utilizando el binario antiguo hasta que se reinicien.
3. Verifica. Comprueba en Salud del sitio que la compilación de PHP esperada se esté utilizando en cada sitio. Luego, confirma por separado, en el aviso del proveedor o en el registro de cambios del paquete, que el paquete instalado contiene ambas correcciones. Salud del sitio muestra la versión en ejecución, pero no puede demostrar que se incluya una retrocompatibilidad. El comando php -v puede informar de una instalación de PHP diferente a la que se utiliza en tu sitio web, así que no te fíes únicamente de él.

Sea cual sea tu caso, guarda una copia de seguridad reciente que sepas que puedes restaurar. Si sospechas que el sitio se vio comprometido antes de que se actualizara PHP, ten en cuenta que actualizar PHP no elimina el malware ni las puertas traseras. En ese caso, contacta primero con tu proveedor de hosting, ya que el acceso obtenido a través de PHP puede no limitarse a los archivos de WordPress. Para limpiar la instalación de WordPress, consulta nuestra guía «Qué hacer si tu sitio de WordPress ha sido hackeado» .

Preguntas frecuentes

¿Corre riesgo mi ordenador o mi navegador al visitar un sitio web afectado?

No directamente. Las vulnerabilidades se encuentran en PHP del servidor web, no en los dispositivos ni en los navegadores de los visitantes. Sin embargo, un sitio web comprometido a través de estas vulnerabilidades podría modificarse para mostrar contenido malicioso, por lo que los visitantes pueden enfrentarse a riesgos indirectos.

¿Necesito reinstalar WordPress?

No, no se trata de solucionar estas vulnerabilidades. Se corrigen actualizando PHP en el servidor, y reinstalar WordPress no modifica PHP. Aun así, una reinstalación puede formar parte del proceso de limpieza de un sitio web que ha sido comprometido.

¿Puedo solucionar esto sin la ayuda de mi proveedor de alojamiento web?

Depende de si controlas el entorno de ejecución de PHP. En un VPS o servidor dedicado, puedes instalar tú mismo los paquetes parcheados. En un alojamiento compartido o administrado, el proveedor controla PHP. Muchos paneles de control permiten cambiar una versión de PHP de un sitio, pero que dicha versión esté parcheada o no depende del proveedor.

Fuentes

• Proyecto PHP, Aviso de seguridad: Vulnerabilidades críticas de ejecución remota de código, actualice ahora , 21 de octubre de 2026.
• Proyecto PHP, GHSA-w8hw-w9fx-j79w: RCE a través de corrupción de OOM (CVE-2026-109618) , 21 de octubre de 2026.
• Proyecto PHP, GHSA-6wmf-4rv5-p3rp: RCE a través de estado global obsoleto (CVE-2026-109619) , 21 de octubre de 2026.
• La Fundación PHP, la actualización de seguridad de PHP de hoy y cómo estamos reforzando la seguridad de PHP , 21 de octubre de 2026.
• Proyecto PHP, versiones compatibles .
• php-src commit 712e60f: Evitar la corrupción del estado mediante rescate , la mitigación mínima para versiones al final de su ciclo de vida.
• Repositorio RPM de Remi, registro de cambios de php74-php , entrada para 7.4.33-31, 21 de octubre de 2026.
• Ubuntu, páginas de estado de seguridad para CVE-2026-109618 y CVE-2026-109619 , 21 de octubre de 2026.
• Cloudflare, Cloudflare implementa protecciones contra la vulnerabilidad php2shell , 21 de octubre de 2026.