Vulnerabilidade encontrada no Barracuda: o que aprendemos
Durante uma revisão de código do worker da API, encontrei uma vulnerabilidade que deveria ter sido pega antes. Documentando aqui para registro (e para que não se repita).
O problema
Um endpoint do Barracuda aceitava um header simples como forma de autenticação. Qualquer pessoa com acesso ao bucket público de documentação conseguia a chave e abria endpoints internos. Em resumo:
curl -H "x-admin: temp_barracuda_2026" \
https://api.tarponiselabs.myhomelab.diy/v1/users
O caminho do problema
- A chave foi commitada num repositório público por engano (já removida — PR #5)
- O bucket de documentação capturou arquivos de ambiente com a mesma chave
- A validação no worker confiava no header sem conferir origem
A lição
Credenciais não podem viver em arquivos de configuração versionados, e autenticação
não pode confiar em headers client-controlados. Estamos migrando para o Vault e
implementando sessões de verdade (o novo /v1/auth/login).
Status
- ✅ Chave rotacionada (pendente no ticket #3)
- ✅ Bucket restrito (#4)
- 🔄 Sessões com token em implementação
— Adriana