Vulnerabilidades de Bypass de Roles en WordPress

Qué significa bypass de roles

WordPress tiene un sistema de capabilities: Subscriber, Author, Editor, Administrator. Cada rol tiene un conjunto de acciones permitidas. El sistema funciona — cuando se usa correctamente.

Una vulnerabilidad de bypass de roles es un bug donde una acción que debería requerir capability admin corre sin verificación. Un usuario sin privilegios especiales (o incluso un visitante no autenticado) puede disparar acciones a nivel admin: instalar plugins, crear usuarios, modificar contenido.

Estos bugs son extremadamente comunes en plugins WordPress. Solo en 2025, Wordfence/Patchstack divulgaron 200+ CVEs de bypass de roles.

Este artículo es cómo auditamos sitios WordPress por estas vulnerabilidades y las parcheamos.

Cómo se ve un bypass de roles en código

El patrón vulnerable:

add_action('wp_ajax_my_plugin_action', 'my_plugin_handler');
add_action('wp_ajax_nopriv_my_plugin_action', 'my_plugin_handler');

function my_plugin_handler() {
    $option_name = $_POST['option'];
    $option_value = $_POST['value'];
    update_option($option_name, $option_value);
    wp_send_json_success();
}

Bugs: 1. wp_ajax_nopriv_ hace la acción llamable sin auth en absoluto 2. Sin check current_user_can() — cualquier usuario alcanzando el endpoint puede actualizar cualquier opción WP 3. Sin verificación de nonce — ataque CSRF posible 4. $_POST directo sin sanitización — XSS o peor

Un usuario nivel subscriber (o incluso un guest) envía:

POST /wp-admin/admin-ajax.php?action=my_plugin_action
option=siteurl&value=http://attacker.com

La URL del sitio WordPress es ahora el sitio del atacante. Game over.

El patrón correcto

El mismo handler, seguro:

add_action('wp_ajax_my_plugin_action', 'my_plugin_handler');
// NO wp_ajax_nopriv a menos que sea deliberadamente para guests

function my_plugin_handler() {
    // Check de auth
    if (!current_user_can('manage_options')) {
        wp_send_json_error('Insufficient permissions', 403);
    }
    
    // Check de nonce
    check_ajax_referer('my_plugin_action', 'nonce');
    
    // Valida input
    $option_name = sanitize_text_field($_POST['option']);
    
    // Solo permite opciones seguras
    $allowed_options = array('my_plugin_setting_1', 'my_plugin_setting_2');
    if (!in_array($option_name, $allowed_options)) {
        wp_send_json_error('Invalid option', 400);
    }
    
    $option_value = sanitize_text_field($_POST['value']);
    update_option($option_name, $option_value);
    wp_send_json_success();
}

Tres capas: check de capability, check de nonce, whitelist de input.

Auditando tu sitio

Para cada plugin, la auditoría pregunta:

¿Expone endpoints AJAX? (add_action('wp_ajax_*'))
¿Expone endpoints REST? (register_rest_route())
¿Para cada uno, hay check de capability?
¿Para cada uno, hay check de nonce?
¿El input de usuario está sanitizado?

Búsqueda automatizada:

cd /var/www/yoursite

# Encuentra todos los endpoints AJAX
grep -rE "add_action\s*\(\s*['"]wp_ajax_[^'"]+['"]" wp-content/plugins/ > /tmp/ajax-endpoints.txt

# Encuentra los sin current_user_can en el mismo handler
grep -rE "wp_ajax_nopriv_" wp-content/plugins/ > /tmp/nopriv-endpoints.txt

# Encuentra endpoints REST
grep -rE "register_rest_route" wp-content/plugins/ > /tmp/rest-endpoints.txt

Para cada endpoint, abre la función handler. Revisa si:

if (!current_user_can('manage_options')) { wp_die(...); }

…aparece antes de cualquier operación sensible.

Patrones vulnerables comunes en 2026

Patrón 1 — Check de capability faltante en endpoint REST

register_rest_route('myplugin/v1', '/save-option', array(
    'methods' => 'POST',
    'callback' => 'my_save_option',
    // falta 'permission_callback'
));

Sin permission_callback, el endpoint es llamable por cualquiera.

Arreglo:

register_rest_route('myplugin/v1', '/save-option', array(
    'methods' => 'POST',
    'callback' => 'my_save_option',
    'permission_callback' => function() {
        return current_user_can('manage_options');
    },
));

Patrón 2 — Check de permiso en display del formulario, no en acción

La UI del plugin solo se muestra a admins (bueno), pero el handler POST del formulario no re-revisa (malo). Un subscriber puede enviar el POST directamente.

Arreglo: cada handler de acción debe re-revisar capabilities, sin importar de dónde vino el formulario.

Patrón 3 — Check de capability existe pero es `is_user_logged_in()`

Un subscriber está logueado, así pasa. Debería ser current_user_can('manage_options').

Arreglo: usa la capability más restrictiva que la acción necesita.

Patrón 4 — Check de nonce pero sin check de capability

El nonce solo previene CSRF (atacante forzando a tu navegador a enviar petición). No previene a un usuario autenticado malicioso de hacer la acción ellos mismos.

Arreglo: ambos checks. Nonce para CSRF, capability para autorización.

Parcheando plugins de terceros

Para tu propio código: arregla directamente.

Para plugins de terceros: esto es más difícil. Opciones:

Opción A — Espera parche del vendor

Suscríbete a Patchstack o Wordfence Intelligence para divulgación temprana. Los vendors típicamente parchean en 7-30 días de divulgación. Las reglas WAF pueden bloquear explotación en el hueco.

Opción B — Bloqueo por regla WAF

Cloudflare WAF, Wordfence, mitigaciones de Patchstack todos soportan bloqueo basado en reglas de patrones de exploit específicos. Para CVEs conocidos, las reglas provistas por vendor típicamente despliegan en horas.

Opción C — Parche manual

Si la vulnerabilidad es crítica y el parche es lento, puedes editar el código del plugin directamente. Documenta el cambio. Re-aplica en actualización de plugin (de lo contrario la actualización revierte el parche).

Opción D — Reemplaza el plugin

Para plugins con historial consistente de vulnerabilidades, reemplaza con una alternativa mantenida.

Monitoreando por vulnerabilidades nuevas

Configura:

Patchstack (o Wordfence Intelligence) — emails diarios cuando se publican CVEs para plugins que usas
Cron WP-CLI para detectar usuarios admin nuevos (potencial signo de explotación de bypass):

0 * * * * cd /var/www/yoursite && wp user list --role=administrator --field=user_login > /tmp/admins.txt && diff /tmp/admins.prev.txt /tmp/admins.txt | mail -s "Admin changes" admin@yoursite.com; cp /tmp/admins.txt /tmp/admins.prev.txt

Monitoreo de integridad de archivos — alerta en archivos PHP nuevos en wp-content/mu-plugins/

Escaneo rápido con WPScan

wpscan --url https://yoursite.com --enumerate vp,vt,u --api-token YOURTOKEN

Esto enumera plugins, temas, usuarios y referencia contra la base de datos de vulnerabilidades WPScan. El tier gratis soporta 25 escaneos/día.

Errores comunes durante auditoría de roles

Confiar en "tengo Wordfence" — Wordfence escanea por CVEs conocidos, no bugs desconocidos en tu código custom
Solo revisar código propio — los plugins de terceros son la superficie más grande
No re-auditar tras actualización de plugin — versiones nuevas pueden introducir bugs nuevos
Tratar Subscriber como bajo-riesgo — los Subscribers pueden registrarse en la mayoría de sitios; nunca confíes en su input

Cuándo llamar a un especialista

Una auditoría de seguridad WordPress a nivel código es altamente especializada. Auditamos plugins y código custom encontrando 5-15 problemas por sitio típico, con remediación detallada.

Auditoría de seguridad en días. Para compromiso activo ve reparación de sitio hackeado.