# ¿PHP2Shell hackeado? Llame. Le ayudamos.

> ¿Sospecha de un ataque PHP2Shell? Aseguramos los rastros, cerramos la vulnerabilidad y limpiamos el servidor. Llame o escriba por WhatsApp.

Fuente: https://phpsos.de/es/soforthilfe/php2shell-gehackt/  
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 sospecha que su servidor ha sido hackeado a través de PHP2Shell, póngase en contacto ahora. ¿Le afecta? Llame. Le ayudamos. Desde el primer mensaje nos encargamos de la contención, aseguramos los rastros, cerramos la vulnerabilidad, eliminamos el código malicioso y documentamos el incidente hasta su cierre.

> **Actuar de inmediato:**
> **No borre nada ahora y no reinstale nada.** Los archivos borrados y los registros sobrescritos son los rastros que muestran si alguien ha entrado y cómo. Si es necesario, desconecte el servidor de la red, pero déjelo sin modificar. [Comunique la emergencia](https://phpsos.de/es/notfall/) y le indicaremos el siguiente paso.

## ¿Le afecta? Indicios de que PHP2Shell ya se ha utilizado

PHP2Shell es el nombre de dos vulnerabilidades críticas en el propio PHP con las que los atacantes pueden ejecutar código malicioso en remoto sin autenticarse. Hasta ahora no existe una huella inequívoca. Por eso cuenta lo que hace el servidor, no lo que encuentra un escáner. Son indicios de una intrusión:

- Procesos del servidor web o de PHP-FPM que inician una shell como `sh` o `bash`. Es una señal de alarma fuerte.
- Archivos PHP nuevos o modificados en carpetas de subida, de caché o temporales que nadie ha creado.
- Tareas cron, servicios o claves SSH que usted no conoce.
- Conexiones salientes a destinos desconocidos, carga repentinamente alta o tráfico inusual.
- Solicitudes en los registros desde el 17/10/2026, en especial subidas de archivos y solicitudes de sesión llamativas antes de aplicar el parche.
- Avisos del proveedor de hosting, del navegador o del buscador sobre spam, malware o redirecciones.

Encontrará más información en [¿Ya estoy comprometido?](https://phpsos.de/es/php2shell/bin-ich-gehackt-anzeichen/). Que no haya ningún indicio no prueba que el servidor esté limpio. Solo significa que hasta ahora no ha llamado la atención nada.

## Qué hacer ahora mismo

1. **No modificar nada.** No borre archivos, no restaure ninguna copia de seguridad y no reinstale antes de que se haya hecho una copia de seguridad de las pruebas.
2. **Asegurar los registros.** Pida a su proveedor de hosting o a su equipo de TI que no sobrescriban los registros de acceso, de errores y del sistema. La prensa especializada aconseja conservar los registros desde el 20/10/2026.
3. **Decidir sobre la disponibilidad.** Si pueden estar saliendo datos o puede haber visitantes en riesgo, ponga el sitio fuera de línea o en modo de mantenimiento.
4. **Reunir los accesos.** Anote quién tiene acceso al servidor, al panel, al CMS y a la base de datos. Cambie las contraseñas solo tras consultarnos y desde un dispositivo limpio.
5. **Informar a las personas adecuadas.** A la dirección, al delegado de protección de datos y, si tiene una póliza, a la aseguradora.
6. **Llamarnos o escribirnos.** Cuanto antes conozcamos la situación, más podrá demostrarse.

## ¿Cómo ayuda PHP SOS en concreto?

Trabajamos en remoto, sin desplazamientos, en toda Europa.

1. **Evaluar la situación:** aclaramos qué sistemas están en funcionamiento, qué modo de ejecución de PHP se utiliza, qué ha llamado la atención y qué datos podrían estar afectados.
2. **Asegurar y cerrar:** hacemos una copia de seguridad de archivos, base de datos y registros y documentamos el estado antes de cualquier cambio. Después cerramos la vulnerabilidad con el parche o, si todavía no es posible, con medidas provisionales, y reiniciamos todos los procesos de PHP.
3. **Revisar y limpiar:** buscamos webshells, puertas traseras, tareas cron y accesos ajenos y los eliminamos, o reconstruimos el estado a partir de fuentes de confianza. El procedimiento se describe en [Eliminación de malware y webshells](https://phpsos.de/es/leistungen/malware-entfernung/).
4. **Reforzar e informar:** cambiamos los secretos afectados, reforzamos las medidas de protección y entregamos un informe que distingue entre lo demostrado, lo probable y lo desconocido.

Si el incidente se extiende más allá de un servidor, pasamos a una [respuesta a incidentes](https://phpsos.de/es/leistungen/incident-response/) estructurada. Si hacen falta pruebas que se sostengan ante un tribunal, incorporamos el [análisis forense informático](https://phpsos.de/es/leistungen/it-forensik/).

## Por qué un parche por sí solo no basta tras un ataque

Las vulnerabilidades están en el intérprete de PHP, no en el CMS. El proyecto PHP publicó el 21/10/2026 las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Quien actualiza después y reinicia todos los workers está protegido frente a nuevos ataques por esta vía. Pero lo que un atacante haya dejado antes sigue ahí: una webshell, una cuenta adicional, una tarea programada. Precisamente por eso los días entre el 17 y el 21/10 son especialmente importantes.

A esto se suma un segundo punto: una webshell suele ser solo el primer paso. Quien pudo ejecutar código en el servidor web también pudo leer archivos de configuración y hacerse con los accesos a la base de datos, al correo y a las API. Esos secretos hay que sustituirlos; si no, la puerta sigue abierta aunque PHP esté parcheado. Cómo revisar de forma sensata los archivos y las fechas se explica en la guía sobre [cómo reconocer webshells](https://phpsos.de/es/ratgeber/webshell-erkennen/).

## Obligación de notificar y documentación

Si pudieron verse afectados datos personales, puede ser necesaria una notificación a la autoridad de control en un plazo de 72 horas. El plazo corre desde que se tiene conocimiento, no desde que concluye la investigación. Si su caso debe notificarse lo deciden el delegado de protección de datos o un abogado; nosotros no prestamos asesoramiento jurídico. Nuestra documentación aporta la base para ello. Encontrará más sobre el plazo en [Obligación de notificación del RGPD en 72 horas](https://phpsos.de/es/compliance/dsgvo-meldepflicht-72-stunden/) y los pasos posteriores en la [lista de comprobación tras un hackeo](https://phpsos.de/es/ratgeber/checkliste-nach-dem-hack/).

## Qué debería enviarnos

- Descripción de qué se ha notado desde cuándo y quién lo ha notado
- Tipo de servidor: servidor propio, servidor gestionado o paquete de hosting, y el proveedor
- Resultado de `php -v` y, si se conoce, el modo de ejecución (PHP-FPM, mod_php, LiteSpeed)
- Momento de la actualización de PHP, si ya se ha aplicado
- Acceso al servidor o autorización para hablar con su proveedor de hosting
- Persona de contacto con capacidad de decisión para apagar y reiniciar

## Por qué PHP SOS

Trabajamos Made in Germany y llevamos más de 25 años especializados en seguridad informática junto con nuestra red de socios, profesionales de la ciberseguridad. Usted tiene un único interlocutor que le acompaña desde el primer mensaje hasta el cierre. Todo lo que hacemos queda documentado, para que pueda acreditarlo ante la dirección, la aseguradora y las autoridades. No prometemos nada que nadie pueda cumplir: si faltan registros, lo decimos abiertamente, y señalamos qué está demostrado y qué sigue siendo una suposición.

## ¿Le afecta? Llame. Le ayudamos.

No espere a que la sospecha se convierta en certeza. Llame o escriba por WhatsApp. Nos hacemos cargo desde el primer mensaje y seguimos hasta que el incidente esté cerrado y documentado. [Comunicar la emergencia ahora](https://phpsos.de/es/notfall/).


## Preguntas frecuentes

**¿Basta con actualizar PHP si mi servidor quizá ya ha sido hackeado?**  
No. La actualización cierra la vulnerabilidad, pero no elimina el software malicioso ya introducido ni demuestra que antes no haya pasado nada. Tras el parche hay que revisar el servidor en busca de indicios de intrusión.

**¿Cómo reconozco un ataque PHP2Shell exitoso?**  
No hay indicadores de compromiso publicados y confirmados. La detección se basa en el comportamiento: procesos del servidor web que inician una shell, archivos PHP nuevos en carpetas de subida o de caché, tareas cron o claves SSH desconocidas y conexiones salientes sospechosas.

**¿Debo desconectar el servidor de la red si sospecho una intrusión?**  
A menudo es lo correcto, ya que el BSI (Oficina Federal alemana de Seguridad de la Información) aconseja desconectar temporalmente el servidor web incluso cuando no es posible actualizar de inmediato. Lo importante es no borrar nada y conservar los registros y los archivos, para poder esclarecer el incidente.

**¿Tengo que informar a la autoridad de protección de datos tras un ataque PHP2Shell?**  
Si pueden verse afectados datos personales, puede ser necesaria una notificación en un plazo de 72 horas. La decisión la toma usted junto con su delegado de protección de datos o un abogado; nosotros aportamos los hechos técnicos.

**¿Se han hackeado ya servidores a través de PHP2Shell?**  
Según informes de los medios, hubo intentos de ataque observados desde el 17/10/2026, y Cloudflare informó de intentos de ataque observados. El BSI no comunicó en un primer momento ataques exitosos confirmados de forma generalizada. En un caso concreto, esto solo se puede aclarar en el propio servidor.

## Fuentes

- [BSI: Oficina Federal alemana de Seguridad de la Información](https://www.bsi.bund.de/)
- [php.net: avisos de seguridad](https://www.php.net/)
- [RGPD art. 33: notificación a la autoridad de control](https://dsgvo-gesetz.de/art-33-dsgvo/)
