PHP2Shell: WordPress no puede parchear esto

El 21 de octubre de 2026 a las 13:30 UTC, el equipo de PHP liberó 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Traen la corrección de dos vulnerabilidades críticas que se conocen juntas como PHP2Shell: CVE-2026-109618 y CVE-2026-109619, ambas con CVSS 9.2.

Las dos son ejecución remota de código sin autenticación. No hace falta usuario, contraseña ni un plugin vulnerable. Basta con que el servidor tenga PHP y esté expuesto a internet.

Y acá va lo importante, porque es lo que casi nadie está explicando: si tenés WordPress actualizado, seguís expuesto. La falla no está en WordPress. Está una capa más abajo.

Este tipo de falla se detecta con monitoreo, no con suerte.

El parche de PHP no lo aplica WordPress: lo aplica el servidor. Un plan de mantenimiento incluye verificación de la versión real de PHP, coordinación con el hosting, mitigaciones temporales y revisión de compromiso posterior.

Ver el servicio de mitigación PHP2Shell →

Qué pasó

Son dos bugs distintos con el mismo resultado. Conviene entenderlos por separado, porque las mitigaciones también son distintas.

CVE-2026-109618 — corrupción de memoria en el manejo del límite de memoria. PHP aplica su memory_limit configurable usando longjmp(): aborta el request en el momento exacto en que se pasa del límite. Si eso ocurre mientras PHP está parseando un file upload multipart, el request queda a medio construir. La limpieza posterior trata esos datos inválidos como si fueran válidos y libera memoria que nunca se inicializó. Esa memoria todavía contiene datos de requests anteriores, que el atacante controla.

CVE-2026-109619 — estado global que sobrevive al request. Un error fatal corta el request, pero el worker conserva referencias a memoria ya liberada. El siguiente request que atiende ese mismo worker puede leer ese estado viejo antes de que la inicialización normal lo pise.

Afecta a PHP-FPM, mod_php de Apache, php-cgi, FrankenPHP y LiteSpeed. O sea: toda instalación que sirva requests web, desde PHP 5.4 en adelante.

El equipo de PHP marca mod_php como el escenario de mayor riesgo. Hay un exploit demostrado que dispara el ataque con un solo request sin autenticar, antes de que corra una línea de código de la aplicación.

Y el 23 de octubre, dos días después, apareció una tercera: CVE-2026-115560. Esa es mucho más acotada —solo afecta aplicaciones que cambian session.serialize_handler en runtime antes de llamar a session_start()— y el equipo de PHP la considera de riesgo improbable. No habrá release de emergencia: la resuelven en el ciclo normal. La mitigación es session.upload_progress.enabled=0, la misma que ya se recomendaba el 21.

Por qué tu WordPress no puede arreglar esto

PHP2Shell no es un CVE de WordPress. Es un CVE del intérprete que ejecuta WordPress. La falla vive en el binario de PHP o en el módulo que lo embebe dentro del servidor web.

Las consecuencias son concretas:

• WordPress 7.1.2, el último security release, no corrige nada de esto. No puede: no es su código.
• El auto-update de WordPress no aplica el parche. Aunque tengas las actualizaciones automáticas activas y el panel diga “todo al día”.
• Wordfence, MalCare, 2FA, login renombrado y los WAF de plugin no frenan el escenario mod_php. Todos corren después de que PHP arrancó el request. El ataque ocurre antes.
• Un WAF perimetral sí ayuda: Cloudflare publicó reglas de emergencia el mismo 21. Pero inspecciona el tráfico, no repara el intérprete.

Dicho de otro modo: podés tener el WordPress más actualizado del mundo corriendo sobre un PHP 8.1 sin parchear, y estar completamente expuesto.

Qué significa estar expuesto

RCE sin autenticación y por debajo del código de la aplicación equivale a control total del servidor. Desde ahí el atacante lee wp-config.php y obtiene usuario y contraseña de la base, salts y claves de API; escribe en cualquier archivo; instala persistencia por fuera de WordPress; y pivotea a otros sitios del mismo hosting compartido.

Hay un detalle que complica la detección: si el ataque entra por debajo de la aplicación, el log de WordPress y los plugins de seguridad no muestran nada raro. El sitio sigue funcionando. Vos no te enterás.

Cómo saber si tu PHP está parcheado

No alcanza con mirar la versión de WordPress. Y tampoco alcanza con php -v por SSH: ese comando puede mostrar un PHP distinto al que usa el servidor web.

1. Desde WordPress: Herramientas → Salud del sitio → Información → Servidor. Ahí ves la versión que realmente está sirviendo el sitio.
2. Compará con las versiones corregidas: 8.5.12, 8.4.27, 8.3.36, 8.2.35. Si el número es menor, no está parcheado.
3. Cuidado con las distros: Debian, Ubuntu y RHEL suelen backportear el fix sin cambiar el número de versión. La versión se ve vieja, pero el parche está. Se confirma comparando el paquete (dpkg -l o rpm -q) con la versión corregida que publique tu proveedor.

Si estás en hosting gestionado, esto no lo resolvés vos: lo resuelve el hosting. Hostinger ya lo aplicó el 22 de octubre en todos sus planes salvo VPS. Si tu proveedor no lo hizo, es momento de abrir ticket y guardar la respuesta por escrito.

Si estás en un VPS o servidor propio, el parche es tuyo.

Si todavía no podés actualizar

Actualizar es el único fix completo. Pero si el cambio de versión te lleva días —porque hay plugins que rompen, porque el hosting no lo permite, porque es un PHP sin soporte— estas son las mitigaciones que publicaron el equipo de PHP y CERT-EU. Todas se aplican en configuración que se lee antes de parsear el request, y hay que reiniciar todos los workers después. ini_set() y .user.ini no sirven: corren demasiado tarde.

Contra CVE-2026-109618 (corrupción en OOM):

• memory_limit=-1 fijado con php_admin_value en el pool de FPM o en la config de Apache, para que la aplicación no lo pueda subir de nuevo. Suena contraintuitivo, pero el exploit necesita un límite finito para disparar la ruta vulnerable.
• post_max_size bajo: 8M si el sitio no recibe archivos, 32M si los recibe. upload_max_filesize siempre por debajo.
• Límites en el proxy o el servidor web: tamaño de body decodificado, cantidad de campos, partes multipart, headers y profundidad de anidado. Incluyendo requests sin Content-Length.
• Memoria acotada por container o cgroup. Nunca RLIMIT_AS ni RLIMIT_DATA: esos provocan justo la falla de asignación que dispara el bug.
• Si el sitio no usa multipart/form-data, bloquear ese tipo de request antes de que llegue a PHP.

Contra CVE-2026-109619 (estado viejo):

• session.upload_progress.enabled=0 en php.ini, pool de FPM o config del servidor. Reiniciar workers.
• En PHP 8.5, fatal_error_backtraces=0.
• pm.max_requests=1 si el rendimiento lo permite: cada worker muere después de un request y se rompe el vínculo entre el que planta el dato y el que lo reusa.
• Eliminar directivas inválidas o deprecadas que tiren warnings antes de iniciar el request.
• Corregir los errores fatales y timeouts que un atacante pueda alcanzar.

Contra CVE-2026-115560:

• session.upload_progress.enabled=0. Si ya lo aplicaste el 21, no hay nada más que hacer.

Qué hacer ahora

En orden:

1. Verificá tu versión real de PHP (Salud del sitio → Información → Servidor).
2. Si es menor a 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35, actualizá hoy. En hosting gestionado, abrí ticket y pedí confirmación por escrito.
3. Si estás en PHP 8.1 o anterior: no hay parche upstream. PHP publicó backports mínimos de código para 7.4, 8.0 y 8.1, pero si no compilás desde fuente la salida es migrar a una rama soportada. Y ojo: PHP 8.2 llega a fin de vida el 31 de diciembre de 2026.
4. Reiniciá Apache, PHP-FPM y todo worker de larga duración. Un contenedor sin rebuild sigue con el PHP viejo.
5. Dejá session.upload_progress.enabled=0 aunque ya hayas parcheado. No perdés nada y cierra una clase entera de ataques.
6. Si el sitio estuvo expuesto con PHP sin parchear entre el 21 y hoy, tratalo como posiblemente comprometido: rotá salts, contraseña de base, claves de API y contraseñas de administradores, y revisá archivos nuevos fuera de wp-content.
7. Revisá los logs de Apache y FPM de esos días buscando requests multipart anómalos seguidos de errores de memory limit, 500 repetidos y reciclado inusual de workers.

La lección de fondo no es PHP2Shell. Es que la seguridad de un WordPress no termina en WordPress. Termina en el servidor que lo corre, y ese es el que casi nadie mira.

Si querés que lo verifique por vos, te digo en qué estado está tu PHP y qué falta: mitigación PHP2Shell para WordPress. Y si el sitio ya muestra señales de compromiso, el camino es recuperar un WordPress hackeado.

Preguntas frecuentes

¿Actualizar WordPress me protege de PHP2Shell? No. PHP2Shell son dos vulnerabilidades del intérprete de PHP (CVE-2026-109618 y CVE-2026-109619), no de WordPress. El auto-update de WordPress no puede aplicar ese parche porque no es su código. Tenés que actualizar PHP en el servidor a 8.5.12, 8.4.27, 8.3.36 o 8.2.35.

¿Cómo sé qué versión de PHP está usando mi WordPress? En el panel de WordPress andá a Herramientas → Salud del sitio → Información → Servidor. Ahí figura la versión real que sirve el sitio. No uses php -v por SSH: puede mostrar una versión distinta a la del servidor web.

¿Wordfence o un plugin de seguridad me protegen de PHP2Shell? No en el escenario mod_php, que es el de mayor riesgo. Los plugins corren después de que PHP arrancó el request, y el ataque ocurre antes. Solo un WAF perimetral (Cloudflare, AWS WAF) inspecciona antes de que el request llegue al servidor, y aun así es mitigación, no solución.

¿Qué hago si mi hosting no actualiza PHP? Abrí un ticket y pedí confirmación por escrito de la versión y la fecha de build. Mientras tanto aplicá las mitigaciones temporales: memory_limit=-1 por php_admin_value, post_max_size bajo y session.upload_progress.enabled=0, con reinicio de todos los workers. Si el proveedor no responde, migrar de hosting es parte de la solución.

¿Cómo sé si ya me comprometieron? Rotá salts de wp-config.php, contraseña de la base, claves de API y contraseñas de administradores, y revisá archivos nuevos fuera de wp-content. En los logs de Apache o FPM buscá requests multipart anómalos seguidos de errores de memory limit, 500 repetidos y reciclado inusual de workers.