Roles y permisos WordPress: el vector ignorado

En pocas palabras: WordPress tiene 5 roles predefinidos y más de 60 capabilities individuales. Cuando una cuenta con rol de Editor queda comprometida, el atacante puede publicar, editar o borrar cualquier contenido del sitio sin necesidad de credenciales de Administrador.

Los roles y permisos en WordPress determinan qué puede hacer cada cuenta registrada en el sitio: desde publicar un post hasta instalar plugins o borrar usuarios. Son 5 roles predefinidos que agrupan capacidades concretas, y cuando uno de esos roles le queda grande a quien lo tiene, o cae en manos equivocadas, el daño puede ser considerable.

En WordPress, un rol de usuario es un conjunto predefinido de capabilities que determina qué operaciones puede realizar una cuenta en el backend del sitio. Las capabilities son permisos individuales como publish_posts, manage_plugins o delete_others_posts. Un rol agrupa varias capabilities; una capability sola no define nada hasta que alguien la tiene asignada. Esta distinción entre rol (el bundle) y capability (el permiso atómico) es clave para entender dónde viven los riesgos de seguridad, porque los ataques no siempre apuntan al Administrador: apuntan al eslabón más débil de la cadena de permisos.

¿Cuáles son los 5 roles predefinidos de WordPress y qué puede hacer cada uno?

Según la documentación oficial de WordPress, los roles predefinidos son cinco. Cada uno es un nivel de acceso distinto, y entender sus diferencias es el punto de partida de cualquier política de seguridad seria.

• Administrador — acceso total: gestión de usuarios, plugins, temas, configuración del sitio y todo el contenido. Es el único que tiene capabilities como manage_options, install_plugins y manage_users. En multisite, existe un Super Admin con poderes adicionales sobre la red.
• Editor — puede publicar, editar y borrar posts y páginas propios y de cualquier otro usuario. Tiene edit_others_posts y delete_others_posts. No gestiona plugins ni usuarios. Tiene más poder del que la mayoría asume.
• Autor — puede crear y publicar sus propios posts, subir archivos de media. No puede tocar el contenido de otros ni gestionar el sitio.
• Contribuidor — puede redactar y editar sus propios posts, pero no publicarlos. Tampoco puede subir archivos. Un Editor o Administrador tiene que aprobar su trabajo antes de que salga al aire. (Lo que sí puede hacer es leer todos los borradores del sitio, incluyendo los ajenos.)
• Suscriptor — acceso mínimo: solo puede leer contenido y gestionar su propio perfil.

*En instalaciones de sitio único. En WordPress multisite, unfiltered_html está desactivada para Editores por defecto.

¿Cómo funcionan las capabilities? La diferencia entre rol y permiso individual

Imaginá que llegás a tu WordPress y encontrás que un plugin de reservas creó un rol llamado booking_agent con la capability publish_posts. El plugin lo necesitaba para confirmar reservas de forma programática, pero resulta que cualquier usuario con ese rol también puede publicar artículos en tu blog. Nadie lo diseñó con malicia: simplemente nadie lo revisó (y el desarrollador del plugin tampoco lo documentó, claro). Relacionado: autenticación en dos pasos para cuentas.

Así funcionan las capabilities en WordPress: son permisos atómicos que se pueden asignar directamente a un usuario, independientemente de su rol, o agruparse dentro de un rol. Cuando instalás un plugin que necesita permisos propios, generalmente crea un rol custom o agrega capabilities a roles existentes. Lo que casi nadie verifica es qué capabilities exactas contiene ese rol custom, ni si tienen un scope más amplio del necesario.

Algunas capabilities especialmente sensibles que vale la pena conocer:

• unfiltered_html — permite insertar HTML arbitrario, incluyendo scripts. Si un Editor con esta capability guarda un post con JavaScript malicioso, ese script se ejecuta para todos los visitantes.
• upload_files — si el servidor no filtra las extensiones, un archivo subido como imagen puede ser un PHP ejecutable.
• edit_theme_options — acceso al customizer, widgets y menús. En algunos temas, desde acá se puede inyectar código que afecta todo el sitio.
• manage_users — quien tiene esta capability puede crear nuevas cuentas de Administrador sin que nadie lo note.

Como detalla la documentación de desarrolladores de WordPress, las capabilities se pueden asignar individualmente con $user->add_cap(), lo que significa que un usuario puede tener capabilities que van más allá de su rol nominal. Eso es exactamente lo que los atacantes buscan explotar.

Cuando los permisos excesivos se convierten en un vector de ataque real

Ponele que el community manager de una empresa maneja el blog con rol de Editor. Usa la misma contraseña en tres servicios. Uno de esos servicios tiene una filtración, y de repente alguien con esa contraseña entra a WordPress, va a Entradas y empieza a publicar spam en masa. No hace falta explotar ningún plugin con vulnerabilidad: solo hubo un rol mal asignado y una contraseña reutilizada.

Ese escenario es más frecuente de lo que parece. Pero hay casos más sofisticados:

• Plugin de formularios con rol excesivo — algunos plugins de formularios crean un rol form_agent para manejar notificaciones. Si ese rol incluye publish_posts por descuido del desarrollador, cualquier persona que acceda a esa cuenta puede publicar artículos directamente.
• Editor comprometido que inyecta SEO spam — el atacante no necesita tocar la configuración del sitio. Le basta con edit_others_posts para modificar los posts más rankeados e inyectar links de afiliado o redirigir a páginas de phishing. El daño al posicionamiento puede tardar meses en revertirse.
• Escalada de privilegios vía XSS — si hay una vulnerabilidad XSS en el panel de administración (algo que Wordfence y Patchstack reportan con regularidad en plugins populares), un atacante puede hacer que un Administrador ejecute sin querer un script que eleva el rol del atacante a Administrador. Esto se llama privilege escalation y es un vector activo en 2026.
• Plugin abandonado con rol custom persistente — desactivaste un plugin hace seis meses (nadie recuerda exactamente cuál ni para qué) pero su rol custom sigue en la base de datos. Si ese rol tiene capabilities peligrosas, cualquier usuario con ese rol asignado las conserva, aunque el plugin ya no exista.

¿Y qué pasa cuando un Contribuidor accede a los borradores internos del sitio? Exacto: los puede leer todos. Si tu equipo usa posts en borrador para guardar estrategias editoriales, datos de clientes o comunicaciones internas, cualquier colaborador externo con rol de Contribuidor los ve en el backend. Que no pueda publicarlos no significa que no pueda leerlos. Tema relacionado: cabeceras HTTP de seguridad.

¿Cómo auditar qué permisos tiene cada usuario de tu WordPress?

La auditoría de roles no es una tarea de una vez: tiene que ser parte de la rutina de seguridad del sitio. El punto de partida es lo más básico: ir a Usuarios > Todos los usuarios y verificar qué rol tiene cada cuenta. Parece trivial, pero la mayoría de los sitios tienen al menos un usuario con rol más alto del necesario.

Para un análisis más granular, WP-CLI es la herramienta adecuada. Si manejás un servidor propio, deberías tener acceso. Estos son los comandos más útiles:

• wp user list --fields=ID,user_login,roles — lista todos los usuarios con su rol asignado.
• wp user list-caps <user-ID> — muestra todas las capabilities de un usuario específico, incluyendo las asignadas directamente (no solo las que hereda del rol).
• wp role list — lista todos los roles existentes, incluyendo los creados por plugins.
• wp cap list <nombre-del-rol> — lista las capabilities de un rol específico.

Qué buscar en la auditoría:

• Usuarios inactivos con roles altos — una cuenta de Editor que no se usa hace meses sigue siendo un vector. Cambiar su rol a Suscriptor o desactivarla directamente es lo mínimo.
• Usuarios cuya fecha de creación no coincide con tus registros — si un Administrador fue creado en una fecha que no reconocés, ese es un indicador de compromiso activo.
• Roles custom que no reconocés — si wp role list muestra roles que no sabés de dónde vienen, investigá qué plugin los creó antes de borrarlos.
• Capabilities asignadas directamente a usuarios fuera de su rol — esto lo muestra wp user list-caps. Si un Suscriptor aparece con publish_posts asignada directamente, hay algo que investigar.

Errores comunes en la gestión de roles y permisos

Estos errores los comete gente con años de experiencia en WordPress. No son obviedades.

• Creer que solo el Administrador puede causar daño grave — falso. Un Editor comprometido puede publicar contenido de phishing en todos los posts del sitio, modificar artículos rankeados para inyectar links y arruinar el posicionamiento en semanas. El daño es diferente al de un Admin comprometido, pero puede ser igual de costoso.
• No revisar los roles custom que crean los plugins — cuando instalás un plugin y lo configurás, rara vez mirás qué roles creó. Muchos plugins crean roles con capabilities que sobran para lo que realmente necesitan. Ese exceso queda activo aunque nunca lo uses.
• Dejar usuarios inactivos sin revocar permisos — si alguien de una agencia externa que manejaba el blog tiene una cuenta activa con rol de Editor, y esa persona usa el mismo mail en otro servicio que fue comprometido, tu sitio tiene una puerta abierta. No hace falta que el atacante sepa que tiene acceso: lo descubre con credential stuffing.
• Asumir que el rol de Contribuidor es «seguro» para externos — un Contribuidor no puede publicar, pero tiene acceso de lectura a todos los borradores. Si guardás contenido sensible en borradores, está expuesto a cualquier externo con ese rol.

Plugins y herramientas para gestionar permisos de forma segura

WP-CLI es lo más potente para auditorías en batch, pero no todo el mundo tiene acceso SSH al servidor. Para los demás casos, hay opciones desde el panel. Para más detalles técnicos, mirá endurecimiento integral de WordPress.

• Members — permite crear roles custom y visualizar qué capabilities tiene cada uno. La interfaz muestra una lista de capabilities con checkboxes, y podés ver qué heredó un rol de los predefinidos y qué se agregó encima. Útil para agencias que manejan varios clientes.
• User Role Editor — foco en mostrar capabilities por rol y por usuario de forma granular. Sirve para detectar capabilities asignadas directamente a usuarios que bypasean el rol nominal.
• Wordfence Security — alerta sobre cambios en usuarios: nuevos Administradores creados, cambios de rol, logins desde IPs desconocidas. No gestiona roles, pero los monitorea.
• Code Snippets — para desactivar capabilities específicas sin tocar el functions.php del tema. Podés agregar un snippet que remueva unfiltered_html de los Editores o restrinja uploads a tipos de archivo permitidos.

Si tu sitio está en un hosting compartido como donweb.com, el acceso a WP-CLI puede estar disponible por SSH o directamente desde el panel de control. La diferencia entre una auditoría de dos minutos y una de treinta pasa por tener o no tener ese comando disponible.

¿Cómo detectar si un plugin agrega permisos peligrosos a tu sitio?

Antes de activar cualquier plugin, hay un par de pasos que la mayoría salta. Primero: revisá el changelog del plugin en WordPress.org. Si en alguna versión dice «added custom role» o «registered new capabilities», eso merece atención. Muchos desarrolladores no documentan exactamente qué capabilities crearon, lo que ya es una señal por sí sola.

Segundo: después de activar el plugin, usá User Role Editor o el comando wp role list para ver si aparecieron roles nuevos. Una táctica práctica es tomar nota del output de wp role list antes de la instalación y compararlo después. Lo que apareció tiene que justificarse con la funcionalidad real del plugin.

Qué verificar puntualmente:

• ¿El plugin creó un rol custom? Si sí, revisá sus capabilities con wp cap list <nombre-del-rol>. Un plugin de galería no necesita manage_users.
• ¿El plugin modifica capabilities de roles predefinidos? Esto es más difícil de detectar pero User Role Editor lo muestra de forma clara.
• ¿Qué pasa si desactivás el plugin? El rol custom generalmente queda en la base de datos. Marcalo para auditarlo después de cada actualización.
• ¿El plugin crea usuarios propios durante la instalación? Algunos plugins de integración crean una cuenta de servicio. Verificá qué rol tiene esa cuenta.

Subís el plugin, lo activás en staging, revisás los roles con WP-CLI, verificás que no hay capabilities que sobren, lo migrás a producción y recién ahí lo das por aprobado. No tarda diez minutos y te evita bastantes dolores de cabeza.

Preguntas Frecuentes

¿Cuáles son todos los roles predefinidos en WordPress?

WordPress define 5 roles predefinidos: Administrador (acceso total al sitio), Editor (gestiona contenido propio y ajeno, sin acceso a plugins ni usuarios), Autor (publica solo sus propios posts), Contribuidor (redacta pero no publica) y Suscriptor (solo lectura y perfil propio). Cada rol agrupa un conjunto específico de capabilities. Los plugins pueden crear roles adicionales, que persisten aunque el plugin se desactive. Complementá con autenticación moderna sin contraseña.

¿Cómo asigno o cambio el rol de un usuario en WordPress?

Desde el panel, entrá a Usuarios > Todos los usuarios, hacé clic en el usuario y cambiá el campo «Rol» en la pantalla de edición. Para cambios masivos, seleccioná varios usuarios en la lista y usá «Cambiar rol a» en el menú de acciones en lote. Por WP-CLI el comando es wp user update <user-ID> --role=editor. El cambio es inmediato.

¿Qué peligro concreto hay en dar permisos excesivos a un usuario?

Depende del rol. Un Editor comprometido puede modificar o borrar cualquier post del sitio, inyectar links de spam en artículos rankeados y arruinar el posicionamiento. Un usuario con manage_users puede crear nuevas cuentas de Administrador sin que nadie lo vea. Un usuario con unfiltered_html puede insertar JavaScript malicioso que afecte a todos los visitantes. El daño no requiere vulnerabilidades de software: basta con que la cuenta sea comprometida.

¿Qué es una capability en WordPress y cómo se controla?

Una capability es un permiso individual en WordPress, como publish_posts, manage_plugins o edit_others_posts. Se pueden asignar a un rol completo (afecta a todos los usuarios con ese rol) o directamente a un usuario específico. Se gestionan con WP-CLI (wp cap add / wp cap remove), con plugins como User Role Editor o Members, o por código con las funciones add_cap() y remove_cap() de WordPress.

¿Cómo sé si un plugin dejó roles o permisos activos después de desactivarlo?

Los roles y capabilities que crea un plugin se guardan en wp_options (clave wp_user_roles) y en wp_usermeta. Desactivar o borrar el plugin no elimina esos datos. Para verificarlo, usá wp role list y comparalo contra los 5 roles predefinidos: todo lo que no sea Administrador, Editor, Autor, Contribuidor o Suscriptor fue creado por un plugin o de forma manual. Si el plugin ya no existe, ese rol se puede borrar con wp role delete <nombre>.

Conclusión

La gestión de roles y permisos en WordPress es una de esas cosas que parece resuelta desde el momento en que asignás el rol inicial y nunca más la revisás. Eso es exactamente el problema. Las cuentas acumulan permisos con el tiempo: los plugins agregan capabilities, los usuarios cambian de función pero mantienen el rol viejo, los colaboradores externos dejan de trabajar pero no dejan de tener acceso, y ese drift silencioso es un vector de ataque que no requiere ninguna vulnerabilidad de software para materializarse.

El principio de mínimo privilegio no es una recomendación de seguridad avanzada. Es lo básico: cada usuario tiene solo lo que necesita para hacer su trabajo, nada más. Aplicarlo en WordPress requiere una auditoría inicial de cinco minutos con WP-CLI y una revisión periódica de usuarios activos.

Empezá con wp user list --fields=ID,user_login,roles para ver el panorama completo, y con wp role list para detectar roles custom que no reconocés. Ese diagnóstico inicial ya te va a mostrar más de lo que esperás.

Fuentes

• WordPress.org — Roles and Capabilities: documentación oficial de los 5 roles predefinidos y sus capabilities
• WordPress Developer Handbook — Roles and Capabilities para desarrolladores de plugins
• Wordfence Blog — análisis de vulnerabilidades y ataques activos en WordPress
• Patchstack Vulnerability Database — base de datos de vulnerabilidades en plugins y temas de WordPress