php2shell: dos fallos críticos de PHP obligan a actualizar ya cualquier web en WordPress, WooCommerce o PrestaShop

El 21 de octubre de 2026 el proyecto PHP publicó PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen dos vulnerabilidades críticas que pueden permitir ejecutar código en el servidor sin autenticación, según el aviso de seguridad de php.net, del propio proyecto PHP. El mismo día, WordPress avisó de que no habrá actualización suya para esto: el arreglo está en PHP. Si tu web corre sobre WordPress, WooCommerce, PrestaShop o cualquier otro PHP, lo que hay que actualizar hoy es la versión de PHP de tu servidor.

«PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.» (PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen dos vulnerabilidades críticas que pueden permitir la ejecución remota de código sin autenticación; se recomienda encarecidamente a todos los usuarios de PHP que actualicen de inmediato), dice php.net en su aviso del 21 de octubre de 2026.

¿Qué fallos corrige PHP y a quién afectan?

Corrige dos fallos que afectan a toda instalación de PHP que sirva peticiones web, según el aviso de php.net del 21 de octubre de 2026: CVE-2026-109618 (GHSA-w8hw-w9fx-j79w, «RCE via OOM corruption») y CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp, «RCE via stale global state»). Los dos son ejecución remota de código: el primero aprovecha cómo PHP maneja la falta de memoria y el segundo, restos de una petición que otra petición reutiliza.

Están expuestos PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed; el riesgo más alto, según php.net, es mod_php. «php2shell» es el nombre que les ha puesto Cloudflare, no php.net. Ni php.net ni WordPress publican puntuación CVSS.

¿Por qué actualizar WordPress no lo arregla?

Porque el fallo no es de WordPress, ni de un plugin, ni del tema: es de PHP, el lenguaje sobre el que corren. Así lo dice WordPress en su aviso del 21 de octubre de 2026: «No WordPress update is required or planned for these issues.» (no hace falta ni está prevista ninguna actualización de WordPress para estos fallos). Tu WordPress, tus plugins y tu tema no necesitan nada por esto; lo que cambia es la versión de PHP del servidor.

Si tu web no usa PHP —por ejemplo, una web estática en Netlify, Vercel o Cloudflare—, esto no te toca.

¿Qué versión de PHP te toca tener?

La versión parcheada de la rama en la que esté tu servidor, publicada el 21 de octubre de 2026:

Las versiones de PHP anteriores a la 8.2 ya no reciben parches de seguridad del proyecto PHP, según WordPress. Por la gravedad, el equipo de seguridad de PHP sí publicó backports mínimos de código fuente para 7.4, 8.0 y 8.1, pensados para quien compila PHP por su cuenta. Si administras tu propio servidor y sigues en una de esas versiones, WordPress recomienda valorar sacar el sitio de línea mientras migras.

¿Cómo compruebas tu versión y qué le pides al hosting?

En WordPress, la versión de PHP aparece en Herramientas > Salud del sitio > Información > Servidor; en cualquier otra web PHP, en el panel del hosting. Con eso delante, depende de dónde esté tu web:

1. Hosting compartido o gestionado: pregúntale hoy a tu proveedor si ya actualizó PHP a 8.5.12, 8.4.27, 8.3.36 o 8.2.35. No lo des por hecho: confírmalo.
2. VPS o servidor propio: actualiza PHP ya a la versión parcheada de tu rama.
3. PHP 8.1 o anterior: plan de migración a 8.2 o superior, sin esperar.

¿Y si hoy no puedes actualizar?

Entonces php.net da mitigaciones que reducen la exposición, pero que según el propio aviso no dejan segura la instalación: memory_limit=-1 fijado a nivel de servidor, post_max_size bajo (8M sin subidas de archivos, 32M con ellas) y session.upload_progress.enabled=0, reiniciando los workers. Lo que arregla los fallos es la versión nueva.

¿Qué datos conviene guardar?

Estas son las cifras y fechas que confirman php.net y WordPress a 21 de octubre de 2026:

• 21 de octubre de 2026: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen dos vulnerabilidades críticas que pueden permitir ejecución remota de código sin autenticación. Fuente: aviso de seguridad de php.net, el propio proyecto PHP.
• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w, «RCE via OOM corruption») y CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp, «RCE via stale global state»): las dos vulnerabilidades del aviso del 21 de octubre de 2026. Fuente: php.net.
• Servidores afectados: toda instalación de PHP que sirva peticiones web (PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP, LiteSpeed); el riesgo más alto es mod_php. Fuente: php.net, 21 de octubre de 2026.
• Sin actualización de WordPress: no hay ni habrá actualización de WordPress para estos fallos, y las versiones de PHP anteriores a la 8.2 ya no reciben parches de seguridad del proyecto PHP. Fuente: WordPress News, «Critical PHP Security Release», 21 de octubre de 2026.
• Mitigaciones si no se puede actualizar ya (no hacen segura la instalación): memory_limit=-1 fijado en el servidor, post_max_size bajo (8M sin subidas de archivos, 32M con ellas) y session.upload_progress.enabled=0 reiniciando los workers. Fuente: php.net, 21 de octubre de 2026.

Son fallos distintos de las otras alertas de seguridad recientes, la de WordPress 7.1.2 y la de Next.js 16.4.1, que se arreglan por separado. Revisar versiones conviene que sea una rutina, no una reacción a cada aviso.

En Rigol&Co podemos revisar contigo en qué versión de PHP está tu servidor y ayudarte a actualizarla o migrar tu web.