21 de octubre de 2026 | PHP | Seguridad informática
El 21 de octubre de 2026, el equipo de seguridad de PHP publicó actualizaciones para todas las versiones de PHP que aún cuentan con soporte. Corrigen dos vulnerabilidades críticas que se han dado a conocer como PHP2Shell. La BSI ha emitido una advertencia al respecto y exige parchear sin demora los sistemas afectados. Quien opere un servidor web con PHP debería actuar hoy mismo. Esto vale también para todos los que «solo» operan un WordPress, Nextcloud o Joomla, pues estas aplicaciones se ejecutan sobre PHP.
Este artículo resume qué ha ocurrido, qué versiones de PHP están afectadas, qué versión necesita ahora y cómo comprobar en pocos minutos si su servidor está protegido.
Contenido de este artículo
- ¿Qué ha ocurrido? La cronología
- Las dos vulnerabilidades de PHP de un vistazo
- ¿Quién está afectado?
- Estas versiones de PHP son seguras
- Así comprueba y actualiza su servidor
- PHP 8.1 y anteriores: sin actualización oficial
- Medidas provisionales y la cuestión de «¿desconectar el servidor?»
- Preguntas frecuentes
- Asistencia de Biricon IT Services
¿Qué ha ocurrido? La cronología
El equipo de seguridad de PHP anunció de antemano la publicación de las correcciones para que los proveedores de alojamiento y los administradores tuvieran tiempo de prepararse. La publicación en sí tuvo lugar el 21 de octubre de 2026. La BSI emitió su advertencia (versión 1.1) ese mismo día.
- 20 de octubre de 2026: aviso previo del equipo de seguridad de PHP de que al día siguiente aparecerán actualizaciones de seguridad.
- 21 de octubre de 2026, 14:00 UTC (16:00 h CEST): se publican los parches para PHP 8.5, 8.4, 8.3 y 8.2.
- 21 de octubre de 2026: la BSI advierte de las «vulnerabilidades críticas que amenazan a las aplicaciones web en todo el mundo» y recomienda parchear sin demora. Según la BSI, grandes proveedores de alojamiento han desconectado en parte servidores de forma preventiva.
Las dos vulnerabilidades de PHP de un vistazo
Se trata de dos errores independientes en el núcleo de PHP: CVE-2026-109618 y CVE-2026-109619. Según el equipo de seguridad de PHP, ambos pueden hacer que un atacante ejecute código en el servidor sin iniciar sesión (unauthenticated Remote Code Execution). Las vulnerabilidades se valoran con CVSS v4.0: 9,2 (crítico).
| Característica | Significado |
|---|---|
| Identificadores | CVE-2026-109618 y CVE-2026-109619 |
| Valoración | CVSS v4.0: 9,2 — crítico |
| Efecto | Ejecución de código en el servidor (Remote Code Execution), sin inicio de sesión |
| Causa 1 | Memoria dañada cuando PHP se queda sin memoria durante el procesamiento (Out-of-Memory) |
| Causa 2 | Estado global obsoleto que permanece en la memoria entre solicitudes |
| Especialmente expuesto | Apache con mod_php |
Según la valoración de la BSI, en el momento de la publicación no había ataques confirmados, pero sí indicios no confirmados de intentos de explotación. En el caso de vulnerabilidades críticas en un software tan extendido, la experiencia indica que hay que contar con que los atacantes analicen las correcciones y preparen ataques automatizados. Por eso la ventana de tiempo para parchear es corta.
¿Quién está afectado?
En principio está afectado cualquier servidor en el que se ejecute PHP, con independencia de cómo esté integrado PHP: PHP-FPM, mod_php en Apache, php-cgi, FrankenPHP o LiteSpeed. Según el equipo de seguridad de PHP, el riesgo es mayor con Apache con mod_php.
La BSI menciona expresamente aplicaciones que se basan en PHP y que por ello pueden verse también afectadas:
- Sistemas de gestión de contenidos: WordPress, Drupal, TYPO3, Joomla
- Sistemas de tienda: Magento
- Nube y almacenamiento de archivos: Nextcloud
- Interfaces de cortafuegos: pfSense, OPNsense
La propia aplicación no tiene por qué ser defectuosa para ello. La vulnerabilidad está en PHP, por lo que actualizar solo WordPress, Nextcloud & Co. no ayuda. Hay que actualizar la versión de PHP del servidor. En cortafuegos como pfSense y OPNsense, la versión de PHP corregida llega con la respectiva actualización de firmware del fabricante.
Estas versiones de PHP son seguras
Las vulnerabilidades están corregidas en las siguientes versiones. Todo lo anterior se considera vulnerable.
| Rama de PHP | Mínimo requerido | Nota |
|---|---|---|
| PHP 8.5 | 8.5.12 | rama actual |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | El soporte termina el 31 de diciembre de 2026 |
| PHP 8.1 y anteriores | sin actualización oficial, véase abajo | |
Así comprueba y actualiza su servidor
1. Determinar la versión de PHP instalada
En la línea de comandos del servidor, php -v muestra la versión de PHP de la línea de comandos. El servidor web puede utilizar una versión de PHP distinta. Por ello, compruebe también la versión de PHP-FPM o del módulo de Apache, por ejemplo con php-fpm8.3 -v o mediante una página que muestre phpinfo() (eliminarla inmediatamente después).
2. Instalar la actualización mediante la gestión de paquetes
En Debian, Ubuntu, RHEL y derivadas, la versión corregida llega a través de la gestión de paquetes habitual, por ejemplo apt update && apt upgrade o dnf upgrade. En fuentes de terceros como el PPA de Sury o el repositorio de Remi, los nuevos paquetes suelen aparecer con rapidez.
apt changelog php8.3-fpm o rpm -q --changelog php | grep CVE-2026-1096).
3. Reiniciar el servicio PHP
Una actualización de paquetes por sí sola no basta: los procesos de PHP en ejecución conservan el código antiguo en memoria. Reinicie PHP-FPM (systemctl restart php8.3-fpm) o Apache (systemctl restart apache2) y compruebe después si los procesos se iniciaron tras la actualización.
4. Webs alojadas
En el alojamiento compartido, por lo general actualiza el proveedor. En el menú de cliente suele poder configurarse la versión de PHP por web. Elija allí una de las versiones seguras indicadas arriba, o pregunte al proveedor por el estado de los parches. Según la BSI, algunos proveedores han desconectado servidores de forma preventiva. Si su página no está accesible durante un breve tiempo, esa puede ser la causa.
PHP 8.1 y anteriores: sin actualización oficial
Para PHP 8.1 y anteriores ya no hay actualizaciones de seguridad oficiales. Los operadores de estos sistemas tienen dos opciones:
- Cambiar a una versión con soporte (recomendado). Cuanto más antigua es la versión, mayor es el esfuerzo de adaptación de la aplicación y las extensiones, por lo que conviene probar antes el cambio.
- Portar las correcciones hacia atrás (backport). El equipo de seguridad de PHP ha puesto a disposición las correcciones en ramas de desarrollo en GitHub. Quien compila PHP por sí mismo puede incorporar estos cambios a versiones más antiguas. Es una solución provisional y requiere conocimientos especializados.
También PHP 8.2 cuenta con soporte solo hasta el 31 de diciembre de 2026. Planifique por ello ya ahora el paso a PHP 8.4 u 8.5 y no lo aplace al cambio de año.
Medidas provisionales y la cuestión de «¿desconectar el servidor?»
Con el anuncio, el equipo de seguridad de PHP describió también medidas de protección provisionales. Estas reducen el riesgo, pero no cierran del todo las vulnerabilidades. No sustituyen la actualización y solo están pensadas para salvar el tiempo hasta la actualización.
Si un servidor debe desconectarse de la red hasta la actualización depende de su importancia y de su accesibilidad. La BSI señala que los grandes proveedores han dado este paso. Como regla general:
- Servidor accesible públicamente, actualización posible ahora: parchear de inmediato, no es necesario apagarlo.
- Servidor accesible públicamente, actualización no posible a corto plazo: restringir el acceso (por ejemplo, mediante el cortafuegos solo para direcciones conocidas) o apagar el servicio temporalmente, especialmente con
mod_php. - Servidor accesible solo internamente: parchear con prontitud; la urgencia es menor.
Preguntas frecuentes
¿Tengo que actualizar WordPress, Joomla o Nextcloud?
No por esta vulnerabilidad. Se encuentra en PHP, no en la aplicación. Actualice la versión de PHP en el servidor. Aun así, actualizar la aplicación es recomendable, con independencia de lo anterior.
¿Cómo puedo saber si alguien ya ha explotado la vulnerabilidad?
Es difícil dar una respuesta segura. Son señales de alerta los archivos PHP desconocidos en el directorio web, los procesos inusuales bajo el usuario del servidor web, las cuentas de usuario o tareas cron nuevas y el tráfico saliente inusual. Ante una sospecha concreta, conviene realizar un análisis forense del sistema y, en caso de duda, reinstalarlo.
¿Basta con un Web Application Firewall?
Un firewall puede interceptar patrones de ataque conocidos, pero no sustituye a la actualización. Encontrará más información sobre la combinación de varias capas de protección en nuestro artículo Proteger Odoo 19: firewall, 2FA & Web RBL. Los principios son válidos para cualquier aplicación web.
¿Afecta a Odoo?
No. Odoo está escrito en Python y no se ejecuta sobre PHP. Solo se verían afectadas las aplicaciones PHP que se ejecuten en el mismo servidor.
¿Dónde encuentro la información oficial?
El anuncio del equipo de seguridad de PHP se encuentra en los archivos de noticias de php.net (entrada del 20 de octubre de 2026); las versiones, en php.net/downloads. La advertencia de la BSI lleva el número 2026-297981-1032 y se ha publicado en bsi.bund.de .
Asistencia de Biricon IT Services
Si no está seguro de qué versión de PHP se ejecuta en su servidor o necesita ayuda con la aplicación de parches, estaremos encantados de ayudarle: con el inventario de todos los sistemas PHP, con la instalación de las actualizaciones, con la migración a una versión de PHP con soporte y con la comprobación de posibles compromisos. Como proveedor de servicios informáticos, gestionamos servidores, firewalls y aplicaciones web para pequeñas y medianas empresas.
Situación a 21 de octubre de 2026. La situación puede cambiar en poco tiempo; son determinantes las publicaciones del equipo de seguridad de PHP y de la BSI.