🪵Logs con PII: el riesgo silencioso que tu auditoría de WordPress está ignorando

Abrís /var/log/nginx/access.log y ves esto:

181.45.22.118 - - [19/Apr/2026:14:22:03 +0000] "GET /mi-cuenta/?reset-pass&key=abc123 HTTP/2.0" 200 ...
181.45.22.118 - - [19/Apr/2026:14:23:11 +0000] "POST /wp-login.php" 302 ...
203.12.44.91 - - [19/Apr/2026:14:25:47 +0000] "GET /checkout/?email=juan.perez@dominio.com HTTP/2.0" 200 ...

Ahí hay tres problemas serios que tu política de privacidad probablemente no cubre:

1. IPs retenidas indefinidamente.
2. Un token de reseteo de contraseña en un log de acceso —donde cualquiera con acceso al log puede intentar usarlo.
3. Un email en la URL (mala práctica del dev, pero ahí está), registrado para siempre.

Los logs son el rincón de los ecommerce donde más PII se acumula sin que nadie la vea. Los devs miran la base de datos, los abogados miran la política, los auditores miran el checkout. Nadie mira los logs. Y cuando hay una brecha, los atacantes extraen en minutos lo que tardaron años en acumularse: historial completo de visitantes, tokens, emails, intentos de login, patrones de comportamiento.

Este artículo es el mapa completo de dónde se acumula PII en los logs de WordPress, cómo auditarla sin volverte loco, y cómo sanitizar sin romper la observabilidad que necesitás para debuguear y responder a incidentes.

Los seis sistemas de logging que acumulan PII en un WordPress típico

Si nunca auditaste los logs, probablemente tenés seis fuentes activas. Cada una con su formato, su ubicación, su PII y su riesgo.

1. Access logs del servidor web

Nginx, Apache o Caddy registran cada request que llega al sitio. Por defecto incluyen IP del cliente, timestamp, método + URL, código de respuesta, User-Agent, referer.

PII típica: IP del visitante, User-Agent (puede ser fingerprint), URLs con parámetros que contienen emails/IDs/tokens, referer que revela navegación previa.

Ubicación: /var/log/nginx/access.log, /var/log/apache2/access.log, o la ruta configurada por tu panel (cPanel, Plesk, Laravel Forge).

Problema mayor: rotación por defecto suele ser débil (mensual, sin límite de tamaño), y los logs rotados rara vez se borran. Encontrarás servidores con 3 años de access logs acumulados.

2. Error logs del servidor y PHP

Cuando algo rompe, el error va al log con el contexto del momento. Ese contexto a menudo incluye variables de sesión, parámetros de POST, headers.

PII típica: cualquier cosa que esté en memoria cuando ocurre el error. Contraseñas en formularios que fallaron validación, tokens de sesión, datos de checkout a medio procesar.

Ubicación: /var/log/nginx/error.log, /var/log/php_errors.log, o wp-content/debug.log si tenés WP_DEBUG_LOG activo (nunca debería estar en producción, pero lo está en el 30% de los sitios).

Problema mayor: los error logs suelen quedar accesibles vía web si la configuración del servidor falla (wp-content/debug.log público es un clásico).

3. Logs de WooCommerce

WooCommerce tiene su propio sistema de logs en wp-content/uploads/wc-logs/. Registra errores de pasarela de pago, fallos de emails, problemas con zonas de envío, deprecaciones.

PII típica: cuando un pago falla, el log puede contener el response de la pasarela con últimos 4 dígitos de tarjeta, código de autorización, email del cliente, referencia de pedido.

Ubicación: /wp-content/uploads/wc-logs/. Los archivos tienen nombres aleatorios pero predecibles (payment-gateway-stripe-YYYY-MM-DD-hash.log).

Problema mayor: por defecto son públicos si no configurás deny en el server. Vulnerabilidad recurrente.

4. Logs de emails transaccionales

Plugins como WP Mail SMTP, Fluent SMTP, Post SMTP, Easy WP SMTP. Todos ofrecen "email log" como feature popular.

PII típica: destinatario, CC, BCC, asunto, body completo del email. En pedidos incluye nombre, dirección, items comprados, total. En recuperación de contraseña incluye el token de reset completo. En suscripciones incluye el link de confirmación.

Ubicación: base de datos, tabla wp_wpms_logs o similar.

Problema mayor: el body del email es una mina de oro para un atacante. Acceso al admin = acceso a todo el historial de comunicaciones. Y los tokens de reseteo que ya caducaron siguen en el log, delatando patrones.

5. Logs de plugins de seguridad

Wordfence, iThemes Security (ahora Solid Security), Sucuri, WP Cerber. Todos registran intentos de login, cambios en archivos, accesos sospechosos, bloqueos de IP.

PII típica: IPs de atacantes y legítimos, usernames intentados (a veces los usuarios tipean su password en el campo de username), user IDs de quien hizo cambios, archivos modificados, información de sesión.

Ubicación: base de datos, tablas propias del plugin.

Problema mayor: retención típica muy larga (Wordfence conserva meses) y algunos plugins incluyen intentos de credenciales fallidas en texto plano cuando el username coincide con un password (ataques de credential stuffing mal configurados).

6. Logs de analytics y tracking

Google Analytics (hash de IP ya por defecto), Matomo auto-hospedado, Plausible, plugins internos de conversión. Si el analytics vive en tu servidor, los logs pueden acumular cookies, hashes de visitante, paths completos.

PII típica: ID de visitante persistente (pseudo-ID pero con alcance temporal largo), paths que incluyen user IDs, referers con tokens.

Ubicación: base de datos del analytics, o archivos planos si auto-hospedás.

Problema mayor: el ID de visitante cross-sesión efectivamente identifica a un usuario recurrente, aunque no sepas el nombre.

Las técnicas de sanitización

No borrás los logs —los necesitás para debuggear y responder a incidentes—. Sanitizás: reducís la PII al mínimo útil.

Truncado de IPs

Para IPv4, quitar el último octeto: 203.12.44.91 → 203.12.44.0. Mantiene el rango geográfico y de red para análisis, destruye la identificación individual.

Para IPv6, quitar los últimos 80 bits (dejar solo los primeros 48): 2001:db8:a::1234:5678:90ab → 2001:db8:a::.

Se puede aplicar al momento del logging (mejor) o como batch job que reescribe logs a cierta edad (peor, porque el log crudo existe durante ese tiempo).

Hashing con sal

Reemplazar IPs o emails por hash(valor + sal_rotada). La sal rota cada 30-90 días, así que hashes viejos no se correlacionan con nuevos. Permite detectar patrones dentro de una ventana pero no a lo largo de meses.

Usar Argon2 o SHA-256 con sal de al menos 32 bytes. Nunca MD5 o SHA-1 para este propósito.

Redacción con regex

Para logs textuales (access logs, error logs con contexto), aplicar patrones de reemplazo:

• Emails: \w[\w._%+-]*@\w[\w.-]+\.\w{2,} → [EMAIL]
• Números de tarjeta: \b(?:\d[ -]*?){13,19}\b → [CARD]
• DNIs/CUITs comunes: patrones según país.
• Tokens de sesión conocidos: parámetros como key=, token=, nonce= → [TOKEN]

La redacción puede ser destructiva (reemplazar in-place) o con mapping (guardar el valor original tokenizado en un vault separado para casos donde necesitás desandarla). Para logs de observabilidad pura, destructiva es lo correcto.

Rotación agresiva

Definir un plazo máximo y aplicarlo con cron. Propuestas típicas:

• Access logs crudos con IP: 30 días.
• Access logs sanitizados (IPs truncadas/hasheadas): 12 meses.
• Error logs con contexto: 14 días.
• Logs de WooCommerce: 30 días, 90 si hay disputa activa.
• Logs de emails: metadatos 90 días, body 7 días máximo.
• Logs de plugins de seguridad: 90 días.
• Logs de analytics: según lo que el producto defina, pero nunca indefinido.

Rotación implica borrado efectivo, no solo mover a otro directorio y olvidar.

Pipeline separado

Para observabilidad seria, muchos sitios mandan los logs a una stack externa (ELK, Grafana Loki, Datadog, Sumo Logic). Esa stack agrega retención y control, pero también agrega un sub-procesador con copias de PII. Tres reglas:

1. Sanitizar antes de enviar al pipeline, no después.
2. Cifrar en tránsito (TLS) y en reposo (AES-256 o equivalente).
3. Firmar DPA con el proveedor que incluya retención y derecho de borrado por titular.

Los plugins que más PII loguean y cómo reconfigurarlos

Tres plugins son responsables de la mayoría de los hallazgos incómodos en auditorías.

WP Mail SMTP

Por defecto, si activás el email log, guarda el body completo. El vector de ataque es que un admin comprometido tiene acceso inmediato a todas las comunicaciones históricas.

Reconfiguración:

1. Email Log: activado pero con "Save Content" desactivado.
2. Retention: 30 días máximo.
3. Rol con acceso al log: solo administrador principal, no administradores secundarios.
4. Export del log: solo manual, con justificación documentada.

Si realmente necesitás el body para debuguear, activalo temporal (1 semana), documentalo en tu log de cambios de configuración, y desactivalo cuando termines.

Wordfence

El Live Traffic de Wordfence registra cada visita con IP, User-Agent, path completo. Históricamente retuvo hasta 90 días con plan premium.

Reconfiguración:

1. Live Traffic: deshabilitado en producción salvo análisis específico.
2. Login Security Logs: retención 90 días, acceso restringido.
3. Firewall Logs: retención 30 días.
4. Send logs to Wordfence Central: evaluado bajo DPA, no activado por defecto.

WooCommerce (built-in)

Los logs van a archivos planos en uploads/wc-logs/. El problema es doble: accesibles vía web por defecto, retención infinita.

Reconfiguración:

1. Bloquear /wp-content/uploads/wc-logs/ en la configuración del servidor.
2. Cron diario que rota logs mayores a 30 días (o los mueve a storage cifrado).
3. Configurar log level a "Error" en lugar de "Debug" en producción.
4. Revisar qué extensiones están escribiendo logs: gateways de pago, shipping methods, taxes. Cada una tiene su propio archivo.

Pipeline de observabilidad sin acumulación de PII

El objetivo no es tener logs perfectos. Es tener logs útiles sin riesgo de PII acumulada. Un pipeline mínimo:

Capa 1 — Escritura del log. Interceptar en el momento de escribir: truncar IPs, redactar tokens conocidos, no loguear bodies completos.

Capa 2 — Rotación local. Borrar logs crudos pasados los 30 días, archivar sanitizados.

Capa 3 — Pipeline externo (opcional). Enviar logs sanitizados a una stack de observabilidad con retención definida y DPA firmado.

Capa 4 — Respuesta a incidentes. Cuando hay un incidente, escalada temporal de verbosidad, retención extendida durante la investigación, sanitización antes de compartir con terceros (consultoría forense, equipo legal).

Capa 5 — Auditoría periódica. Trimestral: revisar qué se está logueando, si hay plugins nuevos agregando fuentes, si la retención se está aplicando correctamente, si hay acceso no autorizado a los logs.

Ese pipeline no es obra de un día. Es una capacidad que se construye iterativamente. Pero empezar es barato: truncar IPs en el nginx.conf y rotar los access logs a 30 días se hace en una hora.

Qué hacer con los logs viejos que ya tenés

Es probable que descubras al auditar: años de access logs, gigabytes de wc-logs, tablas de 50 millones de filas en WP Mail SMTP.

El camino correcto:

1. Inventario. Tamaño, fuente, contenido de muestra, edad de los más viejos.
2. Triage. Separar los que tienen uso operativo documentado de los que no.
3. Los sin uso: borrado completo, con evidencia de la acción.
4. Los con uso: sanitización batch (script que procesa y reescribe), seguido de rotación normal.
5. Documentación. Política de retención nueva, comunicada al equipo, aplicada con cron.
6. Verificación. 30 días después, auditar que la política se está aplicando.

El pasado no te exime —si te auditan mañana, los logs viejos son evidencia de acumulación—. Pero una acción correctiva documentada (fecha, qué se hizo, por qué) convierte el hallazgo en "atendido" antes de que se vuelva problema.

Cierre

Los logs son el barrio olvidado del WordPress. Son infraestructura, no feature de cliente. Nadie los ve, nadie los audita, nadie los menciona en la política de privacidad. Y ahí es donde se acumulan años de PII que, el día de una brecha, salen en segundos.

Sanitizar logs no rompe la observabilidad —la mejora—. Un log con IPs truncadas y tokens redactados es más seguro y sigue siendo útil para detectar ataques, debuguear errores y responder a incidentes. Lo que se pierde es capacidad de identificar visitantes individuales, que es exactamente lo que no deberías poder hacer sin base legal.

La auditoría de logs es el ejercicio más barato de privacidad con mejor retorno. Una tarde de trabajo cerrando el nginx.conf, el WP Mail SMTP y el wc-logs puede reducir el blast radius de una brecha futura en un orden de magnitud. Es inversión que se paga sola la primera vez que alguien intenta explotarte.