# ¿Parchear, apagar o esperar? Una ayuda para decidir ante la vulnerabilidad de PHP

> ¿Desconectar el sitio web por la vulnerabilidad de PHP? Una ayuda para decidir entre parchear, apagar y esperar, con criterios, procedimiento y límites honestos.

Fuente: https://phpsos.de/es/blog/patchen-abschalten-abwarten/  
Actualizado: 25/10/2026  
Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6

**En resumen:** si debe desconectar un sitio web por la vulnerabilidad de PHP depende de una pregunta: ¿se ejecuta PHP en ese servidor, de forma comprobable, en una versión corregida y se han reiniciado todos los procesos? Si es así, no hace falta desconectar. Si la actualización no es posible de inmediato, el BSI recomienda sacar temporalmente el servidor web de la red. Esperar solo es defendible si el sistema no usa PHP, no es accesible públicamente o el proveedor ha confirmado el parche por escrito.

## La situación en la que debe decidir

PHP2Shell comprende dos vulnerabilidades en el propio PHP, CVE-2026-109618 y CVE-2026-109619, ambas valoradas con CVSS v4.0 9,2. Permiten la ejecución de código malicioso a distancia sin inicio de sesión. Las versiones corregidas están disponibles desde el 21 de octubre de 2026: 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Para PHP 8.1 y anteriores ya no hay actualizaciones oficiales.

El BSI ha emitido el nivel de alerta naranja y aconseja la actualización inmediata o, en su defecto, la desconexión temporal. Según informaciones de los medios, la ciudad de Maguncia, departamentos del Gobierno regional de Hesse y otras instituciones públicas han desconectado sitios web de forma preventiva; la Cancillería del Estado de Hesse no comunicó ningún ataque. Qué pueden deducir de ello las empresas figura en [Las autoridades desconectan sitios web](https://phpsos.de/es/blog/behoerden-webseiten-offline/).

Para los responsables de las empresas la pregunta es más práctica: ¿qué hacemos hoy con nuestra tienda, nuestro portal, nuestro sitio web corporativo?

## Desconectar el sitio web, parchear o esperar: las tres opciones comparadas

La tabla siguiente pone las opciones una al lado de otra. No sustituye la valoración de su caso concreto, pero hace visible la ponderación.

| Criterio | Parchear de inmediato | Apagar temporalmente | Esperar |
|---|---|---|---|
| Protección frente a PHP2Shell | Alta, si el parche y el reinicio están acreditados | Alta mientras dure la desconexión | Ninguna mientras no esté parcheado |
| Interrupción de la actividad | Corta, para la actualización y el reinicio | De horas a días | Ninguna |
| Requisito | Versión de PHP compatible, acceso, ventana de mantenimiento | Decisión de la dirección, página sustitutiva estática | Motivo acreditado de por qué no hay riesgo |
| Esfuerzo | Bajo a medio | Bajo en lo técnico, alto en lo organizativo | Bajo, pero esfuerzo de comprobación para la prueba |
| Caso típico | Servidor con PHP 8.2 a 8.5 | Sistema antiguo con PHP 8.1 o anterior, estado poco claro | Sistema sin PHP o accesible solo internamente |
| Riesgo residual | Una intrusión anterior sigue siendo posible | Una intrusión anterior sigue siendo posible | Plenamente existente |

Una fila merece atención: ni el parche ni la desconexión aclaran si antes ya ocurrió algo. Según informaciones de los medios, el primer intento de ataque observado fue el 17 de octubre de 2026, es decir, antes del parche. Por eso, mirar posibles rastros forma parte de cada opción.

## En cinco preguntas hacia la decisión

Vaya respondiendo las preguntas por orden. La primera respuesta clara suele llevar a la decisión.

1. **¿Se ejecuta PHP en el sistema y es accesible desde internet?** Si no, el sistema no está afectado directamente por PHP2Shell. Documente cómo lo ha comprobado.
2. **¿Está acreditado el estado del parche?** Acreditado significa: versión corregida o backport con números CVE en el registro de cambios del paquete y reinicio de todos los procesos de PHP. No basta la indicación de versión en el panel. Cómo comprobarlo lo explica [Comprobar correctamente la versión de PHP y el estado del parche](https://phpsos.de/es/php2shell/php-version-pruefen/).
3. **¿Se puede instalar la actualización en las próximas horas?** Si es así: parchear, reiniciar, comprobar. Hasta entonces pueden ayudar medidas transitorias.
4. **¿No es posible, por ejemplo por PHP 8.1 o falta de acceso?** Entonces, según el BSI, el camino es la desconexión temporal. Las medidas transitorias según php.net reducen el riesgo, pero no protegen por completo; los detalles figuran en [Medidas inmediatas si todavía no puede parchear](https://phpsos.de/es/php2shell/sofortmassnahmen-ohne-patch/).
5. **¿Hay indicios de compromiso?** Entonces la cuestión ya no es «parchear o apagar», sino «gestionar el incidente». Apagar, asegurar pruebas, no borrar con precipitación.

## Si apaga: apáguelo bien

Una desconexión debe eliminar la superficie de ataque, no solo ocultar la página de inicio. Una página de mantenimiento que sigue generándose con PHP no cumple este fin. Es mejor una página HTML estática que el servidor web sirva sin PHP, o una redirección a otro servidor.

Piense en todo lo que depende del mismo PHP: subpáginas, interfaces para apps o para la gestión de mercancías, áreas de administración, retrollamadas de pago. Hable de antemano con el proveedor de pagos y con logística si hay una tienda afectada. E informe a empleados y clientes en palabras claras: la página está fuera de línea de forma preventiva, el contacto se canaliza por teléfono y correo electrónico. Es mejor que el silencio, que alimenta las especulaciones.

También es importante el final de la desconexión. Establezca bajo qué condición vuelve a estar en línea la página, por ejemplo «PHP en versión corregida, reinicio comprobado, primera revisión de rastros sin hallazgos». Así el freno de emergencia se convierte en un procedimiento ordenado.

> **Importante:**
> Apagar no es una derrota. Varias entidades públicas han hecho justo eso, según informaciones de los medios, sin que hubiera un ataque. Una desconexión preventiva no significa automáticamente que un sitio web haya sido hackeado.

## Cuándo no necesita un proveedor de servicios

No toda decisión requiere ayuda externa. Si su sitio web está en un proveedor de alojamiento que confirma por escrito el estado del parche y el reinicio, y no hay anomalías, con una breve documentación está bien posicionado. Lo mismo vale si su propia TI puede parchear por sí misma un servidor con una versión de PHP compatible y domina el control.

La ayuda compensa cuando hay sistemas con una versión antigua de PHP, el estado es poco claro, hay varios servidores afectados o existen indicios de intrusión.

## ¿Cómo ayuda PHP SOS en concreto?

1. Aclaramos con usted en poco tiempo qué sistemas están afectados y qué estado de parche está acreditado.
2. Entregamos a la dirección una base de decisión en una página: opciones, riesgos, camino recomendado.
3. Aplicamos el camino elegido, es decir, parche con reinicio, medidas transitorias o una desconexión limpia con página sustitutiva estática, como parte de nuestra [ayuda inmediata PHP2Shell](https://phpsos.de/es/leistungen/php2shell-soforthilfe/).
4. Buscamos rastros desde el 17 de octubre de 2026 y documentamos el resultado.

## Conclusión

Parchear es lo normal, apagar el freno de emergencia adecuado, esperar solo es defendible con prueba. Quien responde con honestidad a las cinco preguntas y deja constancia escrita de la decisión actúa conforme a la recomendación del BSI y puede demostrar después por qué.


## Preguntas frecuentes

**¿Tengo que desconectar mi sitio web por PHP2Shell?**  
No, si PHP ya funciona en una versión corregida y todos los procesos se han reiniciado. El BSI (Oficina Federal alemana para la Seguridad de la Información) recomienda la desconexión temporal para el caso de que una actualización inmediata no sea posible.

**¿Qué cuesta más una desconexión: las ventas o el riesgo?**  
Solo se puede responder en el caso concreto. Una parada de horas suele ser más planificable que una intrusión cuyas consecuencias y duración nadie conoce. Deje constancia por escrito de la ponderación, sea cual sea su resultado.

**¿Puede ejecutarse una página de mantenimiento en el mismo servidor?**  
Sí, si se sirve como archivo estático sin PHP. Si la página de mantenimiento sigue generándose con PHP, la superficie de ataque permanece.

**¿Es alguna vez correcto esperar?**  
Sí, en casos claramente delimitados: cuando en el sistema no se ejecuta PHP, cuando no es accesible desde internet o cuando el proveedor ha confirmado por escrito el parche y el reinicio. Esperar sin tales pruebas no es una opción, sino un riesgo.

**¿Quién debería tomar la decisión?**  
La persona que responde del riesgo empresarial, por lo general la dirección o el propietario. TI aporta los hechos. Quién decide debería constar de antemano en el plan de emergencia.

## Fuentes

- [BSI: aviso sobre PHP2Shell](https://www.bsi.bund.de/)
- [php.net: avisos de seguridad](https://www.php.net/)
- [hessenschau: sitios web de autoridades desconectados en Hesse](https://www.hessenschau.de/panorama/sicherheitsluecke-zahlreiche-behoerden-webseiten-in-hessen-abgeschaltet-v2,sicherheitsprobleme-hacker-webseiten-100.html)
- [ZDFheute: vulnerabilidad de seguridad en PHP](https://zdfheute.de/politik/sicherheitsluecke-php-webseiten-onlinedienste-cybersicherheit-bsi-100.html)