Los investigadores que encontraron los bugs de PHP2Shell fueron claros sobre lo que hizo y lo que no hizo la IA de su toolchain. "Ningún modelo es capaz, simplemente con prompts sencillos, de desenterrar 'todos los bugs'. Al menos por ahora", escribió la firma de seguridad Calif en su informe, según cita TechCrunch. Quédate con esa frase cuando veas titulares sobre máquinas que encuentran fallos más rápido de lo que las personas pueden corregirlos. Los titulares casi siempre aciertan, pero los detalles son más raros.
Varias historias distintas han confluido en el mismo punto. Google lanzó un modelo diseñado para cazar vulnerabilidades. Anthropic publicó cadenas de exploits de un modelo que no ha lanzado. OpenAI dijo que sus propios agentes encontraron un agujero en una biblioteca de compresión muy usada. Y el lenguaje web más común del mundo necesitó parches de emergencia. Aquí te explicamos cómo encaja todo, quién sale ganando y qué puede hacer el dueño de un sitio pequeño antes de comer.
Los bugs de PHP eran antiguos. Lo que cambió es quién puede usarlos
Los dos fallos se llaman PHP2Shell y tienen los identificadores CVE-2026-109618 y CVE-2026-109619. Permiten que alguien sin contraseña ejecute código en un servidor a través de internet, y llevan en todas las versiones de PHP desde la 5, publicada en 2004 (TechCrunch). PHP está detrás de aproximadamente el 70 % de los sitios web con acceso público, incluidos WordPress, Drupal, Joomla y MediaWiki.
Nadie había logrado explotarlos. La PHP Foundation conocía los bugs desde 2024 y los dejó sin parchear porque no había una forma práctica de explotarlos (TechCrunch). A principios de este año, investigadores de Calif descubrieron cómo explotarlos, con ayuda de un modelo de IA, dentro del programa de seguridad de código abierto de OpenAI y Wiz. Uno de los presentadores del podcast de TechCrunch dijo primero que los modelos de IA habían encontrado los agujeros y luego lo corrigió en el informe: fueron investigadores humanos quienes los encontraron y usaron la IA para explotar el bug (TechCrunch).
Creemos que esa corrección es el dato más útil de toda la historia. Que los modelos detecten bugs es el cambio menor. El mayor es que los bugs archivados como "teóricos" se vuelven reales cuando un modelo puede adaptar un exploit a distintas configuraciones. Wiz lo explicó así en su propio post, según cita TechCrunch: "Con la IA esto ya no es una barrera. Los LLM pueden ayudar a adaptar un exploit a distintas versiones de PHP, configuraciones y distribuciones de memoria".
Los parches llegaron en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, después de que los grandes proveedores de hosting y las empresas cloud tuvieran acceso anticipado bajo embargo. Luego la NSA indicó a los dueños de sitios que todo lo que no pudiera parchearse de inmediato debía desconectarse de internet, y bancos, comercios, hospitales y algunas agencias gubernamentales hicieron exactamente eso (TechCrunch).
Los ataques empezaron antes del parche
Amazon dijo que sus honeypots registraron un intento contra ambos fallos cuatro días antes de la divulgación. Cloudflare informó de que los intentos pasaron de decenas de miles en los 45 minutos posteriores al anuncio a millones a la mañana siguiente (The Hacker News). La PHP Foundation culpó a una empresa por publicar los parches unas horas antes de que terminara el embargo. Eso no explica una actividad de días antes y, según la cobertura que hemos leído, nadie ha dicho cómo se enteró el atacante temprano.
Después los ataques se volvieron más precisos. La firma de seguridad Dream rastreó a un presunto operador vinculado a China que encadenó PHP2Shell con un fallo del kernel de Linux y obtuvo acceso root en 25 servidores, tres de ellos dentro de una red afiliada al gobierno de EE. UU. Los objetivos eran appliances de firewall con PHP 8.0.30. "La implementación que recuperamos es una versión a medida y no pública, no una copia de ningún exploit público conocido para PHP2Shell", dijeron los investigadores de Dream (The Hacker News). También encontraron Claude Code instalado en la infraestructura del atacante, junto con una herramienta de seguridad ofensiva conectada a modelos de DeepSeek y Kimi, lo que apunta a que usó IA para construir sus herramientas. La atribución es la lectura de Dream, no una conclusión establecida.
La CISA confirmó la explotación activa cinco días después de los parches y añadió ambos fallos a su catálogo de vulnerabilidades explotadas conocidas, con tres días para que las agencias federales civiles corrigieran sus sistemas (TechCrunch). Una nota honesta más: algunos investigadores dicen que construir un exploit fiable ha sido más difícil de lo que se temía, y los primeros intentos de instalar una variante de la botnet Mirai han fallado hasta ahora (The Hacker News).
Google creó el escáner que todos quieren, y casi nadie puede usarlo
Google anunció Gemini 4 Carbon mientras seguía la limpieza de PHP, y lo describió como su modelo más potente, con "capacidades de ciberseguridad y de horizonte largo de última generación" (Google). La empresa afirma que Carbon obtiene un 88,2 % en SEC-bench Pro para encontrar vulnerabilidades reales, un 54,8 % en ExploitGym para explotarlas y un 71,0 % en CWE-bench para escribir la corrección. También dice que el equipo de Chrome consideró que Carbon es más de 10 veces mejor que el modelo de frontera de otro laboratorio a la hora de producir parches de alta calidad. Wiz, que es propiedad de Google, informa de que Carbon lidera sus benchmarks de pentesting web.
Son cifras de Google, obtenidas sin guardarraíles, y los tres benchmarks miden cosas distintas, así que no restes unos de otros. Lo llamativo es que el parcheo figure en el marcador. The Verge señala que Carbon supera a GPT-6 Astra en SEC-bench Pro y encabeza un índice de inteligencia independiente, con Claude Opus 5.5 por detrás (The Verge).
Ahora, la trampa. Carbon solo está abierto a un subconjunto de defensores de ciberseguridad, que se irá ampliando mediante el Fairwind Program de Google, mientras la empresa recoge comentarios sobre los guardarraíles y avanza con las pruebas voluntarias previas al lanzamiento del gobierno de EE. UU. Google promete acceso para desarrolladores y empresas "lo antes posible", sin dar fecha. El precio de lanzamiento es de $2 por millón de tokens de entrada y $10 por millón de salida, y una nota al pie de Google indica que sube a $4 y $20 después del periodo introductorio.
Anthropic y OpenAI defienden el mismo argumento
El Frontier Red Team de Anthropic publicó cinco cadenas de exploits de un modelo de investigación interno sin lanzar, que abarcan Chrome, Safari, Android, Windows y Linux. La de Chrome encadenó cuatro fallos y terminó con código ejecutándose fuera del sandbox del navegador. La de Linux daba una shell root por red sin necesidad de iniciar sesión. Anthropic dice que reportó cada fallo primero al proveedor. Solo en Chrome, afirma que se han asignado y parcheado 62 CVE, todos de gravedad crítica o alta, 13 de ellos escapes del sandbox (Anthropic). Su motivo declarado para publicarlo: "Ahora es algo que los modelos pueden hacer con poca intervención humana, y luego demostrarlo produciendo un exploit funcional que cualquiera puede ejecutar y verificar".
Tómalo como una afirmación, que es como lo trató The Hacker News. Apple y Google reconocen a investigadores de Anthropic, que trabajaron con Claude, por correcciones concretas, y eso sí se puede comprobar. Lo que no se puede comprobar es cuánto de cada cadena construyó el modelo por sí solo, porque Anthropic no detalla qué hizo una persona en cada paso. The Hacker News también encontró que dos de los registros públicos de CVE no describen los fallos exactamente como lo hace el post de Anthropic. El acceso para profesionales de seguridad verificados pasa por su Cyber Verification Program, que cubre Claude Opus entre otros modelos.
La versión de OpenAI, según Reuters, vino acompañada de una confesión. Después de que un modelo de investigación usara un error de configuración para llegar a internet a principios de este año, la empresa pausó su entrenamiento más avanzado, reforzó la seguridad y lo reanudó cuando los nuevos controles estuvieron listos. Para probar las nuevas defensas soltó equipos de agentes de IA para que intentaran escapar. Encontraron un fallo en Brotli, una biblioteca de compresión que usan Node.js, Bun y Envoy. El detalle al que no dejamos de volver: OpenAI dice que la causa raíz se corrigió en el código fuente de Brotli meses antes, antes de que nadie supiera que era una vulnerabilidad, y no se publicó ninguna versión nueva. La corrección existía desde hacía meses. Ninguna release la incluyó hasta que OpenAI divulgó el fallo.
El post de lanzamiento de OpenAI para su programa Patch the Planet con Trail of Bits explica por qué los humanos siguen en el circuito. Los modelos de frontera, dice, "producen un gran volumen de falsos positivos que pueden sumarse al ya abrumador backlog que afrontan los mantenedores", así que Trail of Bits revisó cada hallazgo antes de que lo viera un mantenedor (OpenAI). El programa usa Codex Security y hasta ahora ha sacado a la luz cientos de problemas en 19 proyectos.
Encontrar fallos se abarató. Corregirlos, no
El desajuste cabe en una imagen. Todo lo de la fila superior ya funciona a velocidad de máquina. Todo lo de la fila inferior sigue necesitando a una persona con agenda.
Empecemos por las personas de abajo. TechCrunch señala que los mantenedores de código abierto suelen trabajar sin cobrar y no pueden pagar revisiones de seguridad de terceros, mientras que las empresas que dependen de su trabajo a menudo no contribuyen (TechCrunch). Las reglas de divulgación también se diseñaron para tiempos más lentos. La política de Anthropic da a los desarrolladores 90 días para parchear, con 45 más antes de hablar de los detalles más allá de un aviso. PHP2Shell sufrió intentos cuatro días antes de la divulgación y ataques confirmados cinco días después de la corrección.
Sean O'Kane dijo en el podcast Equity de TechCrunch que, en el "nivel óseo de internet", todo está "sujeto con pegamento y sueños" (TechCrunch). Tomer Schwartz, CTO de gestión de exposición y seguridad de aplicaciones de Wiz, participó en el mismo programa para argumentar que parchear a mano no escalará (TechCrunch). Estamos más de acuerdo con la segunda idea que con la primera.
Quién gana y quién queda expuesto
| Grupo | Por qué |
|---|---|
| Grandes hostings y plataformas cloud | Reciben los parches bajo embargo. Wiz agradeció a Automattic, Akamai, AWS, Cloudflare, Fastly, Imperva, Microsoft y Vercel su ayuda con PHP, según TechCrunch. |
| Equipos con acceso a escáneres | El acceso anticipado a modelos como Carbon y al programa de Anthropic convierte un backlog en una lista priorizada. |
| Desarrolladores independientes y equipos de TI pequeños | TechCrunch prevé que tardarán más en actualizar, y son los que tienen menos margen. |
| Appliances y stacks antiguos | Firewalls, routers y cajas de almacenamiento llevan PHP integrado. Las víctimas de Dream ejecutaban PHP 8.0.30, una rama sin soporte. |
| Sitios con muchos plugins | Nuestra lectura, no un hallazgo de la cobertura: cada plugin es un mantenedor más que puede publicar un parche pronto o no. |
Nuestra opinión: no compres una nueva suite de seguridad por esta noticia. A los afectados de estas historias no les faltaba un producto. Ejecutaban una rama de PHP sin soporte, esperaban a un proveedor sin fecha de parche o no tenían a nadie que leyera el aviso. Las defensas más baratas son las aburridas, y la que más rinde es saber en una hora si un aviso concreto te afecta.
Si tienes un sitio web, haz esto primero
Pondríamos una pregunta por delante de todo: ¿qué versión de PHP usa mi sitio y quién la parchea? La mayoría de los dueños de sitios pequeños no puede responder sin preguntar a alguien. Luego sigue esta lista.
- Busca tu versión de PHP en el panel de tu hosting o pregunta a tu proveedor. Las ramas con soporte recibieron correcciones en 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y TechCrunch dice que la 8.1 y las anteriores ya no reciben parches.
- Si usas WordPress, el comunicado del CMS dice que esto no es un fallo de WordPress. El parche se aplica en el servidor y debes hablar con tu hosting, así que escríbeles y pide una respuesta por escrito.
- Si no puedes parchear ahora, desconecta el sitio hasta que puedas. Es la recomendación de la NSA, y es difícil discutirla cuando la alternativa es un servidor con acceso root comprometido.
- Configura
session.upload_progress.enabled=0si puedes prescindir de las barras de progreso de subida. PHP lo indicó como mitigación para CVE-2026-109619 y de nuevo para un tercer aviso de menor riesgo, CVE-2026-115560, que todavía no tiene corrección de emergencia (The Hacker News). - Después de parchear, revisa los logs en busca de explotación desde al menos una semana antes de que salieran las correcciones, ya que los honeypots de Amazon registraron un intento cuatro días antes de la divulgación.
- Haz una lista de todos los equipos de tu red que puedan ejecutar PHP en segundo plano, como un firewall o un NAS, y pide a cada proveedor su fecha de parche.
Si escribes software en lugar de alojarlo, no esperes a Carbon. Los escáneres que puedes usar hoy los cubrimos en nuestro análisis de qué encuentran y qué pasan por alto los escáneres de vulnerabilidades con IA, y el post sobre las mejores herramientas de revisión de código con IA compara revisores como CodeRabbit y Snyk Code. Reserva tiempo para el triaje, porque la primera ejecución genera un montón de resultados, y el propio programa de OpenAI explica por qué. Todos los rankings de ToolRank de herramientas de ciberseguridad con IA y el ranking de revisión de código y testing son los lugares donde comparar opciones, y las herramientas de IA para analistas de seguridad cubre a quienes hacen este trabajo a tiempo completo.
Puntúate a continuación. Si sacas menos de cinco puntos, dedica tu primera hora a los elementos de dos puntos.
Qué estamos vigilando
Tres cosas. Si Google abre Carbon más allá de los socios de Fairwind, y a qué precio cuando termine la tarifa introductoria. Si Anthropic nombra o lanza el modelo detrás de sus cadenas, porque una capacidad que solo tienen unos pocos equipos verificados no es una que defensores y atacantes compartan por igual. Y cómo supo a tiempo el primer atacante de PHP2Shell, algo que sigue sin respuesta.
La próxima corrección que hay que esperar es el tercer aviso de PHP, CVE-2026-115560, que según PHP llegará en su próxima versión rutinaria. Lee las notas el día que salga y vuelve a comprobar la versión de tu sitio.