PHP2Shell: alguien intentó usar la falla de PHP cuatro días antes del arreglo; gobiernos y bancos apagaron servicios por precaución

Alguien intentó usar un hueco presente en millones de páginas web cuatro días antes de que saliera el arreglo. Ese hueco se llama PHP2Shell: son dos fallas (CVE-2026-109618 y CVE-2026-109619) en PHP, el lenguaje que mueve por detrás al 69.2 % de los sitios web cuyo lenguaje del servidor se conoce, según W3Techs (27 de octubre de 2026). Ahí corren tiendas en línea, blogs de WordPress y portales de todo tipo.

Qué permite la falla

En palabras simples: un extraño puede entrar al "cuarto de máquinas" de una página sin llave y darle órdenes al servidor. Técnicamente, el equipo de PHP las describe como ejecución remota de código sin autenticación, con una gravedad de 9.2 sobre 10 en la escala CVSS v4. No todas las instalaciones son igual de fáciles de atacar: el riesgo más alto está en servidores con Apache y el módulo mod_php, y la explotación depende de la configuración.

Palo Alto Networks estima que hay más de 22.6 millones de instalaciones expuestas potencialmente vulnerables en internet.

Qué pasó, día por día

• 17 de octubre: Amazon identifica en sus servidores trampa (honeypots MadPot) un intento de explotar la falla, cuatro días antes del arreglo. Recomienda revisar registros desde al menos esa fecha.
• 21 de octubre: PHP publica el arreglo (versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12) a las 14:00 UTC. El arreglo ya existía en privado: la primera falla se reportó el 11 de agosto y se mantuvo bajo embargo.
• 26 de octubre: CISA, la agencia de ciberseguridad de EE. UU., agrega ambas fallas a su catálogo de vulnerabilidades explotadas, con plazo del 29 de octubre para las agencias federales.

El impacto: servicios apagados por precaución

Varios gobiernos y empresas desconectaron servicios mientras parchaban, por precaución y sin hackeo confirmado:

• Países Bajos: el gobierno desconectó "uit voorzorg" (por precaución) portales como Overheid.nl, MijnOverheid.nl y DigiD, el acceso digital a los trámites del gobierno, y dijo que no había señales de abuso. También se apagaron el sitio del Parlamento y páginas de hospitales.
• Finlandia: Valtori, el centro de informática del gobierno, apagó como precaución los servicios web públicos que mantiene.
• Japón: bancos como MUFG, Mizuho y Shizuoka Bank pausaron algunos servicios en línea como precaución.
• Reino Unido: la ministra Lloyd informó a la Cámara de los Lores que 32 servicios del gobierno no estaban disponibles y 4 lo estaban parcialmente, "en su mayor parte" por medidas precautorias; Downing Street aclaró que eso no significaba que hubieran sido hackeados.

El dato honesto: ¿hay víctimas?

En las trampas de un investigador (Adel Karimi), el ataque ya funcionó 35 veces el 24 de octubre, aunque en una configuración preparada a propósito para ser favorable. Pero al 27 de octubre no hay ninguna víctima real confirmada en público: ni la propia víctima, ni una autoridad, ni dos medios serios han nombrado a una organización comprometida por PHP2Shell. CISA no ha revelado qué organizaciones fueron afectadas, y Palo Alto retiró el 25 de octubre un reporte que había ligado las fallas con la intrusión a una agencia europea.

Un caso que circuló es el de una extorsión contra una inmobiliaria japonesa y una veintena de sitios en Japón. Según SOCRadar, ocurrió del 9 al 11 de octubre, antes de que las herramientas de PHP2Shell llegaran al servidor del atacante (21 de octubre), y los archivos no muestran relación entre PHP2Shell y esas intrusiones.

Qué hacer

Si tu página usa PHP, actualízala hoy a la versión parchada de tu rama: 8.2.35, 8.3.36, 8.4.27 u 8.5.12, o al paquete ya parchado de tu distribución de Linux. ¿Usas PHP 8.1 o una versión anterior? PHP ya no saca versiones nuevas para esas ramas: pide el parche a tu proveedor o distribución, o migra a una rama con soporte. Si no puedes actualizar, CISA recomienda desconectar el sistema hasta protegerlo.

Aparte, el 23 de octubre PHP avisó de una tercera falla aún sin parche (CVE-2026-115560), menos probable de explotar; mientras sale el arreglo recomienda desactivar la opción session.upload_progress.enabled.