En resumen: si debe reinstalar o limpiar un servidor tras un hackeo depende de lo seguro que esté del alcance de la intrusión. Si el atacante pudo tener derechos de root, no está claro el momento de la intrusión o faltan registros, una reconstrucción desde fuentes de confianza es la opción más fiable. Una limpieza solo entra en consideración con una infección estrechamente delimitada y bien acreditada. En ambos casos vale: primero asegurar las pruebas y cerrar la vulnerabilidad, después poner orden.
Por qué esta pregunta se plantea con tanta frecuencia tras PHP2Shell
Según php.net, PHP2Shell permite la ejecución de código malicioso a distancia sin inicio de sesión. Quien haya operado un servidor sin parchear debe por ello preguntarse si desde el 17 de octubre de 2026, según informaciones de los medios el primer intento de ataque observado, ha ocurrido algo. El parche no responde a esta pregunta, y no hay indicadores de compromiso publicados y confirmados.
Si entonces aparece un archivo sospechoso, un proceso desconocido o una tarea cron ajena, hay que decidir. El impulso suele ser borrar rápido o reinstalar de inmediato. Ambas cosas pueden ser correctas, pero no como primer paso.
El orden antes de la decisión
Antes de elegir entre limpiar y reinstalar, hay que hacer tres cosas. Valen para ambos caminos.
- Contener: sacar el servidor de la red o limitar el acceso a lo imprescindible, sin apagarlo si aún se quiere asegurar la memoria RAM.
- Asegurar pruebas: guardar registros, archivos, base de datos y, si es posible, una imagen del sistema, con fecha y suma de verificación. Por qué es necesario antes de cualquier reinstalación lo explica Asegurar pruebas antes de reinstalar.
- Implicar a la aseguradora y a protección de datos: muchas pólizas de ciberseguro esperan que se coordinen los pasos esenciales. Encontrará indicaciones en Ciberseguro: qué cuenta en caso de siniestro. Si existe una obligación de notificación según el RGPD, lo valoran el delegado de protección de datos o el abogado.
Solo después compensa la ponderación propiamente dicha.
Reinstalar el servidor tras el hackeo o limpiarlo: los criterios
| Criterio | Limpiar | Reinstalar |
|---|---|---|
| Alcance de la intrusión | Estrechamente delimitado, acreditado, por ejemplo un archivo en la carpeta de subidas sin más rastros | Poco claro o con indicios de acceso al sistema |
| Posibles derechos de root del atacante | Descartados con buenas pruebas | No se pueden descartar |
| Disponibilidad de registros | Completos para el periodo relevante | Incompletos, sobrescritos o manipulables |
| Esfuerzo | Menor, si el hallazgo es claro | Mayor, pero más planificable |
| Incertidumbre restante | Mayor, es difícil descartar puertas traseras ocultas | Menor, si se reconstruye limpiamente desde fuentes de confianza |
| Tiempo de parada | Normalmente más corto | Normalmente más largo, bien controlable con preparación |
| Idoneidad para sistemas antiguos | Problemática si el sistema ya estaba obsoleto | Buena ocasión para pasar a una versión de PHP compatible |
Como regla general: cuanto menos se sabe, más habla a favor de la reconstrucción. Con una vulnerabilidad en el intérprete de PHP que ejecuta código en el contexto del usuario del servidor web, un atacante puede aprovechar otras vulnerabilidades para obtener más derechos. Sin una investigación a fondo, apenas puede descartarse.
Ambos caminos en la práctica
Qué significa realmente «reinstalar»
Reinstalar no significa copiar la copia de seguridad antigua a un servidor nuevo. Una reconstrucción comienza con un sistema operativo limpio de fuente oficial, paquetes actualizados y una versión de PHP parcheada. La aplicación se instala desde el original del fabricante, y los plugins y temas igual.
Solo entonces se añaden los contenidos propios, y revisados. Los archivos subidos no deben contener scripts ejecutables; la base de datos puede contener contenido inyectado, como cuentas de administrador ocultas o scripts en las entradas. Los archivos de configuración se escriben de nuevo en lugar de copiarse. Se renuevan todas las credenciales: base de datos, administradores del CMS, claves SSH, claves de API, panel de alojamiento.
Las copias de seguridad desempeñan aquí un papel importante, pero solo si su estado es anterior a la intrusión y ellas mismas no han sido modificadas. Varias generaciones en lugares separados lo hacen comprobable; más información en Copias de seguridad según la regla 3-2-1.
Cuando limpiar es defendible
Una limpieza puede tener sentido si la infección se descubrió pronto, hay registros completos y la investigación no arroja ningún indicio de más accesos. Entonces se eliminan los archivos encontrados tras asegurarlos, se revisan las tareas cron, las cuentas de usuario y las claves SSH, y se comparan los archivos del núcleo con el original del fabricante.
Es importante una valoración realista: las webshells suelen ser discretas y estar ocultas en varios lugares. Cómo encontrarlas lo describe Reconocer y eliminar webshells. Tras una limpieza, el servidor debería vigilarse de cerca, para que se note una puerta trasera pasada por alto.
No borre nada antes de que los registros y los archivos estén asegurados, y cierre la vulnerabilidad antes de que el servidor vuelva a la red. De lo contrario perderá los rastros e invitará a la siguiente intrusión.
Cuándo no necesita un proveedor de servicios
En un sitio web sencillo en alojamiento compartido, donde el proveedor gestiona el sistema y confirma el parche de PHP, la decisión a menudo ni siquiera depende de usted. Puede reinstalar la aplicación desde el original, revisar los contenidos y renovar las credenciales, con el apoyo del proveedor de alojamiento. También un equipo interno con experiencia puede afrontar por sí mismo una reconstrucción si la preservación de pruebas y la documentación están resueltas.
La ayuda externa compensa si no se pueden descartar derechos de root, podrían estar afectados datos personales, interviene el seguro o hay varios sistemas relacionados.
¿Cómo ayuda PHP SOS en concreto?
- Aseguramos registros, archivos y base de datos con valor probatorio antes de modificar nada.
- Valoramos el alcance de la intrusión y recomendamos limpiar o reconstruir con motivación, separando entre acreditado, probable y desconocido.
- Reconstruimos el servidor si hace falta desde fuentes de confianza, con una versión de PHP parcheada y accesos renovados.
- Asumimos la eliminación de malware donde una limpieza sea defendible, y documentamos cada paso.
Conclusión
La pregunta «¿reinstalar o limpiar?» se responde por el conocimiento de la intrusión. Quien no conoce con seguridad el alcance, reconstruye. Quien puede delimitarlo con buenas pruebas, puede limpiar. En ambos casos rige el mismo orden: contener, asegurar, cerrar la vulnerabilidad y después poner orden.
Preguntas frecuentes
¿Es siempre mejor reinstalar tras un hackeo?
No siempre, pero a menudo. Si no está claro hasta dónde llegó el atacante, una reconstrucción desde fuentes de confianza suele ser la opción más fiable. En una infección estrechamente delimitada y bien acreditada puede bastar una limpieza.
¿Puedo simplemente restaurar una copia de seguridad antigua?
Solo si es seguro que la copia es anterior a la intrusión y no contiene ninguna puerta trasera. Además, la vulnerabilidad debe haberse cerrado antes; de lo contrario, el servidor vuelve a ser atacable de inmediato. Los datos más recientes deben revisarse por separado.
¿Qué debo asegurar antes de reinstalar?
Registros, una copia de los archivos y de la base de datos y, si es posible, una imagen del sistema. Necesita estas pruebas para el análisis de causas, el seguro y una posible notificación. Tras borrar, desaparecen.
¿Basta con borrar la webshell encontrada?
Pocas veces. Los atacantes suelen crear varias puertas traseras, por ejemplo tareas cron, cuentas de usuario o claves SSH. Quien solo borra el archivo visible deja abiertos los demás accesos.