Vulnerabilidades críticas de PHP: por qué las fundaciones benéficas deberían revisar sus sitios ya

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 a un atacante ejecutar su propio código en el servidor — sin inicio de sesión, sin contraseña, sin ninguna acción por parte del personal o de los voluntarios.

PHP es el lenguaje en el que está escrita la mayoría de los sitios de internet: WordPress, Joomla, OpenCart, Bitrix, Laravel. Los sitios de fundaciones benéficas, iniciativas de voluntariado y recaudaciones casi siempre están hechos con él, de modo que el riesgo les afecta igual que a las grandes empresas.

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.

Qué supone esto para la recaudación de fondos

Nadie busca por separado el sitio de una fundación concreta. Cuando los ejemplos de intrusión se hacen públicos — y ya lo son —, en pocas horas se ponen en marcha escáneres automáticos que recorren todo internet de forma indiscriminada. Les da igual que sea un portal corporativo o una página de recaudación para un vehículo: lo único que importa es si el servidor responde con una versión vulnerable.

Para una fundación, el escenario más peligroso no es el que deja el sitio visiblemente estropeado. Al contrario: el sitio funciona, se ve como siempre — y el número de tarjeta o los datos del bote de recaudación en la página de la colecta han sido cambiados en silencio. Las donaciones siguen llegando, la gente transfiere dinero, y se descubre cuando alguien coteja los ingresos. Junto a esto llegan las consecuencias habituales: una web shell en el servidor, publicidad ajena en las páginas, el dominio en listas negras y el correo que deja de llegar a donantes y socios.

El tercer riesgo son los datos. Las listas de donantes, las solicitudes de las unidades y los documentos sobre la entrega de ayuda suelen estar en el mismo servidor que el sitio.

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 la fundación no tiene una persona responsable del sitio y del alojamiento, la comprobación se puede encargar fuera — en particular a SmartGT: revisarán los recursos y dirán sin rodeos si existe una amenaza.

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