{"id":935,"date":"2026-09-26T17:05:30","date_gmt":"2026-09-26T17:05:30","guid":{"rendered":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/cms\/sql-injection-wordpress-blindar-varios-sites\/"},"modified":"2026-09-26T17:05:30","modified_gmt":"2026-09-26T17:05:30","slug":"sql-injection-wordpress-blindar-varios-sites","status":"publish","type":"post","link":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/seguranca\/sql-injection-wordpress-blindar-varios-sites\/","title":{"rendered":"SQL injection WordPress: blindar v\u00e1rios sites de uma vez"},"content":{"rendered":"

Voc\u00ea abre o banco de um site e encontra, no meio da tabela wp_options, um bloco de c\u00f3digo que ningu\u00e9m colocou ali. Ou pior: o site come\u00e7a a redirecionar para dom\u00ednios estranhos, e voc\u00ea desconfia que o problema n\u00e3o est\u00e1 nos arquivos, mas nas consultas que o WordPress faz ao banco. SQL injection WordPress \u00e9 exatamente isso: algu\u00e9m conseguiu inserir comandos SQL atrav\u00e9s de um campo de formul\u00e1rio, par\u00e2metro de URL ou plugin vulner\u00e1vel, e agora o banco carrega instru\u00e7\u00f5es que n\u00e3o deveriam existir.<\/p>\n

O sintoma nem sempre \u00e9 \u00f3bvio. \u00c0s vezes o site funciona normalmente, mas h\u00e1 registros novos em wp_users, links estranhos em wp_posts ou op\u00e7\u00f5es com nomes aleat\u00f3rios em wp_options. Em outros casos, a p\u00e1gina inicial \u00e9 substitu\u00edda por um redirecionamento ou o painel administrativo fica lento. A diferen\u00e7a entre um site com SQL injection e um site apenas invadido por outro vetor est\u00e1 no rastro: a inje\u00e7\u00e3o deixa marcas no banco, n\u00e3o s\u00f3 nos arquivos.<\/p>\n

Por que SQL injection WordPress \u00e9 t\u00e3o comum em plugins e temas<\/h2>\n

O WordPress em si, quando mantido atualizado, tem boa prote\u00e7\u00e3o contra inje\u00e7\u00e3o SQL. O problema est\u00e1 no c\u00f3digo de terceiros. Plugins e temas que montam consultas concatenando strings em vez de usar prepared statements abrem a porta. Um exemplo cl\u00e1ssico \u00e9 uma fun\u00e7\u00e3o que recebe um par\u00e2metro de URL e o insere direto na cl\u00e1usula WHERE, sem sanitiza\u00e7\u00e3o.<\/p>\n

Al\u00e9m disso, plugins abandonados ou sem atualiza\u00e7\u00e3o recente s\u00e3o alvos f\u00e1ceis. Se voc\u00ea administra v\u00e1rios sites, a chance de um deles ter um plugin vulner\u00e1vel \u00e9 alta. Por isso, a triagem de vulnerabilidades em plugin WordPress \u00e9 uma etapa que n\u00e3o pode ser pulada.<\/p>\n

Outro ponto: temas antigos, principalmente os que usam campos personalizados sem valida\u00e7\u00e3o, tamb\u00e9m podem ser vetores. O atacante n\u00e3o precisa de acesso ao painel; basta encontrar um par\u00e2metro que chegue ao banco sem tratamento.<\/p>\n

Como diagnosticar SQL injection WordPress em v\u00e1rios sites<\/h2>\n

Antes de sair limpando, \u00e9 preciso confirmar. A ordem de verifica\u00e7\u00e3o abaixo funciona tanto para um site quanto para dezenas, e pode ser feita via WP-CLI ou phpMyAdmin.<\/p>\n

    \n
  1. Verifique a tabela wp_options.<\/strong> Procure por op\u00e7\u00f5es com nomes aleat\u00f3rios, valores contendo <script><\/code>, base64_decode<\/code> ou eval<\/code>. Um comando \u00fatil \u00e9 SELECT option_name, option_value FROM wp_options WHERE option_value LIKE '%<script%' OR option_value LIKE '%base64%';<\/code>. Em v\u00e1rios sites, rode isso em cada banco.<\/li>\n
  2. Inspecione wp_postmeta e wp_usermeta.<\/strong> Inje\u00e7\u00f5es persistentes costumam se esconder em metadados. Procure por meta_values com tags script ou redirecionamentos. Exemplo: SELECT * FROM wp_postmeta WHERE meta_value LIKE '%<script%';<\/code>.<\/li>\n
  3. Cheque wp_posts e wp_users.<\/strong> Posts com conte\u00fado estranho, usu\u00e1rios novos com nomes aleat\u00f3rios ou e-mails suspeitos. A auditoria de logins WordPress: auditar admins em v\u00e1rios sites<\/a> ajuda a identificar contas criadas pelo atacante.<\/li>\n
  4. Analise os logs de acesso.<\/strong> Procure por requisi\u00e7\u00f5es com par\u00e2metros que contenham UNION SELECT<\/code>, OR 1=1<\/code> ou --<\/code>. Se o servidor tiver logs, essa \u00e9 a prova mais direta.<\/li>\n<\/ol>\n

    Em um parque de sites, automatize essa varredura. Um script simples que percorre os bancos e aplica as consultas acima economiza horas. Ferramentas de gerenciamento em massa, como o 100% WP, ajudam a rodar comandos WP-CLI em todos os sites de uma vez, mas o diagn\u00f3stico manual ainda \u00e9 necess\u00e1rio para interpretar os resultados.<\/p>\n

    Portas de entrada mais comuns<\/h2>\n

    Nem toda inje\u00e7\u00e3o vem de um plugin famoso. Muitas vezes \u00e9 um plugin pequeno, sem atualiza\u00e7\u00e3o h\u00e1 meses, que faz consultas diretas. Outras vezes, \u00e9 um tema comprado em marketplaces duvidosos. A tabela abaixo resume os vetores mais frequentes.<\/p>\n\n\n\n\n\n\n
    Vetor<\/th>\nComo identificar<\/th>\nPrioridade<\/th>\n<\/tr>\n
    Plugin desatualizado<\/td>\nVers\u00e3o antiga, sem atualiza\u00e7\u00f5es recentes<\/td>\nAlta<\/td>\n<\/tr>\n
    Tema com consultas customizadas<\/td>\nFun\u00e7\u00f5es que usam $wpdb->query<\/code> sem prepare<\/td>\nAlta<\/td>\n<\/tr>\n
    Formul\u00e1rios de contato<\/td>\nCampos que v\u00e3o direto para o banco<\/td>\nM\u00e9dia<\/td>\n<\/tr>\n
    Par\u00e2metros de URL<\/td>\nRequisi\u00e7\u00f5es com ?id=<\/code> ou ?cat=<\/code> sem valida\u00e7\u00e3o<\/td>\nM\u00e9dia<\/td>\n<\/tr>\n<\/table>\n

    Se voc\u00ea tem v\u00e1rios sites, comece pelos que usam plugins em comum. Um plugin vulner\u00e1vel pode estar em todos eles, e a inje\u00e7\u00e3o pode ter atingido cada banco de forma independente.<\/p>\n

    Como prevenir SQL injection WordPress na pr\u00e1tica<\/h2>\n

    Prevenir \u00e9 mais barato que limpar. As medidas abaixo valem para qualquer site, mas em escala exigem padroniza\u00e7\u00e3o.<\/p>\n