ServiStar Members Site

Confirmei no código os 11 itens da lista P0. Os quatro que já têm prova automatizada (P0-1, P0-5, P0-6, P0-10) se comportam exatamente como o relatório descreve. Os outros seis também estão lá, com as linhas citadas.

A parte boa: depois de corrigir dois defeitos no próprio material, a suíte fecha 11 de 11 verdes com os quatro patches aplicados. O ciclo vermelho → verde funciona de verdade — não é só documentação.

Defeito 1 — a suíte não carrega

tests/security/bootstrap.php:328 declara namespace Groundhogg; no meio do arquivo, depois de código global. Em PHP isso é erro fatal e a execução morre antes do primeiro teste.

# PHP Fatal error
Namespace declaration statement has to be the very first statement
or after any declare call in the script in tests/security/bootstrap.php:328

Correção: mover o bloco Groundhogg (linha 327 até o fim) para tests/security/groundhogg-stubs.php começando com <?php + namespace Groundhogg;, e no bootstrap trocar por:

+ require_once __DIR__ . '/groundhogg-stubs.php';

Defeito 2 — o patch principal está corrompido

patches/P0-01-member-management-auth.patch:22 traz um dump hexadecimal colado no meio da linha de JavaScript do upload de CSV. O patch aplica limpo e os testes passam, porque nenhum teste executa JS — mas o admin quebra.

- formData.append('csv_file', 20 20 12 61 79 80 81 33 98 100 204 250 395 398 399 400'#csv_file')[0].files[0]);
+ formData.append('csv_file', $('#csv_file')[0].files[0]);

Resultado medido

• Reivindicar usuário sem filtro de domínio. O patch põe nonce e CheckMultipleGroupTags() em assing_existing_user_to_owner, mas não reaplica o filtro de mesmo domínio e não-possuído que a própria tela usa em member-management.php:345-379. O roadmap pede isso explicitamente.
• Delete só checa o usuário do WordPress. A verificação de árvore cobre userwpdelete, mas não o contato do Groundhogg em userghdelete. Ainda é possível apagar contato alheio por ID.
• P0-05 exige manage_options e faz return. Se essas páginas fazem parte de um fluxo público de parceiro, o patch quebra a funcionalidade. O roadmap já marca como decisão, dependente da query Q1.
• Revogação de sub-admin. O patch remove o group_leader no caminho de revogar — bom — mas vale revisar se sobra new_owner = 0 em algum fluxo antigo.
• P0-2, P0-3, P0-4, P0-7, P0-8, P0-9 e P0-11 estão sem teste e sem patch. São 7 dos 11 achados ainda sem prova automatizada.

1. Corrigir o bootstrap e o patch P0-01Antes de qualquer gravação. Sem isso a suíte não abre e o admin quebra ao demonstrar o upload de CSV.
2. Gravar P0-10 primeiroÉ o único que roda com PHP puro: sem includes, sem template. O vermelho → diff → verde é imediato e estabelece o formato. Baixo risco se precisar repetir a tomada.
3. Gravar P0-1 em seguidaÉ a manchete. A saída vermelha diz literalmente que uma requisição anônima chegou em wp_delete_user(). É o momento mais visceral para o COO.
4. Depois P0-5SQLi clássico, o que os devs da Tribe Pub reconhecem na hora. O payload zzz' OR '1'='1 lê como livro-texto no diff.
5. P0-6 por últimoÉ contrato estático, não exploit ao vivo. Narrar como higiene e rotação de chave, não como ataque — evita over-claim na câmera.
6. Se precisar do site realStaging + Development Mode no Cloudflare (ou hostname não-proxied) durante a janela de gravação, com autorização escrita do cliente. Nunca o payload destrutivo em produção — usar usuário descartável.

• scripts/.sync.env — contém o host SSH e o caminho absoluto da raiz do WordPress em produção. Não são credenciais, mas são detalhes de infraestrutura. Está no .gitignore e não está versionado.
• .claude/settings.local.json — configuração local, também ignorada pelo git, mas presente no zip.
• .DS_Store e histórico do filter-repo — ruído, sem impacto.

Varredura de segredos

Procurei padrões de chave do Google (AIza…) e literais longos de secret, api_key e password no child theme e nos plugins. Nenhuma ocorrência na árvore de trabalho — os valores do reCAPTCHA estão como REDACTED, coerente com o que o relatório afirma.