Nombre del complemento	WP JobHunt
Tipo de vulnerabilidad	Referencia directa a objeto insegura (IDOR)
Número CVE	CVE-2025-7733
Urgencia	Bajo
Fecha de publicación de CVE	2025-12-25
URL de origen	CVE-2025-7733

Referencia Directa de Objeto Insegura (IDOR) en WP JobHunt (≤ 7.7) — Lo que los propietarios de sitios de WordPress deben hacer ahora

Autor: Equipo de seguridad de firewall WP
Fecha: 2025-12-23
Categorías: Seguridad de WordPress, Respuesta a Vulnerabilidades, Guía de WAF

---

Resumen

Una vulnerabilidad de Referencia Directa de Objeto Insegura (IDOR) recientemente divulgada que afecta a las versiones de WP JobHunt ≤ 7.7 (CVE‑2025‑7733) permite a un usuario autenticado con una cuenta de nivel candidato acceder o manipular recursos de candidatos que no posee. El problema se clasifica como Control de Acceso Roto con un CVSS de Patchstack de 4.3. Esta publicación explica la vulnerabilidad en lenguaje sencillo, los posibles escenarios de ataque, indicadores de detección, mitigaciones inmediatas, endurecimiento a nivel de código que puedes aplicar hoy, y cómo un Firewall de Aplicaciones Web (WAF) gestionado y el parcheo virtual pueden proteger sitios mientras esperas un parche del proveedor o una remediación permanente.

---

Por qué esto es importante

Los tablones de empleo y los plugins de reclutamiento como WP JobHunt almacenan información de identificación personal (PII): nombres, direcciones de correo electrónico, CVs/hojas de vida, historial laboral y potencialmente documentos subidos por los solicitantes. Un IDOR que permite a una cuenta de nivel candidato acceder o enumerar los registros de otro candidato arriesga violaciones de privacidad y exposiciones de cumplimiento (GDPR, CCPA, etc.), además de daños a la reputación.

Aunque la gravedad reportada aquí es “baja” (CVSS 4.3), esa calificación refleja la puntuación de impacto técnico y no el impacto comercial. En la práctica, el acceso a perfiles de candidatos o adjuntos puede ser consequential para las organizaciones que manejan datos de contratación.

---

¿Qué es un IDOR (Referencia directa de objeto insegura)?

La Referencia Directa de Objeto Insegura (IDOR) es un problema de control de acceso donde la aplicación utiliza identificadores (IDs numéricos, slugs, nombres de archivos, claves de objeto) en las solicitudes y no verifica si el usuario que solicita realmente tiene permiso para acceder al objeto referenciado.

Síntomas típicos:

• URLs o puntos finales de API como /candidate.php?id=123, /wp-json/wp-jobhunt/v1/candidate/123, o acciones de admin-ajax usando IDs de candidatos.
• La aplicación devuelve datos de recursos cuando un usuario autenticado altera el parámetro ID (por ejemplo, cambiando 123 a 124) y obtiene datos para un usuario diferente.
• No hay verificación del lado del servidor de que el propietario del recurso sea el usuario actual o que el solicitante tenga una capacidad administrativa.

IDOR aparece frecuentemente en puntos finales REST, acciones AJAX, descargas de archivos y enlaces directos a adjuntos.

---

Qué es el problema de WP JobHunt (a alto nivel)

• Una autenticación de nivel candidato es suficiente para llamar a un recurso que devuelve detalles de candidatos o adjuntos para IDs de candidatos arbitrarios.
• Las versiones vulnerables del plugin no imponen verificaciones de propietario para recursos de nivel candidato. Dicho de otra manera: el código confía en los IDs de objeto entrantes sin verificar la propiedad o capacidades.
• La vulnerabilidad permite a un usuario candidato autenticado ver (y en algunas implementaciones potencialmente editar) los perfiles de otros candidatos o descargar archivos que pertenecen a otros usuarios.

La vulnerabilidad se rastrea como CVE‑2025‑7733 y fue divulgada el 2025-12-23. Los investigadores informaron que las cuentas de candidatos pueden explotar referencias directas de objetos para acceder a registros que no les pertenecen.

---

Escenarios típicos de explotación

1. Enumeración y Fuga de Privacidad
   – El atacante se registra como candidato y itera IDs de candidatos (1,2,3…) o manipula GUIDs en solicitudes de API.
   – El atacante recopila listas de nombres, correos electrónicos, números de teléfono y posiblemente archivos de currículum.
   – Los datos recopilados pueden ser utilizados para spam, ingeniería social o vendidos.
2. Acoso dirigido / DoS a solicitantes
   – Un atacante localiza el registro del candidato de un usuario en particular y descarga o elimina archivos (si existe acceso de escritura).
   – Incluso el acceso de solo lectura a un CV puede ser sensible.
3. Cambio a abuso administrativo (encadenado con otros errores)
   – IDOR combinado con otros errores lógicos o configuración de roles débiles podría permitir a un atacante escalar privilegios o descubrir enlaces internos útiles para otros ataques.
4. Cumplimiento e impacto legal
   – Las obligaciones de violación de datos pueden ser activadas dependiendo de los datos expuestos. Pueden seguir multas regulatorias y notificaciones requeridas.

---

Cómo detectar si su sitio está afectado

Comience con estas verificaciones inmediatas:

• Inventario de la versión del plugin
  – Si WP JobHunt está instalado, verifique la versión del plugin. Se informa que las versiones ≤ 7.7 son vulnerables. Si su versión es posterior y existen correcciones publicadas por el proveedor, priorice el parcheo.
• Busque en los registros patrones sospechosos
  – Busque solicitudes a puntos finales que devuelvan datos de candidatos. Ejemplos (patrones a buscar en los registros de acceso):
    – /wp-json/wp-jobhunt/v1/candidate/
    – admin-ajax.php? (busque nombres de parámetros como candidate_id, id, uid, user_id en llamadas AJAX)
    – Cualquier solicitud que contenga la cadena “candidate” seguida de un ID numérico
• Busque manipulación de parámetros
  – Solicitudes repetidas de una sola IP o agente de usuario donde solo cambia un ID (por ejemplo, id=123 → id=124 → id=125). Eso es una fuerte señal de enumeración.
• Verifique el directorio de cargas y los registros de acceso
  – Si los archivos adjuntos de los candidatos (currículos, CVs) se almacenan en rutas predecibles (uploads/jobhunt/candidates/123.pdf), intenta encontrar accesos a archivos que un candidato no debería poseer.
• Verifica los mapeos de roles de usuario de WordPress y las cuentas de los candidatos
  – Identifica cómo las cuentas de los candidatos se mapean a los usuarios de WordPress (¿rol de usuario personalizado o tabla de base de datos separada?) y si los registros de los candidatos están vinculados a través de user_id, author_id o un campo meta.
• Audita la base de datos
  – Inspecciona la tabla de candidatos o el tipo de publicación para los campos de propietario. Correlaciona las solicitudes de registro de acceso para IDs de candidatos específicos con el usuario autenticado que realiza esas solicitudes.

Si descubres un acceso que parece no autorizado, trátalo como un incidente confirmado y sigue los pasos de respuesta a incidentes a continuación.

---

Mitigaciones inmediatas que puedes aplicar ahora (antes de que esté disponible un parche)

1. Desactiva los puntos finales públicos de candidatos (si no son necesarios)
   – Si tu bolsa de trabajo no requiere la recuperación pública de candidatos (por ejemplo, vistas públicas de CV), desactiva temporalmente o restringe estos puntos finales.
2. Restringe las descargas y los archivos adjuntos de los candidatos
   – Utiliza reglas a nivel de servidor para prevenir el acceso directo a los archivos de los candidatos a menos que la solicitud esté autorizada (ver ejemplos de WAF / Nginx/Apache más adelante).
3. Refuerza las capacidades del rol de candidato
   – Asegúrate de que las cuentas a nivel de candidato tengan las capacidades mínimas. Elimina capacidades innecesarias como editar_publicaciones o privilegios de carga si no son requeridos.
4. Fuerza la autenticación y los nonces en los puntos finales de AJAX
   – Asegúrate de que todos los puntos finales de AJAX y REST que devuelven datos de candidatos requieran inicio de sesión y nonces válidos de WordPress.
5. Monitorea y bloquea la enumeración
   – Implementa limitación de tasa y bloqueo para solicitudes repetidas que cambian los IDs de objeto. Si detectas una cuenta iterando IDs de candidatos, bloquéala o márcala.
6. Activa el registro detallado y la copia de seguridad
   – Habilita el complemento de registro o aloja registros para la ventana de tiempo; crea copias de seguridad inmediatas de tu sitio y base de datos.
7. Aplique parches virtuales a través de un WAF
   – Una regla de WAF que aplica verificaciones de propiedad o bloquea a los usuarios a nivel de candidato de consultar IDs de candidatos que no coinciden con su cuenta proporciona una mitigación rápida mientras se espera un parche del proveedor.
8. Cambios temporales de rol
   – Si es necesario, elimine temporalmente la capacidad de registrar nuevas cuentas de candidatos hasta que se publique una solución.

---

Ejemplo de endurecimiento del lado del servidor (PHP): patrón de verificación de propiedad

A continuación se muestra un ejemplo genérico que ilustra cómo verificar la propiedad en el código del lado del servidor antes de devolver detalles sensibles del candidato. Este es un patrón: adáptelo cuidadosamente a su código de complemento y modelo de datos.

// Example: secure_candidate_fetch.php (pseudo-code)
add_action('wp_ajax_get_candidate', 'wpfh_secure_get_candidate');
add_action('wp_ajax_nopriv_get_candidate', 'wpfh_secure_get_candidate'); // usually no for candidate-only

function wpfh_secure_get_candidate() {
    // Verify logged in
    if (!is_user_logged_in()) {
        wp_send_json_error('Authentication required', 401);
    }

    // Verify nonce (ensure client uses wp_create_nonce in forms)
    if (!isset($_REQUEST['nonce']) || !wp_verify_nonce($_REQUEST['nonce'], 'wpfh_candidate_nonce')) {
        wp_send_json_error('Invalid request', 400);
    }

    $current_user_id = get_current_user_id();
    $requested_candidate_id = isset($_REQUEST['candidate_id']) ? intval($_REQUEST['candidate_id']) : 0;
    if (!$requested_candidate_id) {
        wp_send_json_error('Missing or invalid candidate ID', 400);
    }

    // Fetch candidate owner (example: candidate is a custom post type, or stored in a custom table)
    // If candidate is a post:
    $candidate_post = get_post($requested_candidate_id);
    if (!$candidate_post || $candidate_post->post_type !== 'candidate') {
        wp_send_json_error('Candidate not found', 404);
    }

    // Ownership check: allow if current user is admin or if current user owns this candidate record
    if (!current_user_can('manage_options') && intval($candidate_post->post_author) !== intval($current_user_id)) {
        wp_send_json_error('Forbidden', 403);
    }

    // Safe: return only fields that are needed
    $response = array(
        'id'    => $candidate_post->ID,
        'name'  => get_post_meta($candidate_post->ID, 'candidate_name', true),
        // Avoid leaking private fields unless necessary
    );

    wp_send_json_success($response);
}

Notas:

• Identifique si los registros de candidatos son publicaciones, tablas personalizadas o metadatos de usuario y adapte la verificación de propiedad.
• Evite devolver URLs de archivos que se puedan acceder directamente sin una verificación de autorización.
• Nunca confíe en verificaciones del lado del cliente; siempre aplique la propiedad del lado del servidor.

---

Ejemplo de regla de API REST / WP‑JSON

Si los datos del candidato se exponen a través de la API REST de WP, asegúrese de que la devolución de llamada de permisos del endpoint incluya una verificación de propiedad. Ejemplo:

register_rest_route('wp-jobhunt/v1', '/candidate/(?P<id>\d+)', array(
    'methods'             => 'GET',
    'callback'            => 'wpfh_rest_get_candidate',
    'permission_callback' => function($request) {
        $user_id = get_current_user_id();
        if (!$user_id) {
            return new WP_Error('rest_forbidden', 'You must be authenticated', array('status' => 401));
        }

        $candidate = get_post($request['id']);
        if (!$candidate) {
            return new WP_Error('rest_not_found', 'Candidate not found', array('status' => 404));
        }

        // Allow admins
        if (current_user_can('manage_options')) {
            return true;
        }

        // Only the owner can view
        return intval($candidate->post_author) === intval($user_id);
    }
));

---

Orientación sobre WAF / parches virtuales (cómo ayuda WP‑Firewall)

Un WAF gestionado puede implementar parches virtuales que mitigan la explotación sin alterar el código del complemento. Enfoques típicos de parches virtuales para este IDOR:

• Bloquear patrones anómalos de enumeración de ID de candidatos:
  – Si un usuario candidato autenticado emite múltiples solicitudes GET con IDs de candidatos secuenciales en un corto período de tiempo, bloquee o limite la tasa de la cuenta/IP de origen.
• Aplique verificaciones de propiedad en el borde:
  – Para llamadas REST/AJAX que incluyan parámetros candidate_id, haga coincidir el candidate_id con el ID del usuario actualmente conectado (o con una lista permitida de IDs alternativos para roles de administrador/prueba). Las solicitudes que no superen la prueba de propiedad deben ser bloqueadas en la capa de WAF.
• Proteja las descargas de archivos:
  – Niegue el acceso directo a URL de archivos adjuntos de candidatos desde solicitudes no autenticadas y reescriba los endpoints de descarga a un controlador seguro, verificado con nonce.
• Bloquee métodos no autorizados:
  – Si el complemento expone endpoints de escritura o eliminación para candidatos, bloquee las cuentas de rol de candidato de invocar esos endpoints a menos que pasen la validación completa de propiedad.
• Coincidencia basada en firma:
  – El WAF puede detectar patrones típicos de endpoint (por ejemplo, /wp-json/wp-jobhunt/v1/candidate/ o parámetros admin-ajax.php como candidate_id) y aplicar un escrutinio adicional.

Regla concreta de WAF (pseudo):
– SI la ruta de la solicitud coincide con /wp-json/wp-jobhunt/v1/candidate/\d+ Y la autorización HTTP indica un rol de candidato conectado Y el ID de usuario de la solicitud != ID de propietario de candidato capturado ENTONCES bloquear.

Importante: Debido a que el WAF en el borde no siempre puede leer los datos de sesión de WordPress de forma nativa, WP‑Firewall proporciona un modo de integración que inyecta un encabezado firmado que refleja el ID y el rol del usuario autenticado (solo en solicitudes internas). Esto permite que el WAF aplique verificaciones de propiedad de manera confiable.

---

Firmas regex sugeridas para WAF (ejemplos para administradores)

Nota: Pruebe cuidadosamente en staging antes de aplicar en producción.

• Detectar acceso a la API de candidatos:
  Expresión regular: ^/wp-json/wp-jobhunt/v1/candidate/(\d+)
• Detectar parámetros AJAX candidate_id:
  Expresión regular: (candidate_id|candidateID|id)=\d+
• Bloquear patrón de enumeración (limitación de tasa):
  Activar: > 10 solicitudes en 60s a endpoints de candidatos con IDs secuenciales o variados desde la misma IP o sesión.

Ejemplo de fragmento de limitación de tasa de Nginx para bloquear enumeraciones simples:

Fragmento de nginx.conf # (conceptual)

Nuevamente: use un WAF capaz de analizar cookies o encabezados firmados para tomar decisiones de propiedad. Bloquear solo por IP puede producir falsos positivos para IPs compartidas o rastreadores legítimos.

---

Lista de verificación de respuesta ante incidentes (si sospecha de explotación)

1. Aislar y registrar
   – Capturar un conjunto completo de registros de acceso, registros de errores y registros específicos de plugins. Preservar registros en almacenamiento inmutable.
2. Deshabilitar funcionalidad vulnerable
   – Deshabilitar temporalmente los endpoints de candidatos y las descargas de archivos si es posible.
3. secretos rotativos
   – Si el sitio almacena claves API o tokens vinculados a cuentas de usuario, cámbialos.
4. Notifique a las partes afectadas
   – Si se expuso información personal identificable (PII), consulta con el departamento legal/cumplimiento para determinar si se requiere notificación de violación.
5. Limpia las cuentas comprometidas
   – Revoca cuentas sospechosas, restablece contraseñas y requiere re-autenticación.
6. Restaura desde una copia de seguridad confiable si es necesario
   – Si detectas modificaciones, prefiere restaurar a una instantánea anterior a la compromisión.
7. Implementa parches virtuales y reglas de WAF
   – Aplica mitigaciones en el borde y en la aplicación.
8. Parchea y prueba
   – Actualiza el complemento cuando se publique una solución del proveedor. Después de aplicar actualizaciones, realiza pruebas funcionales de extremo a extremo.
9. Revisión posterior al incidente
   – Documenta la causa raíz, qué salió mal y soluciones permanentes.

---

Cómo probar si tus soluciones funcionan

• Pruebas unitarias e integradas
  – Agrega pruebas automatizadas que llamen a los puntos finales candidatos como diferentes usuarios (propietario, otro candidato, administrador) para asegurar respuestas de permisos correctas.
• Pruebas de penetración
  – Realiza una prueba de penetración enfocada en los puntos finales candidatos con intentos de enumerar o acceder a otros ID.
• Revisión de código
  – Asegúrate de que las verificaciones de permisos estén centralizadas y no dependan únicamente de los valores proporcionados por el cliente.
• Verificación de staging
  – Prueba las reglas de WAF en modo de monitoreo primero (solo detección) para medir falsos positivos, luego cambia a modo de bloqueo.

---

Mejores prácticas para desarrolladores para evitar IDORs

• Utiliza identificadores de objeto canónicos que no sean predecibles (UUIDs) solo como una defensa menor — no como un reemplazo para las verificaciones de control de acceso.
• Centralizar la lógica de control de acceso
  – Colocar las validaciones de permisos en una única función auxiliar y llamarla para cada acceso a recursos, ya sea REST, AJAX o interno.
• Devolver datos mínimos
  – Evitar exponer IDs internos o rutas de archivos en las respuestas JSON.
• Usar verificaciones basadas en capacidades
  – Usar verificaciones de capacidades de WordPress (current_user_can) y comparar IDs de usuario donde sea apropiado.
• Evitar “seguridad a través de la oscuridad”
  – No depender de nonces o nombres de parámetros oscurecidos como la única protección.

---

Lista de verificación de código práctico para mantenedores de plugins

• Hacer cumplir el usuario ha iniciado sesión() en puntos finales candidatos.
• Verificar nonce con wp_verify_nonce() para llamadas AJAX.
• Implementar verificación de propiedad (current_user_id === owner_id) para vistas/ediciones candidatas.
• Usar devolución de llamada de permisos para rutas REST con verificaciones estrictas.
• Sanitizar y validar IDs de objetos (intval, absint).
• Evitar exponer enlaces directos a cargas sensibles; usar una descarga proxy que verifique la autorización.
• Registrar intentos de acceso que fallen en las verificaciones de propiedad y generar alertas administrativas después del umbral.

---

Registro y Monitoreo: qué buscar

• Patrón de IDs secuenciales accedidos por un solo usuario autenticado.
• Acceso a puntos finales de candidatos por usuarios que no deberían tener la capacidad.
• Múltiples respuestas 403 para la misma cuenta (indica sondeo).
• Solicitudes de descarga de archivos PDF/CSV de currículum con referidores o agentes que parecen sospechosos.
• Aumento inusual en el acceso a puntos finales de candidatos después de actualizaciones de plugins o nuevos lanzamientos.

---

Por qué deberías considerar un Firewall de Aplicaciones Web gestionado ahora

Un WAF es especialmente valioso en estas situaciones porque:

• Puede proporcionar parches virtuales rápidos sin editar el código del plugin (importante si no puedes actualizar de inmediato).
• Puede aplicar limitación de tasa y reglas de comportamiento para detener intentos de enumeración y recolección masiva de datos.
• Te brinda registro y alertas consolidadas enfocadas en amenazas a nivel de aplicación, que los registros estándar del servidor pueden no mostrar fácilmente.
• Cuando se integra estrechamente con tu autenticación de WordPress, puede hacer cumplir verificaciones de propiedad en el borde (mitigando IDORs proactivamente).

Si ya operas un WAF, asegúrate de que tenga reglas que aborden:

• Puntos finales REST y AJAX para el plugin de bolsa de trabajo.
• Protección de descarga de archivos y URLs firmadas/nonce.
• Detección y bloqueo de enumeración.

---

Recomendaciones de postura de seguridad a largo plazo

• Mantén el núcleo de WordPress, temas y plugins actualizados en una ventana de mantenimiento con pruebas previas al despliegue.
• Limita la cantidad de plugins: reduce la superficie de ataque eliminando plugins no utilizados o duplicados que proporcionen funcionalidad similar.
• Auditorías de seguridad periódicas y revisiones de código, especialmente para plugins que manejan PII o tienen características de carga de usuarios.
• Revisión de roles: audita periódicamente roles y capacidades personalizados.
• Copias de seguridad regulares con replicación fuera del sitio y procedimientos de restauración probados.
• Implementar la Autenticación Multifactor (MFA) para cuentas administrativas y considerar MFA o una verificación más fuerte para cuentas que pueden acceder a datos sensibles de solicitantes.
• Adoptar prácticas seguras de ciclo de vida de desarrollo al extender o personalizar la funcionalidad de la bolsa de trabajo.

---

Ejemplos de fragmentos de consultas forenses

Registros de acceso de Apache (detectar patrón de acceso secuencial de ID de candidato):

cat access.log | grep "wp-json/wp-jobhunt/v1/candidate" | awk '{print $1,$4,$7}' | sort | uniq -c | sort -nr | head

MySQL: encontrar el propietario del candidato para una publicación (tabla de publicaciones de WP):

SELECT ID, post_author, post_title;

---

Consideraciones de riesgo empresarial y cumplimiento

Incluso cuando una vulnerabilidad se califica como “baja” en términos técnicos, el impacto empresarial puede ser significativo:

• Los CV de los candidatos pueden contener información de contacto, historial laboral y datos de categoría especial.
• La exposición puede activar leyes de notificación de violaciones de datos.
• El daño reputacional puede disuadir a solicitantes y clientes de usar su bolsa de trabajo.

Planifique las comunicaciones con anticipación: prepare una plantilla para las partes interesadas internas y un plan de notificación de privacidad si se confirma la exposición de datos.

---

Resumen: pasos inmediatos para los propietarios del sitio

1. Determine si WP JobHunt (≤ 7.7) está instalado y activo en su sitio.
2. Si tiene el complemento y no puede actualizar de inmediato, implemente WAF/parcheo virtual para bloquear la enumeración a nivel de candidato y el acceso no autorizado a ID de candidato.
3. Asegure los puntos finales de AJAX/REST con verificaciones de propiedad y nonces.
4. Audite los registros en busca de patrones sospechosos de explotación de IDOR como se describió anteriormente.
5. Realice copias de seguridad de los datos y considere restringir el acceso a los archivos de candidatos hasta que se implementen las mitigaciones.
6. Aplica parches de proveedores tan pronto como estén disponibles y valida las correcciones en un entorno de pruebas antes del despliegue en producción.

---

Comienza a proteger tu sitio hoy — Prueba el plan gratuito de WP‑Firewall

Si deseas una forma rápida de bloquear ataques como intentos de IDOR y proteger los datos de los candidatos mientras aplicas parches, regístrate en el plan básico de WP‑Firewall (gratuito) y obtén protección esencial de inmediato: firewall gestionado, ancho de banda ilimitado, un WAF, escáner de malware y mitigaciones para los riesgos del OWASP Top 10. Usa este enlace para registrarte y habilitarlo en tu sitio: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Resumen del plan:

• Básico (gratuito): firewall gestionado + WAF + escáner de malware + mitigación del OWASP Top 10
• Estándar ($50/año): añade eliminación automática de malware y listas de permitidos/denegados de IP
• Pro ($299/año): añade informes mensuales, parches virtuales automáticos y complementos premium

Incluso el plan gratuito proporciona una primera capa de defensa práctica para reducir el riesgo mientras pruebas y aplicas correcciones a nivel de código.

---

Reflexiones finales del equipo de seguridad de WP‑Firewall

Los IDOR son conceptualmente simples y a menudo resultan de la falta de verificaciones del lado del servidor. Pueden ser sutiles de encontrar durante el control de calidad normal porque dependen de interacciones y puntos finales específicos de roles. Las reducciones más rápidas en el riesgo provienen de (a) implementar verificaciones de propiedad del lado del servidor consistentes; y (b) usar protecciones en el borde (WAF, limitación de tasa, parches virtuales) para detener a los atacantes de recolectar o enumerar datos mientras se aplican las correcciones.

Si necesitas ayuda para implementar reglas de WAF para bloquear la enumeración, endurecer tus puntos finales de candidatos, o realizar una prueba rápida y específica para validar la protección, considera contactar a profesionales de seguridad o usar un servicio gestionado que se integre estrechamente con la autenticación de WordPress.

Mantente seguro, valida cada ruta que devuelve datos de usuario y asume que cualquier punto final que reciba un parámetro ID es un candidato para un escrutinio adicional.

— Equipo de seguridad de firewall de WP