PHP2Shell: la falla crítica de PHP que pone en riesgo a miles de sitios web, y qué hacer en Chile

Dos vulnerabilidades críticas en el propio PHP (CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell) permiten ejecutar código en un servidor web sin iniciar sesión; PHP publicó parches el 21 de octubre de 2026 y la explotación ya se observa en internet.

Qué es PHP2Shell

PHP2Shell es el nombre con que circulan dos fallas de seguridad en el motor de PHP, el lenguaje que usan cerca de siete de cada diez sitios web cuyo lenguaje de servidor se conoce. Fueron reveladas el 20 de octubre de 2026, tras una filtración previa a la fecha acordada, y corregidas al día siguiente.

• CVE-2026-109618: ejecución remota de código por corrupción de memoria cuando PHP se queda sin memoria en mal momento.
• CVE-2026-109619: ejecución remota de código por estado global obsoleto (uso de memoria ya liberada, use-after-free).
• Gravedad: 9,2 sobre 10 en CVSS v4.0, según el equipo de PHP. Hay empresas que la puntúan más alto.

Lo que la hace distinta es dónde está el error. No está en un plugin ni en WordPress: está en PHP mismo, así que un sitio bien programado y con el CMS al día puede seguir expuesto. En la demostración publicada, la petición maliciosa actúa antes de que corra cualquier código de la aplicación.

El hallazgo se atribuye a los investigadores de Calif (dentro del proyecto «Patch the Planet» de OpenAI) y de Wiz, con apoyo de inteligencia artificial. Un ingeniero de seguridad vinculado a PHP la comparó con Heartbleed, la falla de OpenSSL de 2014.

Versiones afectadas y parches

Se considera afectada toda instalación de PHP que atienda peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El mayor riesgo está en mod_php. Quien no haya aplicado la actualización debe asumir que es vulnerable.

Rama de PHP	Versión corregida	Qué hacer
8.5.x	8.5.12	Actualizar
8.4.x	8.4.27	Actualizar
8.3.x	8.3.36	Actualizar
8.2.x	8.2.35	Actualizar y planear migración: termina su soporte el 31 de diciembre de 2026
8.1, 8.0 y 7.4	Sin versión oficial	Usar el paquete corregido de tu distribución o proveedor de soporte, o migrar a una rama vigente
7.3 y anteriores (incluido PHP 5)	Sin corrección	Migrar: no hay parche disponible

El problema de fondo es el parque desactualizado. Según datos anonimizados de 12.000 clientes de Qualys, cerca del 71 % de las instalaciones de PHP que miden corre versiones sin soporte, y solo 199.000 estaban parcheadas a las 12 horas de la divulgación. Una advertencia práctica: el comando php de la terminal puede ser una versión distinta de la que sirve tu sitio (PHP-FPM o Apache), así que verifica la que realmente atiende la web.

Situación en Chile: ¿hay sitios atacados?

Al 22 de octubre no hay reportes públicos verificables de sitios chilenos comprometidos con PHP2Shell. Eso no equivale a que no haya ataques: la falta de informes también puede deberse a que nadie ha detectado o publicado un caso.

Lo que sí está confirmado:

• Alerta oficial. El CSIRT Nacional de la ANCI publicó el 21 de octubre la alerta AVC26-00740, de nivel crítico, y pidió actualizar PHP de inmediato. Está dirigida a prestadores de servicios esenciales y operadores de importancia vital, pero sus recomendaciones sirven a cualquier organización con sitios en PHP.
• Explotación mundial en curso. watchTowr observa explotación real desde el 21 de octubre y Amazon registró un intento en sus señuelos antes de la publicación del parche. Un académico de la Universidad de Valparaíso resume la situación así: la alerta no significa que haya sitios chilenos comprometidos, significa que el riesgo es real y el tiempo es corto.
• Exposición local probable. En Chile hay sitios de gobierno, tiendas online, plataformas educativas y medios hechos con PHP y CMS como WordPress, Drupal, Joomla y Magento. Muchas pymes, colegios y municipios están en hosting compartido, donde el cliente no controla la versión de PHP.
• Hostings que ya parchearon. Al menos un proveedor chileno, Tecnoinver, informó que aplicó las versiones corregidas en todos sus servidores.

En el extranjero la reacción fue más drástica: Países Bajos, Finlandia, Francia y Dinamarca sacaron de línea sitios y servicios públicos de forma preventiva mientras no existía el parche.

Si eres una entidad obligada por la Ley 21.663, revisa los plazos de reporte del CSIRT (alerta temprana dentro de las 3 horas de conocido un incidente significativo). Para reportar o consultar, la ANCI indica el 1510 y el correo ayuda@anci.gob.cl.

Nota editorial: si en xyzseguridad.cl tienen conocimiento de un caso concreto, conviene citarlo aquí con su fuente; no encontramos ninguno público al cierre de este texto.

Consejos: qué hacer hoy

La única solución completa es actualizar PHP a una versión corregida. El propio proyecto PHP indica que ninguna configuración cierra por completo las fallas.

Si administras tus propios servidores

1. Inventaría cada PHP. Incluye contenedores, paneles como cPanel o Plesk, subdominios y sistemas de proveedores. Revisa la versión con dpkg -l | grep php (Ubuntu o Debian) o rpm -qa | grep php (RHEL, Rocky, AlmaLinux).
2. Respalda y actualiza. En Ubuntu: sudo apt update && sudo apt upgrade. Comprueba antes que puedes restaurar el respaldo.
3. Reinicia todos los servicios que cargan PHP (PHP-FPM, Apache, LiteSpeed). Los procesos en marcha siguen usando el código vulnerable hasta que se reinician.
4. Verifica la versión real que atiende la web, no solo la de la línea de comandos.
5. Si usas PHP 8.1 o anterior, instala el paquete corregido de tu distribución o proveedor de soporte, y agenda la migración a una rama vigente.

Si tu sitio está en hosting compartido

• Pregunta por escrito a tu proveedor si aplicó el parche y a qué versión. Si el servidor es administrado, pide que lo confirme.
• En cPanel, abre Multi-PHP Manager y revisa qué versión usa cada dominio.
• Actualizar WordPress o tus plugins no basta: la falla está en el intérprete del servidor.

Mientras llega el parche

• Un firewall de aplicaciones web (como el de Cloudflare) reduce el riesgo, pero es un paliativo, no reemplaza la actualización.
• PHP compartió medidas temporales, como desactivar el progreso de carga de sesiones o limitar el tamaño de las solicitudes. Solo reducen algunas rutas de ataque.
• Si un servicio no puede actualizarse ni protegerse, evalúa aislarlo o sacarlo de línea temporalmente, como hicieron varios gobiernos.

Precauciones al probar

• Hay numerosos repositorios públicos que dicen ofrecer exploits de PHP2Shell. La PHP Foundation dijo el miércoles que solo veía exploits incompletos o que no funcionaban, aunque después otras firmas reportaron explotación real. Ejecutar código ajeno en tu red es en sí un riesgo: no los uses.
• Para comprobar exposición, existen herramientas de escaneo abiertas, como php2shell-scanner de Searchlight Cyber. Úsalas solo contra servidores propios o con autorización por escrito.

Señales de compromiso y qué hacer si sospechas

Los indicadores confirmados todavía son pocos, por lo que conviene revisar con lupa y no esperar una firma única. Estas señales merecen atención:

• Caídas o reinicios repetidos de los procesos de PHP y errores de agotamiento de memoria que coinciden con peticiones sospechosas.
• Archivos que nadie subió, sobre todo archivos PHP nuevos en carpetas de subida o temporales.
• Cambios en el sitio que nadie hizo, o redirecciones a otros sitios.
• Cabeceras Set-Cookie: PHPSESSID con valores anómalos en las respuestas, un patrón descrito por Imperva.

Si detectas algo de esto:

1. Aísla el servidor o pon el sitio en mantenimiento, sin apagarlo todavía si necesitas conservar evidencia.
2. Conserva los registros del servidor web, de PHP y del sistema antes de limpiar nada.
3. Actualiza PHP y reinicia los servicios.
4. Cambia credenciales, claves de API y tokens guardados en el servidor: investigadores demostraron que se puede filtrar memoria de los procesos de PHP, que puede contener contraseñas y llaves.
5. Restaura desde un respaldo anterior al incidente o reconstruye el servidor; limpiar a mano un servidor comprometido suele dejar puertas traseras.
6. Reporta al CSIRT Nacional (1510 o ayuda@anci.gob.cl) si eres una entidad obligada por la Ley 21.663 o si el incidente es relevante.