Dos fallas en el motor de PHP obligaron a adelantar una actualización de seguridad. Los parches están disponibles desde el 21 de octubre, pero los reportes de ataques muestran por qué también importa revisar lo que ocurrió antes de instalarlos.
Información verificada al 22 de octubre de 2026. Los horarios de esta nota corresponden a Argentina (UTC−3).
PHP2Shell puso en alerta a administradores de sitios, desarrolladores y equipos de seguridad de todo el mundo. El nombre reúne dos vulnerabilidades críticas en PHP, la tecnología que ejecuta aplicaciones web en el servidor y sobre la que funcionan sistemas como WordPress, Drupal y Joomla.
El escenario ya cambió respecto de las primeras alertas: hay correcciones disponibles y reportes de actividad de ataque. Para entender qué significa eso para un sitio, conviene separar tres situaciones: usar software vulnerable, recibir un intento de explotación y sufrir una intrusión confirmada. Una no demuestra automáticamente las otras.
En este artículo:
- Qué es PHP2Shell y por qué generó tanta preocupación
- Qué falló dentro de PHP
- La cronología: investigación, filtración y parches adelantados
- Qué se sabe de los ataques
- Qué versiones tienen corrección
- Qué conviene hacer ahora
- La inteligencia artificial también forma parte de esta historia
- Después del parche, queda la verificación
Qué es PHP2Shell y por qué generó tanta preocupación
Las fallas están identificadas como CVE-2026-109618 y CVE-2026-109619. Ambas recibieron una calificación de 9,2 sobre 10 en CVSS v4.0, correspondiente a severidad crítica. CVE es el identificador de cada vulnerabilidad; CVSS es la escala que evalúa su gravedad. El anuncio oficial de PHP comunicó esa puntuación el 20 de octubre.
El riesgo principal es la ejecución remota de código sin autenticación: bajo las condiciones necesarias, un atacante puede lograr que el servidor ejecute instrucciones sin disponer previamente de una cuenta válida. Las consecuencias dependen del entorno y de los permisos del proceso afectado; no significa necesariamente obtener privilegios de administrador de todo el servidor.
La preocupación se explica por el lugar donde está el problema. PHP ejecuta el código de las aplicaciones: una falla en esa capa puede afectar a sitios cuyo código propio no tenga el mismo error. Wiz demostró explotación en WordPress, Drupal y Joomla, utilizados como aplicaciones representativas. Eso no acredita que todos los sitios que usan esos sistemas hayan sido comprometidos.
Qué falló dentro de PHP
La CVE-2026-109618 está relacionada con el manejo del agotamiento de memoria. Si una operación se interrumpe en un momento particular, PHP puede conservar estructuras internas incompletas y tratarlas después como válidas. Esa inconsistencia puede provocar corrupción de memoria y permitir ejecución de código.
El riesgo es especialmente alto con Apache y mod_php, una forma de integrar PHP al servidor web: se demostró un ataque que actúa antes de que empiece a ejecutarse el código de la aplicación. También se confirmaron rutas de explotación mediante aplicaciones que usan PHP-FPM, otro sistema habitual para ejecutar PHP.
La CVE-2026-109619 afecta al estado que queda entre solicitudes. Un error fatal puede dejar referencias a memoria ya liberada; una petición posterior, procesada por el mismo trabajador, puede volver a utilizarla. Se verificaron fallas del proceso y una demostración de ejecución remota sobre una aplicación real. Esa demostración técnica no debe confundirse con un ataque malicioso confirmado contra un sitio en producción.
La cronología: investigación, filtración y parches adelantados
La PHP Foundation explicó que en 2024 ya había indicios del problema de memoria, aunque sin un vector concreto de ejecución remota. Reportes de Calif, OpenAI y Wiz al equipo de PHP en agosto de 2026 demostraron su alcance. La organización reconoció que dificultades de decisión y recursos habían retrasado la corrección, y describió cambios en su trabajo de seguridad.
- 17 de octubre: AWS registró un intento contra sus sensores, identificado posteriormente como PHP2Shell. La actividad precede a la divulgación pública.
- 20 de octubre, alrededor de las 12:00: comenzaron a circular los identificadores de las fallas, junto con horarios y una puntuación de gravedad incorrectos.
- 20 de octubre, 16:33: PHP publicó el anuncio oficial de una actualización para el día siguiente.
- 20 de octubre, cerca de las 17:00: Calif publicó por error un video de demostración, que luego retiró.
- 21 de octubre, 04:41: un distribuidor publicó imágenes de software con la corrección antes del levantamiento del embargo, según la Foundation.
- 21 de octubre, 11:00: llegó la publicación coordinada de los parches, adelantada un día respecto de la fecha prevista originalmente.
El embargo es el período en que investigadores, desarrolladores y distribuidores coordinan la solución antes de divulgar los detalles. Busca que las correcciones estén listas cuando el problema se haga público. En este caso, esa coordinación se alteró durante las horas previas al lanzamiento.
Qué se sabe de los ataques
El reporte de Amazon Threat Intelligence aporta un dato relevante: el intento del 17 de octubre ocurrió contra MadPot, su infraestructura de sistemas señuelo para detectar amenazas. AWS no sabe cómo se obtuvo información antes de la divulgación. También observó intentos previos al lanzamiento y nuevas pruebas de concepto utilizadas contra sus sensores después de publicarse los parches.
AWS describe explotación extendida, pero aclara que no puede determinar si los intentos anteriores a la divulgación habrían funcionado en sistemas reales. Por eso, su informe no constituye un recuento de sitios comprometidos. Tampoco permite atribuir toda la actividad a la filtración del 20 de octubre.
Cloudflare informó tráfico de ataque contra sus clientes y cambios en los intentos para evadir sus protecciones. Sus reglas de firewall de aplicaciones web, o WAF, pueden filtrar patrones conocidos. Esa protección es complementaria: no modifica el código vulnerable de PHP ni sustituye el parche.
Estos informes justifican actuar con urgencia. No respaldan afirmar que toda la web fue hackeada, ni ofrecen una cifra global verificada de sitios afectados. Del mismo modo, una interrupción de servicio o una pausa de mantenimiento, por sí solas, no prueban una intrusión.
Qué versiones tienen corrección
El aviso oficial del 21 de octubre identifica estas versiones corregidas en las ramas mantenidas por el proyecto:
| Rama de PHP | Versión con la corrección |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
PHP 8.1 y las ramas anteriores no recuperaron el soporte regular. Excepcionalmente, el equipo ofreció correcciones mínimas en código fuente para 7.4, 8.0 y 8.1. Eso no equivale a disponer de un instalador universal ni garantiza futuras actualizaciones.
También existen backports: correcciones incorporadas por una distribución o proveedor a un paquete que conserva una versión base anterior. Ver una versión base como «8.3.6» de forma aislada no permite concluir que un paquete sigue expuesto: hay que comprobar el aviso de cada proveedor y el estado real del paquete.
Qué conviene hacer ahora
Para un sitio con hosting administrado, la pregunta concreta al proveedor es si el intérprete PHP que atiende ese sitio ya tiene aplicada la corrección. Actualizar el gestor de contenidos o sus plugins no demuestra que esa capa del servidor también se haya actualizado.
Quien administra su propio servidor necesita verificar toda la instalación, no solamente descargar el paquete. Un recorrido práctico es:
- Identificar los entornos: revisar qué versión y qué paquete utiliza cada sitio, aplicación o contenedor.
- Aplicar la corrección oficial: usar el canal del proyecto, la distribución o el proveedor correspondiente, con respaldo y comprobaciones de compatibilidad.
- Activar el código actualizado: reiniciar los servicios o procesos que lo necesiten y comprobar el funcionamiento del sitio.
- Confirmar qué está ejecutándose: la versión de PHP de la terminal puede ser distinta de la que atiende solicitudes web.
- Revisar la exposición previa: buscar anomalías en los registros y, si hay indicios, activar una investigación de seguridad.
Después de actualizar, los procesos pueden requerir reinicio. En Apache con mod_php corresponde reiniciar Apache; en instalaciones con PHP-FPM hay que revisar el servicio y sus procesos. No hay un único comando que resuelva correctamente todos los entornos.
PHP advierte que los cambios temporales de configuración cubren rutas específicas y no reemplazan la actualización. Copiar ajustes de memoria o instalar «parches» de procedencia desconocida puede sumar problemas sin resolver la exposición. Si no es posible actualizar inmediatamente, las medidas transitorias deben evaluarse para esa instalación.
La inteligencia artificial también forma parte de esta historia
Wiz explicó que la asistencia de IA ayudó a sus investigadores a encadenar y adaptar demostraciones de explotación. El trabajo incluyó pruebas, validación y coordinación entre equipos humanos. El caso muestra cómo estas herramientas pueden acelerar la investigación de errores complejos; no demuestra que una IA haya atacado por sí sola a toda Internet.
Después del parche, queda la verificación
Instalar la corrección atiende estas vulnerabilidades, pero no demuestra que antes no haya ocurrido una intrusión ni elimina automáticamente sus posibles consecuencias. La actividad anterior al anuncio que registró AWS hace especialmente relevante revisar ese período.
La respuesta completa combina dos tareas: confirmar que el sitio está ejecutando software corregido y evaluar cualquier señal de compromiso previo. Esa distinción permite cerrar la actualización con evidencia, sin confundir una medida aplicada con una garantía absoluta de seguridad.