PHP2Shell: el balance tres días después, cuando el infocon volvió a verde

Cuando el viernes 23 de octubre SANS Internet Storm Center volvió a bajar su nivel de alerta a verde, medio mundo lo leyó como “se acabó”. Y en parte es verdad: la ventana de emergencia de PHP2Shell se cerró, el parche se publicó a la hora pactada y las distribuciones ya lo están empaquetando. El problema es que el mismo post que bajaba la alerta decía, textual, que “the risk is real, even if we did not see immediate mass exploitation. That part is still to come; it is just delayed”. Ese es el patrón de siempre: la señal de tráfico baja antes que la amenaza, y el trabajo de sysadmin no termina cuando alguien baja la bandera. Ahí es cuando empieza la parte que decide si tu servidor termina con un webshell o intacto.

Este post es el cierre de esa historia, no otra explicación del CVE. Ya escribí sobre el vector de session.upload_progress.enabled, sobre qué protege y qué no el WAF de Cloudflare, y sobre el ruido de los miles de PoC que circulaban. Faltaba la pregunta posterior: con el parche fuera y el exploit todavía sin existir, qué se hace el lunes 26 de octubre a las nueve de la mañana en una operación real. Eso es lo que desarmo aquí, con los comandos y los números reales.

Qué pasó estos tres días: la cronología sin adornos

El punto de partida real de esta historia no es el 21 de octubre. Es el 17 de octubre: cuatro días antes de que nadie hablara públicamente de PHP2Shell, Amazon Threat Intelligence ya había detectado un intento de explotación en su honeypot MadPot, desde una IP asociada a una red de anonimización comercial. Eso cambia la pregunta de “cuándo parcheo” a “desde cuándo investigo”, y esa diferencia es la que separa a una operación que cierra el caso de una que lo deja abierto.

Armé la línea de tiempo con las fuentes primarias para no TERMINAR con una versión recortada:

Fecha y hora (UTC)	Qué pasó	Fuente
17-oct-2026	Amazon Threat Intelligence detecta un intento de explotación de PHP2Shell en su honeypot MadPot desde la IP 103.216.220.92, cuatro días antes de la divulgación	AWS Security Blog
20-oct-2026	PHP anuncia un release de seguridad con aviso previo para el 21 de octubre a las 14:00 UTC	php.net
21-oct-2026, 03:02	Cloudflare activa por defecto las reglas WAF contra php2shell para clientes con WAF, gratis y de pago, el mismo 21 de octubre y antes de que se levantara el embargo	Cloudflare Blog
21-oct-2026, 02:00 a 08:00	Amazon identifica varios PoC circulando y ataques adicionales desde infraestructura de anonimización distinta, con payloads que varian (indicio de varios actores)	AWS Security Blog
21-oct-2026, 14:00	Se levanta el embargo y salen PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35	php.net
21-oct-2026	SANS sube el infocon a Yellow por CVE-2026-109618 y CVE-2026-109619; CISA publica su alerta pidiendo parcheo inmediato	SANS ISC, CISA
22-oct-2026	Fortinet actualiza la lista de productos bajo investigación en el aviso FG-IR-26-186 y agrega referencias de IPS	Fortiguard PSIRT
23-oct-2026, 13:43	SANS vuelve a infocon Green y publica el wrap-up; PHP publica el aviso informativo de CVE-2026-115560; CERT-EU publica la v1.2; CISA actualiza su alerta y suma una regla SIGMA de detección	SANS ISC, php.net, CERT-EU, CISA
26-oct-2026	PHP publica builds de Windows con sufijo -1 (8.5.12-1, 8.4.27-1, 8.3.36-1, 8.2.35-1) que incluyen Brotli 1.2.1; CISA añade CVE-2026-109618 y CVE-2026-109619 a su catálogo KEV de vulnerabilidades con explotación confirmada	php.net, CISA
5-nov-2026 (previsto)	PHP 8.6.0 RC5, el último release candidate; RC4 ya incluye los arreglos de las dos RCE	php.net

Un detalle de la tabla que cambia el diagnóstico: el WAF de Cloudflare estuvo activo antes de que se levantara el embargo (Cloudflare afirma que desplegó sus protecciones “about 9 hours ahead of public disclosure”), y Amazon ya veía PoC desde las 02:00 UTC de ese mismo día, doce horas antes de las 14:00. El reloj de la calma pública nunca fue el reloj real del atacante.

Por qué el infocon volvió a verde si el riesgo sigue ahí

El inficon de SANS no mide si tu servidor está parcheado. Mide cambios en el tráfico malicioso y en la posibilidad de que se disrupta la conectividad. El propio documento del inficon lo define así: “the Infocon is intended to apply to the condition of the Internet infrastructure”. Cuando lo bajan, lo que baja es la señal. Tu postura de seguridad no cambia por decreto de nadie.

El rubric de puntuación que usan está publicado y explica por qué el evento se punteó a Yellow: suma puntos por ejecución remota de código, por falta de parche o mitigación efectiva, por explotación activa, por afectar software en su versión actual, por estar ampliamente desplegado y por haber PoC disponible, y resta un punto cuando el vendor ya publicó un advisory con un workaround decente. Seis puntos o más mueven el infocon a Yellow, y diez a Orange. Yellow fue exactamente el nivel que justifica la cobertura del evento, y el historial oficial de SANS lo registra como el primer Yellow desde log4j en diciembre de 2021, sin ningún evento de PHP anterior en la lista publicada.

La lectura correcta del wrap-up no es “ya pasó”. Es esta: la divulgación coordinada funcionó, los parches salieron, y el 23 de octubre todavía no había un exploit público confiable, aunque Amazon ya reportaba explotación amplia contra sus sensores y varios actores decían tener código funcional en la manga. El 26 de octubre el balance dio un vuelco: CISA metió ambos CVE en su catálogo KEV, la lista de vulnerabilidades con explotación confirmada en la naturaleza. El propio Johannes Ullrich lo dice: “Vulnerability disclosure worked in this case. Patches were available. There will likely be many more vulnerabilities of similar severity that will be released and exploited with less responsibility”. Este fue el escenario bueno: aviso coordinado, parche a la hora, sin fiasco de supply chain. El próximo puede ser peor.

Y hay un recordatorio que no se negocia: PHP sigue diciendo en su propio advisory que no hay mitigaciones completas y que actualizar es la única opción segura. Que el inficon esté verde no vuelve opcional el parche. Y SANS lo dice sin rodeos: los workarounds “may buy you more time”, y lo mismo aplica a las reglas de WAF. CERT-EU coincide en el fondo: reducen la exposición a rutas de ataque específicas, pero no hacen segura una instalación sin parche.

El exploit público que todavía no es confiable: qué analizaron en SANS

Aquí está el dato más valioso de la semana y el que menos circuló. Johannes escribió que, hasta donde él sabía, no había exploit confiable público, aunque varias empresas afirmaban tener código funcional. Ese mismo día, otro handler del equipo, Bojan Zdrnja, publicó el análisis de fondo: construir un exploit universal y de un clic es bastante difícil. Su veredicto, textual: hay una cantidad increible de “AI generated – erm, slop” entre los PoC publicados, y los que sirven tienen precondiciones y hacen trampa.

El exploit funciona en tres fases, y cada una tiene un requisito concreto de configuración. Esto es lo que importa, porque convierte “hay un exploit de PHP” en una pregunta verificable sobre tu servidor:

• Fase 1, fuga de heap: provoca el agotamiento de memoria y filtra la base del Zend MM. El PoC envía 1001 campos de 3000 bytes más un campo de 12 MB, y exige memory_limit en 8 MB. En instalaciones reales el valor típico es 128 MB, lo que hace el disparo más exigente.
• Fase 2, defeat de ASLR: filtra la base de libphp.so para calcular direcciones de funciones. El truco es leer un puntero de código con offset estático respecto a la base de la librería, y los PoC públicos hacen trampa: leen los offsets de zval_ptr_dtor y zif_system directamente del libphp.so del servidor. Un atacante real necesita una tabla de offsets por distribución y versión.
• Fase 3, ejecución: reescribe el destructor del puntero para que apunte a la función de ejecución de comandos, con un límite de 14 bytes para el comando. La demo usa un pool prefork de un solo worker: en producción con varios workers el atacante tendría que agotar todos y liberar uno.

Traducido a operación: tu exposición a los PoC públicos depende de tu configuración, no solo de tu versión. Si tienes memory_limit en 128 MB y varios workers en el pool, el PoC que circula hoy no te sirve. Eso no es una defensa: es una demora. Y hay un segundo punto, más incómodo, en la misma nota de Zdrnja: el workaround se justifica porque, según él, “there apparently is a way to bypass even the (currently) available fix”, y por eso pide mantener la mitigación puesta hasta la próxima actualización.

Un matiz que no conviene perder: “no hay exploit público confiable” y “hay una enorme cantidad de intentos de ataque” no se contradicen. Un intento puede ser un escáner, un PoC roto o un ataque real. Por eso el número de intentos no te dice nada sobre tu estado: solo tu propio logging te lo dice.

Revisa tu pool antes que tu versión: el exploit tiene precondiciones

Si vas a sacar un solo comando de este post a la terminal del servidor, que sea este. El valor de memory_limit y el número de workers por pool definen si estás en el escenario fácil o el difícil del exploit público, y ninguna de las dos variables aparece en un php -v.

# El limite de memoria con el que corre PHP
grep -rn "memory_limit" /etc/php/8.3/fpm/php.ini
# Cuantos workers y de que tipo es cada pool
grep -rn "^pm" /etc/php/8.3/fpm/pool.d/www.conf
# La configuracion final que el pool realmente aplica
php-fpm8.3 -tt | grep -E "memory_limit|pm.max_children|pm = "

El -tt vuelca la configuración final antes de salir, la forma barata de confirmar que el valor que ves es el que aplica el worker y no el que quedó en el archivo. Si tu pool corre con un solo worker (prefork, o pm.max_children = 1 en cualquier modo), estás exactamente en el escenario del PoC público. Y si tu memory_limit está en 128 MB, el disparador de la fase 1 no se reproduce con el script que circula.

Nada de eso te salva, por dos razones. La primera: el lector de offsets del PoC es una comodidad, no una necesidad; alguien con tiempo puede construir la tabla para las combinaciones de distribución y versión más comunes. La segunda: el memory_limit no es lo único que puede fallar una asignación. El propio advisory de PHP lo dice al recomendar memory_limit = -1: “an underlying allocation failure can still reach the vulnerable path”. Ponerlo en infinito no es seguridad, es denegación de servicio.

Y hay una segunda verificación urgente que casi nadie tiene en la cabeza, porque es del vector descubierto después del parche. El 23 de octubre Cloudflare actualizó su nota con algo que no estaba en el anuncio original: la regla WAF que cubre CVE-2026-115560 protege a los clientes solamente si su sitio usa el nombre de campo por defecto de progreso de subida. Si cambiaste session.upload_progress.name, esa regla no te cubre. Y si además dejaste session.upload_progress.enabled en 1, tienes el vector abierto sin red de contención.

Investiga desde el 17 de octubre, no desde el 21

Amazon formula tres lecciones que aplican mucho más allá de este CVE. La primera es la que más duele cuando uno revisa logs a posteriori: un embargo solo protege a los defensores hasta que alguien más encuentra el mismo bug. La divulgación coordinada sigue siendo el modelo correcto, pero hay que dejar de asumir que la fecha de divulgación pública es la fecha más temprana de explotación. En PHP2Shell, el compromiso puede preceder al advisory, y aquí fue el 17 de octubre.

La segunda lección es de gestión, no de seguridad: “mide los tiempos de parcheo y mitigación en horas”. Una SLA de siete o treinta días asume un retraso que ya no existe, y con asistencia de IA es cada vez más barato convertir el diff de un parche o el texto de un advisory en un exploit funcional, así que más actores pueden actuar en horas una vez que los detalles técnicos se publican. La tercera: invierte en detecciones que no dependan de la firma de un CVE concreto, porque la primera explotación suele llegar antes de que esas firmas existan.

Traducido a comandos concretos en tu operación, la lista es esta:

# El campo de upload progress delata el intento de explotacion en tus logs de acceso
grep -c "PHP_SESSION_UPLOAD_PROGRESS" /var/log/nginx/access.log
grep "PHP_SESSION_UPLOAD_PROGRESS" /var/log/nginx/access.log | tail -20

Ese es el indicador que recomienda Amazon: peticiones POST con la cadena PHP_SESSION_UPLOAD_PROGRESS en los envíos de formulario. Es un campo de multipart, así que aparece en el log de acceso solo si tu formato de log incluye el cuerpo o los nombres de campo; si tu log solo guarda la línea de request, tienes que mirar el log de errores del servidor web.

# Errores de agotamiento de memoria y fatales: la huella del CVE-2026-109618
grep -i "allowed memory size" /var/log/php8.3-fpm.log | tail -30
grep -i "PHP Fatal error" /var/log/php8.3-fpm.log | tail -30

Y hay un segundo control que CISA pide explícitamente: las organizaciones que no pueden actualizar de inmediato, o que siguen en PHP 8.1 o anteriores sin soporte, deberían poner sus sistemas PHP fuera de línea hasta poder parchearlos. El tercero, que es el que separa un escaneo de una intrusión, es vigilar si los workers de PHP lanzan shells o descargan herramientas. En la práctica eso se ve como hijos inesperados del proceso de PHP, y como archivos ejecutables que no deberían existir en tu docroot.

# Procesos hijos directos de los workers de PHP
for pid in $(pgrep -f "php-fpm: pool"); do ps -o pid,cmd --ppid "$pid" --no-headers; done
# Archivos ejecutables creados o modificados en el docroot en los ultimos 3 dias
find /var/www -type f -mtime -3 -perm /111 -print

Sobre los IOCs, hay un matiz que se pierde si copias la lista a un bloqueo de firewall sin leer la fuente. Amazon publica seis direcciones y dice, textual, que son infraestructura de anonimización compartida y que hay que investigar las apariciones en vez de bloquearlas: bloquearlas te quita visibilidad de un actor que va a rotar de IP de todas formas. Las direcciones son 103.216.220.92, 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 y 95.217.98.37, con la primera observada el 17 de octubre y el resto el 21.

# IOCs de Amazon Threat Intelligence: investigar, no bloquear en bloque
for ip in 103.216.220.92 31.223.184.166 37.19.200.5 134.209.159.64 103.114.163.188 95.217.98.37; do
  echo "$ip"
  grep "$ip" /var/log/nginx/access.log | tail -5
done

Aísla los appliances que no vas a poder parchear

Hay un punto que se queda en la sombra de los titulares de CVE y donde se va a quedar buena parte del problema: los dispositivos embebidos y appliances que no van a recibir parche nunca. SANS lo dice sin rodeos: paneles de administración de routers, almacenamiento en red, cámaras, comederos automáticos para mascotas y refrigeradores no deberían estar expuestos a internet, y deberían estar aislados en redes internas. “A este punto, esto es el mínimo”, dice el texto, corran PHP o no.

El motivo por el que esto pega justo ahora en PHP es que muchísimos firewalls y routers de código abierto están escritos en PHP: SANS lo advierte de forma explícita en la entrada donde levantó el infocon a Yellow, con la recomendación de esperar las actualizaciones de esos productos y de no exponer su panel a internet. Y no es un riesgo genérico de “dispositivos viejos”: en esa misma entrada SANS lista los boletines que publicaron esa semana Cisco, OPNsense, PfSense y Palo Alto Networks.

La segunda lección está en el aviso de Fortinet, FG-IR-26-186, publicado el 21 de octubre y actualizado los días 22, 23 y 26: los productos bajo investigación incluyen FortiDDoS, FortiSOAR y FortiSOAR PaaS, mientras que la lista de confirmados NO afectados incluye FortiOS, FortiWeb, FortiProxy, FortiClient EMS, FortiGate Cloud y FortiSandbox; FortiClient Cloud Services, por su parte, ya fue remediado por Fortinet y no requiere acción del cliente. Es decir: un vendor cuyo producto principal no está comprometido puede tener un producto lateral comprometido. Si tu inventario de appliances se hizo por marca y no por componente, tiene huecos.

La mitigación aquí no es un parche, es topología, y es la más barata de toda esta historia porque no depende de que nadie parchee nada:

# Paneles de administracion alcanzables en tu LAN (autorizado: tu propia red)
nmap -Pn -p 80,443,8080,8443 --open 192.168.1.0/24

Lo que buscas son paneles de administración de firewall, NAS y cámaras alcanzables desde la red de usuarios. El objetivo no es cerrarlos todos, es que el panel de un appliance viva en su propia VLAN de gestión, con acceso solo desde la red administrativa. Es un cambio de firewall que toma una tarde y elimina de una vez una categoría de problemas que ningún CVE va a resolver por ti.

Las cifras reales: qué mide Censys y cómo leerlas

Las estimaciones de exposición que circulan esa semana son distintas según quién las mida, y Vale la pena entender por qué. Censys mantiene un tablero público dedicado a php2shell, actualizado cada hora con sus propios escaneos. Tomo la instantánea del 26 de octubre de 2026:

• 42.292.050 servicios PHP vistos en una versión afectada en algún momento desde que empezó el seguimiento el 21 de octubre
• 32.445.775 siguen en una versión afectada en su escaneo más reciente
• 9.868.930 pasaron de una versión afectada a una corregida
• 346.261 de esos parches se resolvieron en las últimas 24 horas
• 58.365.773 servicios PHP adicionales (57% del total detectado) no revelan su versión y por eso no aparecen ni como vulnerables ni como parcheados
• 851.145 servicios que reportan versiones que nunca se publicaron quedan excluidos, porque son casi con seguridad honeypots

La lectura que importa es esta: de las respuestas versionadas que Censys vio en la última hora, el 71.9% seguían reportando una versión afectada, y el total de respuestas PHP en 24 horas fue de 320.971.528. La curva de parcheo va por detrás de la curva de ruido, y la diferencia entre ramas es enorme:

Rama	Servicios con versión	Servicios en la versión corregida	Adoptación del fix
PHP 8.5	3.117.109	2.334.211	74.9%
PHP 8.4	3.092.564	1.970.977	63.8%
PHP 8.3	7.544.377	3.634.549	48.2%
PHP 8.2	5.777.479	2.808.912	48.6%

Las dos ramas con más servicios desplegados, 8.3 y 8.2, son las que menos han parcheado, y la razón es la misma que en tu servidor: 8.2 sigue con soporte de seguridad hasta el 31 de diciembre de 2026 y su parche es el 8.2.35, así que ahí sí hay una actualización que aplicar; lo que no hay es un plan más allá de esa fecha, y para quien sigue en una versión anterior a 8.2.35 lo que toca es actualizar y, de paso, planear la migración. Para el que no está en esa rama, el número de servicios en 8.1 o anteriores es de 24 millones sin release oficial (PHP solo publicó backports de código fuente para 7.4, 8.0 y 8.1), y para PHP 7.4, la más común entre las que no tienen release, son 7.979.440 servicios.

Tres advertencias sobre cómo leer estas cifras, porque se usan mal todo el tiempo. Primera: son servicios, no máquinas ni organizaciones; un servidor puede alojar muchos sitios y se cuenta como varios. Segunda: los conteos basados en versión son un techo, no un piso, porque las distribuciones suelen aplicar backports sin cambiar el número de versión, así que hay sistemas parcheados que Censys sigue viendo como vulnerables. Y tercera: con el 57% de los servicios PHP de internet sin revelar su versión, el número real de afectados no es calculable con precisión. El dato de escala que sí ayuda a dimensionar: el advisory de Censys del 21 de octubre detectaba 6.292.667 hosts y 115.000.393 web properties corriendo PHP, los afectados se reparten en 233 países, y Estados Unidos concentra 10.312.927 servicios afectados, el país más golpeado por lejos. El resto de la exposición está desperdigada por el mundo, que es exactamente el perfil de quien no tiene un equipo de seguridad dedicado y por lo tanto necesita que el camino por defecto sea el parche.

Verifica tu mitigación y tu versión real antes de cerrar el caso

Un hallazgo habitual, y que en PHP es especialmente grave porque hay dos versiones en juego en cada servidor: el paquete instalado y la que realmente corre. Un php -v en tu terminal te muestra el intérprete de línea de comandos, que en un servidor con varios roles casi nunca es el mismo binario que atiende las peticiones web.

# El paquete de PHP instalado y su version
dpkg -l | grep -E "^ii  php" | awk '{print $2, $3}'
# La version del interprete de linea de comandos
php -v | head -1
# Y la version que ve un visitante real de tu sitio
curl -s https://tu-sitio.example.com/info.php | grep -i "PHP Version"

El info.php tiene dos advertencias que siguen causando incidentes: debe quedar fuera del docroot o protegido con autenticación, porque expone rutas del sistema y versiones exactas de cada módulo, y debe borrarse en el mismo minuto en que lo usas. Es la diferencia entre un phpinfo() público que le entrega a un escáner el mapa de tu stack, y nada.

Sobre el nombre del campo de progreso de subida, el detalle del 23 de octubre que menos se ha propagado, revisa dos cosas: que session.upload_progress.enabled esté en 0 aplicado a nivel administrativo, y que no hayas cambiado session.upload_progress.name a un valor propio. Si lo cambiaste, la regla WAF de Cloudflare que protege ese vector no te cubre.

Qué cambia en tu operación a partir de mañana

Si tuviera que dejar cinco acciones concretas para un equipo que expone su backend con PHP en internet, serían estas, en orden:

1. Investiga desde el 17 de octubre. No desde el 21, ni desde el día que leíste la noticia. Empieza el hunting de logs en esa fecha y trata lo que encuentres como incidente hasta demostrar lo contrario.
2. Parchea en horas, no en días. Tu SLA de siete o treinta días es un residuo de otra época. Con asistencia de IA es más barato convertir un advisory en exploit, el tiempo entre el parche y el exploit funcional se está acortando por razones estructurales, y esa es la métrica que hay que mover.
3. Construye detección conductual. Workers de PHP que lanzan shells, descargas de herramientas, archivos ejecutables nuevos en el docroot, errores de memoria en el log. Nada depende de conocer el CVE.
4. Actualiza el inventario para incluir appliances. Firewalls, NAS, cámaras, paneles de terceros. Con la marca y el componente, no con la marca sola.
5. Aisla lo que no puedes parchar. CERT-EU lo dice así: si no es factible parchear de inmediato, aísla de la red pública las aplicaciones expuestas a internet hasta que la corrección esté aplicada y verificada. Es lo que distingue una operación que se gobierna de una que espera.

Y una cosa de fondo que el wrap-up de SANS deja como cierre y que me parece la más útil de todas: “many partial exploits have been released. Be careful; some of them may be parasitic, trying to exploit whoever runs them”. Si vas a probar un PoC para ver si aplica a tu entorno, recuerda que ese script viene de internet y va a correr con tus permisos. Aísalo en una máquina desechable, en una red que no sea la de producción, y asumí que el PoC puede intentar metasploitearte a ti.

Vale la pena, y para quién

Para un servidor propio con FPM o mod_php, esto fue trabajo de una tarde un martes, y el resto de la semana fue desmontar ruido. Parchear, aplicar la mitigación que ya describí en detalle en el post sobre CVE-2026-115560, reiniciar los workers y revisar el pool: eso es todo. La parte de forense es una tarde, y su valor real no es encontrar un atacante, es saber con qué fecha empezar a mirar la próxima vez.

Para el hosting compartido el caso es distinto y más incómodo, porque tú no controlas el pool. Ahí la conversación con el proveedor no es “estoy en riesgo de RCE”, es “estoy en una versión que deja de recibir parches en menos de dos meses”, y ese es un argumento que la mesa de tickets entiende mejor. Mientras esperas, lo único bajo tu control es reducir exposición y verificar por HTTP que la directiva se ve en Off, sabiendo que puede llegar tarde al parseo de la petición.

Para el equipo que opera una flota, el entregable de esta semana no fue el parche, sino tres cosas que ahora existen en tu operación: una fecha de inicio de investigación que no es la del comunicado, una lista de detección que no depende de la firma de un CVE, y un inventario que incluye los appliances que nadie iba a contar. Eso es lo que se lleva la próxima vez que esto pase, que va a pasar.

Y para el resto, el escenario mayoritario en la lectura pública de esta historia: PHP2Shell fue, en los términos de Johannes, un ensayo general. La divulgación coordinada funcionó, los parches salieron a la hora y el exploit no existía todavía el 23 de octubre, cuando Johannes escribió el wrap-up. Ese fue el final bueno de esa etapa. La siguiente arranca con el KEV de CISA del 26 de octubre y con los actores que ya tienen el código en la manga. Vale la pena de que el próximo llegue con menos responsabilidad. De ahí la recomendación más simple del wrap-up, que es también la más difícil de cumplir: actualiza el parche, porque sigue siendo tu única defensa confiable, y hazlo antes de que el ruido te haga bajar la guardia.

Preguntas frecuentes

Lee también

• CVE-2026-115560: el vector de PHP que se cierra con una línea de configuración
• Cloudflare bloquea PHP2Shell, pero tu WAF no protege un origen abierto
• PHP2Shell: las RCE de PHP que explotaron miles de PoC falsos
• PHP tardó 2 años en parchear una RCE: el fallo estructural que la PHP Foundation reconoció
• CVE-2026-111497: el fallo de Brotli que rompe Node.js, Bun y Python