En 2025, WordPress registró 11.334 vulnerabilidades nuevas, un aumento de 42% según Patchstack en relación con el año anterior. Las altamente explotables subieron 113% según Patchstack. El tiempo entre la divulgación de una falla y la primera explotación masiva: 5 horas. En Tech86 ya vimos suficiente para afirmar: el problema no se resuelve con más plugins de seguridad. La salida es estructural, y se llama arquitectura headless.
El ecosistema es el problema, no el core
El core de WordPress es relativamente seguro. Patchstack documentó que el 97% de las vulnerabilidades provienen de plugins. El sitio promedio corre entre 20 y 40 plugins. Cada uno es un vector de ataque potencial. Un plugin desactualizado expone XSS o RCE, y es explotado en cuestión de horas.
La matemática es implacable: 20 plugins × 12 actualizaciones por año × 5 horas de ventana de explotación. Nadie aplica parches en 5 horas. Ni los equipos dedicados. El problema es de supply chain estructural, y no se resuelve instalando un plugin de seguridad más que, por definición, también es un plugin.
Ya hemos atendido clientes que corrían 35 plugins y descubrieron que 8 llevaban más de un año abandonados. Dos de ellos tenían vulnerabilidades conocidas desde hacía meses. El sitio estaba comprometido y nadie lo había notado. Esto no es la excepción, es la regla.
Lo que queda expuesto en el WordPress monolítico
Un WordPress tradicional expone a internet todo lo que no debería estar expuesto. /wp-login.php queda accesible y recibe en promedio 30.000 intentos de brute-force por día. XML-RPC queda activo por defecto. El endpoint de upload queda accesible. El directorio de plugins queda accesible.
Cada uno de esos endpoints es una puerta que no necesita estar abierta. Pero en el modelo monolítico no hay forma de cerrarlas sin romper funcionalidad. WordPress necesita servir páginas, procesar formularios, aceptar uploads y autenticar usuarios, todo por el mismo servidor, todo en la misma superficie.
El resultado es un sitio donde la misma infraestructura que sirve el blog a los visitantes también procesa autenticación, acepta uploads y ejecuta PHP por request. Es el equivalente a dejar la puerta trasera de la oficina abierta porque el delivery necesita entrar.
Lo que headless elimina estructuralmente
La arquitectura headless separa el CMS del frontend. WordPress se convierte en un origen de contenido detrás de una API autenticada. El frontend es HTML preconstruido servido por CDN. Las implicaciones de seguridad son directas:
- PHP por request en el frontend → HTML preconstruido vía CDN. Cero PHP en el tráfico público.
- Database query por page load → Datos renderizados en build time. Sin SQL injection en el frontend.
/wp-login.php→ Admin detrás de firewall, sin URL pública. Sin brute-force.- XML-RPC → No existe en el frontend. Upload endpoint → no existe. Directorio de plugins → no existe.
Headless no es un plugin más. Es la remoción estructural de la superficie de ataque. El ataque que funcionaba en el WordPress monolítico simplemente no encuentra superficie para explotar.
Rendimiento por diseño, no por workaround
La migración headless no es solo seguridad. Es rendimiento real, y los números de un caso concreto con 400 páginas B2B hablan por sí solos:
| Métrica | WordPress monolítico | Headless (Next.js) | Reducción |
|---|---|---|---|
| LCP | 2.8s | 0.7s | 75% |
| CLS | 0.18 | 0.01 | Prácticamente eliminado |
| TTI | 5.1s | 1.2s | 76% |
| Peso de página | 3.2MB | 480KB | 85% |
Core Web Vitals impacta la conversión y el ranking. En el WordPress monolítico, el enfoque es compensar: plugin de caché, Cloudflare Pro, optimización manual de assets. En headless, el rendimiento es por diseño: el HTML ya está listo, servido desde el punto más cercano al usuario.
Aprendimos de un cliente que gastaba 200 dólares/mes en Cloudflare Pro + plugins de caché premium para lograr un LCP de 2.8s. Tras la migración headless, el LCP cayó a 0.7s sin ningún plugin de caché, porque no existe caché cuando la página ya es estática.
Lo que cambia en la operación del día a día
La operación de un sitio headless es fundamentalmente diferente. Sin plugin de caché que configurar. Sin Cloudflare Pro para compensar PHP lento. Sin auditoría de plugins semanal. Sin parche de emergencia a las 3 de la mañana porque un plugin popular tuvo un zero-day divulgado.
El CMS vive en un origen separado, detrás de una API autenticada. El frontend es estático. Cuando se divulga una vulnerabilidad en WordPress, usted actualiza el CMS, pero el frontend no se ve afectado porque no ejecuta PHP. La ventana de 5 horas entre divulgación y explotación deja de ser una pesadilla.
El costo operativo baja. El riesgo baja. El rendimiento sube. No es magia, es arquitectura.
El costo de la migración y el ROI real
La inversión en migración headless varía según el porte:
- Pequeño (blog/institucional): R$ 3.000 a 7.000
- Mediano (B2B con integraciones): R$ 7.000 a 15.000
- Enterprise (e-commerce, multirregión): R$ 15.000 o más
El ROI llega en meses. Hosting más barato porque sirve HTML estático. Cero plugins premium de caché, seguridad y optimización. Cero downtime por parche de emergencia. Conversión que sube porque el sitio carga en 0.7s en lugar de 2.8s.
La pregunta que hacemos a cada cliente WordPress: ¿cuántos plugins tiene su sitio? ¿Cuántos actualizó la semana pasada? ¿Cuántos no actualiza por miedo a romper algo? Si la respuesta es "no sé", está operando con una bomba de tiempo de supply chain. Temporizador: 5 horas.
En Tech86 migramos sitios WordPress a arquitectura headless con Next.js. Sin plugin. Sin /wp-login.php expuesto. Sin pesadilla de parches. La seguridad deja de ser reactiva y pasa a ser estructural.