PHP2Shell: detectaron intentos de ataque antes de los parches y esto importa para WordPress

Amazon Threat Intelligence informó que encontró un intento de explotación de PHP2Shell fechado el 17 de octubre de 2026, cuatro días antes de la divulgación pública de los fallos y sus parches. El hallazgo obliga a distinguir dos tareas: corregir la vulnerabilidad y revisar qué pudo ocurrir antes de instalar la actualización.

Foto ilustrativa: imgix / Unsplash. No muestra un ataque ni la infraestructura de NotiApple.

Qué detectó Amazon y qué no demuestra

Según el reporte original de AWS, publicado el 21 de octubre, la actividad apareció en MadPot, su infraestructura de señuelos para estudiar ataques. La compañía también identificó intentos posteriores y señaló que seguía investigando.

AWS aclaró que no estaba determinado si esos intentos habrían funcionado contra sistemas reales. El dato confirma actividad anterior a la divulgación; no prueba que todos los servidores expuestos fueran comprometidos ni permite atribuir un ataque a un sitio particular.

Los dos fallos y las versiones corregidas

El aviso oficial de PHP del 21 de octubre identifica CVE-2026-109618 y CVE-2026-109619 como vulnerabilidades críticas que pueden permitir ejecución remota de código sin autenticación. Afectan al procesamiento de solicitudes web, con alcance que incluye PHP-FPM, Apache y LiteSpeed.

Las versiones publicadas para corregir esos dos problemas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Los proveedores pueden distribuir correcciones adaptadas a sus paquetes: en ese caso, corresponde pedir confirmación expresa del parche y no juzgar únicamente por el número visible.

La aclaración adicional del 23 de octubre

PHP publicó otro aviso sobre un escenario específico relacionado con el progreso de cargas y cambios en la serialización de sesiones. Recomienda desactivar temporalmente session.upload_progress.enabled hasta la siguiente versión regular; aclara que las aplicaciones que no cambian ese manejador en ejecución pueden mantener la función.

La evaluación debe hacerla quien administra el servidor. No conviene copiar cambios de configuración sin conocer qué aplicaciones y funciones dependen de ellos.

Por qué actualizar WordPress no alcanza para este caso

WordPress, sus plugins y PHP son componentes diferentes. Pulsar «Actualizar» dentro del panel puede poner al día el gestor o una extensión, pero no demuestra que el hosting haya actualizado el motor PHP que atiende las visitas.

Para un sitio alojado en un servicio administrado, la consulta útil al proveedor es concreta:

• ¿Qué versión y paquete de PHP sirven las solicitudes web del dominio?
• ¿Se aplicaron las correcciones de ambos CVE y se cargó efectivamente la versión corregida en los procesos activos?
• ¿Se revisó la recomendación adicional del 23 de octubre?
• ¿Se analizaron registros desde el 17 de octubre buscando actividad sospechosa?

AWS recomienda actualizar y revisar registros, procesos inesperados y cambios de archivos. Una versión corregida evita seguir expuesto a estos fallos, pero no acredita por sí sola que no haya ocurrido una intrusión anterior.

Cloudflare también informó protecciones y tráfico de ataque, y pidió aplicar los parches incluso contando con su firewall. Esa capa defensiva no reemplaza la actualización del servidor.

Fuentes: PHP, AWS y Cloudflare, consultadas el 23 de octubre de 2026. Punto de partida: WIRED en español. Esta cobertura no constituye una auditoría de un sitio específico.