scan-wp-sec

Scanner local e passivo para inventariar sites WordPress, identificar configurações expostas e cruzar versões detectadas com bases de vulnerabilidades baixadas ou consultadas localmente.

O objetivo é apoiar correção de ambientes próprios/autorizados. O scanner não executa exploração, brute force, fuzzing agressivo nem upload de payloads.

Fontes suportadas

• Wordfence Intelligence V3: feed JSON completo, com autenticação por API key.
• NVD CVE API 2.0: busca opcional por palavra-chave para enriquecimento manual (--nvd).
• OSV.dev: busca no ecossistema WordPress via API pública (--osv).
• WordPress.org API: referência para metadados públicos de plugins/temas quando necessário.

Fontes planejadas para próximos módulos:

• Moodle Security Announcements para Moodle.
• WPScan/Patchstack como integrações opcionais, respeitando tokens e termos de uso.

Instalação

Instalar todas as dependências Python do projeto:

python3 -m venv .venv
. .venv/bin/activate
python3 -m pip install -e '.[pdf]'

Instalação mínima:

python3 -m venv .venv
. .venv/bin/activate
python3 -m pip install -e .

Instalação com exportação PDF:

python3 -m pip install -e '.[pdf]'

Se você já instalou com -e ., basta rodar o segundo comando para adicionar o suporte a PDF no mesmo ambiente virtual.

Também funciona sem instalação:

PYTHONPATH=src python3 -m scan_wp_sec scan https://exemplo.edu.br

Baixar base Wordfence

Crie uma API key gratuita no Wordfence Intelligence e rode:

export WORDFENCE_API_KEY="sua-chave"
scan-wp-sec update-wordfence --feed production --output data/wordfence-production.json

Esse comando também grava um arquivo local de metadados com a data/hora do snapshot baixado.

Por padrão, o scanner trata data/wordfence-production.json como base Wordfence gerenciada. Quando esse arquivo existir e você rodar scan sem --db, o app:

• usa essa base automaticamente;
• verifica se ela foi baixada no dia atual;
• tenta fazer refresh automático antes do scan se ela estiver desatualizada em D-1;
• prossegue com o snapshot local e registra aviso se o refresh automático falhar.

Para ambientes sem internet, baixe a base em uma máquina permitida, transfira o JSON e o arquivo .meta.json correspondente para o ambiente interno, ou rode o scan apontando --db.

Uso CLI

scan-wp-sec scan https://site.institucional.edu.br \
  --db data/wordfence-production.json \
  --html reports/site.html \
  --pdf reports/site.pdf \
  --json reports/site.json

Opções úteis:

• --offline: não consulta fontes externas durante o scan.
• --nvd: faz busca informativa na NVD por componentes detectados. Não envia a URL do site, apenas nomes/versões de componentes.
• --osv: consulta OSV.dev (ecossistema WordPress) por componentes detectados. Resultados complementares ao Wordfence, deduplicados por CVE.
• --include-potential: lista vulnerabilidades de componentes detectados mesmo quando a versão não pôde ser determinada.
• --no-exposure-checks: desativa verificações de arquivos/endpoints comuns expostos.
• --pdf: exporta o relatório em PDF. Requer reportlab instalado via extra pdf.
• --db: força o uso de uma base Wordfence específica e tem precedência sobre a base gerenciada padrão.

Interface web local

scan-wp-sec serve --host 127.0.0.1 --port 8765 --db data/wordfence-production.json

Acesse http://127.0.0.1:8765 e informe a URL autorizada.

Na tela inicial, a interface mostra a versão atual do scan-wp-sec e o status/data da base Wordfence gerenciada. Também há um botão Atualizar Wordfence para forçar a atualização manual da base pela própria interface web.

Após cada scan, a página de resultado expõe um link Baixar PDF. Se o ambiente estiver sem a dependência PDF, a interface retorna erro claro em vez de arquivo vazio.

Os relatórios HTML, PDF e JSON também mostram a data da base Wordfence usada no scan, quando uma base local estiver disponível.

O que o scanner verifica

Detecção de WordPress e componentes:

• Indícios de WordPress em HTML, REST API, headers X-WP-* e caminhos padrão.
• Versão do core quando exposta por meta generator, assets, readme.html, feeds RSS ou Atom.
• Plugins e temas referenciados em wp-content/plugins e wp-content/themes.
• Versões em query string de assets, readme.txt de plugins e style.css de temas.

Vulnerabilidades conhecidas:

• Matching por componente e faixa de versão via feed Wordfence local.
• Enriquecimento informativo via NVD (--nvd) e OSV.dev (--osv), com deduplicação por CVE.

Checks passivos de exposição:

• XML-RPC exposto.
• REST API de usuários pública.
• Enumeração de usuário via /?author=1.
• Página de login (/wp-login.php) acessível.
• wp-cron.php acionável externamente.
• Versão exposta no feed RSS (/?feed=rss2).
• readme.html, debug.log, listagem de diretório em uploads.
• Backups de wp-config.php (.bak, .old, .orig, .~, -backup.php e variantes).
• Repositório Git exposto (/.git/config).
• Arquivos .env acessíveis (/.env, /.env.local, /.env.production).
• Arquivos de diagnóstico PHP (phpinfo.php, info.php, test.php).
• Backups de .htaccess e .htpasswd expostos.
• Dumps de banco de dados acessíveis (database.sql, backup.sql e variantes).

Cabeçalhos HTTP:

• Cabeçalhos de segurança ausentes: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Strict-Transport-Security, Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, Cross-Origin-Resource-Policy.

Limitações

Versões expostas por HTML e assets podem estar ausentes ou mascaradas por cache/minificação. Quando a versão não é confirmada, o relatório marca a confiança como baixa ou média. Resultados da NVD por palavra-chave são informativos e precisam de validação manual.

A exportação PDF é local e offline, mas depende de reportlab. Sem essa biblioteca o scanner continua funcionando para console, JSON e HTML, e falha de forma explícita apenas quando PDF é solicitado.