PHP2Shell: la falla en PHP que expone a WordPress

En pocas palabras: Hay que actualizar el intérprete PHP del servidor —no solo WordPress—. Los parches upstream son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, liberados el 21/10/2026, que corrigen CVE-2026-109618 y CVE-2026-109619 (CVSS 9.2). También son válidos los paquetes del proveedor con esos parches incorporados mediante backport oficial.

Dos vulnerabilidades críticas en el núcleo de PHP, bautizadas PHP2Shell, pueden permitir ejecución remota de código sin autenticación en instalaciones PHP afectadas, incluido WordPress, según la versión, la configuración y la ruta de ejecución. La PHP Foundation liberó parches el 21 de octubre de 2026: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Actualizar WordPress no alcanza: hay que parchear el intérprete PHP del servidor.

CVE-2026-109618 y CVE-2026-109619 son dos fallas de seguridad en memoria dentro del motor de PHP (no en WordPress ni en ningún plugin) que permiten a un atacante sin credenciales ejecutar código en el servidor. Ambas tienen CVSS 9.2 y afectan, según Wiz Research, prácticamente toda versión de PHP lanzada desde la 5.4 en adelante.

¿Qué son CVE-2026-109618 y CVE-2026-109619 (PHP2Shell)?

CVE-2026-109618 es una ejecución remota de código causada por corrupción de memoria cuando una solicitud alcanza el memory_limit de PHP en el momento exacto equivocado, dejando datos internos a medio inicializar que después el motor trata como válidos. CVE-2026-109619 es una ejecución remota de código por estado global obsoleto: un error fatal puede dejar un puntero interno apuntando a memoria de una solicitud anterior, y un worker reutiliza esa memoria liberada (use-after-free).

Según el anuncio oficial de la PHP Foundation, en Apache con mod_php un atacante sin autenticación puede disparar el primer fallo antes de que corra cualquier código de la aplicación, y el equipo confirmó RCE completo con configuración default. El segundo fallo se verificó con una demostración de RCE contra una aplicación real corriendo Apache con mod_php.

Ojo con el dato que circuló mal: durante la filtración del 20 de octubre se habló de un CVSS de 10.0. El puntaje real, confirmado tanto por la PHP Foundation como por el blog de seguridad de Ubuntu, es 9.2.

¿Por qué actualizar WordPress no alcanza para corregir PHP2Shell?

Porque el problema no está en WordPress: está en el intérprete PHP que corre por debajo. Wiz lo deja claro en su investigación: «la explotación no depende de un fallo en el código de la aplicación, incluso una simple aplicación ‘Hello World’ corriendo en una versión de PHP afectada puede ser vulnerable», según el análisis técnico de Wiz Research.

Esto cambia el enfoque de mitigación por completo. Actualizar plugins, cambiar de tema o auditar el código de tu sitio no sirve de nada si el servidor sigue corriendo una versión vieja de PHP. Hay que actualizar el paquete PHP a nivel sistema operativo, ya sea en Apache con mod_php o en PHP-FPM, y después reiniciar Apache si usás mod_php, o el servicio y los pools de PHP-FPM si usás FPM. Si no reiniciás, el worker sigue usando el binario viejo en memoria.

¿Qué versiones de PHP corrigen estas vulnerabilidades y cómo actualizo?

Las versiones parcheadas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, liberadas el 21 de octubre de 2026 según el comunicado oficial de la PHP Foundation. Las versiones upstream anteriores de cada rama requieren el parche; las distribuciones pueden incorporar la corrección mediante backports y conservar un número de versión base anterior. Verificá el paquete corregido que informa tu proveedor.

En Ubuntu, el proceso según el blog de seguridad de Canonical es así:

• Actualizar todo el sistema: sudo apt update && sudo apt upgrade.
• Actualizar solo PHP: si no querés tocar otros paquetes, sudo apt update && sudo apt install --only-upgrade '?name(^php[0-9.]+$)'.
• Reiniciar el servicio: con Apache y mod_php, sudo systemctl restart apache2. O directamente sudo reboot si preferís asegurarte de que todo quede limpio.
• Verificar qué tenés instalado: apt list '?installed ?name(^php[0-9.]+$)' te muestra la versión exacta del paquete PHP en el servidor.

Si tenés Ubuntu 20.04 LTS o anterior, necesitás una suscripción a Ubuntu Pro (gratis hasta 5 máquinas) para acceder a estos fixes vía Expanded Security Maintenance, según el mismo blog de Ubuntu. Si administrás el hosting de tu WordPress en un proveedor gestionado, confirmá con soporte que ya aplicaron el parche: no asumas que «como es managed, ya está». Ya lo cubrimos antes en otra falla reciente de inyección de objetos PHP.

¿WordPress, Drupal y Joomla están confirmados como vulnerables?

Sí, los tres CMS están confirmados como vulnerables mediante pruebas de concepto reales. Wiz Research combinó ambos CVEs en un único exploit, llamado php2shell, y logró ejecución remota de código pre-autenticación contra contenedores wordpress:latest, drupal:latest y joomla:latest usando sus imágenes más recientes al momento de la prueba, según el informe técnico de Wiz.

La tabla que publicó Wiz es elocuente: CVE-2026-109618 permitió RCE pre-autenticación en WordPress, Drupal y Joomla además de divulgación de memoria agnóstica a la aplicación. CVE-2026-109619 confirmó RCE pre-autenticación específicamente en Drupal y en WordPress mediante confusión de tipos en OPcache.

Estas tres plataformas son demostraciones representativas, no una lista cerrada. Cualquier aplicación PHP corriendo sobre una versión vulnerable está en riesgo, porque el problema vive en el motor y no en el código de la aplicación. Si tu sitio corre en PHP afectado, da igual que uses Magento, Laravel o un script casero.

¿Qué hacer si no puedo actualizar PHP de inmediato?

Si no podés parchear ya mismo, buscá mitigaciones temporales de tu proveedor de infraestructura mientras programás la actualización. Según Wiz, compañías como Cloudflare, Akamai, AWS, Google Cloud, Imperva y Vercel prepararon guías de mitigación y detecciones listas para usar para quienes no pueden aplicar el parche al instante. En tener backups a prueba de ransomware profundizamos sobre esto.

Mientras tanto, prestá atención a estas señales de posible explotación:

• Requests multipart inusuales seguidos de errores de memory_limit o respuestas HTTP 500 repetidas.
• Cookies PHPSESSID anormalmente grandes o malformadas en las respuestas del servidor.
• Caídas inesperadas de workers PHP sin una causa clara en los logs de la aplicación.

Eso sí: ninguna de estas señales reemplaza el parche. Como aclara Wiz en su análisis técnico, «estas señales pueden guiar una investigación. Aplicar la actualización de seguridad de PHP sigue siendo la única remediación completa». Si manejás tu propia infraestructura y todavía no migraste a un proveedor con parcheo rápido de este tipo de incidentes, es un buen momento para evaluar opciones como donweb.com para hosting y dominios en Argentina.

¿Por qué se adelantó la fecha de divulgación de PHP2Shell?

La PHP Foundation adelantó el lanzamiento del 22 al 21 de octubre porque los identificadores de CVE se filtraron en foros el 20 de octubre a las 15:00 UTC, acompañados de una fecha incorrecta y un CVSS erróneo de 10.0. No se filtraron detalles técnicos en ese momento, pero la Foundation decidió mover el pre-anuncio y publicarlo a las 19:30 UTC del mismo día, según su comunicado oficial.

La cosa se complicó más: a raíz del adelanto, la firma de seguridad Calif publicó por error un video con su prueba de concepto funcionando contra varios objetivos, lo que aceleró la circulación de exploits de terceros. Y seis horas antes del release coordinado, Chainguard rompió el embargo de forma unilateral publicando imágenes ya parcheadas, algo que la propia PHP Foundation describió como un hecho que «ignoró semanas de trabajo de muchas partes hacia una divulgación coordinada».

Qué está confirmado y qué no

Confirmado: existen dos CVEs con CVSS 9.2, los parches ya están disponibles para las cuatro ramas soportadas de PHP, y Wiz demostró RCE funcional en WordPress, Drupal y Joomla en entorno de laboratorio.

La PHP Foundation señaló que monitoreó los PoCs que circularon tras la filtración y no identificó exploits funcionales al momento del lanzamiento y la divulgación pública. Esa observación está limitada a ese momento y no permite afirmar que actualmente no haya ataques activos. No es motivo para posponer el parche. Para más detalles técnicos, mirá sumar una capa extra activando 2FA.

Errores comunes al reaccionar frente a PHP2Shell

Actualizar solo WordPress y dar por cerrado el tema. Es el error más frecuente: cambiás el core de WordPress, los plugins, el tema, y la vulnerabilidad sigue intacta porque vive en el intérprete PHP del servidor, no en la aplicación.

No reiniciar el servicio después de actualizar el paquete. Corriste apt upgrade, PHP quedó parcheado a nivel de archivos, pero Apache o PHP-FPM siguen con el proceso viejo cargado en memoria hasta que reiniciás. Sin ese paso, seguís expuesto aunque el sistema diga que está actualizado.

Asumir que el hosting ya se ocupó sin confirmarlo. Si tenés hosting compartido o gestionado, dar por hecho que «seguro ya lo parchearon» sin preguntar es arriesgado. Contactá a soporte y pedí confirmación explícita de la versión de PHP activa en tu cuenta.

Esto se conecta con vulnerabilidades críticas en plugins WordPress, un tema que conviene revisar si administrás un sitio propio.

Preguntas Frecuentes

¿Qué es PHP2Shell y qué versiones de PHP afecta?

PHP2Shell es el nombre que le dio Wiz Research a la combinación de dos vulnerabilidades críticas (CVE-2026-109618 y CVE-2026-109619) en el núcleo de PHP. Afecta prácticamente toda versión de PHP lanzada desde la 5.4 hasta antes de los parches del 21 de octubre de 2026. Lo explicamos a fondo en reforzar las cabeceras HTTP de seguridad.

¿Actualizar WordPress corrige CVE-2026-109618 y CVE-2026-109619?

No. Ambas vulnerabilidades están en el intérprete PHP, no en WordPress. Hay que actualizar el paquete PHP del sistema operativo o del hosting a las versiones 8.5.12, 8.4.27, 8.3.36 u 8.2.35, según corresponda, o a un paquete del proveedor con el backport oficial de esos parches.

¿Cómo actualizo PHP en mi servidor para corregir PHP2Shell?

En sistemas basados en Debian o Ubuntu, corré sudo apt update && sudo apt upgrade o apuntá solo a PHP con sudo apt install --only-upgrade '?name(^php[0-9.]+$)', y después reiniciá Apache con sudo systemctl restart apache2 si usás mod_php. Si usás PHP-FPM, reiniciá el servicio y los pools de PHP-FPM correspondientes a tu instalación; reiniciar Apache por sí solo no reinicia PHP-FPM.

¿Mi WordPress está en riesgo aunque no use plugins vulnerables?

Sí. Según Wiz Research, la vulnerabilidad es independiente del código de la aplicación: hasta un «Hello World» sin plugins ni lógica propia puede ser vulnerable si corre sobre una versión de PHP sin parchear. La posibilidad de explotación depende también de la configuración y la ruta de ejecución.

¿Qué hago si mi hosting todavía no actualizó PHP?

Contactá a soporte técnico y pedí confirmación explícita de que aplicaron el parche de octubre de 2026. Mientras esperás, revisá tus logs por señales de explotación como cookies PHPSESSID anormales o caídas inesperadas de workers, aunque eso no reemplaza la actualización.

Conclusión

PHP2Shell deja algo claro: la seguridad de tu WordPress depende de capas que muchas veces ni mirás. El código de tu sitio puede estar impecable y seguís expuesto si el intérprete PHP debajo está viejo. La acción concreta es una sola: verificar la versión de PHP en tu servidor hoy mismo, confirmar que use PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o un paquete del proveedor con el backport oficial de esos parches, y reiniciar Apache si usás mod_php, o el servicio y los pools de PHP-FPM si usás FPM, después de actualizar.

Si administrás infraestructura propia, no dependas solo del unattended-upgrades automático: revisá manualmente que el reinicio se haya ejecutado. Y si tu hosting todavía no confirmó el parche, esa conversación con soporte no puede esperar a la próxima semana.

Fuentes

• PHP Foundation – Comunicado oficial sobre el lanzamiento de seguridad del 21/10/2026
• Wiz Research – Análisis técnico completo de PHP2Shell y demostraciones de explotación
• Ubuntu – Guía de actualización y tabla de versiones corregidas por release