Vulnerabilidad de seguridad en PHP 2026: cómo comprobar y aplicar parches a los servicios web afectados

Interpretar correctamente el mensaje de alarma

La afirmación de que una vulnerabilidad de PHP podría afectar a „la mitad de Internet“ es un titular sensacionalista, pero no una cifra contrastada. No hay pruebas de que la mitad de todos los servicios de Internet sean vulnerables o ya se hayan visto comprometidos. No obstante, el riesgo real es considerable, ya que PHP se utiliza como entorno de ejecución en muchos sitios web, tiendas online, API e interfaces de administración.

Lo decisivo no es si un sitio web utiliza PHP, sino qué versión de PHP procesa sus solicitudes web. Las actualizaciones de seguridad del 21 de octubre de 2026 afectan, en principio, a las instalaciones sin parches de las ramas compatibles, siempre que atiendan solicitudes a través de un servicio web. Por lo tanto, un PHP local destinado a tareas de desarrollo debe evaluarse de forma diferente a un portal de clientes accesible desde el exterior.

El Exposición en Internet La urgencia es un factor determinante. Una tienda accesible al público con formularios y funciones de carga de archivos ofrece más puntos de contacto potenciales que un servicio interno aislado. Sin embargo, un servicio interno tampoco es automáticamente seguro: los accesos mediante VPN, las cuentas comprometidas u otros sistemas de la red pueden hacer que sea accesible. Por lo tanto, el alcance por sí solo no sustituye a una evaluación técnica de riesgos.

Igualmente importantes son el modo de funcionamiento y Soporte para parches. PHP puede ejecutarse, por ejemplo, a través de PHP-FPM, como módulo de Apache, mediante php-cgi o integrado en un producto. Varios dominios en el mismo servidor pueden tener diferentes versiones y métodos de actualización. Dar el visto bueno general a todos los sitios web de PHP sería tan erróneo como suponer que todas las instalaciones son vulnerables de inmediato.

Lo que permiten técnicamente las vulnerabilidades de PHP

A Ejecución remota de código (RCE) significa que, en determinadas condiciones, un atacante puede ejecutar código en un sistema remoto. Según el aviso de seguridad, estas vulnerabilidades de PHP no requieren un inicio de sesión previo. El código se ejecutaría inicialmente con los permisos del proceso web, no automáticamente con permisos de administrador sin restricciones. Por lo tanto, las posibles consecuencias dependen en gran medida de los permisos de los archivos, los datos de acceso y la segregación del servidor.

CVE-2026-109618 afecta a rutas de error en Escasez de almacenamiento. Si PHP interrumpe una solicitud debido a un estado de falta de memoria, las estructuras de datos internas pueden quedar incompletas. Si estas estructuras se siguen utilizando durante la limpieza de la solicitud, puede producirse un daño en la memoria. La descripción oficial menciona, en particular, las solicitudes multiparte, las subidas de archivos y el consumo de memoria al analizar entradas anidadas como contextos técnicos relevantes.

Por el contrario, CVE-2026-109619 afecta a un estado interno vinculado a una solicitud cuya memoria ya ha sido liberada. Si, posteriormente, un worker reutilizado procesa otra solicitud, PHP puede acceder a ese estado obsoleto antes de que se aplique la inicialización normal. El aviso de seguridad hace referencia, entre otras cosas, al progreso de la carga de sesiones y a las rutas de error. Esto describe la clase de error, no es una guía para su explotación.

• Las solicitudes web a través de PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed pueden verse afectadas.
• Los errores se producen en el entorno de ejecución de PHP, no principalmente en WordPress, Joomla, Shopware, los temas o los plugins concretos.
• Los CMS y los marcos de trabajo influyen en las funciones disponibles, como las subidas de archivos, pero no sustituyen a una actualización del intérprete.

Por qué no todas las instalaciones corren el mismo riesgo

El hecho de que un servicio esté expuesto a riesgos en la práctica depende de varios factores. Los más importantes son un entorno de ejecución web PHP sin parches y un servicio web accesible. A continuación, hay que tener en cuenta el modo de funcionamiento, los procesos reutilizados, las funciones de subida de archivos o los formularios complejos, así como los permisos de la cuenta del proceso web. Un servicio con amplios permisos de escritura sobre archivos web o con acceso a otros servicios puede tener consecuencias más graves que un proyecto estrictamente aislado.

En Apache, con mod_php El proyecto PHP hace especial hincapié en el riesgo: un ataque documentado puede desencadenarse incluso antes de que se ejecute el código real de la aplicación. Un CMS bien mantenido no protege, por tanto, contra esta vulnerabilidad en tiempo de ejecución. Esto no significa que PHP-FPM, php-cgi, FrankenPHP o LiteSpeed se consideren seguros; si no están actualizados, también deben revisarse de forma prioritaria.

Además, hay que prestar especial atención a los productos que contienen PHP incrustado. Entre ellos pueden figurar imágenes de contenedores, dispositivos preconfigurados, sistemas de gestión de NAS o productos de red cuya interfaz utilice PHP de forma interna. En estos casos, un comando ejecutado en el servidor a menudo no muestra el tiempo de ejecución real. Además, la actualización del sistema operativo no corrige automáticamente un componente de PHP vulnerable presente en una imagen o en un producto del fabricante.

Un cortafuegos, un cortafuegos de aplicaciones web o unos límites restrictivos de subida de archivos pueden dificultar las solicitudes individuales y reducir la superficie de ataque. Sin embargo, no sustituyen a la corrección del error, ya que no corrigen la gestión defectuosa de la memoria y del estado en el intérprete. Incluso un CMS sin errores depende de un entorno de ejecución seguro. Por lo tanto, es fundamental comprobar y actualizar el estado de los parches del PHP que realmente procesa las solicitudes web.

Comparar el estado de las actualizaciones y el estado del soporte técnico

En cuanto a estas dos vulnerabilidades, lo que cuenta en primer lugar es el estado de los parches dentro de la rama de PHP utilizada. El proyecto PHP indica versiones corregidas concretas para las series compatibles. Las versiones anteriores de la misma serie se consideran afectadas; la solución completa prevista es actualizar a la versión indicada o a una más reciente de esta rama.

A Actualización de parche permanece dentro de la misma línea de desarrollo, por ejemplo, de la versión 8.3.35 a la 8.3.36. Su objetivo es proporcionar la corrección de seguridad y tiene un marco de compatibilidad más restringido que un cambio de la versión 8.2 a la 8.4. Esta última es una migración: para ello, deben comprobarse por separado las dependencias, las extensiones, el código de la aplicación y, en su caso, la implementación.

PHP 8.2 sigue siendo válido para la corrección inmediata, siempre que se utilice, como mínimo, la versión 8.2.35. Sin embargo, esta rama dejará de recibir soporte el 31 de diciembre de 2026. Por ello, no conviene quedarse en esta versión de actualización inmediata: planifica la migración a una rama con un periodo de soporte más prolongado, una vez que se haya comprobado la compatibilidad de la aplicación en un entorno adecuado.

En el caso de PHP 8.1 y versiones anteriores, hay que actuar con especial precaución. El proyecto PHP no ofrece una versión oficial actualizada para ello; los retroportes mínimos del código fuente no equivalen a un paquete disponible de forma generalizada y mantenido. Un backport de seguridad documentado por el proveedor del sistema operativo puede ser adecuado, pero requiere una constatación en el aviso de seguridad o en el registro de cambios del paquete. Si no existe, es necesaria una migración en lugar de un mero cambio cosmético de versión.

Comprobar el tiempo de actividad real del sitio web

La comprobación de la versión comienza con un análisis del estado actual, pero no debe limitarse al shell. En un servidor autogestionado, los siguientes comandos muestran la versión del comando PHP ejecutado en él y los archivos de configuración detectados por dicha ejecución. No modifican ni los paquetes ni la configuración, por lo que son adecuados como primer paso de comprobación, con un riesgo mínimo.

php -v
php --ini

La salida solo describe la función a la que se accede mediante este comando de shell Tiempo de ejecución de la CLI. Por el contrario, un sitio web puede ejecutarse mediante PHP-FPM, Apache con mod_php, php-cgi o un contenedor. Este entorno de ejecución web puede utilizar una versión de PHP y archivos de configuración diferentes a los del comando php -v en el servidor. Para la evaluación de seguridad, lo determinante es el proceso que gestiona las solicitudes HTTP reales.

Por eso, en el alojamiento gestionado, debes comprobar en el panel de control la versión de PHP seleccionada para cada proyecto o dominio y, si es necesario, consultar el estado de los parches del servicio proporcionado. Si hay varios dominios, hay que comprobar cada asignación por separado: es posible que un dominio principal ya utilice la rama actualizada, mientras que una tienda online, una instancia de pruebas o un subdominio sigan utilizando un intérprete más antiguo.

En los servidores con PHP-FPM, la configuración del servicio, los paquetes instalados y la documentación de implementación deben ir de la mano. En entornos de contenedores, además, debes comprobar la imagen realmente desplegada y no solo un manifiesto de compilación local. Lo decisivo es qué revisión del pod o contenedor en ejecución acepta las solicitudes web; una imagen base actualizada no protege a una instancia anterior que ya esté en ejecución.

Planificar las rutas de actualización según el modo de funcionamiento

La forma adecuada de actualizar depende de quién suministre el intérprete y dónde se ejecute. Solo cuando quede claro este ámbito de responsabilidad se podrá decidir con fiabilidad si es necesario un cambio de panel, una actualización del paquete, una nueva imagen o una actualización del fabricante. La siguiente clasificación distingue entre estos casos, sin equiparar los modos de funcionamiento en cuanto a su riesgo.

En el caso del alojamiento compartido, el proveedor debe proporcionar el nivel de parches de seguridad correspondiente a la versión de PHP seleccionada; a continuación, el administrador comprueba la aplicación. En el caso de PHP-FPM o mod_php, el administrador suele actualizar los paquetes y, a continuación, reinicia de forma controlada el servicio correspondiente. Un simple reinicio sin aplicar el parche no sustituye a la actualización.

Las distribuciones de Linux suelen ofrecer parches de seguridad en forma de Retroportación. En ese caso, el número de versión visible del paquete puede diferir del de las versiones publicadas en php.net, aunque la corrección esté incluida. Por lo tanto, no te limites a comparar cadenas de caracteres como „8.4.26“, sino que lee el aviso de seguridad y el registro de cambios del distribuidor. El proyecto PHP señala que las distribuciones y los proveedores de versiones LTS pueden recibir parches.

Los contenedores requieren un proceso específico: compilar una imagen corregida u obtenerla del proveedor, implementarla y sustituir las instancias antiguas. En el caso de las interfaces NAS, los dispositivos de red o las aplicaciones web ya preparadas, la corrección recae, en cambio, en el producto del fabricante. Un parche del sistema operativo del host no llega necesariamente al intérprete integrado; por ello, el inventario y las instrucciones del fabricante siguen siendo imprescindibles.

Medidas inmediatas sin falsa sensación de seguridad

El día de la actualización, lo primero que debes hacer es elaborar un inventario exhaustivo: dominios, API, interfaces de administración, contenedores y productos que puedan tener PHP integrado. Anota, para cada servicio, el modo de funcionamiento web, el canal de actualización correspondiente y el entorno de ejecución de PHP que se utiliza realmente. A continuación, se dará prioridad a todos los servicios accesibles públicamente o críticos para el negocio, y no solo al servidor con el número de versión más llamativo.

A continuación, instala la actualización de seguridad publicada por el proveedor de alojamiento, el distribuidor de Linux, el fabricante de la imagen o el fabricante del producto. Para las ramas de PHP compatibles, la actualización al estado de parches corregido constituye la solución completa; ni un WAF, ni las reglas de subida de archivos, ni un reinicio del servidor web la sustituyen. Planifica el proceso de tal manera que la actualización del paquete, la imagen o del fabricante quede documentada de forma clara y pueda rastrearse en caso de que surjan problemas.

Tras la actualización, hay que todos los antiguos trabajadores se deben cerrar y sustituir por procesos que hayan cargado de forma comprobada el tiempo de ejecución parcheado. Utiliza una recarga solo si la gestión concreta del servicio garantiza esta sustitución completa; de lo contrario, es necesario realizar un reinicio controlado. A continuación, comprueba las horas de inicio de los procesos, el estado de los servicios o el tiempo de ejecución web determinado internamente, en lugar de limitarte a dar por hecho que la sustitución se ha realizado. En el caso de los contenedores, implementa la imagen corregida y elimina todas las instancias antiguas.

A continuación, comprueba los procesos clave de la aplicación, como el inicio de sesión, los formularios, las subidas de archivos, el proceso de pago y las API. Las pruebas muestran si la aplicación y las extensiones funcionan con los parches actualizados; sin embargo, por sí solas no demuestran ni la sustitución completa de los workers ni la ausencia de un compromiso previo. Estos aspectos deben evaluarse por separado mediante pruebas operativas y de seguridad.

Si no es posible aplicar un parche a corto plazo, algunos ajustes concretos pueden limitar las vías de ataque conocidas, pero no garantizan una seguridad total. La desactivación del indicador de progreso de la subida debe estar activa antes de que se analice una solicitud. Comprueba previamente si hay aplicaciones o interfaces que necesiten este indicador de progreso y, a continuación, reinicia cada worker de PHP correspondiente. A continuación, verifica que ningún proceso antiguo siga funcionando con la configuración anterior.

session.upload_progress.enabled = 0

Los límites conservadores para los datos POST y otras opciones mencionadas en el aviso de seguridad tampoco pueden reducir la superficie de ataque más que parcialmente. Los datos leídos tardíamente .user.ini-archivos o un ini_set() Las medidas dentro de la propia aplicación no son suficientes para esta configuración. Considera estas medidas como una reducción temporal del riesgo y mantén como objetivo la actualización de seguridad.

Hay que distinguir esto de la gestión habitual de las sesiones guardadas. La contribución a la Recolección de basura de sesiones en PHP explica cómo interactúan la limpieza, el acceso a los archivos y los procesos de trabajo durante el funcionamiento normal. Sin embargo, esta optimización operativa no subsana las vulnerabilidades aquí tratadas y no sustituye ni al parche corregido de PHP ni a la posterior sustitución de los procesos en ejecución.

Tras la aplicación del parche, comprueba el funcionamiento y detecta posibles anomalías

Una actualización de paquetes completada con éxito solo demuestra, en un primer momento, que se han instalado archivos o paquetes. No confirma ni que el proceso web haya cargado el nuevo entorno de ejecución, ni que la aplicación funcione correctamente con él. Por lo tanto, tras el reinicio, comprueba el entorno de ejecución web correspondiente al servicio y documenta la hora, la versión, el servicio reiniciado y el resultado de la comprobación de funcionamiento.

Las pruebas funcionales deben abarcar los procesos principales reales: páginas públicas importantes, inicio y cierre de sesión, envío de formularios, carga de archivos, proceso de pago o reserva, así como puntos finales de la API y tareas en segundo plano. Prueba únicamente las operaciones para las que tengas autorización y, en el caso de tiendas en producción, utiliza en la medida de lo posible los datos de prueba previstos para ello. Comprueba al mismo tiempo los registros del servidor web, de PHP y de la aplicación en busca de nuevos errores, fallos recurrentes o códigos de estado inesperados.

Es necesario un nuevo comienzo para establecer procesos duraderos y Trabajador Cargarlo con el código actualizado no genera por sí mismo ninguna corrección. Si no se instala la actualización, la vulnerabilidad persiste. En caso de alta carga de trabajo, la ventana de mantenimiento debería elegirse de tal forma que las solicitudes puedan procesarse de manera ordenada y se puedan observar los efectos de un reinicio del worker.

El impacto que tiene un reinicio controlado en el rendimiento depende del número y la carga de trabajo de los procesos PHP. A la hora de planificar, es útil tener en cuenta las colas, los trabajos en curso y las transacciones críticas, en lugar de cerrar los procesos de forma descoordinada. La guía Entender los «workers» de PHP explica el papel que desempeñan estos procesos en las consultas dinámicas paralelas.

Si se producen anomalías tras la aplicación del parche, distingue entre errores de compatibilidad de la aplicación y una implementación incompleta. Compara la configuración, las extensiones activadas y el entorno de ejecución web con el estado anterior al mantenimiento. Una reversión no debe dar lugar a que un servicio accesible al público permanezca de forma permanente en un estado vulnerable; en tal caso, establece rápidamente una ruta de actualización compatible y parcheada.

Dar prioridad a las instalaciones antiguas y ocultas de PHP

Hay que prestar especial atención a los sistemas en los que PHP no aparece como un entorno de ejecución instalado de forma deliberada: imágenes de Docker, dispositivos virtuales, NAS e interfaces de red, así como productos de software ya preparados. Una actualización del host no actualiza automáticamente ni una imagen de contenedor ni el entorno de ejecución interno incluido en un producto del fabricante. Por ello, es recomendable preguntar específicamente a los fabricantes por su evaluación y por una actualización de seguridad para el producto concreto.

En el caso de las ramas antiguas, hay que distinguir claramente entre tres situaciones. Una versión de PHP con soporte oficial recibe las actualizaciones de seguridad publicadas por el proyecto PHP. Un backport de una distribución o de un proveedor puede contener la corrección a pesar de que el número de versión visible sea diferente, pero debe estar justificado por el aviso de seguridad o el registro de cambios de dicho proveedor. Por el contrario, el código fuente mantenido por uno mismo conlleva la responsabilidad propia de la compilación, las pruebas y el funcionamiento; no es un sustituto equivalente a un canal de actualizaciones oficial.

PHP 8.1 y las ramas anteriores ya no recibirán versiones oficiales periódicas. Aunque hay disponible un parche corregido para PHP 8.2, esta rama dejará de recibir soporte a finales de 2026. Utiliza una solución disponible para la situación actual, pero, en el caso de versiones antiguas o que están a punto de dejar de recibir soporte, planifica además una versión probada Migración a una rama con soporte a largo plazo.

1. Actualiza primero los servicios accesibles al público que tengan un entorno de ejecución de PHP sin parches, especialmente si permiten subir archivos o contienen funciones de administración.
2. No utilices Apache con mod_php inmediatamente después de gestionar tiendas, API o portales de clientes críticos para el negocio; el aviso de seguridad oficial destaca que mod_php presenta un riesgo especialmente grave.
3. Registrar contenedores, dispositivos y productos de terceros basándose en imágenes, inventario y estado del fabricante; la ausencia de paquetes PHP visibles no es motivo para bajar la guardia.
4. Aislar los servicios que no cuentan con soporte o para los que no se pueden aplicar parches a corto plazo y restringir el acceso a los mismos, al tiempo que se planifica de forma vinculante su sustitución, actualización o migración.

La segmentación de la red, la obligación de utilizar una VPN o las normas de acceso restrictivas pueden ganar tiempo cuando las interfaces de administración no se pueden parchear de inmediato. Sin embargo, solo son Medidas transitorias, ya que las cuentas de usuario internas, los dispositivos comprometidos y los recursos compartidos mal configurados pueden seguir constituyendo vías de ataque. Si no se ofrece una solución para un producto o si la rama de PHP ha dejado de recibir soporte de forma permanente, la decisión más sensata es sustituirlo o migrar.