Como Desabilitar o Editor de Tema e Plugin com DISALLOW_FILE_EDIT

Escondidas em toda instalação padrão do WordPress estão duas páginas que quase ninguém usa de propósito, mas que silenciosamente transformam uma senha de admin roubada em um comprometimento completo do servidor. Aparência, Editor de Arquivo de Tema e Plugins, Editor de Arquivo de Plugin. Ambas permitem a um admin editar arquivos PHP brutos dentro da instalação diretamente pelo navegador. Ambas ainda estão ligadas por padrão em 2026. E ambas são totalmente opcionais.

Este guia explica por que desligar os editores é uma das alterações de fortalecimento de maior alavancagem que você pode fazer em um site WordPress, como é a única linha de configuração e o que esperar depois (incluindo alguns casos de borda que surpreendem as pessoas).

Por que o editor de código integrado é um problema?

Em um dia normal, ninguém usa o editor. Alterações de tema passam por um tema filho ou pelo pipeline de implantação de um desenvolvedor. Alterações de plugin acontecem em staging, não em produção. O editor fica lá, sem uso, acessível apenas a administradores.

"Acessível apenas a administradores" é a parte que quebra sob ataque. A maneira como a tomada de controle típica do WordPress se desenrola não tem nada a ver com vulnerabilidades em nível de código no próprio editor. É assim:

1. Uma senha de admin é vazada. Phishing, reutilização de senha de um serviço comprometido, um laptop de desenvolvedor com malware, um plugin comprometido que exfiltra cookies de sessão. Escolha qualquer um dos pontos de entrada usuais.
2. O invasor faz login em /wp-admin como um usuário admin real. Da perspectiva do WordPress, nada está errado, este é um login legítimo.
3. O invasor vai direto para Aparência, Editor de Arquivo de Tema, abre functions.php e cola um pequeno backdoor PHP no topo.
4. A partir desse momento, cada requisição à página inicial do site executa o código do invasor. Eles têm um shell remoto em seu servidor.

O editor transforma "senha de admin roubada" em "servidor web roubado". Sem ele, um invasor que rouba uma senha de admin ainda tem acesso de admin (o que já é ruim o suficiente), mas tem que tomar a rota mais lenta e mais barulhenta de enviar um zip de plugin ou tema malicioso para obter execução de código. Esse passo extra é mais uma chance para um plugin de segurança, um scanner de integridade de arquivos ou um WAF no nível do servidor notar e bloquear o upload.

O custo-benefício é absurdamente desequilibrado. O editor é usado algumas vezes por ano por uma minoria minúscula de admins. O risco aparece em cada site que sofre vazamento de credenciais. Desabilitar o editor é uma daquelas alterações em que o pior caso é "alguém precisa usar SFTP para uma edição de cinco minutos" e o melhor caso é "a tomada de controle nunca escala de vazamento de senha para backdoor".

A correção: uma única linha em wp-config.php

O WordPress tem uma constante integrada para exatamente esse caso. Abra wp-config.php no diretório raiz do WordPress e adicione a seguinte linha, em qualquer lugar acima do comentário que diz /* That's all, stop editing! Happy publishing. */:

define('DISALLOW_FILE_EDIT', true);

Salve o arquivo. É isso. O menu Editor de Arquivo de Tema sob Aparência e o Editor de Arquivo de Plugin sob Plugins desaparecem imediatamente para todos os usuários, incluindo administradores. As próprias páginas retornam um erro de permissão se acessadas diretamente via URL. Não há plugin para instalar, configuração para manter, superfície de compatibilidade para se preocupar. A constante faz parte do núcleo do WordPress desde a versão 3.0 (lançada em 2010) e não vai a lugar nenhum.

E se eu também quiser bloquear uploads de plugin e tema do admin?

O WordPress tem uma constante irmã mais rigorosa chamada DISALLOW_FILE_MODS. Faz o que DISALLOW_FILE_EDIT faz, mais bloqueia uploads de plugin, uploads de tema e atualizações do núcleo de dentro da interface admin. Definir é idêntico:

define('DISALLOW_FILE_MODS', true);

Essa é uma alteração de comportamento muito maior. Com DISALLOW_FILE_MODS ativo, você não pode mais instalar ou atualizar plugins, temas ou núcleo do WordPress pela interface admin normal. Todas as atualizações têm que vir de outro lugar: WP CLI, um pipeline de implantação, um upload SFTP ou o painel central de um host gerenciado.

Para a maioria dos sites isso é restritivo demais. Atualizações são a tarefa de segurança mais importante em um site WordPress, e tornar elas mais difíceis geralmente significa que as pessoas as pulam. DISALLOW_FILE_MODS faz sentido em dois ambientes específicos: pipelines de implantação onde a instalação de produção deve ser somente leitura, e configurações de alta segurança onde alguém é genuinamente responsável por enviar atualizações de fora. Para tudo o mais, DISALLOW_FILE_EDIT simples atinge o ponto ideal de "enorme ganho de segurança, sem dor operacional".

O que muda para os usuários depois que você define isso?

Para 99% dos admins em 99% dos sites: nada visível. As duas entradas de menu sumiram do painel. Ninguém percebe, porque ninguém estava usando.

Os casos em que alguém percebe:

• Um desenvolvedor que edita produção diretamente. Se você tem alguém na equipe que rotineiramente edita arquivos de tema ou plugin pelo navegador, ele precisará mudar para SFTP ou um pipeline de implantação. Isso é uma alteração de fluxo de trabalho, não um bloqueador. Aliás, este é um bom momento para perguntar por que o código de produção está sendo editado ao vivo em primeiro lugar.
• Plugins que se conectam ao editor. Um pequeno punhado de plugins estende o editor integrado com recursos extras. Eles falharão silenciosamente em carregar sua UI quando o editor sumir. O próprio plugin geralmente continua funcionando, apenas a integração do editor quebra. Se você depende de um deles, verá a lacuna durante os testes.
• Código personalizado que usa as capacidades edit_themes ou edit_plugins. A constante remove essas capacidades de cada papel, incluindo administrador. Código que condiciona recursos a essas capacidades exatas se comportará como se ninguém as tivesse. Raro, mas vale a pena saber se você mantém um plugin personalizado que faz esse tipo de verificação de capacidade.

Verificando que está ativo

1. Faça login no WordPress como administrador.
2. Abra o menu Aparência na barra lateral admin. A entrada "Editor de Arquivo de Tema" deve estar faltando.
3. Abra o menu Plugins. A entrada "Editor de Arquivo de Plugin" deve estar faltando.
4. Para uma verificação extra, navegue diretamente para https://seudominio.com/wp-admin/theme-editor.php. O WordPress deve redirecioná-lo para uma página que diz "Sorry, you are not allowed to edit theme files".
5. Execute uma nova varredura do InspectWP. A verificação "editor de arquivo habilitado" na seção de segurança deve ficar verde.

Se as entradas de menu ainda estão lá após salvar o wp-config.php, as razões mais comuns são: cache de objeto (limpe-o), cache de opcode como OPcache (pode levar um momento para captar o novo arquivo, ou você pode reiniciar o PHP FPM), a edição de arquivo caiu em um wp-config.php errado em um diretório pai, ou a constante foi definida mais tarde no arquivo por outra coisa e sua linha está sendo sobrescrita. Abra wp-config.php do topo e procure por DISALLOW_FILE_EDIT; você deve ver sua linha e nada mais a definindo de novo depois.

O que essa correção faz e o que não faz

Vale a pena ser claro sobre que tipo de ataque DISALLOW_FILE_EDIT impede e o que deixa intocado. Ele impede o caminho específico em que um invasor usa um login admin roubado para escrever PHP em arquivos de tema ou plugin pelo navegador. Não impede:

• Um invasor enviando um zip de plugin ou tema malicioso do admin (use DISALLOW_FILE_MODS para isso, com as compensações descritas acima, ou restrinja capacidades para uploads de plugin).
• Um invasor explorando uma vulnerabilidade em nível de código em um plugin para escrever arquivos. Isso requer que o próprio plugin seja corrigido.
• Um invasor que tem acesso SFTP ou shell. Nesse ponto, a camada do WordPress é completamente contornada.

DISALLOW_FILE_EDIT é uma camada defensiva, não uma estratégia completa. Ela combina naturalmente com senhas de admin fortes, autenticação de dois fatores em contas admin e um plugin de segurança que monitora alterações inesperadas de arquivo. A combinação remove o caminho de tomada de controle mais fácil e torna os mais difíceis barulhentos o suficiente para serem notados.

Uma linha em wp-config.php, sem plugin, sem manutenção, sem superfície de compatibilidade. Se você não fizer mais nada em um site WordPress este mês, faça isso.