21 de outubro de 2026 | PHP | Seguridade informática
O 21 de outubro de 2026, o equipo de seguridade de PHP publicou actualizacións para todas as versións de PHP que aínda teñen soporte. Pechan dúas vulnerabilidades críticas coñecidas como PHP2Shell. O BSI emitiu unha advertencia ao respecto e esixe parchear sen demora os sistemas afectados. Quen opere un servidor web con PHP debería actuar hoxe mesmo. Isto vale tamén para todos os que operan «só» un WordPress, Nextcloud ou Joomla, porque estas aplicacións funcionan sobre PHP.
Esta publicación resume o que pasou, que versións de PHP están afectadas, que versión necesita agora e como comprobar en poucos minutos se o seu servidor está protexido.
Contido desta publicación
- Que pasou? A cronoloxía
- As dúas vulnerabilidades de PHP dunha ollada
- Quen está afectado?
- Estas versións de PHP son seguras
- Así comproba e actualiza o seu servidor
- PHP 8.1 e anteriores: sen actualización oficial
- Medidas provisionais e a pregunta «Desconectar o servidor?»
- Preguntas frecuentes
- Apoio de Biricon IT Services
Que pasou? A cronoloxía
O equipo de seguridade de PHP anunciou previamente a publicación das correccións para que os provedores de aloxamento e os administradores tivesen tempo de prepararse. A publicación mesma tivo lugar o 21 de outubro de 2026. O BSI emitiu a súa advertencia (versión 1.1) ese mesmo día.
- 20 de outubro de 2026: Aviso previo do equipo de seguridade de PHP de que ao día seguinte aparecerán actualizacións de seguridade.
- 21 de outubro de 2026, 14:00 UTC (16:00 CEST): Publícanse os parches para PHP 8.5, 8.4, 8.3 e 8.2.
- 21 de outubro de 2026: O BSI advirte das «vulnerabilidades críticas que ameazan as aplicacións web en todo o mundo» e recomenda parchear sen demora. Segundo o BSI, grandes provedores de aloxamento desconectaron en parte servidores por precaución.
As dúas vulnerabilidades de PHP dunha ollada
Trátase de dous erros separados no núcleo de PHP: CVE-2026-109618 e CVE-2026-109619. Segundo o equipo de seguridade de PHP, ambos poden provocar que un atacante execute código no servidor sen iniciar sesión (unauthenticated Remote Code Execution). As vulnerabilidades valóranse con CVSS v4.0: 9,2 (crítica).
| Característica | Significado |
|---|---|
| Identificadores | CVE-2026-109618 e CVE-2026-109619 |
| Valoración | CVSS v4.0: 9,2 — crítica |
| Efecto | Execución de código no servidor (Remote Code Execution), sen inicio de sesión |
| Causa 1 | Memoria danada cando PHP se queda sen memoria durante o procesamento (Out-of-Memory) |
| Causa 2 | Estado global obsoleto que permanece na memoria entre solicitudes |
| Especialmente en risco | Apache con mod_php |
Segundo a valoración do BSI, no momento da publicación non había ataques confirmados, pero si indicios non confirmados de intentos de explotación. Con vulnerabilidades críticas nun software tan estendido, a experiencia di que hai que contar con que os atacantes analicen as correccións e preparen ataques automatizados. A xanela de tempo para parchear é, por iso, curta.
Quen está afectado?
Está afectado en principio todo servidor no que funcione PHP, independentemente de como estea conectado PHP: PHP-FPM, mod_php en Apache, php-cgi, FrankenPHP ou LiteSpeed. O risco é máximo, segundo o equipo de seguridade de PHP, con Apache con mod_php.
O BSI cita expresamente aplicacións que se basean en PHP e que, por iso, tamén poden estar afectadas:
- Sistemas de xestión de contidos: WordPress, Drupal, TYPO3, Joomla
- Sistemas de tendas: Magento
- Nube e almacenamento de ficheiros: Nextcloud
- Interfaces de firewall: pfSense, OPNsense
A aplicación en si non ten que ser defectuosa para iso. A vulnerabilidade está en PHP, por iso unha actualización de WordPress, Nextcloud & Co. soa non axuda. Hai que actualizar a versión de PHP no servidor. En firewalls como pfSense e OPNsense, a versión de PHP corrixida chega a través da actualización de firmware do fabricante correspondente.
Estas versións de PHP son seguras
As vulnerabilidades están corrixidas nas seguintes versións. Todo o que está por debaixo considérase vulnerable.
| Rama de PHP | Mínimo necesario | 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 | O soporte remata o 31 de decembro de 2026 |
| PHP 8.1 e anteriores | sen actualización oficial, véxase abaixo | |
Así comproba e actualiza o seu servidor
1. Determinar a versión de PHP instalada
Na liña de comandos do servidor, php -v mostra a versión de PHP da liña de comandos. O servidor web pode usar outra versión de PHP. Por iso, comprobe tamén a versión de PHP-FPM ou do módulo de Apache, por exemplo con php-fpm8.3 -v ou mediante unha páxina que mostre phpinfo() (retíreo inmediatamente despois).
2. Aplicar a actualización mediante a xestión de paquetes
En Debian, Ubuntu, RHEL e derivados, a versión corrixida chega a través da xestión de paquetes normal, por exemplo apt update && apt upgrade ou dnf upgrade. En fontes de terceiros como o PPA de Sury ou o repositorio de Remi, os novos paquetes adoitan aparecer pronto.
apt changelog php8.3-fpm ou rpm -q --changelog php | grep CVE-2026-1096).
3. Reiniciar o servizo de PHP
Unha actualización de paquete soa non chega: os procesos de PHP en execución conservan o código antigo na memoria. Reinicie PHP-FPM (systemctl restart php8.3-fpm) ou Apache (systemctl restart apache2) e comprobe despois se os procesos se iniciaron tras a actualización.
4. Páxinas web aloxadas
No shared hosting, por regra xeral actualiza o provedor. No menú do cliente adoita poderse axustar a versión de PHP por páxina web. Escolla alí unha das versións seguras indicadas arriba ou pregunte ao provedor polo estado dos parches. Segundo o BSI, algúns provedores desconectaron servidores da rede por precaución. Se a súa páxina non está accesible durante un momento, esa pode ser a causa.
PHP 8.1 e anteriores: sen actualización oficial
Para PHP 8.1 e anteriores xa non hai actualizacións de seguridade oficiais. Os operadores deses sistemas teñen dúas posibilidades:
- Cambiar a unha versión con soporte (recomendado). Canto máis antiga é a versión, maior é o esforzo de adaptación da aplicación e das extensións, por iso convén probar antes o cambio.
- Portar as correccións cara atrás. O equipo de seguridade de PHP puxo as correccións á disposición en ramas de desenvolvemento en GitHub. Quen compila PHP por si mesmo pode incorporar eses cambios en versións máis antigas. É unha solución provisional e require coñecementos especializados.
Tamén PHP 8.2 só ten soporte ata o 31 de decembro de 2026. Planifique, por iso, a migración a PHP 8.4 ou 8.5 agora e non a deixe para o cambio de ano.
Medidas provisionais e a pregunta «Desconectar o servidor?»
Co anuncio, o equipo de seguridade de PHP describiu tamén medidas de protección provisionais. Estas reducen o risco, pero non pechan as vulnerabilidades por completo. Non substitúen a actualización e están pensadas só para salvar o tempo ata a actualización.
Se un servidor se debe desconectar da rede ata a actualización depende da súa importancia e da súa accesibilidade. O BSI sinala que grandes provedores deron ese paso. Como regra xeral:
- Servidor accesible publicamente, actualización posible agora: parchear de inmediato, non é necesario apagar.
- Servidor accesible publicamente, actualización non posible a curto prazo: restrinxir o acceso (por exemplo mediante firewall só para enderezos coñecidos) ou apagar temporalmente o servizo, especialmente con
mod_php. - Servidor só accesible internamente: parchear pronto, a urxencia é menor.
Preguntas frecuentes
Teño que actualizar WordPress, Joomla ou Nextcloud?
Non por esta vulnerabilidade. Está en PHP, non na aplicación. Actualice a versión de PHP no servidor. Unha actualización da aplicación é, con todo, aconsellable con independencia diso.
Como podo saber se alguén xa explotou a vulnerabilidade?
É difícil dar unha resposta segura. Son sospeitosos os ficheiros PHP descoñecidos no directorio web, os procesos pouco habituais baixo o usuario do servidor web, as contas de usuario ou os cronjobs novos e o tráfico de datos saínte inusual. Ante unha sospeita concreta, o sistema debería someterse a unha análise forense e, na dúbida, reinstalarse desde cero.
Abonda cun Web Application Firewall?
Un firewall pode interceptar patróns de ataque coñecidos, pero non substitúe a actualización. Pode ler máis sobre a interacción de varias capas de protección na nosa publicación Protexer Odoo 19: firewall, 2FA & Web RBL. Os principios valen para calquera aplicación web.
Está afectado Odoo?
Non. Odoo está escrito en Python e non funciona sobre PHP. Só estarían afectadas as aplicacións PHP que se executen no mesmo servidor.
Onde atopo a información oficial?
O anuncio do equipo de seguridade de PHP atópao nos arquivos de novidades en php.net (entrada do 20 de outubro de 2026), e as versións en php.net/downloads. O aviso do BSI leva o número 2026-297981-1032 e está publicado en bsi.bund.de publicado.
Apoio de Biricon IT Services
Se non está seguro de que versión de PHP se executa no seu servidor ou necesita axuda para aplicar os parches, axudarémolo con gusto: no inventario de todos os sistemas PHP, na instalación das actualizacións, na migración a unha versión de PHP compatible e na comprobación de posibles compromisos. Como provedor de servizos informáticos, atendemos servidores, firewalls e aplicacións web de pequenas e medianas empresas.
Data: 21 de outubro de 2026. A situación pode cambiar a curto prazo; son determinantes as publicacións do equipo de seguridade de PHP e do BSI.