Las vulnerabilidades críticas de PHP fueron objeto de intentos de explotación antes de la publicación de los parches de seguridad. Amazon detectó actividad el 17 de octubre y alertó sobre nuevos intentos tras la divulgación de las fallas.
BUENOS AIRES, 22 de octubre de 2026 (MI PERIÓDICO).- Las vulnerabilidades críticas de PHP fueron objeto de intentos de explotación cuatro días antes de que se publicaran las correcciones oficiales. Amazon Threat Intelligence detectó actividad el 17 de octubre y advirtió sobre nuevos intentos tras la divulgación de las fallas. Los desarrolladores recomiendan actualizar de inmediato los sistemas afectados.
Vulnerabilidades críticas de PHP: qué detectó Amazon
Las vulnerabilidades críticas de PHP quedaron bajo alerta luego de que Amazon Threat Intelligence informara que detectó un intento de explotación el 17 de octubre de 2026, cuatro días antes de la divulgación pública de las fallas y de la publicación de sus correcciones.
El intento fue registrado por MadPot, una red de sistemas señuelo de Amazon Web Services (AWS) diseñada para observar y analizar actividad maliciosa. Según la compañía, la actividad se originó en una dirección IP asociada a una red comercial de anonimización.
Amazon señaló que no pudo determinar cómo el actor obtuvo información sobre las vulnerabilidades antes de que se hicieran públicas. El episodio demuestra que la fecha de divulgación de una falla no necesariamente coincide con el inicio de los intentos de explotación.
¿Qué son las fallas PHP2Shell?
Las vulnerabilidades, identificadas como CVE-2026-109618 y CVE-2026-109619 y conocidas en conjunto como PHP2Shell, afectan al lenguaje de programación PHP. Ambas tienen una puntuación de gravedad de 9,2 sobre 10 según el sistema CVSS v4.0.
Si se explotan con éxito, pueden permitir la ejecución remota de código sin autenticación. Esto significa que un atacante podría ejecutar instrucciones en un servidor vulnerable y comprometer su seguridad.
PHP se utiliza para desarrollar sitios web y aplicaciones. El lenguaje está presente en numerosos entornos de alojamiento y plataformas de gestión de contenidos. La exposición concreta depende de la versión instalada, la configuración del servidor y la forma en que se ejecutan las solicitudes web.
Los intentos de explotación aumentaron tras la divulgación
El informe de AWS indica que, el 21 de octubre, la compañía identificó pruebas de concepto que mostraban cómo explotar las vulnerabilidades. Algunas fueron observadas en sus sistemas señuelo pocas horas después de que se publicaran las correcciones.
Amazon también detectó nuevos intentos de explotación desde otras infraestructuras de anonimización. Las diferencias entre las cargas utilizadas y los recursos de origen sugieren la participación de varios actores, aunque el análisis técnico continúa.
AWS no confirmó que todos esos intentos hayan tenido éxito en sistemas reales. Por eso, la detección de actividad maliciosa no debe interpretarse automáticamente como evidencia de que un servidor determinado fue comprometido.
¿Qué versiones de PHP deben actualizarse?
El equipo oficial de PHP publicó las actualizaciones de seguridad el 21 de octubre de 2026. Las versiones corregidas son:
- PHP 8.5.12.
- PHP 8.4.27.
- PHP 8.3.36.
- PHP 8.2.35.
Las instalaciones anteriores pueden estar afectadas. El aviso oficial señala que el riesgo alcanza a los entornos PHP que atienden solicitudes web, incluidos PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.
PHP 8.1 y las versiones anteriores ya no reciben actualizaciones generales de seguridad del proyecto. Sin embargo, algunos proveedores de sistemas operativos y servicios de soporte extendido pueden ofrecer correcciones específicas.
El equipo de desarrollo recomienda instalar las versiones corregidas de inmediato. Según el aviso oficial, la actualización es la única medida que resuelve completamente ambas vulnerabilidades.
¿Qué deben hacer los administradores de sitios web?
Los administradores deben comprobar qué versión de PHP utilizan sus servidores y confirmar con sus proveedores de alojamiento que las correcciones estén aplicadas. La publicación de un parche no garantiza que ya se haya instalado en todos los entornos.
AWS recomienda revisar los registros de los servidores web en busca de solicitudes sospechosas, prestar atención a las peticiones relacionadas con la carga de archivos y verificar si se produjeron ejecuciones inesperadas de procesos o modificaciones de archivos.
La compañía también aconseja investigar actividad vinculada con el indicador PHP_SESSION_UPLOAD_PROGRESS en solicitudes de carga de archivos. Estas señales deben analizarse junto con otros registros y evidencias, ya que por sí solas no demuestran que haya ocurrido una intrusión.
Si una instalación vulnerable no puede actualizarse de inmediato, los responsables deben evaluar medidas temporales para reducir la exposición. AWS menciona el bloqueo de determinadas cargas de archivos, siempre que se compruebe antes el impacto sobre la aplicación. Estas medidas no sustituyen la instalación de las correcciones.
¿Qué se sabe sobre el riesgo para los sitios web?
El caso PHP2Shell muestra que los intentos de explotación pueden comenzar antes de la divulgación pública y aumentar después de que se conocen los detalles técnicos de una vulnerabilidad.
Sin embargo, no significa que todos los sitios que utilizan PHP hayan sido atacados. Para determinar si un servidor fue comprometido, es necesario revisar sus registros, su configuración y cualquier actividad anómala.
La recomendación central es comprobar las versiones instaladas, aplicar las actualizaciones disponibles y analizar los indicios de actividad sospechosa sin esperar a que se confirme un ataque contra el propio sitio.
Fuentes: Amazon Web Services (AWS), equipo de Threat Intelligence; equipo oficial de desarrollo de PHP; CERT-EU; Associated Press.