Hosting y Seguridad

Vulnerabilidad crítica en PHP (PHP2Shell): qué hacer ya

octubre 24, 2026
GuanaCode

El 21 de octubre de 2026 el equipo de seguridad de PHP publicó actualizaciones de emergencia para dos vulnerabilidades críticas que, según el aviso oficial, pueden permitir la ejecución remota de código (RCE) sin autenticación. Las dos tienen una puntuación de 9.2 sobre 10 (CVSS v4.0) y afectan a cualquier instalación de PHP que atienda pedidos web. Como PHP está detrás de una enorme parte de internet, incluido WordPress, vale la pena entender qué pasó y qué tenés que revisar hoy.

En la comunidad ya circula el nombre PHP2Shell para referirse al conjunto. Es un apodo informal: los identificadores oficiales son los CVE que figuran más abajo.

Qué se corrigió exactamente

Según los avisos publicados en php.net y en el repositorio oficial de PHP (php-src), son dos fallas distintas:

CVE-2026-109618 (corrupción de memoria por falta de memoria): cuando PHP se queda sin memoria en medio de un pedido, puede abandonarlo con datos internos a medio inicializar, y la limpieza posterior termina usando información inválida. El aviso indica que hay formas de provocarlo con pedidos multipart armados a medida, incluso dentro de los límites configurados.
CVE-2026-109619 (estado global obsoleto): parte del estado interno de un pedido puede sobrevivir después de que su memoria fue liberada, y un pedido posterior atendido por el mismo proceso puede usarlo antes de que se reinicie. Un atacante podría aprovecharlo con un pedido que lo genere y otro que lo consuma.

Versiones afectadas y versiones corregidas

Las versiones que incluyen la corrección son:

PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35

Cualquier versión anterior dentro de esas ramas está afectada. Para PHP 8.1 y anteriores ya no hay actualizaciones oficiales del proyecto: el equipo publicó backports mínimos del código fuente para 7.4, 8.0 y 8.1 pensados para quienes compilan PHP por su cuenta, y algunas distribuciones o proveedores de soporte extendido ofrecen parches propios. Si usás una de esas versiones, la salida de fondo es migrar a una rama soportada. Además, PHP 8.2 llega a su fin de vida el 31 de diciembre de 2026, así que conviene planificar el salto a 8.3 o superior.

Qué tan grave es y qué se sabe de los ataques

El proyecto aclara que todas las instalaciones que sirven pedidos web están en el alcance (PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed) y que el riesgo es mayor con mod_php, donde el ataque puede ocurrir antes de que se ejecute código de la aplicación.

Sobre la explotación real, las fuentes no coinciden del todo, y es sano tomarlas con cuidado:

La firma watchTowr informó haber observado intentos de explotación desde el 21 de octubre en su red de honeypots.
Rapid7 señaló que existen varias pruebas de concepto públicas, pero que cada una funciona solo para una combinación específica de sistema operativo, versión de PHP y servidor web; no había confirmado explotación masiva, aunque sí reportes de intentos.
Unit 42 (Palo Alto Networks) informó haber visto código de prueba de concepto y un caso de post-explotación asistido por una plataforma de IA agéntica.

Lo prudente es asumir que un exploit más portable puede aparecer en cualquier momento. Según la prensa tecnológica, CERT-UE llegó a aconsejar sacar de línea los sitios que no puedan actualizarse, una medida extrema pero que muestra la seriedad con la que se tomó el aviso.

Qué hacer: la única solución completa es actualizar

Averiguá qué versión de PHP sirve tu sitio. En WordPress: Herramientas → Salud del sitio → Información → Servidor. Ojo: el comando php -v en una terminal muestra la versión de línea de comandos, que puede ser distinta de la que atiende la web. Si usás PHP-FPM, cada pool puede tener su propia configuración.
Actualizá a la versión corregida de tu rama, o al paquete de tu distribución o proveedor que incluya ambos parches.
Reiniciá los procesos de PHP (FPM, Apache, LiteSpeed) para que la corrección entre en vigencia.
Verificá con tu hosting. Muchas distribuciones aplican las correcciones sin cambiar el número de versión, así que un número menor al esperado no siempre significa que estés sin parche. Preguntá y pedí confirmación por escrito.
Si no podés actualizar ya, restringí el acceso a ese sistema desde internet hasta que puedas hacerlo.

Medidas temporales: ayudan, pero no te dejan seguro

El aviso oficial lista mitigaciones provisorias, y aclara que no sustituyen la actualización ni hacen segura una instalación:

memory_limit=-1, aplicado de forma que ninguna aplicación pueda volver a imponer un límite, y reiniciando los procesos.
Un post_max_size bajo (el aviso sugiere 8M si no se suben archivos y 32M si sí).
session.upload_progress.enabled=0 en php.ini, el pool FPM o la configuración del servidor. Usar ini_set() o .user.ini no alcanza.
En PHP 8.5, fatal_error_backtraces=0.
No usar RLIMIT_AS ni RLIMIT_DATA, porque pueden disparar justamente la ruta vulnerable.

Ocultar errores con display_errors o @ tampoco sirve como protección. Por eso conviene desconfiar de cualquier guía que presente estos ajustes como una solución definitiva: el propio proyecto dice que no existe una mitigación completa por configuración.

Un tercer aviso relacionado

El 23 de octubre PHP informó además sobre el CVE-2026-115560, vinculado al progreso de carga de sesiones. Es de explotación improbable y requiere una configuración poco común (cambiar el manejador de serialización en tiempo de ejecución con ini_set() antes de session_start(), con la carga de progreso activa). La mitigación recomendada hasta el próximo lanzamiento es la misma: session.upload_progress.enabled=0. Si ya la aplicaste, mantenela.

Qué significa para sitios WordPress

La falla está en PHP, no en WordPress, en tus plugins ni en tu tema. Mantener WordPress actualizado no la soluciona; la corrección tiene que venir del servidor. Según informó la prensa, WordPress.org indicó que no se necesita una actualización del núcleo por este tema. Lo que sí podés hacer:

En hosting administrado, revisá el estado de tu proveedor y escribile si no hubo comunicación.
En hosting compartido, esperá el aviso del proveedor y pedí confirmación; si estás en PHP 8.1 o anterior, cambiá de versión desde el panel.
En un VPS o servidor propio, nadie lo va a parchear por vos: actualizá los paquetes y reiniciá PHP.
Antes de subir de versión, hacé un backup completo y probá en un entorno de pruebas, porque plugins o temas viejos pueden fallar en versiones nuevas de PHP.
Un firewall o CDN con reglas específicas (por ejemplo Cloudflare, que informó haber desplegado reglas) reduce el riesgo, pero no reemplaza la actualización, ya que un atacante podría llegar directo al servidor de origen.

Para el día a día de tu sitio, también podés repasar nuestras buenas prácticas para usar WordPress y plugins.

Resumen

Dos fallas críticas de PHP (CVE-2026-109618 y CVE-2026-109619, CVSS 9.2) permiten RCE sin autenticación.
Corregidas en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
PHP 8.1 y anteriores no reciben parche oficial: parche del proveedor o migración.
Las mitigaciones por configuración no hacen seguro un servidor: hay que actualizar y reiniciar.
Confirmá con tu hosting qué versión sirve realmente tu sitio.