Las vulnerabilidades conocidas como PHP2Shell pasaron de alerta preventiva a ataques confirmados, y Apiux y Fortinet coinciden en que el desafío para las empresas es saber dónde tienen PHP y parchearlo sin dejar puertas abiertas mientras tanto.
PHP2Shell es el nombre de la vulnerabilidad de PHP que reúne dos fallas críticas, CVE-2026-109618 y CVE-2026-109619, con un puntaje de 9,2 sobre 10, que permiten a un atacante sin credenciales ejecutar código en un servidor. El problema está en el motor de PHP y no en las aplicaciones que corren encima, de modo que un sitio puede estar expuesto aunque su propio código sea seguro, y PHP impulsa cerca del 70 % de los sitios web, según Cybersecurity Dive.
De la alerta a los ataques
Los primeros intentos de explotación de la vulnerabilidad de PHP se registraron el 17 de octubre, según Amazon, cuatro días antes de que PHP publicara las correcciones del 21 de octubre en las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, un día en que sitios gubernamentales de Países Bajos salieron de línea por precaución, de acuerdo con The Hacker News. Los primeros días hubo escepticismo, porque las advertencias tardaban en materializarse y las pruebas de concepto que circulaban eran de baja calidad, hasta que el 26 de octubre CISA incorporó las fallas a su catálogo de vulnerabilidades explotadas, luego de que investigadores confirmaran una explotación exitosa, de acuerdo con Cybersecurity Dive.
Dos días después, Palo Alto Networks advirtió que hay ataques contra las interfaces de administración de sus firewalls expuestas a internet, y la firma Dream informó que un actor sospechoso de estar vinculado a China encadenó PHP2Shell con otra falla de Linux para tomar el control de 25 servidores en cuatro países, según The Hacker News.
En Chile, el CSIRT Nacional emitió la alerta AVC26-00740, dirigida a proveedores de servicios esenciales y operadores de importancia vital. Pide actualizar de inmediato, revisar los registros de los servidores desde el 17 de octubre y vigilar una tercera falla relacionada que aún no tiene corrección.
El PHP que nadie revisa
Para Lucas Ovalle, Head of Cybersecurity & IT Support de Apiux, uno de los principales riesgos de la vulnerabilidad de PHP para las organizaciones chilenas está en los sistemas antiguos que funcionan sin supervisión permanente, donde pueden existir versiones desactualizadas de PHP que pasan inadvertidas durante años. “Si nadie sabe qué versión de PHP corre ahí, nadie sabe si está expuesto”, advierte, y agrega que el tiempo para reaccionar se acortó: “La velocidad del ataque ya no se mide en semanas, se mide en horas”.
Según Ovalle, una organización que mantiene al día el inventario de sus sistemas sabe dónde usa PHP y puede aplicar mitigaciones temporales mientras actualiza, de modo que no tiene que elegir entre apagar todo y quedar expuesta.
Actualizar, pero con controles mientras tanto
Aamir Lakhani, estratega global de seguridad e investigador de FortiGuard Labs de Fortinet, describe las fallas como un riesgo urgente de seguridad y de continuidad del negocio para quienes dependen de sitios web, portales de clientes y otras aplicaciones web. Explica que actualizar puede requerir pruebas de compatibilidad, ventanas de mantenimiento y reinicios de servicios que retrasan el parche, y plantea aplicar las actualizaciones “tan pronto como se pueda hacerlo de forma segura”, con controles provisionales mientras se completa la remediación. Recomienda además asignar un responsable y un cronograma por cada servicio afectado, y verificar que el código parcheado esté efectivamente en ejecución.
Fortinet, que ofrece parcheo virtual como una de esas medidas provisionales, informó que FortiOS y otros productos suyos no están afectados. En el reporte 2026 de FortiGuard Labs, que Martín Hoz comentó en ZonaCISO, la explotación de fallas ya se mide en ventanas de 24 a 48 horas y lo antiguo sigue siendo el blanco principal.