Una falla de severidad máxima en el núcleo de PHP permite a atacantes no autenticados ejecutar código arbitrario en el servidor. La actualización a las versiones parcheadas es urgente.
Una vulnerabilidad crítica en el lenguaje de programación PHP, uno de los más utilizados para el desarrollo web a nivel mundial, mantiene en alerta a administradores de servidores y desarrolladores. Se trata de dos fallos de seguridad identificados como CVE-2026-109618 y CVE-2026-109619, que afectan al núcleo del intérprete y permiten a un atacante remoto no autenticado ejecutar código arbitrario con los privilegios del proceso web.
La gravedad del hallazgo se refleja en su puntuación CVSS de 9.2 sobre 10, lo que la clasifica como crítica. Según los avisos de seguridad publicados por el equipo de PHP y distribuidos por múltiples instituciones, la explotación exitosa de estas fallas podría comprometer por completo el servidor afectado.
¿Qué versiones están en riesgo?
Todas las instalaciones de PHP anteriores a las versiones corregidas están expuestas. La siguiente tabla resume las versiones mínimas seguras:
| Rama de PHP | Versión segura mínima |
|---|---|
| PHP 8.5.x | 8.5.12 |
| PHP 8.4.x | 8.4.27 |
| PHP 8.3.x | 8.3.36 |
| PHP 8.2.x | 8.2.35 |
Las ramas PHP 8.1 y anteriores ya no reciben soporte oficial, por lo que los servidores que aún las utilicen son especialmente vulnerables y deben migrar a una versión mantenida cuanto antes.
El riesgo en servidores con múltiples versiones
Un aspecto que complica la mitigación es el uso de repositorios de terceros, como packages.sury.org, ampliamente utilizado por paneles de control como HestiaCP para instalar y mantener varias versiones de PHP en un mismo servidor.
En estos entornos, el paquete principal (php8.x) suele actualizarse automáticamente, pero los subpaquetes que contienen los binarios reales —php8.x-cli, php8.x-fpm, php8.x-common y las extensiones— pueden quedar rezagados. Esto significa que un servidor puede aparentar estar actualizado mientras sigue ejecutando la versión vulnerable en el servicio que atiende los sitios web.
Por ello, los especialistas recomiendan verificar no solo la versión que reporta el comando php -v, sino también la que utiliza el proceso FPM en ejecución, mediante php-fpm8.x -i, y confirmar que los subpaquetes estén efectivamente en la versión parcheada.
Medidas recomendadas
- Actualizar de inmediato a la versión corregida correspondiente a cada rama instalada, prestando atención a los subpaquetes y no solo al metapaquete.
- Reiniciar el servicio PHP-FPM después de la actualización para que los sitios web carguen el nuevo código parcheado.
- Verificar el estado real con
php -vyphp-fpm8.x -i, y confirmar que no queden paquetes pendientes conapt list --upgradable | grep -i php. - Revisar si hay otras ramas de PHP instaladas en el servidor, ya que todas ellas deben estar en versiones seguras.
- Como medida temporal, si no es posible actualizar de inmediato, se puede desactivar
session.upload_progress.enabledenphp.iniy ajustarmemory_limita nivel administrativo, aunque estas mitigaciones no eliminan el riesgo por completo.
Un recordatorio sobre la higiene de seguridad
El caso subraya la importancia de mantener rutinas de actualización periódicas y de conocer en profundidad la arquitectura de PHP en el propio servidor. En entornos con múltiples versiones y repositorios de terceros, la actualización automática no siempre es suficiente: es necesario verificar que los componentes críticos estén efectivamente parcheados.
Para los administradores que gestionan varios medios digitales o sitios web en un mismo servidor, la recomendación es clara: priorizar la actualización, verificar el estado real de cada rama y no dar por sentado que el metapaquete actualizado implica un servidor seguro.
Apoya el periodismo independiente
Sinpe 6334-5121 | Donar Aquí