PHP publicou actualizacións de seguridade para corrixir dúas vulnerabilidades críticas que permiten executar código de maneira remota en servidores que procesan peticións web. Os fallos, identificados como CVE-2026-109618 e CVE-2026-109619, teñen unha gravidade de 9,2 sobre 10 e poden facilitar ataques contra sitios web, roubo de datos e modificación de contidos.
As versións corrixidas son PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O equipo de desenvolvemento recomenda actualizar canto antes todas as instalacións afectadas, xa que os ataques non requiren autenticación e poden comprometer os servidores vulnerables.
As dúas vulnerabilidades afectan a instalacións de PHP que atenden peticións web, incluídas as que utilizan PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. O risco é especialmente elevado nas instalacións de Apache con mod_php, nas que se demostrou que unha petición sen autenticar pode desencadear o ataque antes de que se execute o código da aplicación.
O primeiro fallo, CVE-2026-109618, está relacionado coa xestión de erros por falta de memoria. Cando se produce esta situación, PHP pode interromper o procesamento cunha parte dos datos internos da petición aínda sen inicializar correctamente. A posterior limpeza destes recursos pode interpretar como válidos datos inconsistentes, o que abre a porta á execución remota de código.
O segundo, CVE-2026-109619, deriva da persistencia de estado interno despois de liberar a memoria que o almacenaba. Unha petición posterior procesada polo mesmo traballador pode empregar eses datos obsoletos antes de que se complete a inicialización habitual, permitindo tamén executar código de maneira remota.
A dimensión potencial do problema é considerable. Un investigador de seguridade estima que máis de 1,3 millóns de servidores accesibles desde Internet poderían estar afectados. Wordfence, provedor de ferramentas de seguridade para WordPress, advertiu de que os sitios baseados neste xestor de contidos tamén están expostos, xa que dependen de servidores que executan PHP. WordPress supera o 40 % de cota de uso na web, polo que a vulnerabilidade pode ter un impacto moi amplo.
A actualización de PHP non se instala mediante o sistema habitual de actualizacións automáticas de WordPress. Os administradores deben comprobar que versión executan os seus servidores e coordinar a instalación das correccións co provedor de aloxamento ou co responsable da infraestrutura. As distribucións de Linux e os provedores de versións con soporte prolongado recibiron os parches con antelación, polo que cómpre comprobar a dispoñibilidade dos paquetes actualizados correspondentes.
As instalacións de PHP 8.1 e anteriores requiren especial atención, xa que esas versións xa non reciben actualizacións ordinarias do proxecto PHP. Algunhas distribucións e provedores de soporte prolongado poden ofrecer correccións adaptadas, mentres que o equipo de desenvolvemento tamén publicou parches mínimos para PHP 7.4, 8.0 e 8.1 destinados a quen compila o código fonte ou non dispón de paquetes actualizados do seu provedor.
O equipo de resposta a emerxencias informáticas da Unión Europea e o Centro Nacional de Ciberseguridade do Reino Unido recomendaron illar os servizos accesibles desde Internet ou desconectalos temporalmente se non é posible aplicar as correccións de inmediato. GrapheneOS, pola súa banda, retirou temporalmente da rede o seu foro de usuarios para reducir a exposición ante posibles ataques.
Investigadores de Sansec anticiparon unha vaga de ataques masivos pouco despois da publicación das actualizacións, mentres que Cloudflare comunicou a detección de intentos temperáns contra sitios que utilizan PHP e anunciou cambios temporais nas regras da súa devasa para limitar o risco.
O equipo de seguridade de PHP insiste en que só a instalación das actualizacións resolve completamente as vulnerabilidades. Mentres non sexa posible actualizar, recomenda aplicar medidas adicionais para reducir a exposición, como limitar o tamaño das peticións, desactivar determinadas funcións relacionadas co progreso das cargas de sesión e reiniciar os procesos afectados. Estas medidas, porén, non garanten que os sistemas queden protexidos.
