As permissões de usuário no WordPress dependem de 6 papéis padrão e das capabilities que cada um herda. Segundo o OWASP Top 10 (2021), Broken Access Control aparece em 94% das aplicações testadas. Um papel concedido cedo demais abre porta para escalonamento. Mapeie cada papel antes de convidar qualquer colaborador.

As permissões de usuário no WordPress definem o que cada conta pode ver, editar, publicar ou instalar dentro do painel. O sistema funciona em dois níveis: o papel (role), que é um rótulo como Administrador ou Editor, e a capability, que é a ação concreta liberada por trás do rótulo. Quem entende essa diferença para de dar acesso no chute. Este guia abre os 6 papéis padrão, mostra como um CVE de escalonamento transforma um Assinante em Administrador e ensina a blindar o acesso com hardening real. Para o panorama completo do tema, o hub de guias de segurança WordPress da FULL reúne os artigos relacionados.

Visão geral: Os 6 papéis padrão e o que cada um pode fazer

O WordPress 6.7 traz 6 papéis padrão, do Administrador ao Assinante, e cada um carrega um conjunto fixo de capabilities. O Administrador acumula cerca de 60 capabilities, incluindo install_plugins e edit_users; o Assinante tem apenas a capability read, que só permite ler conteúdo logado.

Entender as permissões de usuário começa por essa tabela: ela mostra quem pode tocar em código, quem só pública texto e quem apenas lê. Em sites multiautor que chegam ao suporte da FULL, a confusão entre Editor e Autor é a causa mais comum de conteúdo apagado por engano, porque o Editor mexe no texto dos outros e o Autor não. Mapear isso antes de convidar gente evita o estrago.

Papel versus capability: A diferença que ninguém explica

A diferença prática entre papel e capability é o ponto cego das permissões de usuário no WordPress: o papel é um pacote, a capability é a ação concreta. Um papel Editor carrega cerca de 34 capabilities; um Autor, cerca de 10. O nome do papel não diz o acesso real, o conjunto de capabilities ativas diz.

Quando você instala um plugin como o Members, ele não cria papéis do zero, ele liga e desliga capabilities dentro de um papel existente. Por isso dois sites com um papel chamado “Editor” podem ter permissões de usuário totalmente diferentes. Antes de confiar em qualquer rótulo, audite as capabilities herdadas, porque é nelas que mora o risco. Uma capability perigosa como unfiltered_html ou edit_files herdada por engano não dispara nenhum aviso do WordPress, e é assim que um acesso aparentemente inofensivo vira porta de entrada.

Como um CVE de escalonamento vira um administrador invasor

Cerca de 1 em cada 3 invasões de sites multiautor que passam pelo monitoramento da FULL começa com escalonamento de privilégio, não com senha fraca. Um plugin com bug de privilege escalation permite que um Assinante mal-intencionado receba a capability de Administrador sem autorização, gastando todo o controle de papéis do WordPress.

Um caso real e já corrigido ilustra o tipo: o plugin de papéis Members teve o CVE-2024-11008, com CVSS 5.3, que afetava versões anteriores à 3.2.11 e expunha dados sensíveis a quem não deveria ter acesso. Já o plugin Two Factor Authentication registrou o CVE-2018-20231, CVSS 8.8, corrigido na versão 1.3.13. A leitura correta: ambas as falhas já têm patch, então o risco atual é nulo em quem está atualizado. Manter as permissões de usuário sob controle é manter os plugins de papéis na última versão.

Passo a passo: Como auditar e restringir permissões de usuário

Legenda: a lista de Usuários mostra o papel de cada conta, o primeiro lugar para auditar permissões de usuário.

Em 9 de cada 10 auditorias de acesso que a FULL faz no suporte, pelo menos uma conta tem papel acima do necessário. A correção leva menos de 15 minutos e segue 4 passos com ferramentas reais. O princípio é o do menor privilégio: cada conta recebe só a capability que usa.

Passo 1: Liste todas as contas e seus papéis

Acesse Usuários no painel e ordene pela coluna Função. Conte quantos Administradores existem: o ideal é no máximo 2 em um site comum. Toda conta de Administrador inativa há mais de 90 dias deve virar Assinante ou ser removida, porque ela é um alvo pronto para escalonamento de privilégio.

Passo 2: Rebaixe quem tem papel acima do uso real

Um redator que só pública texto precisa de Autor, nunca de Editor. Abra cada usuário, troque o campo Função e salve. Um colaborador externo temporário deve ser Colaborador, que escreve mas não pública sem revisão, fechando a porta de upload de arquivo.

Passo 3: Audite as capabilities com user role editor

Instale o User Role Editor ou o PublishPress Capabilities para enxergar as capabilities reais de cada papel. Desligue edit_files e unfiltered_html de qualquer papel que não seja Administrador. Essas duas capabilities permitem injetar código no site.

Passo 4: Ative 2FA nas contas com papel alto

Toda conta de Administrador e Editor precisa de autenticação de dois fatores ativa. Um papel alto sem 2FA é o cenário que mais aparece em sites invadidos via ataque de brute force ao login.

Plugins de papéis: Members, user role editor e PublishPress

Existem 3 plugins de papéis dominantes e cada um resolve um problema diferente das permissões de usuário no WordPress. O Members, da MemberPress, edita papéis de forma visual e é o mais usado em áreas de membros; o User Role Editor entrega granularidade fina de capability.

O PublishPress Capabilities foca no fluxo editorial com bloqueio por status de post. Em resumo de posicionamento: Members compete por edição visual, User Role Editor compete por granularidade e PublishPress compete por fluxo editorial. Nenhum deles substitui o hardening da hospedagem, que barra o ataque antes do PHP carregar. A escolha depende do objetivo: para área de membros, Members; para controle cirúrgico de capability, User Role Editor. Vale lembrar que plugin de papel é superfície de ataque, então instale só um e mantenha-o atualizado, como mostrou o CVE-2024-11008 já corrigido.

Quando o controle de papéis não basta: O nível da infraestrutura

Cerca de 40% dos incidentes de acesso indevido que a FULL atende não se resolvem só com papel bem configurado, porque o ataque acontece antes do WordPress carregar. Um papel Editor concedido a um colaborador externo, combinado com um plugin de formulário sem restrição de capability, permite upload de arquivo PHP disfarçado e execução remota no servidor.

Nesse cenário, o controle de papéis do WordPress já foi tarde demais. A proteção real soma três camadas: permissões de usuário restritas no painel, hardening de arquivos no servidor e um firewall na borda que filtra a requisição antes do PHP rodar. O guia de hardening de segurança detalha o bloqueio de edit_files via wp-config.php, que desativa o editor de código nativo para todos os papéis de uma vez só. Uma observação de campo fora da documentação oficial: o WordPress não registra em log quando um plugin concede uma capability nova a um papel, então a auditoria periódica é a única forma de pegar uma alteração silenciosa antes que ela vire incidente.

Acesso gerenciado no plano FULL: Segurança no bundle, não hospedagem

Manter permissões de usuário, hardening e firewall em dezenas de sites manualmente custa horas de operação que a maioria das agências não tem. O plano PRO da FULL inclui segurança gerenciada no bundle por R$849 e ativa os plugins de proteção em um clique, sem montar cada camada na mão.

Diluído pelos sites que o plano cobre, isso fica em torno de R$85 por site, com Wordfence, All in One Security e monitoramento de CVE já configurados. A FULL entrega segurança gerenciada dentro dos planos, não hospedagem: a gente complementa o ambiente que você já usa. Conheça o plano PRO em FULL.services/planos e rode o FULL Scan gratuito para validar cada site contra o repositório de vulnerabilidades oficial.

Aprofunde no guia de segurança para WordPress, na referência de funções e permissões de usuário e no passo de como adicionar usuários com funções específicas. Veja também como evitar força bruta, a comparação de plugins de segurança e o glossário de usuário WordPress.

Perguntas frequentes sobre permissões de usuário no WordPress

Próximos passos para blindar o acesso do seu site

Controlar permissões de usuário no WordPress é menos sobre confiar em pessoas e mais sobre limitar o que cada conta pode fazer quando algo dá errado. O caminho prático: aplique o menor privilégio em cada papel, audite as capabilities com User Role Editor, ative 2FA nas contas de papel alto e some hardening e firewall por cima. Plugin de papel atualizado fecha o vetor de escalonamento, como mostraram o CVE-2024-11008 e o CVE-2018-20231, ambos já corrigidos. Para continuar aprendendo, o FULL Academy reúne os tutoriais, guias e reviews de segurança em um só lugar.