PHP2Shell: la carrera contrarreloj – qué significan los fallos de PHP para los sitios web, los dispositivos y tus datos

Dos fallos críticos en PHP, un embargo roto antes de tiempo e intentos de ataque incluso antes de la divulgación oficial: PHP2Shell no afecta únicamente a los sitios web tradicionales. El entorno de ejecución vulnerable también puede estar integrado en firewalls, paneles de control de alojamiento y otros dispositivos. Explicamos de forma clara qué ocurrió, quién debe actuar y qué deberías hacer realmente como usuario particular.

El 20 de octubre aparecieron en internet dos números que en un primer momento parecían poco llamativos: CVE-2026-109618 y CVE-2026-109619. Tras ellos se encontraban dos vulnerabilidades de PHP que aún no se habían divulgado por completo. PHP es la tecnología que procesa formularios, consulta bases de datos y genera páginas en innumerables servidores web.

La divulgación debía seguir un proceso ordenado: primero las actualizaciones y las reglas de protección preparadas, y después los detalles técnicos. Sin embargo, los identificadores se hicieron públicos antes de tiempo, comenzó a circular una puntuación máxima errónea de 10,0 y esa misma tarde se publicó por error un vídeo que mostraba un ataque funcional. PHP adelantó el lanzamiento un día.

Demasiado tarde para un comienzo tranquilo: Amazon descubrió posteriormente un intento de explotación fechado el 17 de octubre, cuatro días antes del parche. Tras la divulgación, los proveedores registraron una oleada de ataques que crecía con rapidez; Reuters, citando a Cloudflare, informó de millones de intentos en pocas horas. No fueron millones de intrusiones exitosas, pero la cifra demuestra la rapidez con la que hoy se prueban de forma automatizada las vulnerabilidades críticas.

La vulnerabilidad en sí no está en tu smartphone. Aun así, puede afectarte a través de datos almacenados por un proveedor, sitios web manipulados, campañas de phishing más creíbles o servicios desconectados por precaución. Tu dispositivo puede estar limpio mientras tus datos corren peligro en un servidor ajeno.

Lo más importante

PHP2Shell designa dos fallos de seguridad de memoria en el núcleo de PHP. En determinadas condiciones, un atacante puede ejecutar código en un servidor sin iniciar sesión; una de las vulnerabilidades también puede exponer contenidos de la memoria con tokens de sesión, contraseñas, claves de API o credenciales de bases de datos. Ambas CVE tienen una puntuación de 9,2 según CVSS 4.0.

Las ramas upstream están corregidas a partir de PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las ramas más antiguas pueden recibir correcciones retroportadas por distribuciones, proveedores de alojamiento o proveedores LTS. Actualizar únicamente el CMS o un plugin no basta: lo decisivo es el entorno de ejecución de PHP que procesa realmente las solicitudes web.

Los usuarios particulares no tienen que instalar nada en el teléfono. Los operadores deben inventariar y parchear sitios web, contenedores, interfaces de administración y dispositivos que utilicen PHP, además de investigar posibles ataques anteriores.

1. Cómo un antiguo problema de memoria se convirtió en una carrera mundial contrarreloj

2024: una señal de alarma sin un ataque demostrado

La historia comenzó ya en 2024. Durante una auditoría externa de seguridad de PHP aparecieron los primeros indicios de lo que más tarde se convertiría en el problema de falta de memoria. Sin embargo, no existía una vía fiable desde una solicitud web hasta la ejecución de código, y las posibles correcciones amenazaban con afectar a la compatibilidad o la estabilidad. El pequeño equipo de seguridad no alcanzó rápidamente un consenso. Más tarde, la PHP Foundation describió abiertamente el retraso como un fallo estructural: los procesos de decisión eran demasiado pesados y los recursos demasiado escasos.

Verano de 2026: la investigación asistida por IA convierte la teoría en práctica

En julio y agosto de 2026, Calif, OpenAI y Wiz examinaron el núcleo de PHP mediante métodos tradicionales y potentes modelos de IA. El 11 de agosto se notificó una vía concreta hacia la Remote Code Execution; Wiz encontró de forma independiente otras variantes y demostró cadenas de ataque contra aplicaciones PHP reales. La intervención humana seguía siendo necesaria para reproducir los resultados, descartar falsos positivos y revisar los parches. Aun así, la IA acortó la búsqueda y, con ella, el tiempo del que disponen los defensores tras la divulgación de una vulnerabilidad.

17 de octubre: el primer intento conocido

Amazon Threat Intelligence identificó posteriormente en la telemetría de MadPot un intento de explotación fechado el 17 de octubre. Una detección en un honeypot no demuestra que sistemas reales fueran comprometidos con éxito, pero hace retroceder la ventana de análisis forense. Se desconoce cómo obtuvo el actor suficiente información tan pronto; no existe una atribución fiable.

20 y 21 de octubre: se rompe el embargo y llega el parche

El 20 de octubre comenzaron a circular públicamente los identificadores CVE, junto con la puntuación CVSS errónea de 10,0 y un vídeo de ataque publicado por error. PHP adelantó el lanzamiento al 21 de octubre a las 14:00 UTC. Proveedores de alojamiento, distribuciones y empresas de seguridad prepararon paquetes y filtros en paralelo. Cloudflare activó reglas de protección antes del lanzamiento, combinando señales de las solicitudes y las respuestas. Aun así, un WAF sigue siendo únicamente una barrera adicional: no corrige el código PHP vulnerable.

Las versiones corregidas se publicaron el 21 de octubre; poco después aparecieron herramientas públicas de ataque y escaneos masivos. Organismos públicos, hospitales, universidades y empresas desconectaron servicios de forma preventiva, incluidos temporalmente servicios policiales de Berlín y Brandeburgo. Esto no demuestra una intrusión, sino que puede reflejar un proceso de emergencia que funciona: es preferible quedar fuera de línea de forma controlada que seguir comprometido sin control. PHP2Shell también deja claro que los sistemas accesibles desde internet deben reaccionar ante fallos críticos de RCE en horas, no en días.

Están confirmadas dos vulnerabilidades críticas en PHP, intentos activos de explotación y una superficie potencial de ataque muy amplia. Sigue sin saberse cuántos sistemas fueron comprometidos realmente o cuántos datos se perdieron.

2. Qué falla técnicamente – sin jerga innecesaria

PHP trabaja en la sala de máquinas de un sitio web: ejecuta el código de WordPress, tiendas o portales, procesa entradas y se comunica con bases de datos. Los fallos se encuentran por debajo de la capa del CMS. Por ello, una aplicación completamente actualizada puede seguir funcionando sobre un entorno de ejecución de PHP vulnerable.

CVE-2026-109618: limpiar datos incompletos

Si PHP alcanza su memory_limit en un momento desfavorable, el procesamiento puede interrumpirse mientras algunas estructuras de datos internas solo están parcialmente inicializadas. Durante la limpieza, PHP puede tratar esas áreas como datos válidos. Un atacante intenta provocar deliberadamente este estado e influir en la disposición de la memoria para lograr la ejecución de código.

Se ha demostrado un ataque no autenticado en Apache con mod_php que puede actuar antes de que se ejecute el propio código de la aplicación. En ese caso, el inicio de sesión, la autenticación de dos factores o un plugin de seguridad de WordPress no protegen. También pueden verse afectados otros modos de ejecución de PHP; los requisitos y la fiabilidad varían según la SAPI, la aplicación y la configuración.

CVE-2026-109619: una referencia obsoleta sobrevive a la siguiente solicitud

En la segunda vulnerabilidad, tras un error grave permanece una referencia a una zona de memoria que ya se ha liberado. Cuando el mismo worker de PHP procesa una solicitud posterior, vuelve a acceder a ese estado obsoleto: un use-after-free o estado global desactualizado.

Las consecuencias pueden incluir ejecución de código, fallos del sistema o exposición del contenido de la memoria. Esta última resulta especialmente peligrosa: un atacante no necesita dejar una web shell visible para obtener tokens de sesión, contraseñas de bases de datos, claves de API o certificados. Por tanto, después de aplicar el parche no basta con buscar únicamente archivos modificados.

Remote Code Execution significa, en primer lugar, ejecutar código con los privilegios de la cuenta de PHP o del servidor web, no obtener automáticamente acceso root. Esa cuenta puede, no obstante, leer configuraciones, acceder a bases de datos o comunicarse con servicios internos. Los permisos de archivos, la segmentación de red y el principio de mínimo privilegio determinan hasta dónde puede avanzar una intrusión.

3. ¿Está realmente afectado casi el 70 % de internet?

A 23 de octubre de 2026, W3Techs indica que PHP se utiliza en el 69,3 % de los sitios web cuyo lenguaje de programación del lado del servidor puede identificar el servicio. Dentro de esos sitios PHP, el 65,3 % utiliza PHP 8, el 26,9 % PHP 7 y el 7,7 % PHP 5.

Estas cifras describen la adopción, no el estado de los parches ni los ataques exitosos. Muchos sistemas se actualizaron en cuestión de horas, las distribuciones ofrecen backports con números de versión más antiguos y, en los dispositivos, la vía vulnerable puede no ser accesible públicamente. La conclusión razonable es, por tanto, la siguiente: alrededor de siete de cada diez sitios con un lenguaje del lado del servidor identificable utilizan PHP y tuvieron que revisar sus defensas. No es posible cuantificar con rigor cuántos siguen siendo vulnerables o están comprometidos hoy.

4. Qué significa PHP2Shell para ti como usuario particular

PHP no infecta directamente tu dispositivo

PHP2Shell se ejecuta en servidores. No necesitas restablecer tu smartphone ni instalar una aplicación especial. El riesgo para tu dispositivo solo aparece si un sitio manipulado te convence para descargar algo malicioso. Mantén actualizados el sistema, el navegador y las aplicaciones, y utiliza únicamente fuentes de confianza. Una supuesta “actualización de PHP2Shell” para tu dispositivo probablemente sea un señuelo.

Tus datos pueden verse afectados de todos modos

Cuando compras en una tienda online, tu nombre, dirección e historial de pedidos pueden permanecer almacenados durante mucho tiempo. Si el servidor se ve comprometido, esos datos pueden resultar afectados aunque no hayas visitado el sitio en meses. La exposición de memoria también puede revelar tokens y claves de acceso que no existen como archivos en el servidor.

Incluso un sitio conocido puede ser manipulado: el dominio y el icono del candado permanecen iguales mientras un script inyectado roba datos de acceso o de pago. HTTPS protege el trayecto hasta el servidor, no la integridad del propio servidor. Interrumpe la operación ante ventanas de pago inusuales, redirecciones o descargas inesperadas y contacta con el proveedor por una vía conocida.

Después del ataque técnico suele llegar el fraude

Los datos robados hacen que el phishing resulte más creíble. Incluso un mensaje con tu nombre real y el número de pedido correcto puede ser falso. Abre los servicios importantes mediante la aplicación oficial, un marcador o una dirección escrita manualmente. Entre las señales de secuestro de una cuenta se encuentran los avisos inesperados de inicio de sesión o restablecimiento de contraseña, las sesiones desconocidas, los datos de recuperación modificados y las solicitudes push, TAN o de autenticación de dos factores que tú no has iniciado. No apruebes nada “por seguridad”; revisa directamente la cuenta y elimina los dispositivos desconocidos.

En la banca online, una contraseña o un PIN normalmente no bastan por sí solos gracias a la autenticación reforzada del cliente. Sin embargo, el phishing puede inducirte a aprobar una autorización real para el acceso o el pago de otra persona. Comprueba el destinatario, el IBAN y el importe; ante operaciones desconocidas, contacta con el banco mediante la aplicación oficial o un número conocido.

Qué puedes hacer ahora

Si un servicio informa únicamente de mantenimiento o de una desconexión preventiva, no necesitas cambiar contraseñas indiscriminadamente ni bloquear tarjetas. Utiliza una vía alternativa oficial y sigue las comunicaciones del proveedor.

Si un proveedor informa de una posible exposición de credenciales de acceso, cambia la contraseña en ese servicio y en todos los demás en los que la hayas reutilizado. Cierra las sesiones activas, habilita la autenticación de dos factores o las passkeys y presta especial atención a la seguridad de tu cuenta de correo electrónico.

Si has introducido datos en un sitio sospechoso o instalado una supuesta aplicación de seguridad, protege tus cuentas desde otro dispositivo, contacta con el banco si hay datos de pago implicados y haz revisar el dispositivo afectado.

Ninguna aplicación de seguridad ni ninguna VPN pueden reparar el entorno de ejecución de PHP de la tienda online de un tercero. El software de protección puede ayudar frente a la segunda oleada de ataques con descargas maliciosas, aplicaciones falsas y sitios dañinos conocidos, pero no garantiza que los datos almacenados en un servidor ajeno estén seguros.

5. PHP también está presente en firewalls, sistemas NAS y otros dispositivos

PHP no se encuentra únicamente en sitios web, sino también en interfaces de administración y servicios adicionales de firewalls, routers, sistemas NAS, paneles de control de alojamiento, instalaciones VoIP, grabadores de cámaras y appliances industriales. Un producto solo está afectado si utiliza una versión vulnerable de PHP para procesar solicitudes web accesibles. También importan el nivel de exposición y la disponibilidad de un parche del fabricante.

pfSense: Netgate confirmó que la interfaz gráfica basada en PHP y el portal cautivo están afectados. La interfaz predeterminada suele ser accesible únicamente desde la LAN; un portal cautivo atiende de forma intencionada a clientes no confiables. Por tanto, el mismo fallo presenta riesgos distintos según su exposición.

Palo Alto Networks: determinadas versiones de PAN-OS y Panorama están afectadas. Según el fabricante, el problema afecta a la interfaz web de administración, incluida la API XML, pero no de forma general al plano de datos ni a GlobalProtect. Hasta instalar la corrección, la administración debería ser accesible solo desde redes de confianza o mediante un jump host controlado.

Plesk: los sitios de los clientes utilizan sus propios handlers PHP, mientras que la interfaz de Plesk emplea un motor independiente. Actualizar solo una capa puede dejar olvidada la otra. Por eso, Plesk publicó actualizaciones para ambos componentes.

Cisco y Sophos muestran por qué los productos, los servicios en la nube y las instalaciones de los clientes deben evaluarse por separado. Cisco confirmó que algunas familias de productos estaban afectadas, clasificó otras como no afectadas y continuaba investigando productos adicionales. Sophos declaró que sus productos no estaban afectados, pero desconectó temporalmente el antiguo portal MyUTM, alojado por separado, porque utilizaba una versión vulnerable de PHP.

El NCSC neerlandés mantiene una lista de estado actualizada de forma continua. Es un inventario valioso, pero no sustituye al aviso más reciente del fabricante: una dependencia de PHP no demuestra por sí sola que la vulnerabilidad sea explotable, y la ausencia de un aviso no significa que no exista riesgo.

Qué debes comprobar en un dispositivo doméstico o empresarial

Anota el fabricante, el modelo, el firmware y los paquetes adicionales. Busca ambas CVE y “PHP2Shell” en el sitio oficial de soporte e instala las actualizaciones únicamente mediante la función prevista para firmware o paquetes. Nunca sustituyas por tu cuenta el PHP integrado; los appliances suelen contener adaptaciones del fabricante y componentes firmados.

Desactiva la administración remota desde la WAN, los reenvíos de puertos y las aperturas UPnP innecesarios, y revisa los accesos remotos a través de la nube. Si necesitas acceso externo, utiliza una VPN siempre que sea posible y abre la interfaz local solo después de conectarte.

Separa las redes de invitados, IoT y administración para que los dispositivos comprometidos no puedan alcanzar servicios de gestión locales. Si un firewall, un NAS o un grabador de cámaras deja de recibir actualizaciones de seguridad, sustituirlo suele ser la única solución sostenible.

6. Qué deben hacer ahora los operadores

Paso 1: aclarar responsabilidades e inventariar los activos

En el alojamiento gestionado, normalmente es el proveedor quien realiza la actualización; en VPS, servidores dedicados, contenedores y appliances, la responsabilidad recae en ti o en tu proveedor de servicios. Exige una respuesta verificable sobre ambas CVE, la versión del paquete o del firmware y el reinicio de todos los procesos PHP. Al mismo tiempo, inventaria dominios, subdominios, entornos de staging, proyectos antiguos, webmail, contenedores y dispositivos con PHP integrado.

Paso 2: comprobar el nivel de parche correcto

PHP 8.5.12 · PHP 8.4.27 · PHP 8.3.36 · PHP 8.2.35. Hay backports del código fuente disponibles para PHP 7.4, 8.0 y 8.1; el aviso de la distribución o del proveedor LTS es la referencia válida.

Las distribuciones pueden retroportar correcciones a versiones de paquetes anteriores. Ubuntu 24.04 LTS, por ejemplo, indica que 8.3.6-0ubuntu0.24.04.13 está corregida; cPanel también distribuyó backports. Compara, por tanto, la versión completa del paquete con el aviso de la distribución o del proveedor de la plataforma, no únicamente con el número upstream aislado.

Paso 3: verificar el entorno de ejecución realmente activo

php -v suele mostrar únicamente la versión de línea de comandos. El servidor web puede utilizar otra instalación mediante PHP-FPM, mod_php o un contenedor. Comprueba, por tanto, los pools FPM, los módulos del servidor web, los hosts virtuales y las imágenes:

php -v
php -r 'echo PHP_VERSION, " | ", PHP_SAPI, PHP_EOL;'
systemctl list-units --type=service 'php*-fpm.service'

Después de la actualización, los workers antiguos deben sustituirse: con mod_php, normalmente reiniciando el servidor web; con PHP-FPM, reiniciando los pools. Reiniciar un contenedor con la misma imagen no sirve; la imagen debe actualizarse y desplegarse de nuevo.

Paso 4: impedir que las solicitudes lleguen a PHP en sistemas que no pueden parchearse

Si no puedes aplicar el parche de inmediato, limita el acceso a redes de confianza o a una VPN, o desconecta el servicio. Un plugin de mantenimiento de WordPress no protege si el ataque actúa antes de que se ejecute el código de la aplicación. Utiliza una página de mantenimiento estática o bloquea el acceso en el proxy inverso, el balanceador de carga o el servidor web.

Las reglas de WAF y CDN pueden ganar tiempo, pero no son un parche. Cloudflare observó patrones de ataque cambiantes y tuvo que evaluar conjuntamente las solicitudes y las respuestas. Asegúrate también de que el servidor de origen no sea accesible directamente mediante una segunda dirección IP o un nombre de host alternativo.

Las medidas de configuración de PHP, como desactivar el progreso de carga de sesiones o imponer límites más estrictos de memoria y carga, solo reducen determinadas vías de ataque y pueden tener efectos secundarios.

Paso 5: revisar al menos hasta el 17 de octubre

Conserva los registros del servidor web, PHP, proxy, WAF, sistema y contenedores antes de que roten. Busca solicitudes de formularios inusuales, PHP_SESSION_UPLOAD_PROGRESS, errores de memoria, procesos shell inesperados, archivos nuevos, cuentas, tareas cron y conexiones salientes. Un ataque exitoso no tiene por qué bloquear el worker; a la inversa, un único error no demuestra una intrusión. Lo decisivo es el conjunto de indicios.

Paso 6: rotar los secretos accesibles para PHP

Dado que puede exponerse el contenido de la memoria, en sistemas accesibles desde internet que permanecieron sin parche debes rotar todos los secretos que el proceso PHP podía leer, como contraseñas de bases de datos, tokens de API, nube y despliegue, credenciales SMTP u OAuth y claves de sesión. Corrige o aísla primero el sistema afectado y genera después nuevas credenciales desde un entorno de confianza.

Paso 7: ante indicios de intrusión, no limitarse a “limpiar”

Si existen indicios de compromiso, aísla el sistema de forma controlada, conserva los registros y, cuando proceda, los datos volátiles, y reconstruye los hosts críticos a partir de artefactos de confianza en lugar de limitarte a eliminar los archivos visibles. Revisa también las cuentas de administración y de bases de datos, las canalizaciones de despliegue y los sistemas conectados. Si pueden verse afectados datos personales, implica pronto a los responsables de protección de datos; según el RGPD, una violación sujeta a notificación debe comunicarse, por regla general, en un plazo de 72 horas.

7. La lección general: el descubrimiento se acelera y la corrección debe seguir el ritmo

PHP2Shell muestra cómo la IA desplaza la frontera entre lo “teóricamente posible” y lo “explotable en la práctica”. Los modelos pueden analizar a gran escala código fuente, rastros de fallos y diferencias entre parches; como resultado, también se acorta el intervalo entre la divulgación y la aparición de código de explotación funcional.

La respuesta no consiste simplemente en utilizar más IA. Los mantenedores necesitan recursos y procesos de decisión claros. Los operadores necesitan inventarios completos, ciclos de parcheo rápidos, aislamiento y procedimientos de recuperación ensayados. En Protectstar utilizamos IA junto con revisiones de código y validación humana. Acelera el descubrimiento, pero no sustituye la responsabilidad.

Conclusión

PHP2Shell afecta a servidores, pero puede llegar hasta ti como riesgo para los datos, intento de fraude o interrupción de servicio. Mantente alerta, sin caer en el pánico: utiliza canales de contacto oficiales, no apruebes solicitudes inesperadas y reacciona de forma específica a los avisos de los proveedores afectados.

Para los operadores, lo decisivo es el entorno de ejecución de PHP realmente activo, cada instancia olvidada, los componentes integrados, el reinicio de procesos antiguos y la revisión retrospectiva al menos hasta el 17 de octubre. Si no existe un parche, el aislamiento es más responsable que mantener el servicio en funcionamiento. Que un sitio sea accesible no demuestra que sea seguro.