Amazon avisa que PHP2Shell ya se explota: qué pedirle a tu hosting si usás WordPress

Si tu sitio o tu tienda online corre sobre WordPress (con o sin WooCommerce) o sobre cualquier otra web hecha en PHP, como Joomla, Drupal o Magento, hoy tenés una tarea que no se resuelve desde el panel de WordPress. El proyecto PHP publicó el 21 de octubre las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen dos fallas críticas bautizadas PHP2Shell que pueden permitir ejecutar código en el servidor sin iniciar sesión. Horas después, el equipo de inteligencia de amenazas de Amazon escribió que PHP2Shell «ahora se está explotando de forma amplia en internet» (traducido del inglés), y contó que detectó el primer intento el 17 de octubre, cuatro días antes del aviso oficial.

Qué hacer hoy: la corrección está en PHP, no en WordPress, así que actualizar WordPress, el tema o los plugins no te protege por sí solo; lo dice Automattic, la empresa detrás de WordPress.com y WooCommerce. Si tu hosting maneja PHP por vos, que es lo habitual en un plan compartido, escribile hoy a soporte (o a quien te administra la web) y pedile que confirme que aplicó la actualización. Si administrás tu propio servidor, actualizá PHP ya. Y si tu web está en WordPress.com, WordPress VIP, WP Cloud, Pressable o Tumblr, según Automattic ya estás cubierto y no tenés que hacer nada. Es el raro caso en que reforzar la puerta no sirve, porque la grieta está en el cimiento. Si solo navegás o comprás en tiendas online, no tenés nada que instalar: la falla y el arreglo están del lado de cada servidor.

Qué hacer según dónde está tu web

Si no sabés si tu web pasa por Cloudflare ni qué PHP tiene, no hace falta que lo averigües solo: sumalo a la consulta. Un mensaje así alcanza:

Hola, ¿me confirman que el PHP de mi sitio ya tiene el parche de PHP2Shell (CVE-2026-109618 y CVE-2026-109619), ya sea en 8.5.12, 8.4.27, 8.3.36, 8.2.35 o en el paquete corregido de su distribución? ¿El sitio pasa por Cloudflare? ¿Vieron actividad rara en mi cuenta desde el 17 de octubre?

Cómo ver qué PHP tenés (y por qué el número puede engañar)

En WordPress, entrá a Herramientas → Salud del sitio, abrí la pestaña Información y desplegá la sección Servidor: ahí figura la versión de PHP. Si dice 8.5.12, 8.4.27, 8.3.36, 8.2.35 o un número más alto de la misma rama, tenés la versión corregida del proyecto PHP.

Si dice otro número, no significa necesariamente que estés expuesto. PHP explica que las distribuciones de Linux y los proveedores de soporte extendido recibieron los parches por adelantado y publican sus propios paquetes. Y Cloudflare, en las instrucciones de revisión que publicó, advierte que esos paquetes suelen traer la corrección sin cambiar el número de versión. Por eso la confirmación que vale es la del hosting, no la del número. Si ves 8.1 o menos, la conversación con el hosting es otra: además del parche, toca hablar de migrar.

Las versiones corregidas y hasta cuándo tienen soporte

Ojo con quedarse en 8.2: el parche llega, pero esa rama deja de recibir correcciones de seguridad el 31 de diciembre, en poco más de dos meses.

Qué son las fallas, en criollo

Son dos fallas, registradas como CVE-2026-109618 y CVE-2026-109619, y las dos tienen un puntaje de gravedad de 9,2 sobre 10, en la franja «crítica». Cuando PHP atiende un pedido a una web, reserva memoria para trabajar y la limpia al terminar. Las dos fallas aparecen cuando un pedido hace que PHP se caiga a mitad de camino, por ejemplo al quedarse sin memoria procesando un formulario: la limpieza sale mal y un pedido posterior puede usar datos que no deberían seguir ahí. Un atacante que prepara bien esos pedidos puede terminar ejecutando sus propios comandos en el servidor, que es el «shell» del nombre.

• No hace falta usuario ni contraseña: el ataque funciona con pedidos web comunes.
• Tu sitio no necesita tener ningún error propio: la falla está en PHP. Según Automattic, los investigadores demostraron ataques que funcionan contra instalaciones actuales de WordPress, Drupal y Joomla.
• Viene de lejos: las versiones afectadas llegan hasta PHP 5.4, de hace más de una década, según Automattic y Cloudflare.
• Afecta a todas las formas de servir PHP en la web (PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed). El proyecto PHP considera que el riesgo es mayor con mod_php, donde hay un ataque demostrado que se dispara antes de que corra el código del sitio.

Las fallas las divulgaron Calif.io, Wiz, OpenAI y Quarkslab, según Cloudflare, que participó de la coordinación previa junto con la PHP Foundation.

Cómo se llegó a la explotación

La secuencia la contaron Amazon y Cloudflare el mismo 21 de octubre:

La conclusión práctica que saca Amazon es incómoda: para PHP2Shell, la revisión de un servidor tiene que arrancar al menos desde el 17 de octubre, no desde el día del parche. Y agrega que, con la ayuda de la inteligencia artificial para convertir un parche en un ataque, los plazos para parchear fallas críticas en sistemas expuestos a internet ya se miden en horas.

Si administrás el servidor y hoy no podés actualizar

PHP, Amazon, Automattic y Cloudflare coinciden: estas medidas compran tiempo, no reemplazan la actualización. PHP lo dice sin vueltas: no hay mitigaciones completas.

• Poné el sitio detrás de un firewall de aplicaciones web (WAF). Cloudflare y otros proveedores ya publicaron reglas para estas fallas.
• Si tu sitio no recibe archivos subidos, Automattic sugiere bloquear los envíos de formularios multipart en el servidor web y apagar file_uploads y session.upload_progress.enabled. PHP aclara que session.upload_progress.enabled se configura en php.ini, en el pool de PHP-FPM o en el servidor, no con ini_set() ni con .user.ini, y que hay que reiniciar todos los procesos de PHP.
• En PHP 8.5, PHP sugiere además fatal_error_backtraces=0. Su aviso lista otras medidas más técnicas para quien no pueda parchear.
• Mirá los registros: Amazon recomienda buscar pedidos POST con la cadena PHP_SESSION_UPLOAD_PROGRESS en subidas de formularios y procesos o archivos inesperados en el servidor; Automattic, citando a Wiz Research, suma pedidos multipart raros seguidos de errores de límite de memoria o ráfagas de errores HTTP 500.

Lo que todavía no se sabe

• Cuántos sitios fueron comprometidos. Amazon dice que se explota de forma amplia, pero ninguna de las fuentes publicó una cifra de sitios afectados.
• Si los intentos previos al parche funcionaron. Amazon aclara que su análisis sigue y que no está claro si los intentos del 17 y del 21 de octubre habrían tenido éxito en sistemas reales.
• Si hay víctimas en América Latina. No hay datos por país. La exposición es posible en cualquier lugar donde haya un servidor con PHP sin parchear.
• Cómo se filtró antes de tiempo. Amazon dice que no está claro cómo el primer atacante consiguió la información durante el embargo.

Preguntas rápidas

¿El antivirus de mi PC me protege de esto?

No. Un antivirus cuida la computadora donde está instalado, y esta falla está en el servidor donde vive tu web. Lo que la cierra es actualizar PHP en ese servidor.

Si mi hosting ya actualizó, ¿quedo limpio?

Quedás sin la falla abierta, pero el parche no deshace una intrusión anterior. Por eso Amazon recomienda revisar desde el 17 de octubre. Si tu hosting tiene registros de esos días, preguntale si vio actividad rara en tu cuenta.

Fuentes

• PHP, «Security advisory: Critical remote code execution vulnerabilities, update now», 21 de octubre de 2026 (en inglés), y los avisos técnicos GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp.
• PHP, versiones con soporte (en inglés).
• Amazon Threat Intelligence, «Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot», blog de seguridad de AWS, 21 de octubre de 2026 (en inglés).
• Automattic, «Your Sites Are Protected Against the PHP2Shell Vulnerabilities», 21 de octubre de 2026 (en inglés).
• Cloudflare, «Cloudflare deploys protections against php2shell vulnerability», 21 de octubre de 2026 (en inglés).
• WordPress.org, pantalla Salud del sitio (en inglés).