Auditoría de Seguridad WordPress en Madrid

#El sitio que nadie revisa desde el lanzamiento

La mayoría de sitios WordPress en Madrid no caen por un atacante sofisticado. Caen por el tiempo. Se lanza el proyecto, la agencia entrega, se paga la factura y pasan tres años en los que nadie tiene mandato explícito sobre seguridad, solo sobre que la web responda. Los plugins se quedan en la versión del día de la puesta en producción. Una integración con ERP recibe permisos de administrador porque era lo más rápido. El desarrollador que montó el entorno cambia de empresa, pero su usuario sigue activo. Nada de esto parece grave por separado. Juntos forman exactamente la superficie que los bots automatizados explotan, y esos bots no distinguen entre una pyme en Tetuán y una filial del IBEX en la Castellana.

Una auditoría de seguridad es la forma sistemática de recuperar esos años perdidos. No un escáner que escupe doscientas líneas en rojo, sino una revisión manual de instalación, plugins, cuentas, servidor y cadena de proveedores, donde cada hallazgo se verifica, se evalúa contra su operación real y se prioriza por riesgo efectivo. Para empresas en Madrid usamos dos referencias españolas en la base del informe: el Esquema Nacional de Seguridad para el lado de gobierno y continuidad, y las guías operativas de INCIBE-CERT para detección y respuesta. En la capa de aplicación aplicamos metodología OWASP. El resultado sirve al desarrollador que debe corregir y al responsable que debe responder cuando el comité, el auditor o un cliente pregunta cómo está realmente la seguridad.

#ENS e INCIBE-CERT como referencia en el ecosistema madrileño

Las empresas madrileñas no necesitan buscar solo marcos extranjeros. El Esquema Nacional de Seguridad organiza la seguridad en categorías reconocibles para administraciones, proveedores del sector público y cada vez más para licitaciones privadas que exigen alineación con ENS: identificar y conocer el sistema, proteger, detectar, reaccionar y recuperar. Una auditoría WordPress se puede mapear con precisión sobre esas categorías.

Identificar: inventario completo de plugins, temas, integraciones, cuentas y quién tiene acceso de verdad, incluidos FTP y usuarios de base de datos que nadie recuerda. Proteger: rutinas de actualización, control de accesos, doble factor, endurecimiento del login y configuración del servidor. Detectar: existen logs que mostrarían un acceso anómalo y alguien los revisa periódicamente. Reaccionar y recuperar: hay copias de seguridad probadas y un responsable claro el día del incidente. INCIBE-CERT aporta el vocabulario operativo que muchos equipos de TI en Madrid ya conocen: indicadores, playbooks de respuesta y coordinación con CSIRT cuando el incidente escala.

La observación honesta tras muchas revisiones en la Comunidad de Madrid: la mayoría de entornos WordPress puntúan razonablemente en protección y muy mal en detección. Hay plugin de seguridad y firewall, pero nadie sabe si anoche alguien entró desde una IP inusual porque los logs no se centralizan y no hay turno de revisión.

#Protección de datos: 72 horas AEPD cuando no sabes qué pasó

Un WordPress comprometido rara vez es solo un problema técnico. Si el sitio tiene formulario de contacto, área de clientes, newsletter o tienda, trata datos personales y una intrusión puede ser una brecha de seguridad según el RGPD. Las brechas con riesgo para las personas deben notificarse a la Agencia Española de Protección de Datos en un plazo de 72 horas desde que se tenga constancia. El plazo no es el drama. Lo difícil es el contenido de la notificación: qué categorías de datos, cuántas personas, causa probable, medidas adoptadas. Una empresa sin logs ni inventario de su propia instalación no puede responder con precisión y acaba notificando incertidumbre en cada campo.

Por eso nuestras auditorías incluyen un hilo de privacidad. Para cada hallazgo evaluamos no solo la gravedad técnica sino la consecuencia en protección de datos: ¿afecta a personas identificables y una explotación activaría obligación de notificación? Un xmlrpc abierto y una inyección SQL en un formulario pueden puntuar igual en un escáner automático, pero no son equivalentes ante la AEPD. El informe marca qué hallazgos son críticos para privacidad para que el responsable del tratamiento priorice y documente la decisión en el registro de actividades.

#NIS2 y exigencias que bajan por la cadena de suministro

La regulación de ciberseguridad dejó de ser tema exclusivo de banca o energía. La transposición de NIS2 en España amplía el círculo de entidades con obligaciones de gestión de riesgos, medidas de seguridad y notificación de incidentes. Para una pyme madrileña la consecuencia práctica no suele ser convertir su web corporativa en infraestructura crítica, sino que clientes grandes, administraciones y aseguradoras empiezan a pedir evidencias en contratos y pliegos: cuestionarios, planes de respuesta, prueba de revisiones periódicas.

Ya lo vemos en licitaciones del Ayuntamiento de Madrid, contratos con corporaciones en Las Tablas y acuerdos marco donde el proveedor de marketing digital debe demostrar controles sobre el CMS. Quien responde «tenemos Wordfence» pierde frente a quien adjunta un informe de auditoría con hallazgos, fechas de cierre y valoración de privacidad. La auditoría deja de ser solo reducción de riesgo y pasa a ser documentación comercial en un mercado donde la ciberseguridad entra en criterios de adjudicación.

#Qué encontramos en instalaciones madrileñas

Tras numerosas auditorías en entornos WordPress de Madrid el patrón se repite. Plugins desactualizados en hosting compartido encabezan la lista: cientos de sitios en el mismo servidor y una extensión vulnerable en uno se convierte en trampolín. En segundo lugar, cuentas que no deberían existir: administradores de agencias que cerraron hace dos años, usuario «test» con contraseña del lanzamiento, FTP creado para una migración puntual en 2019. En tercero, ausencia de doble factor en las cuentas que importan, a menudo con el login en la URL por defecto y sin límite de intentos.

Después llegan los clásicos técnicos: xmlrpc.php accesible desde internet, endpoints REST que enumeran usuarios, prefijos de base de datos por defecto, permisos de ficheros heredados del instalador automático y copias de seguridad inexistentes, en el mismo servidor o nunca restauradas en una prueba. Nada de esto requiere un atacante avanzado. Todo lo encuentra una campaña automatizada en minutos.

La diferencia está en la priorización. Un escáner pinta todo de rojo con la misma intensidad. Una auditoría separa lo explotable en su configuración concreta de lo teórico, y lo que toca datos de clientes de lo que en el peor caso expone una página de prueba vacía.

#Herencia de agencias: la cadena de proveedores sin mapa

El riesgo más ignorado en WordPress madrileño no siempre es técnico, es organizativo. Un sitio típico ha pasado por dos o tres proveedores: quien lo construyó, el freelance que hizo mantenimiento y la agencia que «solo iba a retocar el diseño». Cada transición deja accesos y casi nadie limpia. Lo llamamos herencia de agencias: cuentas, claves API, licencias registradas en correos ajenos y customizaciones sin documentación.

La auditoría mapea esa cadena de forma explícita. Quién tiene admin en WordPress, quién entra al panel del hosting, quién controla el dominio y el DNS, dónde están las licencias de plugins de pago y quién puede bloquearle el acceso a su propio sitio. La respuesta suele sorprender. En una revisión reciente el único contacto con acceso DNS era un freelance sin contrato vigente desde 2021. Perder ese contacto en medio de un incidente alarga la respuesta horas o días.

#Tres patrones de auditorías en Madrid

Tres casos anonimizados que se repiten, sin detalles identificativos.

La scale-up de La Nave y el plugin de IA: una startup del campus de La Nave en Villaverde había activado un conector que permitía a un agente externo ejecutar PHP y consultar la base de datos vía webhook. No había CVE: era funcionalidad documentada. El escáner estaba limpio. La auditoría lo clasificó junto a backdoors en uploads porque el efecto operativo es el mismo: un tercero puede modificar ficheros y datos. Se retiró de producción, se limitó a un entorno de pruebas con lista blanca de IP y se documentó quién guardaba la clave. Ese vector encaja en el enfoque ampliado de nuestra auditoría de seguridad WordPress, donde inventariamos plugins con ejecución de código por IA, no solo CVE conocidos.

La tienda WooCommerce con intento de skimming Bizum: una tienda en Chamberí reportó «comportamiento raro» en checkout. Encontramos JavaScript ajeno cargado en la página de pago desde un plugin de regalo obsoleto, patrón de skimming clásico antes de que Redsys o Bizum tomen el control del campo de tarjeta. El intento era tosco y probablemente no extrajo datos reales, pero activó evaluación de brecha: qué clientes pudieron estar expuestos y qué habría que comunicar. Con una auditoría dos años antes el susto habría sido menor.

La entidad sujeta a ENS con xmlrpc abierto: un proveedor de servicios al sector público en Alcobendas tenía xmlrpc activo y REST que listaba editores. No había explotación activa, pero el informe se redactó en lenguaje alineado con ENS para el responsable de seguridad que debía presentarlo internamente. Cerrar xmlrpc y endurecer REST costó una tarde. El valor fue traducir hallazgos técnicos a controles que el comité de seguridad entiende sin ser desarrollador.

#Qué entrega la auditoría y qué no es

La entrega es un informe con lista priorizada, y priorizada significa algo concreto: cada hallazgo verificado manualmente, ordenado por explotabilidad e impacto en su entorno, con remedio recomendado y esfuerzo estimado. Los críticos se comunican en el momento, no tres semanas después en el PDF final. La valoración de privacidad va por hallazgo para alimentar el registro de actividades y preparar una posible notificación AEPD. Cerramos con una sesión donde responsable técnico y dirección pueden preguntar, porque un informe que nadie entiende no genera acción.

Igual de importante es lo que no es. No es un volcado de WPScan: las herramientas automatizadas son materia prima, no entregable. No es teatro del miedo: no inflamos la lista con vulnerabilidades teóricas. Y no es un documento de venta disfrazado: el informe no depende de que encargue la remediación con nosotros. Si tras la auditoría necesita mantenimiento continuo, eso es otro encargo con alcance propio.

#Endurecimiento que sí mueve la aguja en producción madrileña

Endurecer no es marcar una checklist y archivarla. Son restricciones que dificultan la siguiente explotación. En auditorías para Madrid aplicamos, en este orden aproximado, cambios que INCIBE repite en sus guías y que encajan con expectativas ENS cuando el cliente las necesita.

Constantes en wp-config.php: DISALLOW_FILE_EDIT y DISALLOW_FILE_MODS cierran el editor del panel y el instalador casual de plugins. FORCE_SSL_ADMIN evita robo de sesión en redes compartidas de coworking en Malasaña o Las Tablas. WP_AUTO_UPDATE_CORE en minor deja pasar parches de seguridad sin arriesgar una major un viernes tarde. Claves de Redsys, Bizum o Stripe van en variables de entorno fuera del web root, no en wp-config, porque cualquier backdoor en uploads que lea ese fichero también lee la pasarela.

Capa de login: doble factor TOTP en cuentas admin y shop manager, throttling en el edge además de PHP, xmlrpc bloqueado si no se usa, y reglas WAF en Cloudflare con DPA firmado y localización UE cuando el informe debe servir ante AEPD o auditoría ENS. Sistema de ficheros: PHP desactivado en uploads, listado de directorios off, copias externas al hosting y prueba de restauración documentada.

#Cuándo no necesitas una auditoría completa

Falta este párrafo en muchas páginas de servicios. Una instalación reciente hecha por un equipo competente, con contrato de actualizaciones, doble factor y copia probada, no necesita auditoría completa todavía. Basta una revisión de accesos y rutinas de una hora. Lo mismo aplica a una web corporativa sin formularios, sin login y sin datos personales: ahí importa más la configuración endurecida y las actualizaciones automáticas que un informe de cien páginas. Si hay un incidente activo, la auditoría es la herramienta equivocada: primero respuesta con INCIBE-CERT si escala, después revisión cuando vuelva la normalidad.

La auditoría completa encaja cuando se cumple al menos uno de estos puntos: el sitio trata datos de clientes o pagos, ha habido varios proveedores, nadie puede responder quién tiene acceso a qué, llevan más de dos años sin revisión sistemática, o un cliente, auditor o pliego exige documentación. Una conversación inicial aclara en qué categoría está y, si encaja en la primera, lo decimos con claridad.

#Modelo de colaboración para clientes B2B en Madrid

Una auditoría exige confianza porque abre lo más sensible de su operación digital. Por eso el marco es formal desde el primer día: acuerdo escrito de alcance, confidencialidad, contrato de encargo de tratamiento cuando proceda, y cuentas de auditoría propias con caducidad que se eliminan al entregar. Todo lo que hacemos queda registrado, no modificamos producción sin acuerdo y no ejecutamos pruebas destructivas. España y Polonia comparten huso horario, así que la coordinación con equipos en Madrid, remoto o presencial en Castellana o Las Tablas, no arrastra retrasos por franjas horarias.

El presupuesto es individual y se fija como cifra cerrada tras la conversación inicial. Después usted elige: corregir con su proveedor, con nosotros o en combinación. La entrada es sin compromiso: hablamos del alcance y recomendamos con honestidad, también cuando la recomendación es que aún no nos necesita.

Última actualización: 30 de agosto de 2026