¿Tu web hackeada? Escríbenos y lo gestionamos
Si te han hackeado la web, no borres nada todavía: haz una copia de archivos y base de datos, ponla en mantenimiento, avisa al hosting y cambia todas las contraseñas y claves de API desde un equipo limpio. Después hay que encontrar por dónde entraron, limpiar o reconstruir, y actualizar PHP, el CMS y el servidor antes de volver a abrir.
Lo mismo si tu proveedor te ha avisado de una vulnerabilidad y no sabes si te afecta. Nos cuentas qué ha pasado, revisamos el servidor y nos encargamos de la limpieza, las actualizaciones y las claves nuevas.
¿Cómo saber si tu web ha sido hackeada?
Con una sola de estas señales ya merece la pena revisar el servidor. Algunas intrusiones no se ven desde fuera: la web carga normal y alguien está usando el servidor para enviar spam o guardando lo que escriben tus clientes en los formularios.
-
Chrome o Google muestran un aviso rojo de «sitio peligroso» o «sitio engañoso» al entrar en tu web.
-
Al llegar desde Google, la web redirige a casinos, farmacias o páginas de spam.
-
Buscas site:tudominio.es y aparecen páginas que nadie de tu equipo ha creado.
-
Hay usuarios administradores en el WordPress o en el PrestaShop que no reconoces.
-
El hosting ha suspendido la cuenta, o te ha escrito por malware o por envío de spam.
-
Tu proveedor te ha avisado de una vulnerabilidad (php2shell, una CVE de NGINX o de Node.js) y no sabes si te afecta.
-
Los correos de tu dominio rebotan o llegan a la carpeta de spam de tus clientes.
-
El navegador avisa de que el certificado de la web no es válido.
-
Llega una factura de una API (OpenAI, Google Cloud, AWS…) muy por encima de lo normal: alguien está usando tus claves.
Me han hackeado la web: qué hacer en la primera hora
Estos pasos sirven tanto si nos escribes como si no. Van en este orden porque la copia del estado actual se pierde en cuanto alguien empieza a borrar archivos.
- No borres nada todavía. Haz una copia del estado actual, archivos y base de datos, y guárdala fuera del servidor. Anota la hora y haz capturas de lo que ves. Esa copia sirve para averiguar por dónde entraron y, si vas a denunciar, como prueba.
- Corta el daño a tus visitantes. Pon la web en modo mantenimiento o sirve una página estática mientras dure la limpieza. Si el hosting ya ha suspendido la cuenta, no pidas que la reactiven hasta que esté limpia.
- Avisa al hosting. Tiene los registros de acceso del servidor y puede ver si otras webs de la misma cuenta también están afectadas.
- Cambia las contraseñas desde un equipo limpio. Panel del hosting, administradores del CMS, FTP o SFTP, SSH, base de datos, correo del dominio y registrador. Activa la verificación en dos pasos donde se pueda. Si el ordenador desde el que gestionas la web está infectado, las claves nuevas también se pierden.
- Revoca las claves de API que guarda la web. Pasarela de pago, correo transaccional, mapas, servicios de IA: genera claves nuevas y anula las antiguas. Una clave copiada sigue funcionando aunque limpies el servidor.
- Revisa los usuarios administradores. Apunta el nombre y la fecha de alta de los que no reconozcas y después elimínalos.
- Si hay datos personales, empieza a contar. Si la web guarda datos de clientes (pedidos, formularios, cuentas), una intrusión puede ser una brecha de datos personales. El RGPD da 72 horas desde que la detectas para notificarla a la AEPD cuando supone un riesgo para las personas.
Para pedir después la revisión a Google, el proceso está en la ayuda del informe Problemas de seguridad. Si necesitas orientación gratuita, el 017 de INCIBE es la línea gratuita y confidencial de ayuda en ciberseguridad. Para la brecha de datos, la guía de la AEPD sobre notificación.
# ¿Administradores que no reconoces? (WordPress con WP-CLI)$ wp user list --role=administrator --fields=user_login,user_registered# Archivos PHP modificados en los últimos 7 días$ find . -name "*.php" -mtime -7 -type f# En uploads no debería haber ningún .php$ find wp-content/uploads -name "*.php"# Tareas programadas que no creaste$ crontab -lCon acceso SSH al servidor. Si no lo tienes, el hosting puede darte los registros de acceso y la lista de archivos modificados.
¿Qué hago si mi proveedor me avisa de una vulnerabilidad?
Comprobar qué versión usas, actualizar a la corregida y, si el fallo permitía ejecutar código o leer memoria, revisar si alguien entró antes del parche. Estos son los avisos de los últimos días que más webs y servidores tocan.
PHP: php2shell
CVE-2026-109618 y CVE-2026-109619, CVSS 9,2, sin autenticación. Corregidas en 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Wiz demostró la ejecución remota de código contra WordPress, Drupal y Joomla.
Node.js
Diez CVE el 21 de octubre, entre ellas una escritura fuera de límites en el descompresor Brotli que permite ejecutar código. Corregidas en v26.12.1, v24.22.1 y v22.23.4; la 20.x y la 25.x ya no reciben parche.
NGINX
«NGINX Rift» (CVE-2026-42945) tuvo intentos de explotación desde el 16 de mayo. La tanda de octubre, con request smuggling en HTTP/3 y falsificación de sesión TLS, se corrige en 1.31.7 y 1.30.6 o superiores.
Certificados: GoDaddy y eMudhra
GoDaddy revocó 404.607 certificados TLS el 21 de octubre por un problema de cumplimiento; la web que no instale el de reemplazo puede quedar inaccesible. Chrome, Apple y Microsoft han dejado de confiar en ocho CA intermedias de eMudhra con claves débiles.
Secretos: LiteLLM y Railway
La versión 1.107.0 de LiteLLM publicada en PyPI y Docker Hub robaba credenciales al arrancar. Railway detectó actividad anómala en los sistemas que guardan las variables de entorno de sus clientes y pide rotarlas. En los dos casos, las claves se cambian aunque el servidor parezca sano.
Las versiones corregidas, los comandos para comprobarlas y qué rotar en cada caso, en un solo artículo.
Qué parchear, qué rotar y qué certificados cambiar →¿Cómo se repara una web hackeada?
Siete pasos, en este orden. Si se limpia sin saber por dónde entraron, la misma vía sigue abierta.
-
Contención
Primero se para lo que sigue pasando: redirecciones, envío de spam, procesos que no deberían estar corriendo. Si hace falta, la web queda en mantenimiento mientras trabajamos.
-
Copia y análisis básico
Guardamos una copia del estado comprometido y miramos los registros de acceso, los archivos modificados y los usuarios y tareas programadas para encontrar la vía de entrada. Si necesitas un informe pericial para un juicio o para el seguro, eso lo firma un perito; la copia queda guardada para que pueda trabajar con ella.
-
Limpieza o reconstrucción
Si hay una copia anterior a la intrusión y sabemos cómo entraron, se restaura y se limpia. Si no, se reinstala el CMS desde fuentes oficiales y se migra solo el contenido, revisado.
-
Actualizar PHP, CMS y servidor
PHP a una versión con parche, núcleo del CMS, plugins y tema, y el software del servidor (NGINX, Apache, Node.js) si lo gestionas tú. Lo que no admite una versión con soporte se sustituye o se quita.
-
Rotación de credenciales
Contraseñas, claves SSH, claves de API y variables de entorno. Se dan por comprometidas todas las que estaban en el servidor.
-
Verificación y listas negras
Comprobamos que la web sirve lo que debe, pedimos a Google la revisión desde Search Console y revisamos si el dominio o la IP del servidor aparecen en listas negras de correo.
-
Mantenimiento
Copias periódicas guardadas fuera del servidor, actualizaciones y seguimiento de los avisos de seguridad del software que usa tu web.
- Modo mantenimiento si hace falta
- Corte de redirecciones y envío de spam
- Procesos y conexiones sospechosas
- Aviso al hosting
- Copia del estado comprometido, fuera del servidor
- Registros de acceso y de errores
- Archivos modificados recientemente
- Usuarios, tareas cron y claves SSH
- Vía de entrada probable
- Restaurar una copia anterior a la intrusión
- O reinstalar el CMS desde fuentes oficiales
- Eliminar puertas traseras y archivos inyectados
- Revisar la base de datos (usuarios, opciones, contenido)
- PHP a una versión con parche
- Núcleo del CMS, plugins y tema
- NGINX, Apache o Node.js
- Sustituir lo que no tiene soporte
- Hosting, CMS, FTP/SFTP, SSH y base de datos
- Claves de API y tokens
- Variables de entorno
- Verificación en dos pasos
- Revisión en Search Console
- Listas negras de correo e IP
- Certificado TLS válido
- Prueba de que la web funciona
- Copias periódicas fuera del servidor
- Actualizaciones de PHP, CMS y plugins
- Seguimiento de avisos de seguridad
¿Ya lo estás viendo? Mándanos la dirección de la web y lo que has notado.
Escríbenos →¿Se puede limpiar o hay que rehacer la web?
Depende de lo que haya en el servidor y de si existe una copia anterior a la intrusión.
Se limpia
- Sabemos por dónde entraron y se puede cerrar.
- Hay una copia de seguridad anterior a la intrusión.
- El CMS, los plugins y el tema admiten una versión de PHP con soporte.
Conviene reconstruir
- No hay ninguna copia fiable, o la infección vuelve después de cada limpieza.
- La web depende de plugins abandonados o de una versión de PHP sin soporte.
- Se reinstala desde fuentes oficiales y se migra el contenido revisado, o se rehace: para una web corporativa, por ejemplo una web estática con Astro, que no ejecuta PHP en el servidor.
Preguntas frecuentes sobre webs hackeadas
¿Qué hago si me han hackeado la web?
¿Cómo sé si mi web ha sido hackeada?
¿Basta con restaurar una copia de seguridad?
¿Cómo quito el aviso de sitio peligroso de Google?
¿Tengo que avisar a la AEPD?
¿Mi web en PHP está afectada por php2shell?
¿Me garantizáis que no vuelva a pasar?
¿Qué necesitáis para empezar?
Cuéntanos qué ha pasado y lo gestionamos
Con la dirección de la web, lo que has visto y los accesos que conservas revisamos el servidor y te decimos si se limpia, si hay que reconstruir y qué hay que actualizar.
Cuéntanos tu reto. Te proponemos solución.
Sin compromiso. En menos de 24 h recibes una propuesta con alcance, plazos y presupuesto. Sin letra pequeña.