PHP2Shell: la falla crítica de PHP que afecta a toda la web (y qué hacer con tu sitio)

Si te llegó una alerta de tu hosting sobre PHP2Shell, primero lo importante: no es una falla de tu sitio ni de tu proveedor. Es un problema en PHP, el lenguaje que hace funcionar a la mayor parte de la web, y afecta por igual a millones de sitios en todo el mundo. El 21 de octubre de 2026 el proyecto PHP publicó la corrección, y lo que corresponde es aplicarla.

Primero, tranquilidad: cómo lo acompañamos desde QKStudio

En QKStudio desarrollamos y mantenemos sitios y productos digitales sobre PHP desde hace casi veinte años, y este tipo de avisos forma parte del trabajo diario. Ante PHP2Shell revisamos las versiones de PHP de los proyectos que acompañamos, coordinamos con cada proveedor de hosting la aplicación de los parches y verificamos que los sitios sigan funcionando correctamente después de la actualización.

Lo importante es que haya alguien atento para actualizar a tiempo. Si tu sitio está con nosotros, no tenés que hacer nada: nos ocupamos. Y si querés entender qué pasó, abajo te lo contamos en detalle.

En pocas palabras

Son dos fallas en el núcleo de PHP: CVE-2026-109618 y CVE-2026-109619, con una severidad de 9,2 sobre 10 (CVSS 4.0).
En ciertas condiciones permiten ejecutar código en el servidor sin usuario ni contraseña.
Afectan a prácticamente todas las versiones de PHP desde la 5.4, es decir, a más de una década de instalaciones en todo el mundo.
La solución es actualizar PHP a 8.2.35, 8.3.36, 8.4.27 o 8.5.12. Actualizar WordPress, el tema o los plugins no alcanza, porque la falla está un nivel más abajo.

Qué es PHP2Shell

PHP es el lenguaje que corre del lado del servidor en la mayoría de los sitios web: WordPress, Drupal, Joomla, Magento, tiendas online, intranets y una enorme cantidad de sistemas a medida. PHP2Shell es el nombre que recibió un conjunto de errores en la forma en que PHP administra la memoria y maneja los errores fatales, dos piezas que intervienen en casi cada visita a un sitio.

Sin entrar en tecnicismos:

CVE-2026-109618 (falta de memoria): si una petición agota la memoria disponible en un momento muy preciso, PHP puede quedarse con datos internos a medio armar y tratarlos como válidos. Eso corrompe la memoria y abre la puerta a ejecutar código. En servidores Apache con mod_php se puede disparar antes de que el propio sitio llegue a ejecutarse; también se confirmó en PHP-FPM. Ver el reporte oficial (GHSA-w8hw-w9fx-j79w).
CVE-2026-109619 (estado que sobrevive entre visitas): un error fatal puede dejar referencias a memoria que ya fue liberada. La siguiente petición que atienda ese mismo proceso puede reutilizarla, con resultados que van desde exponer datos hasta tomar control del proceso. Ver el reporte oficial (GHSA-6wmf-4rv5-p3rp).

Además de ejecutar código, los investigadores mostraron que la lectura de memoria podría exponer contraseñas, tokens, claves de API o certificados guardados en el servidor.

Por qué es un problema global y no de un proveedor

Es fácil pensar que una alerta de seguridad habla mal del hosting o de quien desarrolló el sitio. En este caso no es así, y los datos lo muestran con claridad:

Está en el lenguaje, no en la aplicación. Según Wiz Research, que participó del hallazgo, hasta un simple «Hola mundo» en PHP podía ser vulnerable. Las demostraciones sobre WordPress, Drupal y Joomla son eso: ejemplos de plataformas que corren sobre PHP.
PHP está en todos lados. Cerca de 7 de cada 10 sitios cuyo lenguaje de servidor se conoce usan PHP, según W3Techs. Un relevamiento de Censys citado por Fortinet contó unos 36,7 millones de servicios expuestos a Internet con versiones potencialmente afectadas.
Lo arrastra más de una década. Las fallas alcanzan a PHP 5.4 en adelante. Cualquier versión publicada en los últimos diez años tiene al menos una de ellas.
Toda la industria salió a responder al mismo tiempo. Amazon Web Services, Cloudflare, Fortinet, Fastly, Vercel y proveedores de hosting como Hostinger publicaron avisos, reglas de protección y guías para sus clientes.
El propio proyecto PHP lo reconoce como un problema estructural. La PHP Foundation explicó que las primeras señales aparecieron en una auditoría de 2024 y que la corrección se demoró por la complejidad del arreglo y la falta de recursos. Anunció cambios en su equipo de seguridad y en cómo toma decisiones.

Cómo se desarrolló

Fecha (2026)	Qué pasó
11 y 24 de agosto	Investigadores de Calif, Wiz y OpenAI reportan las fallas al equipo de seguridad de PHP, que las pone como prioridad.
17 de octubre	Los sensores de AWS registran un intento de explotación, cuatro días antes de la divulgación pública.
20 de octubre	Circulan en foros los identificadores de los CVE con datos incorrectos. PHP adelanta el preanuncio oficial y mueve la publicación un día antes. Esa noche se filtra por error un video con una prueba de concepto.
21 de octubre	PHP publica las versiones corregidas de forma coordinada con distribuidores y proveedores.
23 de octubre	Se publica un aviso complementario sobre un tercer vector relacionado (CVE-2026-115560).

Versiones de PHP corregidas

Rama	Versión segura
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35 (fin de soporte: 31/12/2026)

PHP 8.1 y anteriores ya no reciben versiones oficiales. Para 7.4, 8.0 y 8.1 solo hay correcciones mínimas en el código fuente, y algunas distribuciones de Linux ofrecen sus propios parches. Si tu sitio todavía corre en esas versiones, es un buen momento para planificar la migración.

¿Hubo ataques?

Sí, hubo intentos. AWS detectó uno antes de que el problema se hiciera público, y después de la publicación aparecieron varias pruebas de concepto. Cloudflare reportó tráfico de ataque contra sus clientes y cambios en los ataques para esquivar sus reglas de firewall. Según Hostinger, Wordfence bloqueó más de 74.000 intentos.

Al mismo tiempo, hasta el 26 de octubre no había confirmación pública de intrusiones exitosas a gran escala, y AWS aclaró que no puede afirmar que los intentos que vio hubieran funcionado en sistemas reales. El mensaje es claro: no es motivo de pánico, pero sí de actualizar cuanto antes.

El aviso del 23 de octubre: CVE-2026-115560

Dos días después del parche se informó un vector adicional vinculado a la función de progreso de subida de archivos de las sesiones de PHP, que en ciertas combinaciones de configuración y código puede afectar incluso a las versiones ya corregidas. La recomendación de PHP es desactivar session.upload_progress.enabled (valor 0) desde la configuración del servidor hasta la próxima versión de mantenimiento. En hosting gestionado, esto lo resuelve el proveedor. En un VPS o servidor propio, hay que hacerlo a mano.

Qué hacer con tu sitio

Si tu web está en un hosting compartido o gestionado

Consultá a tu proveedor si ya aplicó la versión corregida de PHP y desactivó el progreso de subida de sesiones. La mayoría de los proveedores serios lo hizo en las primeras horas.
Verificá la versión de PHP desde el panel del hosting o, en WordPress, en Herramientas → Salud del sitio → Información → Servidor.
Si el sitio todavía usa PHP 8.1 o anterior, coordiná el cambio a una versión con soporte.

Si administrás tu propio servidor o VPS

Identificá qué versión y paquete de PHP usa cada sitio, aplicación o contenedor.
Hacé un respaldo y actualizá por el canal oficial (proyecto PHP, tu distribución o tu proveedor). No instales «parches» de origen desconocido.
Reiniciá Apache, PHP-FPM o el servicio que corresponda y confirmá la versión que realmente atiende las visitas, que puede no ser la misma que ves en la terminal.
Desactivá session.upload_progress.enabled en php.ini o en el pool de FPM.
Revisá los registros desde el 17 de octubre: errores de memoria repetidos, respuestas 500 en serie, cookies de sesión anormales, procesos o archivos inesperados. Actualizar no elimina un acceso que ya se haya producido.
Usá un firewall de aplicaciones (WAF) como capa adicional mientras parcheás, nunca como reemplazo de la actualización.

Preguntas frecuentes

¿Mi sitio fue hackeado por PHP2Shell?

No necesariamente. Que una versión de PHP sea vulnerable no significa que el sitio haya sido atacado. Hasta fines de octubre no había confirmaciones públicas de intrusiones exitosas a gran escala. Lo recomendable es actualizar y revisar los registros del servidor.

¿Es una falla de mi hosting?

No. La falla está en PHP, el lenguaje que usan la mayoría de los hostings y sitios del mundo. Lo que sí depende del proveedor es la rapidez con la que aplica la versión corregida.

¿Alcanza con actualizar WordPress y los plugins?

No. Mantener WordPress al día siempre es buena práctica, pero PHP2Shell está en el motor de PHP, por debajo de WordPress. La única solución completa es actualizar PHP.

¿Los visitantes de mi web corren algún riesgo?

Navegar un sitio vulnerable no infecta la computadora de quien lo visita. El riesgo está en el servidor y en los datos que guarda, como formularios, usuarios o credenciales.

¿Un firewall o Cloudflare me protege?

Ayuda a reducir la exposición mientras se actualiza, pero no reemplaza el parche. Los atacantes ya modificaron sus peticiones para esquivar algunas reglas.

¿No sabés qué versión de PHP usa tu sitio? Escribinos y lo revisamos con vos.

Hablemos