Han hackeado tu hosting: qué cambiar en WordPress y WooCommerce, y cuándo avisar a la AEPD

El 23 de octubre de 2026 DreamHost descubrió que un tercero había entrado en el servidor de su gestor de archivos web, y que las credenciales FTP y SFTP de quienes lo usaron desde agosto habían quedado expuestas. Si tienes una tienda WooCommerce en un hosting que avisa de algo así, cambiar la contraseña que te piden no basta: con acceso a los archivos de una web WordPress se lee wp-config.php, y ahí están la contraseña de la base de datos y las claves de sesión. Aquí tienes el caso DreamHost tal como lo cuentan las fuentes, el orden en el que yo rotaría cada credencial, los comandos para comprobar si han tocado tu web y lo que te exige el RGPD frente a la AEPD.

Este artículo no es asesoramiento jurídico individual. La valoración del riesgo para tus clientes es tuya como responsable del tratamiento.

#¿Qué pasó en DreamHost en 2026?

Los hechos, según el anuncio de DreamHost (dreamhost.com), su notificación ante el fiscal general de California (oag.ca.gov) y el artículo de Zack Whittaker en TechCrunch (techcrunch.com):

El punto de entrada fue el gestor de archivos web (files.dreamhost.com), construido sobre software de terceros. Según la carta, el atacante “explotó una vulnerabilidad en ese software” (traducción propia). DreamHost no nombra el producto ni la vulnerabilidad, y añade que el incidente no tiene relación con sus recientes actualizaciones de PHP.

Lo que quedó expuesto, con la redacción de DreamHost, que importa:

• Usuarios y contraseñas FTP/SFTP “de las personas que iniciaron sesión en este gestor de archivos entre aproximadamente agosto de 2026 y el 23 de octubre de 2026” (traducción propia).
• En el correo web hay dos versiones. La carta habla de “información de sesión” de un número limitado de usuarios (traducción propia); el anuncio habla de credenciales de acceso al correo web. Las dos son textos de DreamHost y no dicen lo mismo.
• La carta añade que “también pudo accederse a otra información, como el contenido de tu correo y los archivos del servidor FTP/SFTP” (traducción propia).
• Según DreamHost, no hay indicios de acceso a los datos de inicio de sesión del panel de control ni a los datos de facturación. Los números de tarjeta completos no se guardan.

Sobre el alcance, DreamHost dice “muy por debajo de aproximadamente el 10 %” de las cuentas de correo y FTP/SFTP (traducción propia). La ficha de California no da número de afectados. El titular de TechCrunch habla de un ataque “de meses” y de archivos y buzones robados; la carta de DreamHost usa “pudo”. Que el atacante estuviera dentro desde mediados de agosto o que solo recogiera credenciales desde entonces no está aclarado.

#¿Qué pide DreamHost a sus clientes?

La lista de DreamHost es razonable como punto de partida:

1. Cambiar las contraseñas desde el panel (panel.dreamhost.com). Solo puede hacerlo el titular, y el cambio tarda hasta 15 minutos en aplicarse.
2. Dar por comprometidas las credenciales FTP/SFTP usadas en el gestor de archivos durante ese periodo, y cambiar la misma contraseña, o una parecida, en cualquier otra cuenta.
3. Actualizar los clientes de correo, FTP y SFTP que guardan la contraseña antigua.
4. Revisar los archivos de la web por si hay cambios inesperados.
5. Revisar en las cuentas de correo las reglas de reenvío y los filtros.
6. Pensar si el contenido de los correos o de los archivos da acceso a otras cuentas, y revisarlas.

DreamHost recuerda que nunca pide contraseñas por correo. Tras un incidente así llegan correos falsos de “restablece tu contraseña”: no los abras desde el enlace, entra tú en el panel.

Lo que la lista no cubre es WordPress. Ningún hosting puede saber qué hay dentro de tu wp-config.php ni qué claves de pago guarda tu WooCommerce.

#¿Por qué un robo de credenciales SFTP compromete todo WordPress?

DreamHost no dice que se leyera ningún wp-config.php. No menciona contraseñas de bases de datos, usuarios SSH ni claves de API. Lo que sigue es una deducción mía, y es la razón de todo el procedimiento: quien entra por SFTP en tu web puede descargar wp-config.php, y ese archivo contiene:

• DB_NAME, DB_USER y DB_PASSWORD, que dan acceso a la base de datos con clientes, pedidos y direcciones,
• las claves y salts de autenticación, que firman las cookies de sesión de wp-admin,
• en muchas instalaciones, otras constantes con secretos de plugins.

Y desde la base de datos se leen las claves de API que WooCommerce y las pasarelas de pago guardan en la tabla de opciones. Por eso el orden importa: si cambias solo la contraseña SFTP, quien copió wp-config.php conserva la base de datos y las sesiones.

#¿En qué orden cambio las credenciales de mi WordPress?

Este es el orden que sigo yo. Combina la guía oficial de WordPress.org para webs hackeadas (wordpress.org), que pide cambiar “todos los puntos de acceso” (FTP/SFTP, wp-admin, panel del hosting y MySQL) para todos los usuarios, con la documentación de cada proveedor. Que las claves de WooCommerce y Stripe entren en una lista para brechas de hosting es criterio mío: no encontré una página oficial que lo diga, pero se deduce de que la base de datos queda al alcance.

1. Tu ordenador. La guía de WordPress.org pide un análisis antivirus completo, porque hay troyanos que capturan contraseñas de FTP y de wp-admin. Si tu equipo está infectado, cada contraseña nueva se va por el mismo camino.
2. El panel del hosting. Contraseña nueva y, si lo admite, segundo factor.
3. SFTP y SSH. Contraseñas nuevas para todos los usuarios. Si usas claves SSH, revisa ~/.ssh/authorized_keys en el servidor y quita las que no reconozcas.
4. El correo. Las cuentas que reciben los enlaces de restablecimiento de wp-admin y los avisos de pedidos: contraseña nueva y revisión de reglas de reenvío y filtros. Una regla que reenvía en silencio los correos de “restablecer contraseña” anula todo lo demás.
5. La base de datos. Contraseña nueva del usuario MySQL en el panel y, en el mismo momento, en wp-config.php. La guía de WordPress.org lo recuerda: si cambias usuario y contraseña de la base de datos, actualiza wp-config.php. Con WP-CLI (developer.wordpress.org):

wp config set DB_PASSWORD 'contraseña-nueva-larga'

Entre el cambio en el panel y el cambio en wp-config.php la web da error de conexión, así que hazlo seguido y en horas de poco tráfico.

6. Los salts. Regenerarlos invalida todas las cookies de sesión: quien tenga una sesión robada se queda fuera, y tus usuarios también tendrán que volver a entrar (developer.wordpress.org).

wp config shuffle-salts

El comando “refresca los salts definidos en el archivo wp-config.php” (traducción propia) (developer.wordpress.org). Sin WP-CLI, copia un juego nuevo de https://api.wordpress.org/secret-key/1.1/salt/ y sustituye las ocho líneas en wp-config.php.

7. Administradores y contraseñas de aplicación. Contraseña nueva para cada administrador y revisión de las contraseñas de aplicación de cada usuario. WordPress guarda de cada una la fecha y la IP del último uso, con una precisión de 24 horas (make.wordpress.org):

wp user application-password list 1
wp user application-password delete 1 <uuid>

El primer argumento es el ID del usuario; la sintaxis completa está en la documentación de WP-CLI (developer.wordpress.org). Borra las que no reconozcas o que se usaron desde IP extrañas.

8. Claves REST de WooCommerce. En WooCommerce > Ajustes > Avanzado > API REST, revoca las claves con “Revoke Key” y genera claves nuevas para cada integración: tu ERP, tu programa de facturación, tu conector de marketplaces (woocommerce.com). Anota antes qué integración usa cada clave, porque al revocarla deja de sincronizar.
9. Stripe, si cobras con Stripe. La documentación pide rotar la clave secreta o restringida si se ve comprometida (docs.stripe.com). Al rotarla en el panel, la antigua y la nueva funcionan juntas hasta 7 días, tiempo para poner la nueva en WooCommerce; si sospechas que alguien la tiene, elige que caduque “ahora”. Stripe también permite limitar las claves de producción por IP. El secreto de firma del webhook se rota aparte, con “Roll secret”, y el antiguo puede seguir válido hasta 24 horas (docs.stripe.com). Pon el nuevo en el plugin de pago para que los avisos de pago sigan entrando.
10. Otras pasarelas y servicios. Lo que valga para Stripe vale para cualquier pasarela, transportista o servicio cuya clave esté en la base de datos o en wp-config.php. Revisa la configuración de cada plugin de pago y pregunta a tu proveedor cómo se rota su clave.

Y una vez comprobado que la web está limpia, repite los pasos 2 a 7. La guía de WordPress.org es explícita: si solo cambiaste las contraseñas al descubrir el ataque, cámbialas otra vez ahora.

#¿Cómo compruebo si han tocado mi WordPress?

Con acceso SSH y WP-CLI, tres comandos cubren lo básico.

Administradores. Busca cuentas que no creaste tú, y fíjate en la fecha de alta:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Por defecto la lista incluye user_registered (developer.wordpress.org). Un administrador creado entre agosto y octubre de 2026 en una web de DreamHost merece una explicación.

Archivos del núcleo. Compara cada archivo con las sumas de comprobación de WordPress.org:

wp core verify-checksums --include-root

Con --include-root también avisa de lo que no es de WordPress en la raíz (developer.wordpress.org).

Plugins:

wp plugin verify-checksums --all

Con --strict marca también cambios en los readme (developer.wordpress.org). Ojo: compara con las sumas de WordPress.org, así que los plugins de pago y los desarrollados a medida no se comprueban. En una tienda WooCommerce suele haber varios. Para esos, compara con una copia descargada de nuevo del proveedor.

Y lo que la guía de WordPress.org pide revisar a mano: los .htaccess de la raíz y de los subdirectorios, index.php, y header.php, footer.php y functions.php del tema activo. Sustituir /wp-admin y /wp-includes por los de la misma versión es seguro, porque no guardan nada tuyo.

Si encuentras algo, deja de rotar y limpia primero. Tienes el procedimiento completo en mi guía para limpiar un WordPress hackeado.

#¿Tengo que notificar la brecha a la AEPD?

Si tu tienda trata datos de clientes, probablemente tienes que valorarlo, y en 72 horas. El reparto de papeles en el RGPD (EUR-Lex):

Sobre el plazo, las directrices 9/2022 del Comité Europeo de Protección de Datos, en su apartado 44, dicen que en principio el responsable debe considerarse consciente “una vez que el encargado le ha informado de la brecha” (traducción propia) (edpb.europa.eu). La valoración del riesgo no la hace el hosting: la haces tú.

Mi lectura para un cliente de DreamHost, que no es una resolución de ninguna autoridad sobre este caso: las 72 horas empiezan, en principio, cuando te llega el aviso de DreamHost (el correo de restablecimiento del 23 al 25 de octubre o la carta formal), no el 15 de agosto. Y si las credenciales SFTP expuestas abrían wp-config.php y la base de datos de WooCommerce, con nombres, direcciones e historial de pedidos, hay base para considerar la brecha notificable. Una web corporativa sin datos personales seguramente solo necesita el registro interno del art. 33.5.

En España la autoridad es la AEPD. Su FAQ sobre brechas (aepd.es) indica que la notificación se hace “dentro de las 72 horas siguientes a que el responsable tenga constancia de ella”, a través del “canal de brechas, que se encuentra en la sede electrónica de la AEPD”, y que hay que documentar las brechas se notifiquen o no.

Qué preparar para la notificación, aunque no tengas aún todos los datos:

• cuándo te avisó el hosting y por qué medio,
• qué datos guarda tu tienda (clientes, direcciones, pedidos, cuentas de usuario),
• qué credenciales estaban expuestas y cuándo las cambiaste,
• qué has comprobado (los comandos de la sección anterior y su resultado),
• qué vas a decir a los clientes si decides que el riesgo es alto.

#Lista de comprobación tras una brecha en el hosting

#¿Cuál es el siguiente paso?

Hoy mismo: abre el panel de tu hosting, busca cualquier aviso de seguridad de las últimas semanas y apunta la fecha en que lo recibiste, porque de ella depende el plazo de la AEPD. Después ejecuta wp user list --role=administrator y wp core verify-checksums; con eso sabrás en diez minutos si estás en el escenario de rotar credenciales o en el de limpiar una infección. Si tu tienda es WooCommerce y quieres que alguien revise contigo las integraciones y claves que hay que renovar, mira cómo trabajo en mi página de desarrollo en WooCommerce.