PHP2Shell: ataques desde el 17 de octubre; revisa tu web

Amazon informó el 21 de octubre de 2026 de que vio un intento de ataque a los fallos PHP2Shell de PHP el 17 de octubre, cuatro días antes del aviso público, y de que ahora se explotan de forma amplia. Si tu web usa PHP, actualizar no basta: conviene revisar qué pasó desde el 17.

Lo que se sabe

  • El primer intento: según el informe de Amazon Threat Intelligence, publicado en el blog de seguridad de AWS el 21 de octubre, sus señuelos MadPot (servidores trampa para atraer ataques) registraron un intento de explotación el 17 de octubre. Vino de una dirección de una red comercial de anonimización. Amazon dice que no sabe cómo consiguió el atacante la información antes de tiempo.
  • El día del parche: Amazon cuenta que el 21 de octubre, hacia las 02:00 UTC (21:00 del 20 en Lima), ya circulaban varias pruebas de concepto, y que entre las 02:00 y las 08:00 UTC hubo más intentos desde otras redes anónimas. Por las diferencias entre ellos, cree que eran varios actores. Añade que su análisis sigue y que no sabe si esos intentos habrían funcionado en sistemas reales.
  • Después del aviso: PHP publicó las versiones corregidas a las 14:00 UTC (9:00 en Lima). Según Amazon, en pocas horas aparecieron más pruebas de concepto y las vio usadas contra sus sensores casi de inmediato. Su conclusión: «PHP2Shell is now being broadly exploited in the wild».
  • Qué recomienda: actualizar ya a las versiones corregidas, que según AWS es la única solución completa para los dos fallos (CVE-2026-109618 y CVE-2026-109619). No hay, dice, ningún ajuste de configuración que los cubra del todo.
  • Si no se puede actualizar hoy: Amazon propone valorar el bloqueo de las subidas de archivos multiparte, después de comprobar cómo afecta a la aplicación.
  • Qué revisar: buscar en las subidas de formularios peticiones POST con la cadena PHP_SESSION_UPLOAD_PROGRESS, revisar los registros del servidor web y buscar procesos o cambios de archivos inesperados. La investigación, según AWS, debe empezar «al menos» el 17 de octubre, no el día del aviso.
  • Las direcciones IP: el informe lista seis IP vistas el 17 y el 21 de octubre. Amazon aclara que son de infraestructura de anonimización compartida, no exclusivas de estos ataques, y pide investigarlas en lugar de bloquearlas.

Qué cambia y qué no

El parche es el mismo de ayer: PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o el paquete corregido de tu distribución. Eso no cambia.

Lo que cambia es la fecha desde la que hay que mirar. Al publicar, la PHP Foundation dijo que no había identificado exploits que funcionaran. El informe de Amazon no contradice eso del todo, porque no sabe si los primeros intentos tenían éxito, pero sí deja claro que alguien lo intentaba desde el 17 y que hoy los ataques son amplios. Una web que se actualizó el 21 pudo estar expuesta cuatro días antes.

El informe tampoco dice cuántas webs se vieron comprometidas. Habla de intentos contra sus señuelos, no de víctimas.

Cómo saber si te afecta

  1. Confirma tu versión de PHP. En WordPress: Herramientas → Salud del sitio → Información → Servidor. En Drupal: Informes → Informe de estado. Si no ves 8.5.12, 8.4.27, 8.3.36 u 8.2.35 o superior (o un paquete corregido de tu proveedor), actualizar sigue siendo lo primero.
  2. Pregunta al hosting por las fechas. «¿Cuándo aplicaron la versión corregida de PHP en mi plan? ¿Han revisado los registros desde el 17 de octubre por los fallos CVE-2026-109618 y CVE-2026-109619?». En hosting compartido, los registros del servidor los suele tener el proveedor.
  3. Busca archivos nuevos o cambiados desde el 17. En el administrador de archivos del panel o por SFTP, ordena por fecha de modificación las carpetas de la web, sobre todo las de subidas, temas y plugins o módulos. Un archivo .php que no reconoces en una carpeta de imágenes es mala señal.
  4. Revisa los usuarios administradores. En WordPress o Drupal, mira si hay cuentas nuevas o con permisos que no diste.
  5. Si tienes VPS o servidor propio, quien lo administre debe revisar los registros de acceso desde el 17 de octubre con los indicadores del informe de AWS y buscar procesos raros lanzados por el usuario del servidor web.
  6. No bloquees esas IP a ciegas. Son de redes de anonimización que usa mucha gente. Si aparecen en tus registros, es una pista para investigar, no una prueba.
  7. Si encuentras algo, no basta con borrar el archivo: cambia contraseñas y claves guardadas en la web (base de datos, correo, pagos), restaura desde una copia anterior al 17 si la tienes y vigila en Search Console avisos de seguridad o páginas nuevas que no publicaste.

Relacionado: PHP2Shell: ya hay ataques contra PHP; qué hacer hoy

Fuentes

Actualizaciones: si PHP, AWS o el CERT de algún país publican cifras de webs comprometidas, se añadirán aquí con su enlace.