Vulnerabilidades críticas de PHP: la actualización no se puede posponer

El 21 de octubre de 2026 el equipo de PHP publicó actualizaciones extraordinarias y el equipo europeo de respuesta a incidentes informáticos CERT-EU emitió un aviso de urgencia. El motivo: dos vulnerabilidades con una valoració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 y sin una sola acción por parte de su personal.

PHP es el lenguaje en el que está escrita la mayor parte de los sitios de internet: WordPress, Joomla, OpenCart, Bitrix, Laravel y, además, cientos de scripts propios con los que un sitio se conecta al CRM, al correo o al programa de gestión. Si su sitio no funciona con PHP, puede cerrar este artículo. Si no sabe con qué funciona, eso ya es motivo para preguntárselo a quien se encarga de él.

Qué se ha encontrado exactamente

Hay dos vulnerabilidades, ambas valoradas en 9,2 puntos y ambas con el mismo resultado: la ejecución de código ajeno en el servidor sin autenticación.

CVE-2026-109618: corte por falta de memoria

PHP tiene un ajuste, memory_limit: una petición que ha consumido demasiada memoria se corta por la fuerza. El problema está en cómo se corta. PHP puede interrumpirse en el momento en que los datos internos de la petición están rellenos solo a medias, por ejemplo mientras se procesa un archivo enviado por un formulario de subida. La limpieza posterior toma esos datos a medio hacer por buenos e intenta liberar memoria que nunca existió. Y en esa memoria puede estar lo que el atacante haya dejado allí con peticiones anteriores.

CVE-2026-109619: restos de la petición anterior

El segundo agujero trata de que el servidor no «olvida» del todo al visitante anterior. El estado interno que pertenecía a una petición a veces sobrevive a la liberación de memoria, por ejemplo tras un error fatal. La siguiente petición que cae en ese mismo proceso de trabajo llega a aprovechar esos restos antes de que la inicialización normal 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 señala como la más arriesgada precisamente la combinación de Apache con mod_php, que sigue siendo la estándar en muchos alojamientos baratos.

El exploit de demostración funciona con una única petición sin autenticar, antes incluso de que empiece a ejecutarse el código del propio sitio. Es decir: ni los plugins de seguridad, ni las contraseñas complejas, ni la autenticación en dos pasos ayudan aquí; 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 abiertos que llevan PHP incorporado por dentro aunque desde fuera no se vea: paneles de administración, equipos de red, sistemas de videovigilancia, portales corporativos. La lista de ese software se mantiene en el repositorio del NCSC neerlandés.

Por qué «nuestro sitio es pequeño» no sirve aquí

Nadie busca su sitio en concreto. Cuando los ejemplos de explotación se hacen públicos —y ya lo son—, en unas horas arrancan escáneres automáticos que recorren todo internet de forma indiscriminada. Les da igual si es el sitio de una fábrica o la página de una peluquería: lo único que cuenta es si el servidor responde con una versión vulnerable.

Después el guion es el de siempre: se sube una shell web al servidor, el sitio empieza a repartir spam o páginas de publicidad ajena, el dominio entra en listas negras y el correo que sale de él deja de llegar. Y las pérdidas no las cuenta quien entró, sino quien necesita el sitio para trabajar.

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. Importa comprobar la versión con la que funciona el sitio, no la de 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: se conserva la compatibilidad y el sitio no se rompe por eso. No lo confunda con pasar de 8.2 a 8.4, que sí requiere pruebas.
3. Si tiene 8.1 o anterior, esas 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 pasar a una rama con soporte, y conviene planificarlo ahora y no la próxima vez.
4. Reinicie los gestores. Sin reiniciar php-fpm o Apache, los procesos de trabajo siguen con el código antiguo y la actualización no surte efecto.
5. Compruebe el resultado. Lo más sencillo es una página temporal con phpinfo(), que hay que borrar en cuanto se haya comprobado, o la sección «Versión de PHP» del panel tras recargar.

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

Si no se puede actualizar ahora mismo

A veces el sitio es antiguo y la actualización requiere preparación. Entonces hay medidas temporales que estrechan la ventana del ataque:

• cerrar el desbordamiento de memoria como vía de entrada: memory_limit=-1, puesto de forma que la aplicación no pueda sobrescribirlo, y comprobar que ningún pool ni directorio devuelve el límite;
• reducir post_max_size —8M en sitios sin subida de archivos, 32M si las subidas son necesarias— y mantener upload_max_filesize por debajo;
• 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 peticiones en el servidor web o en el proxy.

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

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

De dónde salen estos datos

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

---

¿No sabe qué versión de PHP funciona en su sitio ni a quién le toca actualizarla? Escríbanos: revisaremos sus sistemas y le diremos sin rodeos si hay amenaza y qué hacer con ella.