O equipo de seguridade de PHP anunciou unha actualización extraordinaria para corrixir dúas vulnerabilidades críticas que poderían permitir a execución remota de código en servidores afectados. Os fallos, identificados provisionalmente como CVE-2026-109618 e CVE-2026-109619, presentan unha puntuación CVSS v4.0 de 9,2 cada un. Recoméndase ás organizacións identificar as súas instalacións de PHP e preparar a aplicación inmediata das correccións oficiais.
O equipo responsable do desenvolvemento e mantemento de PHP comunicou a publicación dunha actualización extraordinaria de seguridade para corrixir dúas vulnerabilidades críticas que afectan á contorna de execución utilizada por numerosas aplicacións e servizos web.
A publicación está prevista para o 21 de outubro de 2026 ás 16:00 horas, hora peninsular española. O equipo de PHP indicou que podería adiantarse se se divulgan detalles técnicos adicionais ou aparecen evidencias de explotación activa.
As análises técnicas preliminares relacionan estas vulnerabilidades con posibles escenarios de execución remota de código (RCE). Este tipo de fallo pode permitir que un atacante execute instrucións non autorizadas no servidor afectado, coas consecuencias que poidan derivarse dos privilexios do proceso comprometido e da configuración de seguridade do sistema.
PHP é unha tecnoloxía amplamente utilizada para desenvolver e executar aplicacións web. Está presente en portais corporativos, páxinas institucionais, plataformas de comercio electrónico, sistemas de xestión de contidos e servizos dixitais de administracións públicas e empresas.
Entre as plataformas que utilizan PHP atópanse WordPress, Drupal, Joomla, Magento, Adobe Commerce, WooCommerce e Shopware. Non obstante, o uso destas solucións non implica necesariamente que todas as súas instalacións sexan vulnerables. O risco efectivo dependerá da versión de PHP utilizada, da configuración do servidor e das condicións técnicas de explotación que confirme o fabricante.
Un aspecto especialmente relevante é que os fallos afectan ao propio intérprete PHP e non exclusivamente ás aplicacións desenvolvidas sobre el. Por este motivo, actualizar unicamente un xestor de contidos, as súas extensións ou os seus complementos non garante a corrección destas vulnerabilidades.
A información dispoñible indica que se difundiron detalles preliminares antes da publicación coordinada das correccións. Esta circunstancia incrementa a necesidade de adoptar medidas preventivas, aínda que non se dispón dunha caracterización oficial completa dos vectores de explotación nin do alcance dos posibles incidentes.
Vulnerabilidades identificadas
Os identificadores asociados provisionalmente ás vulnerabilidades son os seguintes.
| Identificador | CVSS v4.0 | Impacto potencial |
| CVE-2026-109618 | 9,2 · Crítica | Execución remota de código |
| CVE-2026-109619 | 9,2 · Crítica | Execución remota de código |
O equipo de seguridade de PHP confirmou a existencia de dúas vulnerabilidades críticas cunha puntuación CVSS v4.0 de 9,2 cada unha. A asociación destes identificadores CVE e os detalles sobre a posible execución remota de código proceden de análises técnicas difundidas antes da publicación do aviso definitivo.
A información completa sobre as condicións de explotación, as versións afectadas e as correccións específicas deberá contrastarse co aviso oficial do proxecto PHP.
Versións potencialmente afectadas
A información preliminar difundida por investigadores de seguridade apunta a unha posible afectación de instalacións de PHP desde a versión 5.4. Non obstante, este alcance procede de fontes externas e debe considerarse provisional ata a confirmación oficial.
As ramas que contan con soporte oficial do proxecto PHP son:
- PHP 8.2.
- PHP 8.3.
- PHP 8.4.
- PHP 8.5.
As versións PHP 5.x, 7.x, 8.0 e 8.1 atópanse fóra do soporte oficial. Estas instalacións deberán revisarse de maneira prioritaria e, cando corresponda, migrarse a versións mantidas.
Determinadas distribucións Linux e provedores comerciais poden seguir proporcionando correccións de seguridade para versións antigas mediante parches retroportados. Nestes casos, deberá comprobarse expresamente se o provedor ofrece unha corrección que cubra as vulnerabilidades identificadas.
O feito de utilizar unha rama de PHP con soporte non garante por si só que a instalación estea protexida. É necesario verificar que incorpora as actualizacións de seguridade correspondentes.
Impacto potencial
A explotación dunha vulnerabilidade de execución remota de código podería permitir a realización de diferentes accións maliciosas sobre os sistemas afectados.
Entre as posibles consecuencias atópanse o acceso non autorizado á información almacenada no servidor, a modificación ou eliminación de ficheiros, a instalación de programas maliciosos, a alteración dos contidos publicados e a interrupción dos servizos.
En determinadas circunstancias, o acceso inicial tamén podería facilitar o roubo de credenciais, a consulta de configuracións sensibles ou novos intentos de acceso a sistemas internos.
A gravidade do impacto dependerá dos privilexios asociados ao proceso PHP, dos controis de illamento existentes e da exposición do servidor a redes externas.
Nas contornas de aloxamento compartido ou nas infraestruturas que prestan servizo a varias aplicacións, resulta especialmente importante avaliar o posible alcance dun compromiso e a separación de privilexios entre os diferentes servizos.
Medidas de mitigación
1. Actualización do intérprete PHP
A principal medida correctiva consiste en instalar unha versión de PHP que incorpore as correccións oficiais en canto estean dispoñibles.
As organizacións deberán verificar as versións publicadas polo equipo de PHP e aplicar as actualizacións correspondentes a todas as instalacións afectadas.
Recoméndase prestar especial atención aos sistemas que utilizan varias versións de PHP simultaneamente, xa sexa por requisitos de compatibilidade entre aplicacións ou pola coexistencia de intérpretes independentes para a liña de comandos, servidores web e procesos en segundo plano.
Actualizar unicamente WordPress, Drupal, Joomla, Magento ou outras aplicacións que utilizan PHP non corrixe necesariamente estas vulnerabilidades, dado que os fallos se atopan na propia contorna de execución.
2. Inventario e preparación dos sistemas
Antes da publicación das correccións, as organizacións deben identificar os activos potencialmente afectados e preparar a súa actualización.
Esta revisión deberá incluír servidores web, aplicacións corporativas, plataformas de comercio electrónico, xestores de contidos, contedores, imaxes Docker e servizos de aloxamento administrado.
Recoméndase documentar a versión de PHP instalada, o sistema operativo, a persoa ou equipo responsable do servizo, a súa exposición a Internet, as aplicacións dependentes e a criticidade da información tratada.
Os sistemas accesibles publicamente e aqueles que prestan servizos esenciais ou procesan información sensible deben recibir atención prioritaria.
Así mesmo, recoméndase reservar unha xanela de mantemento urxente, comprobar a compatibilidade das aplicacións nunha contorna de preprodución e verificar que existen copias de seguridade recuperables antes de introducir cambios.
Cando o mantemento de PHP dependa dun terceiro, deberá solicitarse ao provedor confirmación das versións instaladas e do calendario previsto para a súa actualización.
3. Medidas temporais de contención
Cando non sexa posible instalar inmediatamente as correccións, recoméndase reducir a superficie de exposición dos servizos potencialmente vulnerables.
Entre as medidas que poden adoptarse atópanse a restrición dos accesos mediante enderezos IP autorizados, redes privadas virtuais ou mecanismos de autenticación situados antes da aplicación.
Tamén debe valorarse o illamento temporal de Internet dos servizos que non poidan protexerse adecuadamente, especialmente cando procesen información sensible ou presten servizos esenciais.
A segmentación de rede pode limitar o acceso desde un servidor comprometido cara a outros sistemas internos. Do mesmo xeito, restrinxir as conexións saíntes innecesarias contribúe a dificultar determinadas accións posteriores ao compromiso.
Os cortalumes de aplicacións web (WAF) e os mecanismos de filtrado de tráfico poden proporcionar protección adicional fronte a determinados patróns de ataque. Non obstante, a súa eficacia dependerá do vector de explotación e das regras aplicadas.
Non existe, segundo a información oficial dispoñible antes da publicación das correccións, unha medida de configuración universal e validada que garanta a protección fronte a ambas as vulnerabilidades.
Por este motivo, non debe asumirse que desactivar determinadas funcións de xestión de sesións, carga de ficheiros ou procesamento de solicitudes HTTP elimina o risco.
Estas medidas temporais non substitúen a instalación das correccións oficiais.
4. Comprobacións posteriores á actualización
Unha vez aplicados os parches, deberá verificarse que os servizos utilizan efectivamente a versión corrixida do intérprete PHP.
Para iso, recoméndase reiniciar os procesos afectados, incluídos os servizos PHP-FPM ou os procesos do servidor web que correspondan segundo a arquitectura despregada.
Nos servidores que executen PHP mediante PHP-FPM, deberá comprobarse que os procesos de traballo se reiniciaron e utilizan os novos binarios. Cando PHP estea integrado directamente en Apache ou noutro servidor web, deberán seguirse os procedementos específicos correspondentes.
Tamén é importante diferenciar a versión de PHP dispoñible na liña de comandos da utilizada para atender as solicitudes web, xa que poden ser distintas.
O seguinte comando permite consultar a versión do intérprete dispoñible na liña de comandos:
php -v
Cando se utilice PHP-FPM, esta comprobación deberá complementarse coa verificación da versión e configuración utilizadas polo servizo, tendo en conta que o nome do executable pode variar segundo a distribución.
As comprobacións deberán realizarse sen expoñer publicamente información sensible sobre a configuración do servidor.
Nas infraestruturas baseadas en contedores, recoméndase reconstruír as imaxes cos compoñentes corrixidos e volver despregalas. Actualizar unicamente o sistema anfitrión non garante que os contedores incorporen a nova versión de PHP.
Finalmente, deberán realizarse probas funcionais das aplicacións e revisar os rexistros para identificar posibles erros derivados do proceso de actualización.
5. Sistemas con versións de PHP sen soporte
As instalacións que utilizan PHP 5.x, 7.x, 8.0 ou 8.1 requiren especial atención porque estas ramas finalizaron o seu ciclo de soporte oficial.
Nestes casos, a medida recomendada consiste en planificar a migración a unha versión mantida e compatible coas aplicacións utilizadas.
Cando a migración non poida realizarse de forma inmediata, deberá consultarse co provedor do sistema operativo, da distribución Linux ou do servizo de soporte contratado para determinar se existen correccións de seguridade retroportadas.
As organizacións deberán comprobar expresamente que estas correccións cobren as vulnerabilidades identificadas e non asumir que un paquete está protexido polo mero feito de recibir actualizacións xerais do provedor.
Ata dispoñer dunha solución, deberán reforzarse as restricións de acceso, o illamento dos sistemas e a supervisión de posibles actividades maliciosas.
Detección e revisión de posibles compromisos
Ante o risco de execución remota de código, recoméndase revisar os sistemas potencialmente afectados na procura de comportamentos anómalos.
A monitorización debería incluír os procesos asociados a PHP e aos servidores web, as comunicacións de rede e os cambios en ficheiros e configuracións.
Entre as evidencias que poden xustificar unha investigación atópanse:
- Execución de comandos inesperados. Aparición de procesos como sh, bash ou outros intérpretes iniciados desde php-fpm, php-cgi, apache2 ou httpd, cando non formen parte do funcionamento habitual da aplicación.
- Conexións saíntes anómalas. Comunicacións cara a enderezos IP, dominios ou servizos externos descoñecidos ou non previstos.
- Modificacións non autorizadas. Creación ou alteración de ficheiros en directorios web, especialmente ficheiros PHP descoñecidos que puidesen utilizarse como portas traseiras.
- Mecanismos de persistencia. Aparición de novas tarefas programadas, servizos, contas ou procesos que non fosen autorizados.
- Cambios de configuración. Modificacións inesperadas nos parámetros de PHP, nos servizos web ou nas políticas de acceso.
- Peticións HTTP sospeitosas. Solicitudes que presenten patróns pouco habituais, erros reiterados ou comportamentos incompatibles co uso lexítimo da aplicación.
Estes elementos constitúen indicadores xerais de posible compromiso de servidores web. Non deben interpretarse como indicadores exclusivos de CVE-2026-109618 ou CVE-2026-109619.
No momento de elaborar esta alerta non se dispón dunha relación oficial e completa de indicadores de compromiso específicos para ambas as vulnerabilidades.
A ausencia de alertas non garante que un sistema non fose comprometido. Se se identifican evidencias sospeitosas, recoméndase preservar os rexistros e demais información relevante antes de efectuar cambios que poidan dificultar a investigación.
En caso de compromiso confirmado ou sospeitado, deberán activarse os procedementos de resposta a incidentes da organización, avaliar o alcance do acceso non autorizado e determinar se puideron verse afectadas credenciais, información sensible ou outros sistemas conectados.
Recomendacións para administracións públicas e empresas
As organizacións que utilicen PHP deberían coordinar as actuacións entre os equipos de administración de sistemas, desenvolvemento, seguridade e continuidade de negocio.
En particular, resulta recomendable comprobar que os servizos contratados a terceiros contan con responsables identificados e procedementos de actualización definidos, incluídas as plataformas web xestionadas por provedores externos.
As administracións públicas deben prestar especial atención aos portais institucionais, sedes electrónicas e aplicacións que poidan incorporar compoñentes PHP, verificando a súa exposición e as dependencias tecnolóxicas existentes.
A xestión destas vulnerabilidades debería integrarse nos procedementos habituais de xestión de activos, actualización de compoñentes, tratamento de vulnerabilidades e resposta a incidentes.
No caso dos sistemas incluídos no ámbito de aplicación do Esquema Nacional de Seguridade (ENS), as actuacións deberán coordinarse cos procedementos establecidos para a protección dos sistemas de información, a xestión das vulnerabilidades e a resposta ante incidentes de seguridade.
Tamén se recomenda manter un rexistro das actuacións realizadas, das versións corrixidas, das comprobacións posteriores e das excepcións que deban manterse temporalmente.
Este rexistro permitirá acreditar as medidas adoptadas, facilitar o seguimento das correccións e identificar os sistemas nos que persista algún risco residual.
Xustificación da severidade
A alerta clasifícase con severidade crítica debido á puntuación CVSS v4.0 de 9,2 asignada a ambas as vulnerabilidades, á posibilidade de execución remota de código e á ampla utilización de PHP en infraestruturas web de empresas e administracións públicas.
A potencial afectación de servidores expostos a Internet, xunto coa difusión anticipada de información técnica antes da publicación das correccións, incrementa a urxencia de adoptar medidas preventivas.
A clasificación de severidade crítica corresponde ao impacto potencial das vulnerabilidades e non implica que se confirmase unha campaña de explotación xeneralizada.
