PHP2Shell: dos fallas críticas en PHP ponen en riesgo los sitios web de las empresas

Si el sitio web de su empresa funciona con WordPress, Drupal, Joomla, Laravel o casi cualquier otra aplicación PHP, esto le afecta.

El 21 de octubre de 2026, el proyecto PHP publicó actualizaciones de seguridad de emergencia para dos vulnerabilidades críticas, conocidas como PHP2Shell: CVE-2026-109618 y CVE-2026-109619. Ambas tienen una calificación de 9.2 (Crítica) en la escala CVSS v4.0, según el aviso de seguridad oficial de PHP. Permiten que un atacante sin cuenta ni contraseña ejecute código en un servidor web, y también pueden permitirle leer memoria del servidor que puede contener contraseñas, tokens de sesión, claves de API y certificados.

Por qué esta es diferente

La mayoría de las noticias de seguridad web tratan de un plugin o un tema. PHP2Shell está en PHP mismo, el motor que hace funcionar el sitio. Eso significa:

• Su sitio puede ser vulnerable aunque su propio código sea totalmente seguro. Como la falla está en el motor, incluso una página PHP básica en un servidor sin parchear puede ser atacada.
• Actualizar WordPress o sus plugins no lo corrige. La corrección viene de su servidor, su proveedor de hosting o su imagen de contenedor.
• Es antigua. Los investigadores que la encontraron indican que el código afectado lleva más de una década en PHP.

Las fallas afectan toda instalación de PHP que sirve páginas web, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP considera Apache mod_php como el mayor riesgo, con un ataque demostrado que se ejecuta antes que cualquier código de la aplicación.

¿Se está explotando?

Los detalles se filtraron en internet un día antes de la divulgación planificada, lo que adelantó la publicación del parche. Desde entonces, empresas de seguridad como Cloudflare y watchTowr han reportado intentos activos de explotación de ambas fallas. Al momento de escribir este artículo no se había reportado públicamente ninguna intrusión confirmada, pero ya no hay margen para esperar. Algunas organizaciones desconectaron sus sitios como precaución.

Paso 1: Actualice PHP (la única solución completa)

• PHP 8.5: actualice a 8.5.12
• PHP 8.4: actualice a 8.4.27
• PHP 8.3: actualice a 8.3.36
• PHP 8.2: actualice a 8.2.35

Después de actualizar, reinicie Apache, PHP-FPM y cualquier proceso PHP de larga duración. Una actualización que no se ha cargado no le protege.

• PHP 8.1 y anteriores no reciben actualización oficial. Algunas distribuciones de Linux y proveedores de soporte ofrecen correcciones adaptadas; consulte con el suyo o planifique la migración. PHP 8.2 llega al fin de soporte el 31 de diciembre de 2026.
• Las versiones de paquetes en Linux pueden parecer antiguas. Las distribuciones suelen incluir la corrección sin cambiar el número de versión, así que revise el registro de cambios del paquete buscando los números CVE.
• ¿Hosting compartido o WordPress administrado? Contacte hoy a su proveedor y pregunte por escrito si su PHP ya está parcheado contra CVE-2026-109618 y CVE-2026-109619.

Paso 2: Si no puede actualizar de inmediato

El equipo de PHP aclara que ninguna de estas medidas hace que un servidor sea seguro. Solo reducen rutas de ataque específicas mientras programa la actualización. Son configuraciones técnicas, así que comparta esta sección con quien administre su servidor.

Para CVE-2026-109618 (corrupción por falta de memoria)

• Configure memory_limit=-1 a nivel de servidor para que las aplicaciones no puedan cambiarlo (por ejemplo, con php_admin_value en el pool de FPM o en la configuración de Apache), y verifique que ninguna otra configuración vuelva a poner un límite.
• Reduzca post_max_size: 8M si el sitio no recibe archivos, 32M si los recibe, con upload_max_filesize por debajo.
• Aplique límites de tamaño de solicitud, cantidad de campos y cantidad de encabezados en el servidor web, el proxy o el firewall.
• No use RLIMIT_AS ni RLIMIT_DATA como sustituto; PHP advierte que pueden activar la misma falla.

Para CVE-2026-109619 (estado global obsoleto)

• Configure session.upload_progress.enabled=0 en php.ini o en el pool de FPM (no con ini_set() ni .user.ini) y reinicie todos los procesos.
• En PHP 8.5, configure también fatal_error_backtraces=0.

Un firewall de aplicaciones web (WAF) ayuda a ganar tiempo. Cloudflare publicó reglas para estas fallas, pero reportó que los atacantes ya estaban modificando sus solicitudes para evadirlas.

Paso 3: Después de parchear

• Revise la configuración de memoria. La corrección agrega un nuevo límite estricto de memoria; un proceso que lo alcanza termina de inmediato. Ajuste memory_limit y post_max_size a lo que su aplicación realmente necesita.
• Busque señales de ataques previos: solicitudes multipart inusuales seguidas de errores de memoria o errores HTTP 500 repetidos, cookies PHPSESSID inusualmente grandes y reinicios inexplicables de procesos PHP.
• Si las encuentra, cambie las credenciales que el servidor guarda o usa: contraseñas de bases de datos, claves de API y secretos de la aplicación.

En resumen

PHP2Shell es un problema del servidor que una actualización del sitio web no resuelve. Si no sabe quién mantiene el servidor de su sitio o qué versión de PHP usa, este es el momento de averiguarlo. CyberArm puede revisar la versión de PHP de su sitio, coordinar con su proveedor de hosting y aplicar la actualización o las protecciones temporales. Comience con una evaluación gratuita de TI y seguridad, o vea nuestros paquetes de ciberseguridad, que incluyen la gestión de actualizaciones.