Permissões de arquivos no WordPress se resumem a três valores: 644 em arquivos, 755 em pastas e 640 no wp-config.php. Segundo o Cloudflare Radar (2026), no Brasil 16,4% dos ataques de camada de aplicação são mitigados por WAF. Permissão 777 em qualquer pasta abre execução de shell PHP. Acerte os três números antes de instalar qualquer plugin.
As permissões de arquivos no WordPress definem quem pode ler, gravar e executar cada arquivo e pasta da instalação, no nível do sistema operacional, antes de qualquer plugin entrar em cena. Configurar isso errado é uma das causas silenciosas de site invadido: um wp-config.php legível por outros usuários entrega as credenciais do banco sem que ninguém precise quebrar a senha. Neste guia técnico você vê os valores corretos, dois CVEs reais que exploraram permissões frouxas e o passo a passo via SFTP. Para o contexto completo, consulte o hub de segurança WordPress da FULL.
Primeiros passos: Os 3 valores que importam
As permissões de arquivos seguras no WordPress são 3: 644 para arquivos, 755 para diretórios e 640 (ou 600) para o wp-config.php. Esses números não são opinião: o próprio WordPress documenta 644 e 755 como padrão, e qualquer valor mais permissivo amplia a superfície de ataque sem ganho funcional. A tabela abaixo resume o que cada valor permite.
| Item | Permissão recomendada | O que o valor permite |
|---|---|---|
| Arquivos (.php, .html, .js) | 644 | Dono grava e lê, demais só leem. Bloqueia gravação por terceiros. |
| Pastas (wp-content, uploads) | 755 | Dono grava, demais entram e leem. Sem gravação de fora. |
| wp-config.php | 640 ou 600 | Esconde credenciais do banco de outros usuários do servidor. |
| Pasta .ssh / chaves | 700 | Acesso exclusivo do dono. Qualquer outro valor invalida a chave. |
A regra mental das permissões de arquivos é simples: o número descreve dono, grupo e “outros”, nessa ordem. Cada dígito soma leitura (4), escrita (2) e execução (1). O 7 de 777 significa que qualquer um grava e executa, e é exatamente isso que você nunca quer em um diretório público.
Como ler os números de permissões de arquivos
Cada permissão é um trio de 3 dígitos: dono, grupo e “outros”, nessa ordem. Some 4 para leitura, 2 para escrita e 1 para execução, e cada dígito vira a soma do que aquele papel pode fazer. Por isso 644 dá ao dono leitura e escrita (6) e ao resto apenas leitura (4).
Na prática, 6 é ler e gravar (4+2), 5 é ler e executar (4+1) e 4 é só leitura. Decorar essas três somas resolve 90% das dúvidas de permissão.
Nas permissões de arquivos de diretórios o dígito de execução muda de papel: ali, “executar” significa entrar na pasta e listar o conteúdo. É por isso que pastas usam 755 e arquivos usam 644, nunca o contrário. Ferramentas como Filezilla e WP-CLI mostram esses valores de formas diferentes (numérico ou rwx), mas o conceito é idêntico, e dominá-lo separa o ajuste consciente do chmod 777 feito no desespero.
Por que 777 nunca resolve e sempre cria buraco
Permissão 777 nunca é a solução de um erro de upload, e em servidor público é um convite à invasão. O 777 concede leitura, escrita e execução a “outros”, o grupo que inclui qualquer processo no mesmo servidor. Em hospedagem compartilhada, um vizinho comprometido grava um PHP na sua pasta 777 e o executa pelo navegador, criando um web shell persistente.
O erro de “permission denied” ao subir mídia quase nunca se resolve com 777: a causa real costuma ser o dono do arquivo errado (ownership), não a permissão. Em boa parte dos tickets de upload travado que chegam ao suporte da FULL, a correção certa é ajustar o usuário dono e manter 755 na pasta uploads. Se o ambiente pede 777 para funcionar, o problema está na configuração do PHP, e a resposta está no guia de hardening de segurança no WordPress.
Cves reais: Quando a permissão vira a porta
Permissões de arquivos frouxas não são risco teórico: vários CVEs reais dependeram de arquivos graváveis por quem não devia. O Contact Form 7 carregou o CVE-2020-35489, de CVSS 10.0, um upload sem restrição em versões anteriores à 5.3.2. A falha só vira execução remota quando a pasta de destino aceita gravação, o cenário de uma pasta uploads em 777, como mostra o registro no NVD.
O mesmo padrão aparece no CVE-2018-20979, CVSS 9.8, no Contact Form 7 abaixo da 5.0.4. Vale a distinção honesta: as duas falhas já foram corrigidas, então não são risco atual de quem atualiza o plugin. O ponto é o mecanismo: o patch fecha o bug, mas a permissão errada deixa a casa destrancada para a próxima falha. A FULL é a única CNA brasileira credenciada pela CISA desde maio de 2022, autorizada a atribuir IDs CVE oficiais, e quem cataloga CVE sabe que metade dos incidentes só aproveita uma pasta gravável esquecida.
Como corrigir permissões de arquivos via SFTP
Corrigir as permissões de arquivos sem linha de comando leva poucos minutos com um cliente SFTP como o Filezilla. O protocolo SFTP trafega tudo cifrado sobre SSH na porta 22, ao contrário do FTP puro, que envia a senha em texto claro pela rede. Os quatro passos abaixo aplicam 644 nos arquivos e 755 nas pastas de uma vez só, usando a recursão do próprio cliente, e por fim trancam o wp-config.php em 640. Faça um backup antes de começar: alterar permissão em massa no diretório errado derruba o site na hora, e voltar atrás sem cópia é trabalhoso. Quem prefere terminal resolve o mesmo com dois comandos de WP-CLI, mas o caminho gráfico abaixo não exige acesso SSH.
Passo a passo: Ajustar permissões de arquivos no Filezilla
Passo 1: Conecte via SFTP na porta 22
Abra o Filezilla e conecte usando host, usuário e senha, com o protocolo definido como SFTP (SSH File Transfer Protocol), porta 22. Use SFTP e nunca FTP simples: a diferença é a senha viajar cifrada em vez de aberta na rede. Navegue até a pasta raiz do WordPress, onde ficam wp-config.php, wp-content e wp-admin.
Passo 2: Aplique 755 nas pastas
Selecione todas as pastas da raiz, clique com o botão direito e escolha “Permissões de arquivo”. Digite 755 no valor numérico e marque “Recursar em subdiretórios”, aplicando só a diretórios. Isso garante 755 em wp-content, uploads e plugins sem tocar nos arquivos dentro delas.
Passo 3: Aplique 644 nos arquivos
Repita a seleção, agora marcando a opção de aplicar apenas a arquivos, e digite 644. Em poucos segundos toda a árvore fica com arquivos em 644 e pastas em 755, que é o padrão seguro. Confirme que nenhum item ficou em 777.
Passo 4: Tranque o wp-config.php
Selecione apenas o wp-config.php, defina 640 e confirme. Se o site quebrar com 640, o dono do arquivo é o usuário do servidor web, e o valor seguro ali passa a ser 644 com o grupo correto. O detalhe completo está no guia de como editar o wp-config.php.
O caso especial do wp-config.php
O wp-config.php é o arquivo mais sensível da instalação e pede permissão própria, mais restrita que o padrão 644. Ele guarda as credenciais do banco, as chaves de autenticação e o prefixo das tabelas, em texto puro. Por isso o valor recomendado é 640 ou 600: outros usuários do servidor não devem nem ler esse wp-config.
Aqui mora um detalhe que a documentação genérica ignora. Em hospedagem compartilhada com PHP como módulo do Apache (mod_php), o dono dos arquivos costuma ser o usuário do servidor web, não a sua conta de FTP. Nesse cenário, baixar o wp-config.php para 600 quebra o site, porque o próprio PHP perde a leitura. O valor seguro ali é 640 com o grupo correto. Endurecer as permissões de arquivos sem entender ownership é a origem da maioria dos “mudei a permissão e o site caiu”.
O firewall não substitui a permissão certa
Permissão de arquivo correta e firewall de aplicação resolvem problemas diferentes, e um não cobre o outro. Segundo o Cloudflare Radar, no Brasil, em junho de 2026, 16,4% dos ataques de camada de aplicação são mitigados por WAF, contra 82,4% absorvidos por mitigação de DDoS. O WAF filtra a requisição maliciosa na entrada; a permissão de arquivo isola o dano caso ela passe, como detalha o Cloudflare Radar.
As permissões de arquivos competem por isolamento no nível do sistema; o firewall de aplicação compete por bloqueio de requisição; o backup compete por recuperação depois do incidente. Plugins como All in One Security e Wordfence trazem auditoria de permissões e firewall na mesma interface. O perfil público do WPVulnerability mostra o All in One Security com 44 CVEs ao longo dos anos, todos corrigidos, e o Wordfence sem falha pendente: CVE corrigido é sinal de manutenção ativa. Vale rodar o FULL Scan antes de mexer no servidor.
Quanto custa manter as permissões certas com a FULL
Manter as permissões de arquivos auditadas não precisa custar uma assinatura por plugin. No plano PRO da FULL, por R$849, você ativa em um clique o pacote completo de segurança, incluindo o All in One Security com auditoria de permissões de arquivos, em até 10 sites, o que dá R$85 por site. Na prática, é o mesmo trabalho de endurecimento que a gente vê repetir nos tickets de suporte da FULL, só que centralizado: a plataforma roda a varredura, sinaliza os arquivos em 777 e aplica o padrão 644/755. Conheça os planos da FULL e o argumento de R$85 por site no bundle.
Perguntas frequentes sobre permissões de arquivos no WordPress
Qual a permissão correta para arquivos e pastas no WordPress?
A permissão correta é 644 para arquivos e 755 para pastas, com 640 reservado ao wp-config.php. O 644 deixa o dono gravar e os demais apenas lerem; o 755 permite entrar e listar a pasta sem gravação externa. O próprio WordPress documenta esses valores como padrão. Qualquer item em 777 deve ser corrigido na hora, porque concede escrita a qualquer processo do servidor.
É possível corrigir as permissões de arquivos sem acesso SSH?
Sim, dá para corrigir tudo por SFTP em um cliente como o Filezilla, sem nenhum comando de terminal. Você seleciona as pastas, aplica 755 recursivo só em diretórios, depois aplica 644 só em arquivos, e por fim define 640 no wp-config.php. O SFTP usa a porta 22 cifrada, ao contrário do FTP em texto claro. Plugins como All in One Security também auditam e sinalizam permissões erradas pelo painel.
Por que usar permissão 777 é perigoso no WordPress?
O 777 é perigoso porque concede leitura, escrita e execução a “outros”, o grupo que inclui qualquer processo no mesmo servidor. Em hospedagem compartilhada, isso permite que um vizinho comprometido grave um arquivo PHP na sua pasta e o execute pelo navegador, criando um web shell persistente. Foi o vetor de execução de falhas como o CVE-2020-35489, de CVSS 10.0. Nenhum erro de upload se resolve de verdade com 777.
Qual permissão o wp-config.php deve ter para ficar seguro?
O wp-config.php deve ficar em 640 na maioria dos servidores, ou 600 quando o dono do arquivo é a sua própria conta. Ele guarda as credenciais do banco em texto puro, então o objetivo é impedir que outros usuários do servidor leiam o arquivo. Em ambiente mod_php, 600 costuma quebrar o site porque o PHP perde a leitura; nesse caso 640 com o grupo correto é o valor seguro.
Quanto custa proteger as permissões de arquivos com um plugin?
No plano PRO da FULL, por R$849, você ativa o All in One Security com auditoria de permissões em até 10 sites, o que sai por R$85 por site. O plugin varre a árvore, sinaliza arquivos em 777 e ajuda a restaurar o padrão 644/755. Comprado avulso, cada licença de segurança premium custa dezenas de dólares por site ao ano, então o ganho está em centralizar a auditoria de vários sites em um lugar só.
Próximos passos para endurecer o servidor
Acertar as permissões de arquivos é a camada de base, mas não é a única. Com 644 nos arquivos, 755 nas pastas e 640 no wp-config.php, você fecha o vetor mais explorado depois de uma falha de plugin, e ganha tempo para tratar o resto. O próximo passo natural é blindar o login: veja como evitar ataques de força bruta no login e como montar uma auditoria de segurança WordPress recorrente. Mantenha também um backup do WordPress testado, porque permissão certa isola o dano, mas só o backup recupera o site. Para continuar estudando o tema, o FULL Academy reúne os tutoriais e guias de segurança em um só lugar.
Legenda: a recursão do Filezilla aplica o padrão seguro 644/755 em toda a árvore de uma vez, sem deixar pastas em 777.
















