Situación actual: PHP2Shell. Dos vulnerabilidades críticas de PHP (CVSS 9.2) permiten ejecutar código malicioso sin autenticación. Parches desde el 21/10/2026.Qué hacer ahora →

Qué recomienda el BSI sobre PHP2Shell

El BSI ha declarado el nivel de alerta 3 (naranja) por PHP2Shell y recomienda actualizar de inmediato o desconectar temporalmente. Aquí se explica qué significa en la práctica.

Actualizado 5 min de lecturaLegal y compliance

En resumen: el BSI (Oficina Federal Alemana de Seguridad de la Información) ha declarado el nivel de alerta 3 (naranja) por PHP2Shell. La recomendación es inequívoca: actualizar PHP de inmediato y, si no es posible de inmediato, desconectar temporalmente de la red los servidores web afectados. El BSI contaba con una explotación rápida y a gran escala; al principio no se conocían ataques con éxito confirmados de forma generalizada.

La alerta del BSI sobre PHP en pocas palabras

La Oficina Federal Alemana de Seguridad de la Información es la autoridad técnica central de ciberseguridad en Alemania. Ha publicado una alerta de nivel 3 (naranja) sobre PHP2Shell. El motivo son dos vulnerabilidades críticas en el propio PHP: CVE-2026-109618 y CVE-2026-109619, ambas con CVSS v4.0 de 9,2. Permiten a los atacantes ejecutar código malicioso en el servidor sin autenticación.

Las afirmaciones centrales de la alerta pueden resumirse así:

Afirmación Significado para los operadores
Nivel de alerta 3 / naranja situación seria, hay que actuar
Se recomienda actualizar de inmediato instalar las versiones corregidas de PHP
Si no, desconectar temporalmente de la red supeditar la accesibilidad a la protección
Se espera una explotación rápida y a gran escala no esperar a los primeros avisos de daños
Ataques con éxito generalizados, al principio, no confirmados no es motivo para bajar la guardia

La versión actual en cada momento la encuentra en el sitio web del BSI.

Qué significa en la práctica «actualizar de inmediato»

El proyecto PHP publicó las versiones corregidas el 21/10/2026 a las 14:00 UTC (las 16:00 hora alemana): PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Para PHP 8.1 y anteriores ya no hay actualizaciones oficiales, solo backports mínimos del código fuente para 7.4, 8.0 y 8.1.

Una actualización solo es efectiva cuando se han reiniciado todos los procesos PHP. Los archivos nuevos no bastan mientras sigan en memoria workers antiguos. Además, las distribuciones y los proveedores de hosting a veces instalan las correcciones como backport. Entonces, por ejemplo, Plesk sigue mostrando 8.2.34 aunque esté parcheado. Lo decisivo son el estado de los paquetes y la confirmación del proveedor. Y una actualización del CMS, por ejemplo de WordPress, no cierra la vulnerabilidad de PHP.

Si la actualización no es posible de inmediato

Para este caso, el BSI recomienda desconectar temporalmente de la red los servidores web. Es una medida dura, pero clara. Para muchas empresas, una interrupción planificada de unas horas es menos dañina que una intrusión con fuga de datos.

php.net menciona además medidas provisionales que reducen el riesgo, pero que expresamente no ofrecen una protección completa. Entre ellas están session.upload_progress.enabled=0 en la configuración del servidor, valores limitados de post_max_size, límites de memoria mediante contenedores o cgroups y, en PHP 8.5, fatal_error_backtraces=0, en cada caso con el posterior reinicio de todos los workers. Los detalles están en Medidas inmediatas sin parche.

Actuar de inmediato

Si un servidor web accesible públicamente sigue funcionando con PHP sin parchear y sin medidas provisionales, de la recomendación del BSI se deduce: desconectar el servidor de la red hasta que la actualización esté instalada y todos los procesos reiniciados.

Valoración de la situación

El BSI no está solo en su valoración. Cloudflare informó de intentos de ataque observados y ha desplegado reglas de protección, pero advierte de que las reglas basadas solo en los datos de la solicitud no bastan. Palo Alto Networks (Unit 42) contó más de 22,6 millones de instancias expuestas y potencialmente vulnerables. Según informes de los medios, un primer intento de ataque se observó ya el 17/10/2026, es decir, antes de la publicación de los parches.

Para los operadores se deduce una valoración sobria: quien no haya parcheado hasta hoy no solo debería parchear, sino también comprobar si ya ha pasado algo. Un parche no elimina el software malicioso introducido. No hay indicadores de compromiso (IoC) publicados y confirmados; la detección se basa en el análisis de comportamiento. La prensa especializada aconseja conservar los registros del servidor desde el 20/10/2026. Encontrará indicaciones para la búsqueda en ¿Ya estoy comprometido?.

Qué significa la recomendación para los responsables

Una alerta del BSI no es una ley. Pero es la valoración de la autoridad técnica competente y podrá desempeñar un papel en la valoración posterior de las decisiones, por ejemplo por parte de aseguradoras o auditores. Por eso las direcciones deberían documentar cuándo se enteran de la alerta, cómo valoran sus propios sistemas y qué medidas han tomado. Encontrará indicaciones generales en Responsabilidad de la dirección; no es asesoramiento jurídico.

En la práctica conviene no leer la alerta solo una vez. El BSI actualiza sus avisos cuando cambia la situación, por ejemplo ante nuevos conocimientos sobre la explotación o sobre otras vulnerabilidades. Desde el 23/10/2026 existe además un aviso de php.net sobre CVE-2026-115560, que solo afecta a configuraciones inusuales y que también se mitiga con session.upload_progress.enabled=0. Designe a una persona que compruebe a diario el BSI y php.net hasta el cierre de la situación y transmita los cambios al área técnica y a la dirección. Así no se crea una brecha de conocimiento entre quienes deciden y quienes ejecutan.

¿Cómo ayuda PHP SOS en concreto?

  • Contrastamos sus servidores web con la recomendación del BSI: versión, estado de los paquetes, reinicio, accesibilidad.
  • Dentro de la ayuda inmediata PHP2Shell parcheamos, reiniciamos todos los procesos y entregamos una prueba documental.
  • Donde la actualización no es posible de inmediato, aplicamos medidas provisionales y, si hace falta, ponemos a disposición una página sustitutiva estática.
  • Conservamos los registros y buscamos rastros, para que usted pueda valorar con solidez la situación tras el parche.

Preguntas frecuentes

¿Qué significa el nivel de alerta 3 (naranja) en el BSI?

El color describe una situación de amenaza elevada y seria, con necesidad de actuar. En PHP2Shell, el BSI lo justifica por la criticidad de las vulnerabilidades y por la rápida explotación esperada. La definición exacta de los niveles figura en el sitio web del BSI.

¿Tengo que seguir la recomendación del BSI?

Una alerta del BSI es una recomendación, no una ley. Pero es una valoración de peso de la autoridad técnica competente, en la que pueden basarse aseguradoras, auditores y tribunales. Quien se desvíe debería documentar los motivos. Esto no es asesoramiento jurídico.

¿Había ya ataques con éxito según el BSI?

Según el BSI, al principio no se conocían ataques con éxito confirmados de forma generalizada. Pero el BSI contaba con una explotación rápida y a gran escala. Otras entidades ya informaron de intentos de ataque.

¿Dónde encuentro la versión actual de la alerta?

En el sitio web del BSI, en los avisos de seguridad actuales. La situación puede cambiar; consulte allí y en php.net con regularidad el estado más reciente.

Fuentes

Contacto inmediato

Cada hora cuenta. Escríbanos ahora.

Describa brevemente el sistema, la versión de PHP y lo que ha observado. Nos pondremos en contacto, aclararemos la situación y trabajaremos en remoto hasta que el incidente quede cerrado y documentado.

Ayuda inmediata