Fallas críticas en PHP (php2shell): qué hacer si tu web es WordPress

Qué pasó

El 21 de octubre de 2026, el equipo que desarrolla PHP publicó una actualización de emergencia para corregir dos fallas de seguridad críticas, registradas como CVE-2026-109618 y CVE-2026-109619. En el ambiente ya se las conoce como php2shell.

PHP es el lenguaje con el que están hechos WordPress, WooCommerce, Joomla, Drupal, Magento y miles de sistemas a medida. Casi 7 de cada 10 sitios web lo usan.

Las dos fallas permiten lo peor que le puede pasar a un servidor: que alguien de afuera, sin usuario ni contraseña, haga correr sus propios programas ahí. A partir de eso puede llevarse los datos de tus clientes, meter publicidad o virus en tu web, o usar tu servidor para atacar a otros. El propio equipo de PHP les puso un puntaje de gravedad de 9,2 sobre 10.

Los detalles se filtraron en internet un día antes de lo previsto, y el equipo de PHP adelantó la publicación del arreglo. Al momento de escribir esto, empresas de seguridad como Cloudflare ya reportan los primeros intentos de ataque.

¿Te afecta?

Si tu web está hecha con WordPress (con o sin WooCommerce), Joomla, Drupal, Magento o cualquier otro sistema en PHP: sí, hasta que se actualice el PHP del servidor. La falla está en todas las versiones de PHP de los últimos catorce años, y los investigadores que la descubrieron dicen haber confirmado el ataque contra versiones de WordPress, Drupal, Joomla y Magento.

Lo que más confunde: actualizar WordPress o los plugins no lo arregla. PHP es el programa que corre debajo de WordPress, en el servidor, y lo actualiza quien administra ese servidor: tu empresa de hosting, o quien te mantiene la web.

Si tu tienda o tu web está en una plataforma cerrada, como Tiendanube, Shopify o Wix, esto lo resuelve la plataforma: no hay nada que puedas (ni tengas que) actualizar vos.

Cómo saber qué versión de PHP tiene tu web

En WordPress lo ves sin tocar nada: entrá al panel, andá a Herramientas › Salud del sitio › Información y abrí la sección Servidor. Ahí figura la versión de PHP.

Las versiones que ya traen el arreglo son estas:

Si tu sitio usa PHP…	Está protegido desde la versión
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1 o anterior	No hay versión corregida oficial

Tres aclaraciones:

• Algunos proveedores aplican el arreglo sin cambiar el número. Pasa sobre todo con el PHP que viene con el sistema del servidor (Ubuntu, Debian y similares). Si ves un número más bajo que los de la tabla, no quiere decir que estés expuesto: preguntá.
• Si tu sitio usa PHP 8.1 o más viejo, el proyecto PHP ya no publica actualizaciones para esas versiones. Algunos proveedores tienen parches propios; si el tuyo no, la recomendación de CISA, la agencia de ciberseguridad de Estados Unidos, es sacar el sitio de internet hasta actualizarlo. Pasar a un PHP más nuevo a veces rompe plugins o temas viejos, así que conviene probarlo antes en una copia del sitio.
• Si estás en PHP 8.2, con la 8.2.35 quedás cubierto, pero esa versión deja de recibir actualizaciones el 31 de diciembre de 2026. Es un buen momento para planear el salto.

Qué hacer hoy

1. Escribile a tu hosting o a quien te mantiene la web. Preguntá concretamente: “¿Ya actualizaron PHP por las vulnerabilidades CVE-2026-109618 y CVE-2026-109619?”. Con los números exactos es difícil que te respondan con vaguedades.
2. Cuando te digan que sí, fijate la versión en Salud del sitio, como explicamos arriba.
3. Asegurate de tener una copia de seguridad reciente, guardada fuera del servidor. Si algo ya pasó, es lo que te permite volver atrás.
4. Si no te contestan, o tu sitio está en PHP 8.1 o anterior, no lo dejes para más adelante. Estos ataques se hacen de forma automática: programas que recorren internet probando sitio por sitio. No hace falta que tu web sea conocida para que le toque.

Si tu sitio pasa por Cloudflare, ya tiene activadas reglas que frenan las formas de ataque conocidas, incluso en el plan gratis. Ayuda, pero la misma Cloudflare aclara que es una protección provisoria: no reemplaza la actualización.

Si administrás tu propio servidor

Lo esencial del anuncio oficial, para equipos técnicos:

• Actualizá a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35 (o al paquete corregido de tu distribución) y reiniciá todos los procesos de PHP (PHP-FPM, Apache): hasta que no se reinician, siguen corriendo el código viejo. Si usás contenedores, reconstruí las imágenes y volvé a desplegar.
• Están expuestas todas las instalaciones que atienden pedidos web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo más alto es mod_php, donde el ataque funciona antes de que se ejecute una sola línea de la aplicación.
• Para 7.4, 8.0 y 8.1, el equipo de PHP publicó parches mínimos en código fuente, sin versión oficial.
• Si no podés actualizar ya, hay mitigaciones parciales. PHP aclara que no hacen segura la instalación:

; CVE-2026-109618: fijarlo con php_admin_value (pool de FPM o Apache)
; para que la aplicación no lo pueda pisar
memory_limit = -1

; CVE-2026-109619: en php.ini o en el pool de FPM, no con ini_set() ni .user.ini
session.upload_progress.enabled = 0

; Solo PHP 8.5
fatal_error_backtraces = 0

memory_limit = -1 deja cada pedido sin tope de memoria, así que el anuncio pide acompañarlo con límites de tamaño de pedido en el servidor web o el proxy, un post_max_size bajo (8M si no se suben archivos) y un tope de memoria por contenedor o cgroup. Después de cualquier cambio, reiniciá todos los procesos de PHP.

Y mientras tanto, vigilá procesos de PHP que abran una terminal o descarguen herramientas: es la señal de ataque que CISA recomienda mirar.