php2shell: las vulnerabilidades de PHP que todo sitio WordPress debe parchear ya

Qué es php2shell

CVE-2026-109618 es un fallo en cómo PHP se recupera cuando una petición se queda sin memoria: PHP puede detenerse mientras los datos internos de la petición solo están preparados a medias, y la limpieza posterior trata esos datos rotos como válidos. CVE-2026-109619 permite que el estado interno de una petición sobreviva a su memoria, de modo que una petición posterior atendida por el mismo worker de PHP puede usarlo. El proyecto PHP calificó ambas con 9,2 en la escala CVSS v4.0, es decir, críticas.

Afecta a toda instalación de PHP que atiende peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El proyecto PHP considera que el riesgo es mayor con mod_php, porque hay un exploit funcional en el que una sola petición sin autenticar dispara el ataque antes de que se ejecute código de la aplicación. Investigadores de seguridad informan de que ya hay código de prueba de concepto público, así que cuenta con ataques automatizados contra todo sitio PHP.

Qué versiones de PHP lo corrigen

Cada rama de PHP con soporte tiene una versión que corrige ambos fallos (en la tabla). PHP 8.2 llega al final de su vida el 31 de diciembre de 2026 y después no recibirá correcciones de seguridad; si vas a actualizar de todos modos, pasar a 8.3 o posterior te ahorra otra actualización pronto.

PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto PHP. Algunas distribuciones de Linux y proveedores con soporte a largo plazo ofrecen correcciones adaptadas, y el equipo de seguridad de PHP publicó adaptaciones mínimas del código fuente para 7.4, 8.0 y 8.1 para quien compila PHP por su cuenta. Para todos los demás, la respuesta es actualizar a una versión corregida.

Por qué las actualizaciones de WordPress no lo corrigen

WordPress, sus plugins y sus temas están escritos en PHP, pero PHP está instalado en el servidor. Las actualizaciones automáticas, la pantalla de actualizaciones y los plugins de seguridad no pueden cambiarlo. En un hosting gestionado o compartido, tu proveedor actualiza PHP; en tu propio servidor, viene de los paquetes de tu sistema operativo o de donde instalaste PHP.

Cómo comprobar tu sitio

En WordPress, abre Herramientas → Salud del sitio → Información y despliega Servidor: ahí aparece la versión de PHP. Si es inferior a la versión corregida de su rama, el sitio está expuesto.

Un detalle: si tu PHP viene de una distribución de Linux (Debian, Ubuntu, RHEL, AlmaLinux y otras), la corrección suele adaptarse sin cambiar el número de versión. Una versión como 8.2.7-1~deb12u1 puede estar ya parcheada. Consulta el aviso de seguridad de tu distribución sobre CVE-2026-109618 y CVE-2026-109619, o pregunta a tu proveedor qué compilación tienes.

Si tu proveedor gestiona PHP, revisa su página de estado o pregúntale directamente si ya ha instalado una de las versiones corregidas. Si administras tú el servidor, haz una copia de seguridad, instala los paquetes actualizados de tu distribución o proveedor y reinicia PHP.

Si no puedes actualizar hoy

El proyecto PHP deja claro que solo una actualización lo corrige del todo. Su aviso enumera ajustes que reducen vías de ataque concretas mientras programas la actualización. Aplícalos tal como están escritos allí, en php.ini o en la configuración del servidor en lugar de ini_set() o un archivo .user.ini, y reinicia todos los workers de PHP.

Para CVE-2026-109619 el ajuste principal es session.upload_progress.enabled=0. Para CVE-2026-109618 el aviso sugiere memory_limit=-1, fijado donde las aplicaciones no puedan cambiarlo, junto con un post_max_size bajo y un límite de memoria de contenedor o cgroup como red de seguridad. Lee el aviso antes de cambiar límites de memoria: memory_limit=-1 elimina el tope de memoria de PHP, por eso va acompañado de un límite externo.

Ten cuidado con los arreglos rápidos que circulan en foros y redes sociales, como scripts en el borde que prometen bloquear el ataque. En el mejor de los casos reducen la exposición, y un código de un autor desconocido que inspecciona cada subida a tu sitio es un riesgo en sí mismo. La solución es actualizar PHP.

Cómo lo señala Relvato

El monitor de vulnerabilidades de Relvato lee, a través del plugin de Relvato, la versión de PHP con la que funciona un sitio WordPress y señala php2shell como hallazgo crítico con la versión a la que actualizar. En un sitio sin el plugin, el análisis de exposición lo señala cuando el servidor anuncia una versión vulnerable de PHP en su cabecera X-Powered-By, y sugiere ocultar esa cabecera.

Si tu proveedor parcheó una compilación de distribución sin cambiar el número de versión, pídele que lo confirme e ignora el hallazgo: seguirá ignorado en los análisis siguientes.