Vulnerabilidades críticas de PHP: qué significa para los sitios de los proyectos de reconstrucción

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. Dos vulnerabilidades con una puntuación de peligrosidad de 9,2 sobre 10 permiten ejecutar código ajeno en el servidor sin autorización.

PHP es el lenguaje en el que está escrita la mayoría de los sitios: WordPress, Joomla, OpenCart, Bitrix, Laravel. En el contexto de la reconstrucción esto significa portales de programas, páginas de recaudación, registros de bienes dañados, sitios de organizaciones civiles y de contratistas, es decir, recursos donde conviven datos personales, documentos y datos de pago.

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é un sitio del proyecto hackeado es una cuestión de confianza y no solo de tecnología

Nadie busca su proyecto por separado. Cuando los ejemplos de explotación 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 portal de un programa nacional o la página de una iniciativa para una sola comunidad: lo único que importa es la versión con la que responde el servidor.

Las consecuencias típicas son conocidas: una webshell en el servidor, spam y publicidad ajena en las páginas, el dominio en listas negras, el correo que deja de llegar. Pero para los proyectos de reconstrucción lo más caro es otra cosa. En primer lugar, la sustitución de los datos bancarios para las aportaciones: el escenario clásico en el que un sitio con donaciones se hackea no para estropearlo, sino para cambiar en silencio el número de cuenta. En segundo lugar, la rendición de cuentas pública: si los documentos y las cifras pueden modificarse desde fuera, se devalúa el sentido mismo de la transparencia sobre la que se sostiene la confianza de los donantes y los socios.

En tercer lugar, los datos de las personas. Las solicitudes, los registros de bienes dañados y los cuestionarios de los participantes en los programas suelen estar en el mismo servidor que el sitio web.

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 en su proyecto no hay una persona responsable de las actualizaciones y los accesos, la auditoría de los recursos puede encargarse fuera, en particular a SmartGT.

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