Vulnerabilidades críticas de PHP: compruebe el sitio de su negocio o iniciativa

Muchos veteranos, al terminar el servicio, abren su propio negocio, emprenden un proyecto social o lanzan una iniciativa educativa, y casi siempre en algún momento aparece un sitio web. Normalmente lo hicieron con WordPress: rápido, barato, a menudo de la mano de un conocido o de un autónomo con el que hace mucho que no hay contacto.

El 21 de octubre de 2026 el equipo de PHP publicó actualizaciones extraordinarias, y el equipo europeo de respuesta a incidentes cibernéticos CERT-EU publicó una advertencia urgente. El motivo son dos vulnerabilidades con una puntuación de peligro de 9,2 sobre 10, que permiten a un atacante ejecutar su propio código en su servidor. Sin usuario, sin contraseña, sin una sola acción por su parte.

A continuación, sin lenguaje técnico innecesario: qué ha pasado, por qué afecta incluso al sitio más pequeño y qué tres frases conviene escribir hoy mismo a su proveedor de alojamiento.

Qué se encontró exactamente

Son dos vulnerabilidades, ambas valoradas en 9,2 puntos y ambas conducen al mismo resultado: la ejecución de código ajeno en el servidor sin autorización.

CVE-2026-109618 — fallo cuando falta memoria

En PHP existe el ajuste memory_limit: una solicitud que ha consumido demasiada memoria se interrumpe a la fuerza. El problema está en cómo se interrumpe exactamente. PHP puede cortarse en el momento en que los datos internos de la solicitud están llenos solo a medias — por ejemplo, mientras se analiza un archivo enviado a través de un formulario de carga. La limpieza posterior a esa solicitud toma los datos a medio hacer por datos reales e intenta liberar memoria que nunca existió. Y en esa memoria puede estar lo que el atacante dejó allí con solicitudes anteriores.

CVE-2026-109619 — restos de la solicitud anterior

El segundo agujero trata de que el servidor no «olvida» del todo al visitante anterior. El estado interno que pertenecía a una solicitud a veces sobrevive a la liberación de memoria, por ejemplo tras un error fatal. La siguiente solicitud que cae en el mismo proceso de trabajo llega a aprovechar esos restos antes de que la inicialización habitual los ponga a cero.

Está en riesgo cualquier instalación de PHP que atienda peticiones web: PHP-FPM, Apache con el módulo mod_php, php-cgi, FrankenPHP, LiteSpeed. El equipo de PHP califica como la combinación más arriesgada precisamente la de Apache con mod_php — sigue siendo la opción estándar en muchos alojamientos baratos.

El exploit de demostración funciona con una única solicitud no autenticada, incluso antes de que empiece a ejecutarse el código del propio sitio. Es decir, aquí no ayudan ni los plugins de seguridad, ni las contraseñas complejas, ni la autenticación de dos factores: el ataque ocurre un nivel más abajo.

Qué versiones están en riesgo

Todo lo que esté por debajo de estas versiones es vulnerable:

Rama de PHP	Versión segura
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1 y anteriores	sin soporte

Una categoría de riesgo aparte son los productos comerciales y de código abierto que llevan PHP incrustado por dentro, aunque por fuera no se vea: paneles de control, dispositivos de red, sistemas de videovigilancia, portales corporativos. La lista de ese software se mantiene en el repositorio del NCSC neerlandés.

Por qué «tengo un sitio pequeño» no salva aquí

Nadie busca su sitio por separado. Cuando los ejemplos del ataque se hacen públicos —y ya son públicos—, en unas pocas horas se ponen en marcha escáneres automáticos que recorren todo internet uno por uno. Les da igual si es el sitio de una gran empresa o la página de un taller con cinco servicios: lo único que importa es si el servidor responde con una versión vulnerable.

Después el escenario es típico: se sube al servidor código ajeno, el sitio empieza a repartir spam o páginas con publicidad ajena, el dominio acaba en listas negras y el correo enviado desde él deja de llegar a los clientes. Para un negocio pequeño esto duele el doble: el sitio es a menudo el único escaparate y la recuperación se lleva semanas y un dinero que no estaba previsto.

Advertimos aparte sobre lo que suele venir después. Tras noticias así se activan los «maestros» que escriben por su cuenta a los propietarios de sitios: «tiene una vulnerabilidad, deme los accesos urgentemente». Entregue los accesos al sitio y al alojamiento solo a quien conozca y a quien pague por el mantenimiento.

Qué hacer, paso a paso

1. Averigüe su versión. En el panel de alojamiento es la sección «Versión de PHP» o «PHP Selector»; en un servidor propio, el comando php -v. Es importante comprobar la versión con la que funciona el sitio, y no la que está en la línea de comandos: a menudo son distintas.
2. Actualice dentro de su propia rama. Pasar de 8.2.29 a 8.2.35 es una corrección dentro de una misma rama: la compatibilidad se mantiene y el sitio no se rompe por ello. No lo confunda con pasar de 8.2 a 8.4 — eso sí exige comprobaciones.
3. Si tiene 8.1 o anterior — estas ramas no tienen soporte. Por la gravedad de la situación, el equipo de seguridad de PHP publicó correcciones mínimas también para 7.4, 8.0 y 8.1, y parte de los proveedores mantiene compilaciones propias. Pero la decisión correcta es mudarse a una rama con soporte, y conviene planificarlo ahora y no la próxima vez.
4. Reinicie los manejadores. Sin reiniciar php-fpm o Apache, los procesos de trabajo siguen funcionando con el código antiguo y la actualización en realidad no surte efecto.
5. Compruebe el resultado. Lo más sencillo es una página temporal con phpinfo(), que hay que borrar justo después de la comprobación, o bien la sección «Versión de PHP» del panel tras el reinicio.

A los usuarios de alojamiento casi nunca les tocará hacer nada a mano: los grandes proveedores recibieron las correcciones por adelantado y actualizan sus máquinas por su cuenta. Vale la pena escribir una línea al soporte — «¿se ha actualizado PHP a las versiones del 21 de octubre de 2026?» — y obtener la respuesta por escrito.

Si no se puede actualizar ahora mismo

Ocurre que el sitio es viejo y la actualización requiere preparación. Entonces hay medidas temporales que estrechan la ventana para un ataque:

• cerrar el desbordamiento de memoria como punto de entrada: memory_limit=-1, definido de modo que la aplicación no pueda redefinirlo, y una comprobación de que ningún pool ni directorio devuelva el límite;
• reducir post_max_size — 8M para sitios sin subida de archivos, 32M si las subidas son necesarias, y upload_max_filesize mantenerlo más bajo;
• desactivar session.upload_progress.enabled y reiniciar todos los procesos de trabajo;
• en PHP 8.5 desactivar además fatal_error_backtraces;
• limitar el tamaño y la complejidad de las solicitudes a nivel del servidor web o del proxy.

Ninguna de estas medidas hace que la instalación sea segura. Solo cierran las vías conocidas: el problema lo cierra por completo únicamente la actualización.

Si ni eso es posible, CERT-EU aconseja una solución sencilla e impopular: retirar el servicio vulnerable de internet público hasta que la corrección esté instalada y comprobada.

De dónde proceden estos datos

• CERT-EU, Security Advisory 2026-018 «Critical Vulnerabilities in PHP»
• El anuncio del lanzamiento de las actualizaciones en php.net
• Descripción técnica de CVE-2026-109618 y CVE-2026-109619

---

Si no sabe con qué está hecho su sitio y quién responde por él, eso ya es motivo para aclararlo sin esperar la siguiente noticia. La comprobación también puede encargarse a SmartGT, el equipo que mantiene los recursos digitales del clúster.

Autor del material — SmartGT. Fuente original: «Vulnerabilidades críticas de PHP: la actualización no se puede postergar».