¿Auditando WordPress? Empieza con tus plugins

Resumen

La mayoría de las auditorías de seguridad de WordPress están al revés: enfatizan las actualizaciones del núcleo y los informes de escáneres mientras que las vulnerabilidades que realmente afectan viven en los plugins. Un informe técnico de SANS encontró que más del 96% de las vulnerabilidades del ecosistema se originan en plugins de terceros, y aproximadamente el 43% no requieren autenticación. Este artículo describe una auditoría centrada en plugins para un pequeño equipo de marketing interno, usando la historia de un sitio que fue hackeado porque todos estaban escaneando la capa equivocada. Aprenderás a inventariar y clasificar cada plugin, probar superficies de ataque no autenticadas, revisar manualmente usuarios y registros, y traducir los hallazgos a un lenguaje de riesgo que un jefe no técnico entienda. El resultado es un ritual de triaje trimestral en lugar de un ejercicio de casillas.

La mayoría de las auditorías de seguridad de WordPress son teatro. Pasas una tarde actualizando el núcleo, cambiando la contraseña de administrador y ejecutando un escáner de plugins que orgullosamente informa "No hay problemas críticos". Mientras tanto, el plugin que aceptaba cargas de archivos y se actualizó por última vez hace tres años permanece tranquilamente en tu directorio de uploads, esperando a alguien que no está en la lista de invitados.

Los números lo respaldan. Un informe técnico de SANS sobre el escaneo de plugins de WordPress encontró que más del 96% de las vulnerabilidades en el ecosistema de WordPress se originan en plugins de terceros, con temas en 4% y núcleo por debajo del 1%. Aproximadamente el 43% de esas fallas pueden explotarse sin ninguna autenticación. Así que cuando tu auditoría gasta la mayor parte de su energía en el núcleo, estás examinando los árboles mientras un incendio forestal comienza en el directorio de plugins de al lado.

Esto no es un llamado a entrar en pánico por el núcleo. Las vulnerabilidades del núcleo como las fallas RCE de wp2shell que tuvieron exploits públicos recientemente deberían parchearse el día en que se anuncian. Pero son lo suficientemente raras como para no merecer la mayor parte de tus horas de auditoría. El grueso pertenece a los plugins, y ahí es donde comienza el flujo de trabajo real.

Imagina el escenario anterior: un domingo por la mañana, tu sitio redirige a una página de casino, y tu jefe escribe: "Creía que teníamos seguridad". Sí tenías seguridad: tenías una auditoría de casillas. El escenario posterior es un sistema de triaje que trata los plugins como la superficie de ataque que en realidad son, los prueba desde el exterior y verifica las cosas que los escáneres no pueden ver.

Formas parte de un pequeño equipo de marketing con un sitio de WordPress que ha estado funcionando desde 2017. Tiene un plugin personalizado de registro de eventos que un freelancer construyó en 2019, un plugin de formulario de contacto con un campo de carga de archivos, y un plugin de slider que fue vendido y ya no tiene una página pública de actualizaciones. Esta no es una pila inusual. Aquí es donde comienza tu auditoría.

---

El inventario de plugins es tu política de seguridad

Haz inventario de cada plugin y tema. Anota la versión, la fecha de la última actualización, si el proveedor sigue activo y si alguien realmente lo usa. Luego clasifica cada uno en una categoría: mantenido y usado, mantenido y no usado, abandonado pero usado, abandonado y no usado. Elimina los no usados de inmediato. Ignora la defensa de "solo cuesta $50 al mes": un plugin no usado es un pasivo, no una característica. Para los abandonados pero usados, decide: reemplázalo o acepta el riesgo y anótalo en un registro de riesgos que tu jefe haya visto.

El plugin de registro de eventos cae en la categoría de abandonado pero usado. Acepta pagos y envía correos de confirmación, y reemplazarlo es un proyecto, así que lo conservas por ahora. Pero escribes una nota que dice: "esta es la fuente más probable de una futura brecha", y lo agregas a la parte superior de la lista de pruebas.

Superficie de ataque	Proporción de vulnerabilidades conocidas de WordPress	Prioridad de auditoría
Plugins de terceros	Más del 96%	La más alta: inventariar, escanear, probar, reemplazar
Temas	Alrededor del 4%	Media: solo si es personalizado o desactualizado
Núcleo de WordPress	Menos del 1%	Baja: mantener parcheado, seguir adelante

Cuando SecurityWeek contó más de 8,000 nuevas vulnerabilidades de WordPress en 2024, la gran mayoría eran de este tipo: problemas de plugins, no parches del núcleo. Un escáner te informará sobre las que han sido divulgadas y tienen un CVE. No te informará sobre el código personalizado del freelancer sin CVE, porque nadie lo ha examinado cuidadosamente. Ese examen manual es tu trabajo. Para un recorrido más profundo de revisiones específicas de plugins, consulta esta guía sobre auditar tus plugins de WordPress en busca de vulnerabilidades.

---

Pruébalo como un extraño: el 43% que no necesita contraseña

Tu escáner ya te ha dicho que no hay nada malo. Ahora haz lo que él no puede: sondear el sitio desde el exterior, sin iniciar sesión. Comienza con cada campo de carga de archivos, cada formulario que procesa un POST, cada endpoint admin-ajax. ¿La carga realmente verifica el contenido del archivo, o solo la extensión? ¿Dónde terminan los archivos cargados y puede el servidor web ejecutar PHP en ese directorio? El 43% de las fallas de plugins que no requieren autenticación suele encontrarse exactamente en estos lugares: XSS almacenado no autenticado, carga arbitraria de archivos e inyección de objetos PHP.

El plugin de formulario de contacto permite a los visitantes adjuntar un currículum. Renombra el archivo usando el nombre original del visitante, así que subes "resume.php" y se guarda en una carpeta /uploads/contact/ que es escribible por diseño. Si el servidor también permite ejecutar PHP en ese directorio, el atacante acaba de obtener una webshell. Fastly ha documentado explotación activa de XSS almacenado no autenticado en plugins de WordPress; esto no es un riesgo de nicho para diapositivas. Tu prueba es simple: crea un archivo con contenido conocido, súbelo y mira si regresa con su nombre y tipo original. Luego intenta subir un archivo .php. Si regresa como .php, acabas de encontrar un agujero explotable.

Aquí es donde también se viene abajo el argumento de "pero nuestro plugin de seguridad tiene un WAF". Un WAF puede bloquear un payload conocido, pero las reglas de normalización de rutas en las que se basa a menudo divergen de lo que el servidor realmente hace. La Guía de Pruebas de Seguridad Web de OWASP es una mejor referencia que cualquier panel de control: describe cómo probar fallas de carga de archivos y XSS almacenado de manera metódica. Y si descubres que el plugin está abandonado, es hora de aplicar el protocolo de limpieza: el peligro oculto de los plugins de WordPress abandonados explica por qué dejar una extensión muerta en su lugar es peor que eliminarla y ajustar tu flujo de trabajo.

---

Lo que el escáner no puede ver: usuarios, registros y código antiguo

Las pruebas dinámicas detectan lo que está expuesto en este momento. La revisión manual detecta lo que ya está dentro. Comienza con las cuentas de usuario: abre la lista de administradores y busca cuentas que no hayas creado. Un administrador llamado "support" con una dirección de correo gratuita y sin un humano detrás es una puerta trasera, no un colega. Verifica las marcas de tiempo de los archivos en wp-content/uploads para detectar cualquier cosa modificada recientemente que no sea tu contenido. Revisa el registro de acceso del servidor en busca de solicitudes que parezcan un comando curl de un bot en lugar del navegador de una persona.

El plugin de eventos tiene una carga de "foto del orador" que guarda en uploads/event-headshots/. Durante la prueba encuentras un archivo que no es tuyo: un pequeño archivo PHP con un nombre de apariencia aleatoria. Esa es tu webshell. Llegó allí a través de la misma falla de carga que probaste hace dos semanas, y para entonces un escáner aún no lo "vería" porque no es una vulnerabilidad de plugin; es evidencia de una. La revisión manual lo encuentra, lo elimina y revisa el registro para ver la dirección IP que lo puso allí. Invicti ha señalado que la inyección de objetos PHP en plugins está en aumento, y es casi invisible para los escaneos de caja negra porque el objeto malicioso solo se materializa durante la ejecución. La única forma de detectarlo es leer el código en busca de patrones peligrosos como llamar a unserialize() con entrada proporcionada por el usuario. Leer unos cientos de líneas del plugin personalizado es más barato que pagar un retenedor de respuesta a incidentes.

Aquí es también donde el consejo estándar de "solo instala más plugins de seguridad" llega a su límite. Apilar tres plugins de seguridad te da reglas WAF superpuestas que se bloquean entre sí, un torrente de correos de registro duplicados y el ocasional error de "estás baneado" en tu propio inicio de sesión de administrador. Un plugin de seguridad activo, bien configurado, es suficiente. Lee sobre por qué demasiados plugins de seguridad resultan contraproducentes antes de agregar algo más a la pila.

---

Decirle la verdad a tu jefe sin generar pánico

A tu jefe no le importan las puntuaciones CVSS ni la inyección de objetos PHP. Le importa que el sitio se caiga, que la tienda no tome pedidos y el presupuesto de TI. La traducción es simple: "Este plugin tiene una falla conocida de ejecución remota de código no autenticada. Un extraño puede eliminar el contenido de nuestro sitio o instalar una puerta trasera. Necesitamos reemplazarlo este trimestre". Luego muestra la lista de prioridades: reemplazar el plugin de eventos, deshabilitar la carga de archivos del formulario de contacto hasta que valide adecuadamente los tipos de archivo, rotar todas las credenciales de administrador y programar la próxima revisión trimestral.

También tienes una ventaja de lenguaje: CISA mantiene el catálogo de Vulnerabilidades Explotadas Conocidas, que te dice exactamente qué fallas publicadas se están utilizando activamente en el mundo real. Si alguno de tus plugins aparece allí, el argumento ya no es teórico: existe un exploit conocido y estás contra el reloj. Si no aparecen, úsalo de todos modos como estándar de lo que significa "urgente". El seguimiento de CISA facilita convencer a un jefe no técnico de que esto no es un correo de phishing; es una base de datos pública de lo que los atacantes están haciendo en este momento. Cuando termine el trimestre, tendrás un flujo de trabajo de remediación, no un ejercicio único de casillas. Un flujo de trabajo para convertir vulnerabilidades en un ciclo de parches mantiene el hábito vivo.

---

El antes era un sitio roto, un correo frenético y un informe de escáner limpio que decía que no había nada malo. El después es un ritual trimestral: inventariar, clasificar, probar desde el exterior, revisar usuarios y registros, y anotar las decisiones que tomaste y los riesgos que aceptaste. El escáner se convierte en un mapa de dónde mirar, no en un certificado de salud. Los plugins se convierten en una lista que conoces por su nombre. Y la próxima vez que tu jefe pregunte por la auditoría, tendrás una respuesta que no implique cruzar los dedos.