En resumen: La vulnerabilidad de PHP PHP2Shell consiste en dos fallos críticos en PHP, la base de la mayoría de los sitios web y tiendas en línea. Mediante ellos, los atacantes pueden ejecutar código malicioso en servidores web sin contraseña. El BSI (Oficina Federal alemana para la Seguridad de la Información) alerta con el nivel naranja y aconseja: actualizar de inmediato o, si no, desconectar temporalmente de la red los servidores afectados. Para la dirección esto significa hoy: aclarar la responsabilidad, exigir la actualización y su justificante, decidir sobre una desconexión y documentarlo todo.
La situación en tres frases
El 21 de octubre de 2026 el proyecto PHP publicó actualizaciones para dos vulnerabilidades críticas de seguridad, conocidas con el nombre PHP2Shell. Está afectado PHP mismo, no un producto concreto, es decir, potencialmente todo sitio web, toda tienda y todo portal que funcione con PHP. El BSI ha declarado el nivel de alerta 3 / naranja, las empresas de seguridad informan de intentos de ataque y, según el BSI, inicialmente no se conocían ataques exitosos confirmados de forma generalizada.
Autoridades como la BKA (Oficina Federal de Policía Criminal alemana) y varias ciudades desconectaron sus sitios web de forma preventiva, según los medios. Fue prudencia, no una señal de ataque.
Qué significa la vulnerabilidad de PHP para la dirección y la empresa
La pregunta no es si usted usa PHP. Casi toda empresa lo hace en algún sitio: sitio web, tienda, portal de candidatos, área de clientes, intranet, sistema de tickets, microsite de una agencia. La pregunta es si esos sistemas están al día y quién es responsable de ello.
Si un ataque tiene éxito, en el peor de los casos el atacante puede hacerse con el servidor. Las posibles consecuencias son fuga de datos, contenidos manipulados, redirecciones a páginas fraudulentas, caída de la tienda o el uso indebido del servidor para otros ataques. Si pueden verse afectados datos personales, se suman obligaciones de notificación; el plazo según el art. 33 RGPD es, por lo general, de 72 horas. Los detalles están en Obligación de notificación según el RGPD. Esto no es asesoramiento jurídico.
Qué costes suelen producirse en el peor de los casos lo clasifica el artículo Partidas de coste de un hackeo.
Dónde se pasa por alto PHP con frecuencia en las empresas
La mayoría tiene controlado el sitio web principal. Lo que más se pasa por alto son los sistemas periféricos: el portal de candidatos de un proveedor externo, la landing page de una campaña anterior, un área de socios para distribuidores, el sistema de tickets del soporte, una nube de archivos en un servidor propio o la interfaz web de un almacenamiento en red. También los sistemas de pruebas de las agencias suelen ser accesibles públicamente y funcionan en el mismo servidor que el sitio web real.
Para la dirección la lección es sencilla: la pregunta a TI no es «¿Está parcheado nuestro sitio web?», sino «¿Están parcheados todos nuestros sistemas con PHP, también los de los proveedores de servicios?». La diferencia entre ambas preguntas es con frecuencia justo el punto por donde un ataque tiene éxito.
Lo que la situación no es
Igual de importante es la valoración a la baja. PHP2Shell no es motivo de activismo que perturbe el funcionamiento más de lo necesario. Quien ha parcheado de forma acreditada, ha reiniciado todos los procesos de PHP y no encuentra anomalías en la revisión puede volver al funcionamiento normal. Una desconexión temporal es una opción para casos sin aclarar, no una obligación para todos.
Cinco preguntas a su TI o a su proveedor de servicios
Puede plantear estas preguntas hoy. Las respuestas deberían llegar por escrito.
- ¿Cuáles de nuestros sistemas funcionan con PHP? Una lista con dirección, finalidad y responsable.
- ¿Está parcheado cada sistema? Versión corregida 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o un backport confirmado por el proveedor.
- ¿Se han reiniciado todos los procesos de PHP? Sin reinicio, la actualización no surte efecto.
- ¿Qué pasa con los sistemas en PHP 8.1 o anterior? Para ellos no hay actualizaciones oficiales. ¿Cuál es el plan?
- ¿Se ha comprobado si antes de la actualización ocurrió algo? ¿Registros conservados desde el 20 de octubre, indicios buscados?
Si su sitio web está en un proveedor de alojamiento, ayuda una solicitud formal. Una plantilla la ofrece la guía Solicitar al proveedor la confirmación de la actualización de PHP.
Las decisiones que deberían tomarse hoy
| Decisión | Opciones | Base |
|---|---|---|
| ¿Quién dirige? | una persona responsable interna, un socio externo | la responsabilidad debe ser inequívoca |
| Sistemas sin parchear | parchear de inmediato, medidas provisionales, desconectar temporalmente | recomendación del BSI, situación de los datos, relevancia para las ventas |
| Búsqueda de indicios | interna, externa, solo si hay anomalías | necesidad de protección de los datos del servidor |
| Comunicación | informar internamente, preparar a los clientes, esperar | situación tras la revisión |
| Sistemas antiguos | planificar la migración, aislar, desconectar | PHP 8.1 y anterior sin actualizaciones oficiales |
Deje constancia de quién decidió qué, cuándo y sobre qué base de información. Basta una nota breve y fechada. Posteriormente, frente a aseguradoras, clientes u organismos de supervisión, suele valer más que cualquier explicación hecha a posteriori.
Por qué esta documentación es importante para la dirección lo explica la página Responsabilidad de la dirección ante vulnerabilidades de seguridad informática. Esto es información general y no asesoramiento jurídico.
Lo que no debería creer
Los directivos oyen ahora a menudo tres afirmaciones, y las tres son falsas:
- «Hemos actualizado WordPress, así que estamos seguros». La vulnerabilidad está en PHP, no en el CMS. Una actualización del CMS no la cierra.
- «Somos demasiado pequeños, nadie nos ataca». Los ataques son automatizados. Se buscan servidores vulnerables, no nombres conocidos.
- «La actualización ya está puesta, con eso el asunto está resuelto». Un parche no elimina el software malicioso introducido antes y no demuestra que no haya pasado nada.
¿Cómo ayuda PHP SOS en concreto?
- Panorama para la dirección: elaboramos un breve resumen de sus sistemas PHP con el estado y la recomendación para cada sistema.
- Aplicación: parcheamos, reiniciamos o aplicamos medidas provisionales donde aún no es posible una actualización.
- Revisión: conservamos los registros y buscamos indicios de un ataque.
- Justificante: usted recibe una documentación que puede usar internamente y frente a terceros.
El procedimiento lo describe la ayuda inmediata ante PHP2Shell.
Conclusión
PHP2Shell es una vulnerabilidad técnica con una tarea de gestión. La técnica la resuelven los especialistas. La dirección se encarga de que alguien sea responsable, de que se respondan las cinco preguntas y de que las decisiones se tomen de forma consciente y queden documentadas. Todo eso cabe en una mañana, si empieza hoy.
Preguntas frecuentes
¿Debe ocuparse la dirección misma de PHP2Shell?
No de la ejecución técnica, pero sí de la dirección del asunto. La dirección debería asegurarse de que las responsabilidades estén claras, de que se aplique la recomendación del BSI (Oficina Federal alemana para la Seguridad de la Información) y de que decisiones como una desconexión temporal se tomen de forma consciente y se documenten.
¿Cómo explico la vulnerabilidad en una frase?
En PHP, el software en el que funcionan la mayoría de los sitios web y tiendas, hay dos fallos críticos mediante los cuales desconocidos pueden lanzar programas en el servidor sin contraseña; hay una actualización disponible y hay que aplicarla.
¿Cuánto cuesta no hacer nada?
No puede cuantificarse de forma general. Las posibles consecuencias de un ataque exitoso son tiempos de inactividad, fuga de datos, obligaciones de notificación, esfuerzo de limpieza y de análisis forense, y pérdida de confianza de los clientes. Una actualización con revisión suele ser mucho menos costosa.
¿Basta con que se ocupe el proveedor de alojamiento?
En el alojamiento compartido, por lo general es el proveedor quien aplica la actualización. Pídale que se lo confirme por escrito, incluido el reinicio de los procesos de PHP. La confirmación no responde a si antes de la actualización ocurrió algo; para eso hace falta una revisión del sitio web.