PHP2Shell: Qué es la vulnerabilidad crítica de PHP y qué hacer en las próximas 24 horas

El 21 de octubre de 2026, el equipo de PHP publicó actualizaciones de emergencia para dos vulnerabilidades críticas bautizadas como PHP2Shell (CVE-2026-109618 y CVE-2026-109619). Las dos tienen una severidad de 9,2 sobre 10 y permiten que un atacante, sin usuario ni contraseña, tome el control de un servidor web a través de Internet. Palo Alto Networks calcula unos 22 millones de instancias de PHP expuestas. Ya circula código de ataque público, y Amazon detectó el primer intento de explotación el 17 de octubre, cuatro días antes de que existiera el parche.

PHP es el lenguaje sobre el que funcionan WordPress, Drupal, Magento, Joomla y Laravel, además de paneles de administración de equipos de red y software comercial. Si tu organización tiene un sitio corporativo, un portal de clientes, una intranet o un e-commerce, lo más probable es que al menos un servidor use PHP. Esta guía resume el boletín que emitió el CyberSOC de Netprovider: qué está en riesgo, cómo priorizar, qué medidas temporales sirven mientras actualizas y cómo revisar si alguien intentó entrar.

¿Qué es PHP2Shell?

PHP2Shell es el nombre de dos fallas en el núcleo de PHP que permiten ejecutar código de forma remota sin autenticación. Afectan a cualquier sitio o aplicación que corra sobre una versión vulnerable, porque el error está en PHP y no en un plugin ni en un tema. La única solución completa es actualizar PHP a 8.5.12, 8.4.27, 8.3.36 u 8.2.35 y reiniciar los servicios.

Ese último punto cambia la conversación con el equipo que administra el sitio. Actualizar WordPress o instalar un plugin de seguridad no corrige PHP2Shell: la corrección ocurre en el servidor.

Las dos vulnerabilidades, en simple

Fuente: avisos oficiales del PHP Project (GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp), 21 de octubre de 2026.

Investigadores de Wiz, Areion y OpenAI, junto a un investigador independiente, reportaron las fallas el 27 de agosto. Wiz mostró además que una de las vías puede exponer contraseñas, tokens, claves de API y certificados guardados en la memoria del servidor.

Por qué esta alerta exige actuar hoy

Tres datos explican la urgencia. Parte de la información técnica se filtró el 20 de octubre, antes de que existiera la corrección, y PHP adelantó un día su publicación. Hay código de ataque público. Y AWS, SANS Internet Storm Center y Kaspersky reportan intentos de explotación, el primero de ellos anterior al parche.

Las agencias de ciberseguridad emitieron alertas el mismo día de la publicación, con un mensaje común:

Al publicar su alerta, CISA no había observado ataques exitosos, y a la fecha de este artículo ninguna fuente pública confirma un servidor comprometido. Los intentos, en cambio, ya están registrados. La NSA lo resume así: es probable que los atacantes aprovechen estas fallas.

Qué sistemas están en riesgo

El punto de los productos de terceros suele pasar inadvertido. SANS advierte que OPNsense y pfSense usan PHP en sus paneles de administración, y que esos paneles no deberían estar expuestos a Internet. CERT-EU recomienda revisar el listado del NCSC de Países Bajos (github.com/NCSC-NL/php2shell) para identificar software que trae PHP incluido.

Plan de acción: Qué hacer en las próximas 24, 48 y 72 horas

El CyberSOC de Netprovider propone este orden, con los sistemas accesibles desde Internet primero:

Fuente: Boletín de Ciberseguridad del CyberSOC de Netprovider, 21 de octubre de 2026.

Después de actualizar, verifica la versión en ejecución

Kaspersky advierte un detalle práctico: el servidor puede tener instalada la versión nueva y seguir corriendo la antigua hasta que se reinicien los servicios. Revisa con el comando php -v y, si PHP viene de los paquetes de tu distribución de Linux, consulta el registro de cambios del paquete, porque el número de versión puede no cambiar aunque incluya la corrección.

Incluso con PHP actualizado, un atacante puede enviar solicitudes que agoten la memoria y saturen el servidor, aunque ya no logre tomar el control. Por eso conviene mantener los límites de tamaño en formularios y subidas.

Medidas temporales si no puedes actualizar hoy

Estas medidas ganan tiempo. Ninguna reemplaza la actualización, y todas debe aplicarlas el administrador del servidor, con un reinicio de servicios al final:

• Para CVE-2026-109618: quitar el límite de memoria por solicitud (memory_limit=-1) de forma que la aplicación no pueda sobrescribirlo, limitar el tamaño de formularios y subidas, y bloquear las subidas de archivos en los sitios que no las usan.
• Para CVE-2026-109619: desactivar la función de progreso de subidas (session.upload_progress) y, en PHP 8.5, la opción fatal_error_backtraces. PHP recomienda mantener apagada la primera incluso después de actualizar, si no la usas.
• Errores de la aplicación: corregir los errores graves y los tiempos de espera que un visitante pueda provocar, y eliminar configuraciones obsoletas, porque forman parte de la cadena de ataque.
• Firewall de aplicaciones web (WAF): Cloudflare activó reglas para todos sus clientes, incluido el plan gratuito, y CISA indica que un WAF ayuda mientras actualizas.
• Bloqueo de subidas multipart en el WAF: SANS y AWS lo plantean como opción, pero impide todas las subidas de archivos y las rutas que dejes como excepción siguen vulnerables.
• PHP 8.1 y anteriores: desactivar session.upload_progress.enabled en php.ini y reiniciar. Según Huntress, esto corta los abusos conocidos, pero no todas las rutas de ataque.

Hay una nota de costo: algunas de estas medidas pueden afectar el funcionamiento del sitio. Quitar el límite de memoria, por ejemplo, deja al servidor más expuesto a una saturación. Pruébalas en un ambiente controlado antes de llevarlas a producción, si el tiempo lo permite.

Cómo saber si alguien intentó entrar

AWS fecha el primer intento conocido el 17 de octubre. Desde ese día en adelante, el CyberSOC de Netprovider recomienda revisar:

• Registros del servidor web: envíos de formularios inusualmente grandes o malformados y errores repetidos de memoria agotada.
• Cambios en el servidor: archivos nuevos en la raíz web, tareas programadas y cuentas de usuario que nadie del equipo creó (indicadores que destaca Huntress).
• Reglas de detección: ya existen reglas públicas para firewalls web (ModSecurity), sistemas de detección de intrusos (Suricata) y plataformas SIEM (Sigma) que identifican intentos de ataque.

Si sospechas que un servidor fue comprometido, el orden importa. Conserva la evidencia antes de reiniciar, porque el reinicio borra parte de ella. Después cambia las contraseñas, claves de API, tokens y certificados a los que el servidor tenía acceso, ya que una de las vías de ataque permite leerlos desde la memoria. Nuestra guía de respuesta a incidentes según NIST detalla las fases de contención, erradicación y recuperación.

Un aviso sobre el inventario: los escáneres de red confirman que hay PHP instalado, pero no siempre distinguen si la versión es vulnerable. La validación final se hace en cada servidor.

Qué significa para empresas en Chile, Perú y Colombia

En Chile, la Ley Marco de Ciberseguridad cambia lo que pasa si un servidor comprometido presta un servicio esencial. Los prestadores de servicios esenciales y los Operadores de Importancia Vital deben enviar una alerta temprana a la ANCI dentro de las 3 horas desde que conocen un incidente con efectos significativos, y luego un segundo informe y un informe final en los plazos que fija el artículo 9 de la Ley 21.663. Un acceso no autorizado a un portal de clientes o la filtración de credenciales desde la memoria de un servidor puede calificar.

Para quien ya revisó el procedimiento sancionatorio, la conexión es directa: según la propia ANCI, su fiscalización se activa ante un incidente con deber de reporte. El detalle de infracciones y montos está en nuestra guía ANCI: Qué es, qué fiscaliza y cuánto multa.

Perú y Colombia tienen sus propios plazos y canales de reporte. Los resumimos en la guía de reporte de incidentes en Chile, Perú y Colombia. La vulnerabilidad no distingue fronteras: un grupo con presencia en los tres países debería coordinar un solo inventario y una sola ventana de actualización.

Cómo puede ayudarte Netprovider

El boletín que da origen a este artículo lo emitió el equipo de Cyber Threat Intelligence de nuestro CyberSOC 24x7 el mismo 21 de octubre. Con nuestros clientes de servicios gestionados ya estamos trabajando en las tres tareas que más tiempo consumen en una alerta así: el inventario de sistemas con PHP, incluidos los productos de terceros; la priorización según exposición; y el monitoreo de los intentos de explotación con reglas de detección actualizadas.

Si tu organización necesita apoyo para dimensionar su exposición a PHP2Shell, el equipo de ciberseguridad de Netprovider puede acompañarte con el inventario, la revisión de registros desde el 17 de octubre y la aplicación de medidas temporales donde la actualización deba esperar. Para el monitoreo continuo de amenazas como esta, conoce nuestros servicios gestionados con CyberSOC 24x7.

¿Quieres revisar tu caso con un especialista? Conversemos.

Checklist: ¿Qué tan preparada está tu organización frente a PHP2Shell?

Asigna 2 puntos si la respuesta es sí, 1 si está en curso y 0 si aún no empieza.

1. Tenemos un inventario de todos los servidores con PHP y su versión.
2. El inventario incluye productos de terceros (firewalls, paneles, software comercial).
3. Sabemos cuáles de esos sistemas están expuestos a Internet.
4. Actualizamos PHP en los sistemas expuestos y reiniciamos los servicios.
5. Verificamos que los servicios en ejecución usan la versión corregida.
6. Aplicamos medidas temporales o WAF donde no se pudo actualizar.
7. Revisamos los registros desde el 17 de octubre.
8. Los paneles de administración de equipos de red no están expuestos a Internet.
9. Tenemos un plan con fechas para migrar PHP 8.1 o anterior.
10. Sabemos a quién y en qué plazo reportar si confirmamos un incidente.

Entre 16 y 20 puntos: tu organización tiene la respuesta encaminada. Mantén los límites en formularios y sigue los avisos de los fabricantes.

Entre 10 y 15 puntos: avanzas bien. Concentra las próximas 24 horas en los puntos con 0 o 1 de los sistemas expuestos a Internet.

Menos de 10 puntos: conviene empezar hoy por el inventario y los sistemas expuestos, y apoyarte en un equipo externo si el tuyo está dedicado a la operación diaria.

Preguntas frecuentes

¿Mi sitio en WordPress está afectado por PHP2Shell?

Sí, si corre sobre una versión vulnerable de PHP. La falla está en PHP y no en WordPress, así que actualizar el CMS o sus plugins no la corrige. Tu proveedor de hosting o tu equipo de infraestructura debe actualizar PHP en el servidor y reiniciar los servicios.

¿Qué versiones de PHP corrigen PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, publicadas el 21 de octubre de 2026. Las distribuciones de Linux publican sus propios paquetes corregidos, que pueden mantener el número de versión anterior.

¿Qué pasa si uso PHP 8.1 o una versión anterior?

PHP no publicará versiones corregidas para esas ramas. CISA recomienda desconectar esos sistemas hasta actualizarlos. Como medida temporal, desactiva session.upload_progress.enabled en php.ini y reinicia, sin dejar el sistema expuesto a Internet.

¿Un firewall de aplicaciones web me protege?

Ayuda mientras actualizas, pero no reemplaza el parche. Cloudflare activó reglas para todos sus clientes y CISA reconoce el WAF como medida temporal. Bloquear las subidas multipart en el WAF corta una vía de ataque, pero impide todas las subidas de archivos.

¿Ya hay ataques confirmados?

Hay intentos de explotación reportados por AWS, SANS Internet Storm Center y Kaspersky desde el 17 de octubre, y existe código de ataque público. A la fecha de publicación, ninguna fuente pública confirma un servidor comprometido.

Fuentes

• Netprovider CyberSOC, Boletín de Ciberseguridad "Alerta crítica PHP2Shell", 21 de octubre de 2026.
• PHP Project, avisos de seguridad GHSA-w8hw-w9fx-j79w (CVE-2026-109618) y GHSA-6wmf-4rv5-p3rp (CVE-2026-109619).
• CISA, "Critical Vulnerabilities in PHP Require Immediate Patching", 21 de octubre de 2026.
• NSA, "Critical Patches Recommended for PHP Vulnerabilities".
• NCSC UK, "Critical security issue affecting PHP".
• NCSC-NL, "Ernstige kwetsbaarheden in PHP" y repositorio php2shell.
• CERT-EU, Security Advisory 2026-018. ENISA, declaración conjunta sobre las vulnerabilidades de PHP.
• CSIRT de Chile, alerta de seguridad AVC26-00740.
• AWS, "Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot".
• Palo Alto Networks, "Millions of PHP Instances Exposed: What Organizations Need To Do Right Now".
• Google Cloud / Wiz, "Responding to core PHP vulnerabilities".
• Huntress, "Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities".
• Kaspersky, "PHP2Shell: How to Protect Your Server".
• SANS Internet Storm Center, Stormcast del 22 de octubre de 2026.
• Cisco PSIRT, aviso cisco-sa-php-october26. AlmaLinux, aviso PHP2Shell.
• BleepingComputer, "PHP ships emergency patches for critical PHP2Shell flaws". SecurityWeek, "PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws".