Quién hace la auditoría de seguridad WordPress
Soy Mariusz Szatkowski, desarrollador WordPress desde 2006, y trabajo solo desde Gdynia (Polonia). La auditoría la hago yo de principio a fin, sin subcontratar. No soy un centro de operaciones de seguridad ni vendo vigilancia permanente: hago una revisión escrita de tu web y te digo qué corregir y en qué orden. Cuando el rendimiento cae tras un incidente, las auditorías web WPO pueden ir en el mismo encargo, para no dejar la web rápida pero aún vulnerable.
Qué incluye una auditoría de seguridad WordPress
La auditoría es una revisión de la web que termina en un documento. Reviso:
- Plugins y temas: versiones, vulnerabilidades publicadas, componentes abandonados y, en los que aceptan datos del usuario, el código.
- Usuarios y roles: administradores que sobran, cuentas que nadie reconoce, contraseñas de aplicación activas.
- Configuración:
wp-config.php, constantes de seguridad, permisos de ficheros, modo de depuración, configuración de PHP. - Cabeceras del servidor: HTTPS, HSTS, Content-Security-Policy, X-Content-Type-Options y lo que el servidor revela de sí mismo.
- Copias de seguridad: si existen, dónde se guardan, cuánto tiempo y si se pueden restaurar.
- Señales de intrusión: archivos PHP en
uploads, núcleo modificado, tareas cron extrañas.
El resultado es un informe escrito con hallazgos por gravedad y correcciones priorizadas. La eliminación de malware y el endurecimiento son trabajo aparte, si me lo encargas.
Desde dónde y para quién trabajo
Trabajo en remoto para empresas de España y del resto de la UE, también para quien vende desde Latinoamérica a clientes europeos. No necesito ir a tu oficina ni tocar tus dispositivos: basta con los accesos que describo más abajo. Hablamos por correo y te entrego todo por escrito. Facturo como empresa de la UE con NIF-IVA intracomunitario, y antes de acceder a datos personales firmamos el contrato de encargado del tratamiento del artículo 28 del RGPD.
Cuánto cuesta una auditoría de seguridad WordPress
El presupuesto es individual. Depende del número de plugins, de si hay código a medida que leer, de si es una tienda y de si la web ya está comprometida. Te lo envío por escrito antes de empezar, junto con el alcance. La limpieza de malware y la aplicación de correcciones se presupuestan aparte, cuando ya se sabe qué hay que hacer.
¿Qué es una auditoría de seguridad WordPress?
Es una revisión hecha por una persona que conoce WordPress por dentro, con un resultado concreto: una lista de lo que está mal, por qué importa y cómo arreglarlo. Comprobar si la web carga no sirve de auditoría, y un escáner automático no basta. WordPress mueve una parte enorme de la web, así que los ataques automatizados lo prueban todo el rato: no hace falta que alguien te elija para que entren.
¿Cómo se hackean los sitios WordPress?
Casi todos los incidentes que he limpiado se reducen a unos pocos patrones. Conocerlos cambia lo que se busca en el código y en los registros.
Patrones de vulnerabilidad en plugins de WordPress
El núcleo de WordPress rara vez es la puerta de entrada. Patchstack contó 11 334 vulnerabilidades nuevas en 2025: el 91 % en plugins, el resto en temas y solo 6 en el núcleo, todas de prioridad baja. En el código de los plugins se repiten las mismas formas:
- Rutas REST sin autenticación, registradas con
permission_callback => '__return_true'. - XSS almacenado en shortcodes que imprimen
$_GETo metadatos sin pasar porwp_kses_post(). - Subida arbitraria de ficheros en manejadores AJAX que aceptan el archivo sin
wp_check_filetype_and_ext()ni lista blanca de tipos MIME. - Escalada de privilegios a través de un guardado de ajustes que confía en la petición y modifica roles.
Cruzo los plugins instalados con las bases de datos públicas de WPScan y Patchstack y después leo el código de los que aceptan datos del usuario. Mirar solo las CVE publicadas deja pasar los fallos que todavía nadie ha catalogado.
Enumeración de usuarios en WordPress
?author=1 redirige a /author/<slug>/ y revela el nombre de acceso del administrador. Lo mismo pasa con /wp-json/wp/v2/users en instalaciones que nunca cerraron ese listado público. En una web endurecida, ambos devuelven 404 o una lista vacía.
Amplificación por XML-RPC
/xmlrpc.php recibe intentos constantes de redes de bots. El método system.multicall permite envolver muchas llamadas a wp.getUsersBlogs en una sola petición, de modo que un único POST prueba cientos de contraseñas. Si nada en tu web usa XML-RPC, lo desactivo; si lo usa Jetpack o la app móvil de WordPress, lo restrinjo en el WAF en lugar de quitarlo.
Consecuencias de un hackeo de WordPress en España
Para una empresa española, una web comprometida puede traer obligaciones legales, además del trabajo técnico:
- Notificación a la AEPD. Si la brecha afecta a datos personales, el artículo 33 del RGPD obliga al responsable del tratamiento (tú, no tu proveedor) a notificar a la autoridad de control sin dilación indebida y, de ser posible, en un plazo de 72 horas desde que tuvo constancia, salvo que sea improbable que suponga un riesgo para las personas. Con riesgo alto, el artículo 34 exige avisar también a los afectados. Toda brecha, notificada o no, se documenta internamente (artículo 33, apartado 5). En España, la autoridad de control es la AEPD, y la norma nacional que completa el RGPD es la Ley Orgánica 3/2018 de Protección de Datos Personales y garantía de los derechos digitales.
- Esquema Nacional de Seguridad para el sector público. El Real Decreto 311/2022 se aplica al sector público y a las empresas privadas que le prestan servicios. Su artículo 31 pide una auditoría de la seguridad al menos cada dos años y otra extraordinaria tras cambios sustanciales; los sistemas de categoría básica pueden acreditar la conformidad con una autoevaluación (artículo 38). Mi informe no sustituye a esa auditoría formal, pero sirve como base técnica para la gestión de vulnerabilidades de la web.
- Pasarelas de pago. Si las claves de Redsys, Stripe u otra pasarela están en
wp-config.php, una puerta trasera con acceso a ese fichero las lee. Es uno de los primeros puntos que reviso en una tienda.
Para el texto del RGPD, usa la versión publicada en el BOE. De mí recibes lo que necesita tu abogado o tu delegado de protección de datos: si había datos personales en la base de datos, si alguien pudo acceder a ellos y desde cuándo. La decisión de notificar es tuya.
Vectores de ataque más comunes en WordPress
Vulnerabilidades de plugins y temas
Plugins y temas son la vía de entrada más frecuente: inyección SQL, cross-site scripting, inclusión de archivos y CSRF. Cada plugin activo es superficie de ataque, y uno abandonado por su autor deja sus fallos sin parchear para siempre. En webs en español es habitual encontrar plugins de pasarelas locales y extensiones regionales con ciclos de actualización más lentos que los plugins grandes del repositorio oficial.
Ataques de fuerza bruta
Redes de bots prueban combinaciones de usuario y contraseña desde miles de IP distintas, así que bloquear por IP no basta. Lo que funciona: contraseñas largas, límite de intentos y, sobre todo, doble factor para todas las cuentas con acceso al panel.
Ataques a la cadena de suministro
El código malicioso llega dentro de un plugin o tema que el administrador considera de confianza, a veces a través de una actualización. Se detecta comparando los ficheros con las sumas de verificación oficiales (wp core verify-checksums, wp plugin verify-checksums --all) y vigilando cambios inesperados en los archivos.
Inyección SQL y XSS
La inyección SQL aprovecha formularios y parámetros mal validados para lanzar consultas en la base de datos: leer, cambiar o borrar datos, incluidas credenciales y datos de clientes. El XSS inyecta scripts que se ejecutan en el navegador del visitante y roban cookies de sesión, redirigen o capturan formularios.
Auditoría de sitios WordPress creados con IA
Las webs construidas o ampliadas con herramientas de IA fallan por motivos previsibles: nonces ausentes, entradas sin sanear, rutas REST abiertas y plugins que se acumulan tras cada prompt.
| Capa | Qué reviso | Hallazgo típico |
|---|---|---|
| Código | Plugins propios, functions.php | Sin comprobación de capacidades, SQL concatenado |
| Superficie | REST, AJAX, subidas | permission_callback => '__return_true' |
| Contenido | Duplicados, cifras inventadas | Texto generado con riesgo en temas sensibles |
La corrección va por el rescate de webs hechas con IA, los patrones de código en la auditoría de plugins generados por IA y el contenido en la limpieza de AI-slop. Presupuesto individual tras una primera revisión.
¿Son seguros los plugins de IA con ejecución de código?
Una auditoría habitual busca vulnerabilidades: versiones antiguas, CVE conocidas, validación débil. Hay otro riesgo creciente: plugins que dan a propósito a un agente de IA ejecución de PHP, consultas a la base de datos y operaciones con ficheros (por MCP, CLI o webhook). Esto es una función documentada, y en la práctica equivale a dar a un tercero ejecución remota de código.
Un escáner de CVE da ese plugin por limpio, porque no hay nada que reportar. El riesgo se traslada a la autenticación y a la cadena de suministro: quién guarda la clave del endpoint, dónde vive el secreto, si el endpoint se alcanza desde Internet y qué pasa si se compromete la cuenta del proveedor del modelo.
En cada auditoría añado cinco comprobaciones:
- Inventario de plugins que declaran ejecución de código, acceso a la base de datos u operaciones con ficheros vía IA.
- Para cada uno: si el endpoint exige autenticación y si es público.
- Dónde viven las credenciales (
wp-config.php, tabla de opciones, variables de entorno) y quién puede leerlas. - Si las operaciones quedan en un registro que permita reconstruir un incidente.
- Mi recomendación por defecto: fuera de producción; en staging, solo con consentimiento y lista blanca de IP.
En el informe los clasifico junto a las puertas traseras en uploads, porque el resultado práctico es parecido: alguien de fuera puede cambiar ficheros y datos.
Endurecimiento de WordPress paso a paso
Esto es lo que reviso y, si falta, recomiendo en el informe, más o menos en este orden. Aplicarlo es trabajo aparte, que puedes hacer tú, tu desarrollador o yo.
Constantes en wp-config.php. DISALLOW_FILE_EDIT desactiva el editor de código del panel y DISALLOW_FILE_MODS también el instalador de plugins. FORCE_SSL_ADMIN fuerza HTTPS en el panel. Las actualizaciones menores del núcleo, que traen los parches de seguridad, conviene dejarlas automáticas. El fichero, con permisos 440 o 400 y sin escritura para el usuario del servidor web. Las claves de Redsys, Stripe o de la pasarela del banco, mejor en variables de entorno fuera de la raíz pública que en wp-config.php.
Rotación de secretos. Tras un incidente, se cambian las ocho claves y sales (AUTH_KEY, SECURE_AUTH_KEY y el resto) con el generador de wordpress.org, lo que cierra todas las sesiones. También reviso las contraseñas de aplicación activas en el perfil de cada usuario y recomiendo revocar las que no correspondan a una integración conocida.
Acceso al panel. Doble factor con TOTP (por ejemplo, el plugin Two Factor o Wordfence Login Security) y una vía documentada para recuperar el acceso por WP-CLI si alguien pierde el teléfono. El límite de intentos funciona mejor en el WAF o la CDN que solo en PHP: en Cloudflare, una regla que limite los POST a /wp-login.php por IP y un desafío en /xmlrpc.php.
Sistema de ficheros. Ejecución de PHP bloqueada dentro de /wp-content/uploads/ con una regla de .htaccess o el bloque equivalente de nginx. Listado de directorios desactivado. xmlrpc.php cerrado si la web no lo usa. Permisos de referencia: directorios 755, archivos 644.
Detección. Comparación periódica de núcleo y plugins con las sumas de verificación oficiales por WP-CLI, alertas cuando aparece un administrador nuevo y registros de acceso guardados el tiempo suficiente para reconstruir un incidente.
Incidentes más comunes tras un hackeo de WordPress
El administrador que vuelve. Un plugin de formularios vulnerable permite crear un usuario con wp_insert_user() desde un endpoint AJAX mal protegido. La cuenta recibe el rol de administrador y un nombre inocente como “Support”. Restaurar la copia de la semana pasada no sirve si la cuenta ya estaba ahí: la copia también está contaminada. Se detecta comparando wp_users y wp_usermeta con la última copia limpia, sin fiarse del listado del panel.
La puerta trasera en uploads. Un PHP escondido en /wp-content/uploads/ con nombre de caché recibe código en base64 por POST y lo ejecuta con eval(). Una restauración parcial que solo toca núcleo y plugins lo deja vivo. Por eso reviso cualquier .php, .phtml o .phar dentro de uploads y compruebo que el servidor no ejecuta PHP en ese directorio.
La clave publicada en un repositorio. Un .env con credenciales SMTP o de Stripe acaba en un repositorio público, y el servidor de correo pasa a enviar spam. Hay que cambiar las claves, limpiar el historial de git con git filter-repo y bloquear esos ficheros con un hook antes del commit. Busco .env, copias de wp-config.php y cualquier fichero accesible desde la web que contenga DB_PASSWORD o claves.
El coste de un incidente es sobre todo tiempo: horas para encontrar la vía de entrada, la web en mantenimiento, semanas hasta que Google retira el aviso de Safe Browsing y, si había datos personales, la conversación con tus clientes.
¿Cómo es el proceso de auditoría de seguridad WordPress?
Alcance y accesos
Me escribes qué tipo de web es, qué datos trata, dónde está alojada y qué te preocupa. Te respondo por escrito con el alcance, los accesos que necesito y el presupuesto. Antes de tocar nada hago una copia de archivos y base de datos.
Revisión automática
Con WP-CLI compruebo la integridad del núcleo y los plugins, listo versiones de PHP, MySQL y servidor web, y cruzo cada plugin y tema con las bases de vulnerabilidades publicadas. Busco ficheros sospechosos y reviso permisos de archivos y directorios.
Revisión manual
Lo que un escáner no ve lo miro a mano, sin atacar la web en producción:
- Privilegios: si una cuenta con rol limitado llega a funciones de administrador.
- Validación de datos: si formularios y rutas REST o AJAX comprueban lo que reciben.
- Autenticación: si hay caminos alternativos a zonas protegidas.
- Exposición de información: si los mensajes de error, los comentarios HTML o la API filtran datos.
Configuración
wp-config.php (claves, prefijo, modo de depuración), permisos del sistema de archivos, directivas de Apache o Nginx, directivas de PHP como expose_php, display_errors o allow_url_fopen, y la configuración TLS y de renovación del certificado.
Informe
Un documento con cada hallazgo clasificado por gravedad (crítica, alta, media, baja), con la prueba (extracto de registro, captura o ruta del archivo), el riesgo explicado sin jerga y la corrección concreta, en el orden en que conviene aplicarla. Está escrito para que tu desarrollador pueda aplicarlo sin preguntarme. Lo que no pude comprobar por falta de acceso queda anotado.
Seguridad WordPress para comercio electrónico
PCI DSS y datos de pago en WooCommerce
PCI DSS se aplica a quien acepta pagos con tarjeta. En WooCommerce, lo sensato es que la pasarela (Redsys, Stripe, PayPal u otra) reciba los datos de la tarjeta en su propio formulario o mediante tokens, de modo que tu base de datos nunca guarde números de tarjeta. Aun así, una puerta trasera en la tienda puede modificar el checkout para capturar lo que escribe el cliente, así que reviso las plantillas de pago y los scripts que cargan en esa página.
Cuentas de cliente en WooCommerce
Las cuentas de cliente guardan datos personales. Límite de intentos de acceso, contraseñas razonables y recoger solo los datos que de verdad necesitas reducen el daño si algo falla.
Plan de respuesta a incidentes en WordPress
Conviene decidir antes del incidente quién hace qué: quién toca la web, quién habla con los clientes y quién decide sobre la notificación a la AEPD. En una empresa pequeña puede ser la misma persona, pero tiene que estar escrito.
Durante el incidente, contener sin destruir pruebas: copia primero, aislar después. Tras la limpieza, comprobar que no queda malware, cerrar la vía de entrada y vigilar de cerca unas semanas por si vuelve.
Plugins y herramientas de seguridad para WordPress
Wordfence ofrece cortafuegos a nivel de aplicación, escáner de malware y doble factor. Sucuri combina un WAF en la nube con limpieza de malware y vigilancia de listas negras. All-In-One Security cubre lo básico de forma gratuita. Ninguno sustituye a una revisión: un plugin de seguridad no te dice que tienes un administrador de más ni que tus copias no se pueden restaurar. Elige uno mantenido activamente y que no duplique lo que ya hace tu WAF o tu hosting.
Web hackeada: qué hacer en la primera hora
- No borres nada. Copia los archivos y la base de datos tal como están. Los archivos infectados son prueba y muestran por dónde entró el atacante.
- Cambia las contraseñas desde un dispositivo limpio: panel de WordPress, hosting, SFTP, base de datos, claves API de pagos y correo. Cierra todas las sesiones.
- Pon la web fuera de línea o activa el modo mantenimiento si sirve malware, redirige a los visitantes o recoge datos de formularios y pagos.
- Pide al hosting los registros
access.logyerror.logy pregunta cuánto tiempo los conserva. Sin registros no se sabe qué se leyó. - Revisa Google Search Console. Un propietario desconocido es una señal habitual de intrusión; elimínalo cuando la copia esté a salvo.
- Apunta la hora en que confirmaste la intrusión. Desde ahí corren los plazos del RGPD.
¿Cómo es la limpieza tras un hackeo?
Trabajo sobre una copia, no sobre producción. Primero la vía de entrada (registros, wp core verify-checksums, comparación de los archivos de plugins y temas), después la eliminación de malware y puertas traseras en archivos y base de datos, la revisión de administradores y tareas cron, la reinstalación del núcleo y los plugins desde fuentes limpias y el cambio de todos los secretos. Termina con una comprobación final y, si Google marcó la web, una solicitud de revisión. La duración depende de cuántos archivos están infectados y de si hay registros, por eso doy una estimación solo después de ver la web. El resultado incluye una valoración del riesgo de fuga de datos.
¿Qué accesos necesita una auditoría de seguridad WordPress?
- Una cuenta de administrador temporal con doble factor activado. La creas para la auditoría y la borras cuando termino.
- Acceso SSH o SFTP de solo lectura. Me permite comprobar la integridad de los ficheros con WP-CLI, revisar permisos, leer
access.logyerror.logy buscar puertas traseras en/wp-content/uploads/. Sin él, parte de la superficie queda sin revisar. - Una lista breve de integraciones y plugins importantes: nombre y para qué sirve cada uno. Me ayuda a decidir qué código leer primero.
Ayudan también el acceso a Google Search Console, el informe de una auditoría anterior si existe y las alertas de tu herramienta de seguridad actual. Si falta algo, ajusto el alcance y dejo anotado en el informe lo que no pude verificar. Envía los accesos por un canal aparte, nunca en el texto del formulario.
Auditorías web WPO y rendimiento tras incidentes de seguridad
Una intrusión o un plugin malicioso a menudo pasa desapercibido hasta que el servidor empieza a ir lento. Las auditorías web WPO miden LCP, INP, CLS y TTFB antes y después de las correcciones, según los criterios de Core Web Vitals de Google Search Central. Hacerlas junto a la revisión de seguridad permite saber si la lentitud viene de scripts inyectados, de consultas MySQL sin índices o de la capa de PHP.
Mantenimiento de seguridad después de la auditoría
Las correcciones envejecen: cada actualización de plugin o cambio de configuración puede abrir algo nuevo. Si no quieres ocuparte tú, el mantenimiento WordPress continuado incluye actualizaciones probadas en staging, copias guardadas más de 30 días en la UE y monitorización de disponibilidad cada pocos minutos.
Pedir una auditoría de seguridad
Servicios relacionados
- Desarrollador WordPress: desarrollo a medida con la seguridad en cuenta desde el principio
- Desarrollador WooCommerce: tiendas con la pasarela de pago bien integrada
- Optimización de velocidad: rendimiento y seguridad van de la mano
- SEO, GEO y AEO: visibilidad en buscadores e IA
- Mantenimiento WordPress: actualizaciones y copias de seguridad continuas
- Rescate de webs hechas por IA: el código generado por IA suele omitir comprobaciones de nonce y permisos
- Contacto: pide tu auditoría de seguridad
Antes de fijar el alcance, mira la web tú mismo: el chequeo de sitio WordPress descarga la versión pública de una dirección y da números medidos, incluidas las peticiones que bloquean el primer pintado y cuánto pesan. El resultado es inmediato y no pide correo.
