Octubre negro: PHP2Shell y la ola de ciberataques de 2026

El 21 de octubre de 2026 el proyecto PHP publicó una actualización de emergencia para dos fallos críticos que permiten ejecutar código en un servidor sin iniciar sesión. Los apodaron PHP2Shell, y llegaron en medio de una seguidilla de filtraciones y ataques que algunos usuarios en internet empezaron a llamar el octubre negro, una etiqueta que recoge el medio Bit Life Media y que no es un nombre técnico. Aquí resumimos qué pasó, qué está confirmado y qué no, y qué hacer hoy si tu sitio funciona con PHP.

Qué es PHP2Shell

PHP2Shell es el nombre que recibieron dos vulnerabilidades del motor de PHP: CVE-2026-109618 y CVE-2026-109619. Según el aviso oficial del proyecto PHP, ambas tienen una puntuación de 9.2 en la escala CVSS 4.0 y permiten ejecutar código de forma remota sin autenticación.

CVE-2026-109618

• Ejecución remota de código por corrupción al quedarse sin memoria
• PHP se interrumpe con datos de la solicitud a medio preparar
• La limpieza posterior trata esos datos como válidos
• Puntuación 9.2 en CVSS 4.0

CVE-2026-109619

• Ejecución remota de código por estado global obsoleto
• Datos de una solicitud sobreviven después de liberarse
• Otra solicitud del mismo proceso los puede usar
• Puntuación 9.2 en CVSS 4.0

El punto clave es que el fallo está en PHP, no en WordPress, Drupal, Laravel ni en un plugin. Cloudflare indica que afecta a los servidores web con PHP 5.4 o posterior, y el proyecto PHP señala que el riesgo es mayor con mod_php, la forma en que Apache ejecuta PHP dentro de su propio proceso.

Cómo se llegó a la publicación del parche

La línea de tiempo la reconstruyen la PHP Foundation y Recorded Future. El aviso estaba previsto para el 22 de octubre, pero varias filtraciones obligaron a adelantarlo un día.

1. 111 y 24 de agostoCalif y OpenAI reportan la causa de forma independiente; Wiz envía su reporte el 24.
2. 220 de octubreSe filtran los identificadores CVE y Calif publica por error un video de su prueba de concepto.
3. 321 de octubre, 03:02 UTCCloudflare activa reglas de su firewall de aplicaciones para todos sus planes.
4. 421 de octubre, 07:41 UTCChainguard publica imágenes con el parche antes de la fecha acordada.
5. 521 de octubre, 14:00 UTCPHP publica 8.5.12, 8.4.27, 8.3.36 y 8.2.35 con las correcciones.

Según la PHP Foundation, el primer indicio del problema de memoria apareció en 2024 durante una auditoría externa, pero en ese momento el riesgo de explotación era solo teórico. Las versiones 8.1 y anteriores ya no tienen soporte oficial; aun así, el proyecto publicó parches mínimos para PHP 7.4, 8.0 y 8.1, pensados para quien compila desde el código fuente o no tiene un proveedor con soporte extendido.

Qué está confirmado y qué no

Cloudflare informó que observó tráfico de ataque dirigido a sus clientes y que los atacantes modificaban sus solicitudes para intentar saltarse sus protecciones. Recorded Future cita a Patchstack, que recibió avisos de explotación de proveedores de hosting la mañana del 21 de octubre.

Al mismo tiempo, la PHP Foundation dijo que no identificó exploits funcionales al momento de publicar el parche, y Recorded Future aclara que el alcance real de los compromisos todavía no está establecido.

Qué hacer hoy si tu sitio usa PHP

1. 1Confirma tu versiónEn hosting compartido, pide a tu proveedor que confirme que tu PHP tiene ambos parches.
2. 2Actualiza y reiniciaEn un VPS, instala la versión corregida y reinicia PHP-FPM o Apache.
3. 3Mitiga si no puedes actualizar yaDesactiva session.upload_progress.enabled en php.ini y reinicia: reduce la exposición, no la elimina.
4. 4Revisa desde el 20 de octubreBusca actividad extraña en los registros y cambia las credenciales si sospechas un compromiso.

Dos detalles importan. Primero, el proyecto PHP advierte que esa configuración no funciona si se cambia con ini_set() o con un archivo .user.ini: debe ir en php.ini o en la configuración del servidor. Segundo, actualizar PHP no elimina una puerta trasera si el sitio ya fue comprometido antes del parche.

Si tu sitio usa PHP 7.4, 8.0 u 8.1, este es el momento de planear la migración: WP Cerber recuerda que el soporte de seguridad de PHP 8.2 termina el 31 de diciembre de 2026, así que conviene saltar a 8.3 o posterior, con copia de seguridad y pruebas antes.

El resto del octubre negro

PHP2Shell no llegó solo. En las mismas semanas se acumularon otros incidentes, aunque no hay evidencia de que formen una campaña coordinada:

• LiteLLMLa versión 1.107.0 se publicó con malware que robaba credenciales y estuvo disponible unas dos horas.
• RailwayUn tercero pudo acceder a variables de entorno de clientes, algunas ya descifradas.
• eMudhraOcho certificados intermedios con claves débiles; la empresa sale del negocio de certificados TLS.
• Agentes de IA atacandoReuters y CrowdStrike documentan campañas que usan agentes de IA para vulnerar sitios y empresas.

En el caso de LiteLLM, una herramienta muy usada para conectar aplicaciones con modelos de IA, Datadog Security Labs explica que los atacantes usaron tokens robados de tres ingenieros para publicar la versión maliciosa; la versión segura es la 1.106.2. Railway, por su parte, pausó los despliegues y pidió a todos sus usuarios cambiar las variables de entorno que guardan en la plataforma.

La IA, de los dos lados

La inteligencia artificial aparece en ambos lados de esta historia. Del lado de la defensa, Recorded Future indica que Wiz encontró el primer fallo con herramientas asistidas por IA, y la PHP Foundation confirma que Calif y OpenAI reportaron la misma causa de forma independiente.

Del lado del ataque, Reuters reportó una campaña en la que un atacante usó agentes de IA para intentar entrar a más de 1.200 sitios y logró acceder a los de más de 100 empresas, y CrowdStrike documentó cuatro grupos que usaron Claude Code para vulnerar empresas. La conclusión práctica es la misma: los fallos se encuentran y se explotan más rápido, así que el tiempo entre un parche y su instalación importa más que nunca.

Qué significa para tu sitio

Si tu sitio corre en WordPress o en cualquier aplicación PHP, lo urgente es confirmar hoy la versión de PHP con tu proveedor. Si tu sitio es una aplicación en código cuyas páginas se generan antes de la visita, como explicamos en de WordPress a código: por qué la seguridad de PHP nos hizo migrar, estos dos fallos no le aplican porque el servidor no ejecuta PHP. Eso no lo vuelve invulnerable: sus dependencias también necesitan actualizaciones, como muestra el caso de LiteLLM. Para las medidas básicas que protegen a cualquier negocio, más allá del servidor, lee nuestra guía de seguridad digital para pymes.

En desarrollo web contamos cómo construimos y mantenemos sitios con esas actualizaciones bajo control.

Fuentes

• PHP: aviso de seguridad del 21 de octubre de 2026 sobre CVE-2026-109618 y CVE-2026-109619
• PHP Foundation: la publicación de seguridad de hoy
• Cloudflare: protección del WAF frente a las vulnerabilidades de PHP
• Recorded Future: explotación de PHP2Shell
• WP Cerber: lo que deben saber los dueños de sitios WordPress
• Datadog Security Labs: LiteLLM comprometido en PyPI y Docker
• Railway: aviso de seguridad del 21 de octubre
• CyberScoop: eMudhra cierra su negocio de certificados
• Reuters vía BNN Bloomberg: agentes de IA contra decenas de sitios
• CrowdStrike: nuevas campañas con IA agéntica
• Bit Life Media: octubre negro en ciberseguridad