22,6 millones de servidores expuestos a Internet corrían software PHP potencialmente vulnerable en el momento de la divulgación, según el conteo que Palo Alto Networks Cortex Xpanse hizo público y recogió Clarín. El número explica por qué OpenAI acaba de publicar un checker abierto para que cualquiera —no solo un administrador de sistemas— pueda responder la primera pregunta obvia: ¿mi web está exponiendo una versión de PHP afectada?
Las fallas en cuestión son dos, registradas como CVE-2026-109618 y CVE-2026-109619, bautizadas colectivamente como PHP2Shell y calificadas con 9,2 sobre 10 en la escala CVSS 4.0, según el reporte de Clarín y la cobertura de Infosecurity Magazine. No viven en un plugin ni en un tema de WordPress: están en el motor de PHP.
Qué hace el checker de OpenAI para la vulnerabilidad de PHP
La herramienta es deliberadamente modesta. Se trata de un pequeño comprobador alojado en el repositorio openai/php2shell-checker en GitHub, acompañado de dos skills para Codex, el agente de OpenAI. Una, phpcheck-url, está pensada para cuando solo se tiene la dirección de una web. La otra, phpcheck-server, para cuando se cuenta con acceso al servidor.
Leíste lo que hace la IA. ¿Y en tu negocio?
En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.
👥 Probar 7 díasCon una URL, la herramienta intenta identificar qué versión de PHP expone públicamente el servidor haciendo una petición HEAD —y recurriendo a GET si el método no está permitido— para leer cabeceras como Server o X-Powered-By. Con acceso al sistema, en cambio, comprueba directamente la instalación y verifica que coincida con el PHP-FPM o Apache que está sirviendo la web. En ningún caso lanza peticiones de explotación: su función es comparar versiones, no demostrar si un sitio fue comprometido.
Ese detalle importa. Un checker de versiones sirve para orientarse, no para auditar.
Los tres estados que devuelve la herramienta
El resultado encaja en una de estas tres categorías:
- VULNERABLE: la versión detectada cae dentro del rango que el checker considera afectado.
- OK: la versión está por encima del umbral incorporado.
- UNKNOWN: no hay información suficiente para clasificarla.
Ninguno de los tres equivale a una auditoría completa, y aquí está el matiz que muchos van a pasar por alto. Incluso un OK parte de lo que el servidor declara públicamente: si esa declaración es falsa o está desactualizada, el veredicto también lo está. Y un UNKNOWN no significa que la web esté protegida, solo que no expone su versión en las cabeceras. Ocultar la versión es buena higiene, pero no es un parche.
Cómo comprobar si tu web está afectada, paso a paso
El flujo que describe Xataka es corto y no requiere crear ningún proyecto:
- Abre la aplicación de ChatGPT para escritorio y cambia a Codex desde el selector superior.
- Instala las dos skills con el comando que OpenAI preparó:
$skill-installer install both skills from https://github.com/openai/php2shell-checker. Codex usará el repositorio oficial como origen y pedirá permiso para conectarse a Internet y escribir archivos en su carpeta de skills. - Ejecuta la comprobación con
$phpcheck-url check https://tu-dominio.com/, sustituyendo la dirección por la web que quieras revisar. Si tienes acceso al servidor, usaphpcheck-server.
No estás instalando PHP ni descargando una aplicación pesada: son instrucciones y un script que el agente reutiliza después.
Por qué PHP2Shell es más grave que un fallo de plugin
PHP es el lenguaje de servidor detrás de cerca del 70% de los sitios web cuyo lenguaje del lado del servidor puede identificarse, según los datos de W3Techs que cita Infosecurity Magazine. Eso incluye a WordPress —que por sí solo alimenta alrededor del 40% de las webs, según Xataka— y también a Drupal, Joomla, Magento y buena parte del comercio electrónico.
La diferencia con un fallo de plugin es la posición en la pila. Las dos vulnerabilidades viven en cómo PHP administra la memoria cuando una petición HTTP termina en un error fatal, y cualquier entorno que procese peticiones entrantes queda expuesto: PHP-FPM, Apache con modphp, php-cgi, FrankenPHP y LiteSpeed, según HealthcareInfoSecurity. El riesgo más alto corresponde a modphp, donde ya se confirmaron pruebas de concepto funcionales capaces de ejecutar código sin autenticación.
El peso del legado agrava el cuadro. Clarín recoge telemetría de Shodan según la cual cerca del 60% de los servidores que declaran un banner de PHP corren builds fuera de soporte, mientras que Web Technology Surveys, citado por HealthcareInfoSecurity, sitúa al 27% de las instalaciones en la versión 7 y al 8% en la 5.
Las versiones parcheadas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Para las ramas 7.4, 8.0 y 8.1 el equipo de PHP publicó backports de emergencia desde el código fuente, aunque oficialmente todo lo anterior a la 8.x está en fin de vida y sin soporte. Clarín añade una advertencia operativa concreta: el repositorio Remi, muy usado en RHEL, CentOS y Fedora, no tendría actualizaciones el mismo día del anuncio.
Si no puedes parchear de inmediato, el equipo de PHP publicó mitigaciones temporales que Clarín detalla: desactivar session.upload_progress.enabled para cerrar el vector principal, fijar fatal_error_backtraces = 0 en PHP 8.5, ajustar post_max_size y memory_limit, y evitar límites de proceso tipo RLIMITAS o RLIMITDATA porque inducen justamente el fallo de asignación de memoria que dispara el exploit.
¿Y si tu web está en un hosting compartido?
Este es el punto ciego de la mayoría de startups pequeñas. El runtime no lo administras tú: lo administra tu proveedor. Xataka lo resume bien cuando señala que el mantenimiento de PHP puede estar en manos del administrador o de la empresa de alojamiento, no del dueño de la web.
La consecuencia práctica es incómoda: actualizar WordPress, los plugins o el tema no corrige esto. El parche tiene que llegar al servidor. Y mientras tanto, la evidencia de explotación ya es real: Cloudflare reportó tráfico de ataque dirigido contra clientes expuestos y desplegó reglas de detección en su WAF, según Clarín y Xataka.
El impacto institucional da la escala del asunto. Xataka y TN documentan desconexiones preventivas en Países Bajos —incluido el portal del NCSC y el puerto de Róterdam—, Finlandia, Dinamarca, Francia y Alemania, además de sistemas de Wikimedia. No hay pruebas de que esos apagados respondan a intrusiones confirmadas, y esa distinción importa antes de sacar conclusiones.
Qué significa esto para tu startup
La lección no es «instala un plugin de seguridad». Es que tu inventario de dependencias incluye cosas que no elegiste, y que ese inventario se prueba el día que algo se rompe. Cuatro acciones concretas:
- Verifica tu versión hoy, no mañana. Corre el checker sobre tu dominio público y, si tienes acceso, usa la variante de servidor. Si el resultado es UNKNOWN, no lo leas como aprobación: abre un ticket con tu proveedor de hosting y pide confirmación por escrito de la versión de PHP y de la fecha del parche.
- Descarga un respaldo completo fuera del servidor. Archivos y base de datos, en un disco externo o nube. Si un ataque automatizado entra antes de que tu proveedor parchee, la diferencia entre restaurar y perder todo está en ese backup.
- Audita señales de exposición. Procesos
php-fpmohttpdque invocan shells, herramientas de compilación o utilidades de transferencia; archivos PHP nuevos en la raíz del sitio o en/tmp,/var/tmpy/dev/shm; tareas cron que no creaste. Si vendes online, revisa además el checkout: en eventos de esta magnitud es habitual que se inyecten capturadores de tarjetas. - Activa MFA en tus cuentas críticas. Servidores PHP comprometidos pueden exponer bases de datos y sesiones almacenadas. El segundo factor evita que una credencial filtrada baste.
Y una regla de higiene para el equipo: cualquier correo que anuncie «tu web está comprometida, descarga este parche» es phishing hasta que se demuestre lo contrario. Ve siempre al panel oficial de tu proveedor.
La lección de fondo: la IA encontró el fallo
Hay un detalle del caso que trasciende PHP. Según HealthcareInfoSecurity, las vulnerabilidades fueron descubiertas de forma independiente por dos equipos que usaron modelos de IA: uno de la firma ofensiva Calif, con el modelo GPT-5.6 Sol de OpenAI dentro de su iniciativa Patch the Planet, y otro de Wiz, con Gemini 4 Argon de Google y su propio sistema Atlas. Reportaron las fallas entre el 11 y el 24 de agosto, y la coordinación del arreglo arrancó el 21 de septiembre.
Lo notable, según Wiz, es que la cadena de explotación era tan compleja que antes quedaba al borde de lo que un investigador humano podía lograr de forma práctica. La IA bajó ese umbral. Para un founder, la implicación operativa es sencilla: el tiempo entre que aparece un fallo y aparece un exploit se está comprimiendo, y tu capacidad de responder depende de saber qué corre en tu infraestructura y quién la administra.
Un checker como el de OpenAI no te salva de eso. Pero convierte una pregunta que antes requería un especialista en un comando que cualquiera en el equipo puede ejecutar en dos minutos.
Fuentes
- Xataka: Cómo saber si una web está afectada por la vulnerabilidad de PHP (fuente original)
- Clarín: PHP vulnerability 2026 explained
- Infosecurity Magazine: Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patches
- HealthcareInfoSecurity: Critical PHP Patches Address ‘Very, Very Bad Vulnerability’
- Xataka: Un fallo crítico en PHP pone en jaque a medio Internet
- TN: Alerta mundial por una falla de seguridad en Internet
Leíste lo que hace la IA. ¿Y en tu negocio?
En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.
👥 Probar 7 días
