El fallo de PHP que paralizó medio internet: qué cambia para tu sitio

¿Qué pasó exactamente?

Dos vulnerabilidades en el núcleo de PHP, con puntaje CVSS de 9,2 sobre 10. Las dos permiten ejecución remota de código sin autenticarse, es decir, alguien puede correr lo que quiera en tu servidor sin tener usuario ni contraseña.

Se registraron como CVE-2026-109618 y CVE-2026-109619. La primera nace de una corrupción de memoria cuando una petición llega al límite de memoria en el momento exacto: PHP deja datos internos a medio construir y después los trata como válidos. La segunda ocurre cuando un estado interno sobrevive a la memoria que lo sostenía, y una petición posterior del mismo proceso lo usa como si fuera bueno.

Las dos viven en partes que toca casi cualquier petición: manejo de memoria y manejo de errores. Eso es lo que las hace graves y también difíciles de arreglar sin romper compatibilidad.

Los parches están en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, con retroportes mínimos para 7.4, 8.0 y 8.1. Afecta a versiones desde PHP 5.4, o sea prácticamente a todo lo que corre hoy. El problema no termina en el intérprete: aplica a PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.

Hay un detalle que se subraya poco. Los fallos también permiten leer memoria del proceso, y ahí puede haber credenciales, claves de API y otros secretos. No hace falta que te ejecuten código para que el problema sea caro.

¿Por qué se habla del fin del internet abierto?

Porque estos dos fallos llevaban años a la vista de los auditores y nadie había encontrado la forma de explotarlos. Encontrarla no costó una década de trabajo: costó semanas de análisis con modelos de lenguaje.

La cronología la contó la propia PHP Foundation. En 2024 el proyecto pasó por su primera auditoría externa en años, financiada con fondos públicos europeos y hecha por Quarkslab. Arreglando otro de los hallazgos, un desarrollador del núcleo vio las primeras señales del problema de memoria. Ese mismo año alguien teorizó un posible exploit, pero no encontró un vector concreto y el tema quedó relegado.

Arreglarlo se volvió un nudo. Cada solución rompía compatibilidad, abría un nuevo agujero de denegación de servicio o exigía cambios en extensiones de terceros imposibles de coordinar. El equipo de seguridad tomaba decisiones por consenso, con pocas manos y muchas otras responsabilidades encima. El arreglo se frenó y se retomó varias veces durante meses. La Fundación lo dice sin rodeos: la demora fue una falla estructural, por el proceso de decisión y por falta de recursos.

Lo que rompió el empate fue la IA. La Fundación había escaneado PHP con Claude Mythos, de Anthropic, junto a Alpha-Omega, y sumó después herramientas de OpenAI para validar reportes. Entró al programa Patch the Planet de OpenAI, y por ahí la auditora Calif empezó a revisar PHP el 30 de julio. El 11 de agosto, un investigador de Calif reportó ejecución remota de código incondicional con la misma causa raíz. OpenAI reportó la misma causa ese mismo día, por su cuenta. Llegaron más vectores de OpenAI el 18 de septiembre y de Wiz el 24 de agosto. Desde el 11 de agosto, arreglar esto pasó a ser la prioridad número uno de todo el equipo de seguridad de PHP.

Ahí está el cambio de fondo. Antes el cuello de botella era encontrar fallos: escasearon las manos durante veinte años y por eso el software que sostiene internet se mantuvo con auditorías esporádicas y buena voluntad. Ahora encontrarlos es barato y rápido. El cuello de botella se movió al otro lado, al de arreglarlos.

Los tres cambios que ya están aquí

El primero es el tiempo. Antes había semanas o meses entre la divulgación y el exploit. En este caso se vieron intentos de explotación cuatro días antes de que existieran los parches, y pruebas de concepto circulando mientras el equipo todavía cosía el arreglo. La ventana se mide ahora en horas.

El segundo es quién mantiene el software. PHP no lo sostiene una empresa con miles de ingenieros: lo sostiene una fundación con un equipo pequeño, financiada en parte por donaciones, que este año contrató a tres personas para seguridad y admitió públicamente que su proceso de decisión la trabó. Esa es la contradicción del internet abierto: la infraestructura es de todos y el mantenimiento lo paga casi nadie.

El tercero es el inventario. Casi ninguna pyme sabe qué versión de PHP corre su sitio, ni quién la actualiza, ni cuándo fue la última vez. Ese dato, que antes era un detalle técnico, hoy es la diferencia entre estar parcheado y estar expuesto.

Quién está protegido y quién tiene que moverse

Qué revisar esta semana en tu sitio

1. Averigua la versión de PHP. En WordPress la ves en Herramientas, Salud del sitio, Información. Si no tienes panel, pregúntale a quien administra el hosting.

2. Pide confirmación por escrito al proveedor. Un «ya está todo bien» no sirve; sirve un correo con la versión exacta y la fecha del parche.

3. Si administras tu propio servidor, actualiza y reinicia. El parche no hace nada hasta que el servicio vuelve a levantar.

4. Si no puedes parchear hoy, aplica las mitigaciones que publicó PHP: límite de memoria sin tope controlable por la aplicación y un tamaño máximo de subida bajo. Y desactiva el progreso de subida por sesión, que es la puerta que usaron la mayoría de los ataques observados.

5. Revisa accesos y claves. Como los fallos permiten leer memoria, cualquier credencial que viva en ese servidor hay que darla por expuesta si estuvo sin parche.

6. Comprueba tus respaldos. Un respaldo que nunca has restaurado no es un respaldo, es una carpeta.

¿Y si mi sitio es solo informativo?

Da igual. Un sitio comprometido se usa para mandar spam, alojar phishing o atacar a otros, y el que aparece en las listas negras es tu dominio. Después vienen los meses de trabajo para limpiar la reputación, los correos que dejan de llegar y los clientes que no encuentran tu página en Google.

En Guatemala y Centroamérica el patrón se repite: la pyme contrata el sitio, lo paga una vez y nadie vuelve a hablar de mantenimiento. El fallo de PHP no inventó ese problema, pero lo volvió visible. Tener un sitio sin nadie a cargo de actualizarlo es tener una puerta abierta con la luz apagada.

Preguntas frecuentes

¿Mi hosting ya me protegió?

Si estás en un plan compartido administrado, probablemente sí, porque las mitigaciones se aplican en la plataforma. Aun así pide la versión exacta de PHP y la fecha. Si tienes VPS o servidor propio, la respuesta por defecto es no: ahí nadie actualiza por ti.

¿Actualizar WordPress arregla esto?

No por sí solo. El fallo está en PHP, que va debajo de WordPress. Actualizar el núcleo, los plugins y los temas es necesario siempre, pero no sustituye el parche del intérprete.

¿Cómo sé si mi sitio fue atacado?

Buscando lo de siempre: archivos nuevos o modificados que no reconoces, usuarios administradores que no creaste, procesos raros en el servidor y tráfico a horas imposibles. Si el sitio estuvo sin parche y expuesto, también revisa claves y accesos, además de los archivos.

¿Esto significa que el software libre es inseguro?

Significa que el software libre sostiene la web con un financiamiento que no corresponde a su peso. El fallo apareció en una auditoría pagada con fondos públicos y se resolvió cuando entraron empresas con herramientas de IA. La lección no es desconfiar del código abierto, es que mantenerlo también cuesta.

¿Va a pasar otra vez?

Sí, y con más frecuencia, porque encontrar fallos se abarató y arreglarlos no. La consecuencia práctica para ti es que la actualización deja de ser un trámite anual y pasa a ser una rutina mensual con alguien responsable detrás.

---

Si no sabes qué versión de PHP corre tu sitio ni quién lo actualiza, eso ya es el problema. En Vela Producciones revisamos el desarrollo y el mantenimiento de tu sitio y también el posicionamiento, porque un sitio caído o en listas negras pierde posiciones que cuestan meses recuperar. Escríbenos y lo revisamos con tu caso.