Crisis en PHP:
dos fallos críticos y qué hacer hoy

Durante la semana del 21 de octubre, decenas de sitios de gobiernos, escuelas y hospitales de Europa aparecieron fuera de servicio con mensajes de "mantenimiento". No fue una caída accidental: sus responsables los apagaron a propósito mientras esperaban el parche de un fallo en PHP, el lenguaje que hay detrás de una enorme parte de la web.

Este artículo resume lo que se sabe hasta hoy, explica por qué este caso es especialmente delicado y termina con una guía práctica para revisar y actualizar tu propio servidor. Si programás o administrás sitios, es una lectura corta que puede ahorrarte un problema serio.

Qué pasó, en orden

• 11 de agosto Según la prensa, investigadores de la firma de seguridad Calif, trabajando con OpenAI, reportaron al equipo de PHP el primero de los fallos. Lo habían encontrado con ayuda de un modelo de inteligencia artificial.
• 21 de octubre El equipo de PHP anuncia parches para dos vulnerabilidades críticas y se publican los CVE. Agencias de ciberseguridad de la Unión Europea, Reino Unido, Japón y Australia piden actualizar de inmediato o, si no es posible, sacar de línea los sitios afectados. Varios organismos de Países Bajos, Finlandia, Francia, Alemania y Bélgica apagan sus webs como medida preventiva.
• 22 de octubre Medios especializados empiezan a analizar el alcance. Todavía no hay una cifra de sitios efectivamente comprometidos, y los propios analistas anticipan que tardará semanas en conocerse.

Hubo reportes de explotación activa, aunque no todas las autoridades confirmaron ataques en su territorio. El centro de ciberseguridad de Bélgica, por ejemplo, indicó que no había registrado ataques contra sitios belgas. Conviene tomar ese matiz en cuenta: la prudencia de apagar un sitio no equivale a que ya haya sido vulnerado.

Qué sabemos de las dos vulnerabilidades

Los detalles técnicos públicos son todavía limitados, y parte de la información inicial provino de investigadores y filtraciones más que del aviso oficial. Lo que sí está respaldado por los proveedores de seguridad que ya publicaron análisis es lo siguiente:

"Ejecución remota de código" significa que alguien desde afuera podría lograr que tu servidor corra instrucciones que no le corresponden. Según el análisis de Xataka, las vulnerabilidades que originaron esta crisis podrían explotarse sin necesidad de autenticarse, lo que eleva el riesgo: el atacante no necesita una cuenta ni una contraseña.

Por qué un fallo en el núcleo es distinto

Cuando se descubre un fallo en una aplicación concreta, el daño tiene un límite: afecta a quienes usan esa aplicación. Un fallo en el núcleo del lenguaje es otra categoría, porque cada programa construido encima hereda el problema. Aunque el código de la aplicación esté escrito con cuidado, el servidor sigue siendo vulnerable si el intérprete de PHP lo es.

La escala explica la alarma. De acuerdo con W3Techs, citado por Reuters, PHP funciona en cerca del 70% de los sitios cuyo lenguaje se puede identificar. Es además el motor de WordPress, que según esa misma cobertura mueve alrededor del 40% de todos los sitios web, y de plataformas como Drupal, Joomla y Magento. También está dentro de paneles de hosting y de programas que ni siquiera anuncian que usan PHP.

Hay otro factor: muchos sitios pequeños los administra gente sin equipo de seguridad, en hosting compartido, donde ni siquiera está claro quién actualiza PHP. Para ese grupo, la pregunta práctica no es "¿cómo parcheo?" sino "¿quién lo hace y cuándo?".

El papel de la inteligencia artificial

Xataka propone una lectura útil de esta crisis: más que un fallo recién aparecido, lo que se ve es el efecto de una nueva herramienta sobre una infraestructura vieja. Muchas vulnerabilidades llevan años escondidas en software antiguo, y los modelos de IA de frontera las están sacando a la luz. Laboratorios como OpenAI y Google ya los usan para detectar fallos en PHP, generar pruebas de explotación y validar las correcciones que proponen los ingenieros.

Eso tiene dos caras. La IA es un escudo potente para defender, porque acelera el hallazgo y la corrección. Pero el mismo análisis advierte que también reduce el tiempo y el conocimiento necesarios para convertir una vulnerabilidad conocida en un ataque que funcione. La consecuencia práctica es que la ventana entre "se publica el parche" y "empiezan los ataques" se acorta, y la actualización deja de ser una tarea para "cuando haya tiempo".

Tres preguntas distintas que no conviene mezclar

Un matiz importante del mismo análisis es separar tres cifras que suelen confundirse en los titulares:

• Cuántos sitios usan PHP. Es el 70% del que se habla. Mide la escala, no el daño.
• Cuántos corren una versión vulnerable en una configuración atacable. Es un subconjunto del anterior, y es el que realmente importa para priorizar.
• Cuántos fueron efectivamente comprometidos. Todavía no se sabe, y probablemente se conozca en las próximas semanas.

Para vos, la pregunta útil es la segunda: ¿mi servidor corre una versión sin parchear? Eso sí podés averiguarlo ahora.

Versiones corregidas

El equipo de PHP corrigió ambos fallos en las ramas activas. Estas son las versiones mínimas seguras según el análisis de Fastly:

Si estás en PHP 8.1 o anterior, la recomendación sensata es migrar a una rama activa, o confirmar con tu proveedor que aplica el parche. Los análisis iniciales mencionan además que ramas antiguas (5, 6 y 7) podrían estar afectadas, así que "tengo una versión vieja" no es una forma de estar a salvo.

Cómo revisar y actualizar tu servidor

Paso 1: saber qué versión corre

# Versión del PHP de línea de comandos
$ php -v

# Versión que usa el servidor web (suele ser PHP-FPM)
$ php-fpm -v

# Todas las instalaciones en el sistema (Linux)
$ which -a php

Ojo: el PHP de la terminal y el que atiende tu sitio pueden ser versiones distintas. Para confirmar cuál sirve realmente tus páginas, creá un archivo temporal que imprima PHP_VERSION, abrilo desde el navegador y borralo enseguida.

Paso 2: actualizar según tu entorno

Servidor Linux (Ubuntu o Debian):

$ sudo apt update
$ sudo apt upgrade
# Reiniciar para que cargue la versión nueva
$ sudo systemctl restart php8.3-fpm apache2

Ajustá el nombre del servicio a tu versión (por ejemplo php8.2-fpm). Si tu distribución todavía no publicó el paquete corregido, consultá a tu proveedor o evaluá un repositorio de confianza.

Windows con XAMPP: el PHP de XAMPP se actualiza reemplazando los archivos de la carpeta php. Descargá el zip de tu misma rama desde windows.php.net (misma serie de compilador que usa tu XAMPP), detené Apache, hacé una copia de respaldo, extraé encima conservando tu php.ini y reiniciá. Si aparece un aviso de DLL al iniciar Apache, suele resolverse copiando la DLL que menciona el error desde la carpeta de PHP a apache\bin.

Docker: actualizá la etiqueta de la imagen a una versión corregida y reconstruí.

# Dockerfile
FROM php:8.3.36-fpm

# Reconstruir sin usar caché de capas viejas
$ docker build --no-cache -t mi-app .
$ docker compose up -d

Hosting compartido o con panel: buscá en el panel la opción de "versión de PHP" o "selector de PHP", y verificá en el sitio de tu proveedor si publicó un aviso sobre estos CVE. Si no sabés quién actualiza tu PHP, preguntalo hoy.

Paso 3: verificar y reducir exposición

# ¿Tu servidor anuncia la versión de PHP en las respuestas?
$ curl -sI https://tu-sitio.com | grep -i x-powered-by

Si aparece esa cabecera, desactivá expose_php en tu php.ini. No corrige ninguna vulnerabilidad, pero deja de regalarle información a quien escanea la web buscando versiones concretas.

Si no podés actualizar todavía

Las agencias de ciberseguridad fueron claras: si no es posible aplicar el parche, la alternativa recomendada es retirar de línea los sitios afectados hasta poder hacerlo. Es incómodo, pero fue exactamente lo que hicieron los organismos que apagaron sus webs. Para un sitio que no maneja datos sensibles ni transacciones, una página de mantenimiento durante unas horas es mejor que el riesgo de una intrusión.

Mientras tanto, conviene revisar los registros del servidor en busca de actividad inusual, y recordar que las medidas intermedias (filtros, reglas de firewall) pueden reducir el riesgo, pero no reemplazan al parche.

Qué deja esta crisis

Más allá del parche de esta semana, hay tres lecciones concretas para quien tiene sistemas en producción:

• Tener un inventario. Saber en qué servidores, contenedores y hostings corre PHP, y en qué versión. Quien no lo sabe pierde horas valiosas buscando.
• Tener un responsable. Alguien con nombre y apellido que actualice el entorno, aunque el sitio esté "terminado" y nadie lo toque hace años.
• Probar actualizaciones con anticipación. Un sistema que no puede actualizarse sin romperse es una deuda técnica con fecha de vencimiento. Ahora se ve cuánto cuesta no haberla pagado antes.

Fuentes consultadas

Este artículo es un análisis propio, escrito con nuestras palabras a partir de los siguientes materiales. Para el detalle completo, recomendamos leerlos directamente:

• Laura López, «La IA no ha encontrado un fallo nuevo en PHP, sino algo peor: la forma de aprovechar uno viejo», Xataka, 22 de octubre de 2026.
• Reuters, «What is PHP and why did it take government websites offline?», 21 de octubre de 2026.
• Fastly, «Critical RCE Vulnerabilities Discovered in Core PHP: CVE-2026-109618 and CVE-2026-109619».

Los nombres y marcas mencionados pertenecen a sus respectivos titulares. Este contenido es informativo y no reemplaza el asesoramiento de un profesional de seguridad para tu caso particular.