Olá a todos!
Hoje vou falar-vos de algo que me deixou genuinamente preocupado e que considero um caso de estudo perfeito sobre o que acontece quando se confia cegamente em código gerado por IA sem ter a mínima noção de como programar com segurança. Estou a falar do Huntarr, uma ferramenta self-hosted bastante popular na comunidade *arr que promete automatizar a descoberta de media em falta e upgrades de qualidade no vosso Sonarr, Radarr, Lidarr e companhia. Parece fantástico no papel, certo? Pois bem, a realidade por detrás do código é um autêntico pesadelo de segurança.
A história rebentou no subreddit r/selfhosted quando um utilizador publicou um post devastador intitulado “Huntarr: Your passwords and your entire arr stack’s” — e o que se seguiu foi uma cascata de revelações que devia fazer qualquer homelabber parar e pensar duas vezes antes de instalar software só porque tem uma interface bonita e muitas estrelas no GitHub.
O que é o Huntarr e porque é que tanta gente o usa?
Para quem não conhece, o Huntarr é uma plataforma de automação de media que funciona como um complemento ao ecossistema *arr. A ideia base é simples e legítima: as vossas apps *arr monitorizam RSS feeds para novos lançamentos, mas não vão ativamente procurar conteúdo que já está em falta na vossa biblioteca. Com o tempo, acumulam-se lacunas — temporadas em falta, álbuns incompletos, filmes abaixo do vosso quality cutoff. O Huntarr resolve isto ao fazer pesquisas sistemáticas em batches controlados para não sobrecarregar os vossos indexers.
O projeto cresceu rapidamente e agora inclui módulos integrados como Movie Hunt, TV Hunt, Index Master, NZB Hunt e até um sistema de requests chamado Requestarr. Basicamente, ambiciona substituir partes inteiras do vosso stack. Estamos a falar de um software que tem acesso direto às API keys de todas as vossas aplicações *arr, às credenciais dos vossos indexers, aos vossos download clients, e potencialmente exposto à internet se usarem funcionalidades como o Requestarr que são desenhadas para acesso externo.
Até aqui tudo bem. O problema é que este software foi construído de uma forma que ignora os princípios mais elementares de segurança informática. E quando digo elementares, estou a falar de coisas que qualquer developer com um semestre de formação em segurança saberia evitar.
A auditoria….
Um investigador de segurança chamado rfsbraz fez aquilo que o maintainer do Huntarr deveria ter feito desde o primeiro dia: uma revisão de segurança completa ao código. Não estamos a falar de técnicas sofisticadas de fuzzing ou engenharia reversa exótica. Estamos a falar de uma revisão manual de código cobrindo autenticação, gestão de sessões, rotas sensíveis, execução de comandos, parsing de input e comportamento do serviço no Windows, complementada com análise estática automatizada usando bandit e scanning de vulnerabilidades de dependências com pip-audit. As ferramentas mais básicas que existem.
O resultado? 21 findings no total — 7 críticos, 6 de severidade alta, 5 de severidade média e 2 de best-practice OSS. Mais um finding de severidade alta que agrava um dos críticos existentes. É o tipo de relatório que faz qualquer profissional de segurança perder o sono.
As vulnerabilidades: Um catálogo de horrores
Aqui estão os problemas mais graves porque acho importante que percebam a dimensão disto. Não são bugs subtis. Não são race conditions obscuras. Não são edge cases que só acontecem em condições específicas. São falhas fundamentais que demonstram uma completa falta de compreensão sobre como se constrói software seguro.
Endpoint de settings sem autenticação nenhuma
A vulnerabilidade mais severa é tão simples que quase parece impossível de acreditar. O endpoint POST /api/settings/general não tem qualquer autenticação. Zero. Nada. Nem um check partido, nem um middleware mal configurado. Simplesmente não existe verificação nenhuma. A lista de bypass de autenticação no ficheiro auth.py explicitamente ignora este endpoint.
E o que acontece quando alguém faz um POST a este endpoint? O servidor aceita a escrita e devolve na resposta a configuração completa — não apenas a secção que foi escrita, mas a configuração de todas as aplicações integradas. A resposta inclui passwords de proxy em plaintext, API keys do Prowlarr, API keys e URLs de todas as instâncias do Sonarr, API keys e URLs de todas as instâncias do Radarr, e todas as credenciais de integração. Um único comando curl sem cookies, sem tokens de sessão, sem API key, sem absolutamente nada, dá a um atacante acesso direto a todo o vosso media stack. Se o vosso Huntarr está acessível na rede — e funcionalidades como o Requestarr são desenhadas para acesso externo — qualquer pessoa pode ler as vossas passwords e reescrever a vossa configuração neste preciso momento.
Account takeover via 2FA
Pensam que o 2FA vos protege? Pensem outra vez. O endpoint POST /api/user/2fa/setup retorna o segredo TOTP real a chamadores não autenticados. Um atacante gera um código válido, chama /api/user/2fa/verify, e regista o seu próprio autenticador. Account takeover completo sem sequer saber a password. Este é o tipo de falha que se aprende a evitar nas primeiras aulas de segurança web — nunca expor segredos de 2FA sem verificar primeiro que quem está a pedir é o utilizador legítimo autenticado.
Re-arm do setup flow
O endpoint de clear do setup permite que qualquer pessoa re-ative o fluxo de criação de conta. Isto significa que um atacante pode criar uma nova conta de owner no vosso Huntarr, mesmo depois de vocês já terem feito o setup inicial. Combinem isto com as vulnerabilidades anteriores e temos um cenário onde um atacante pode criar uma conta, registar o seu próprio 2FA, e ter controlo total sobre o vosso sistema.
Bypass de autenticação via Plex
A whitelist de bypass de autenticação em auth.py usa correspondência por substring e sufixo demasiado ampla. Isto isenta mais endpoints do que o pretendido. Um atacante pode definir setup_mode=true, ligar um token Plex controlado por si a uma conta local, e depois autenticar-se como essa conta via o fluxo de login Plex. É uma vulnerabilidade latente que se torna explorável à medida que mais rotas são adicionadas ao sistema.
Zip Slip no upload de backups
O upload de backups é vulnerável a Zip Slip, o que permite escrita arbitrária de ficheiros. Para quem não sabe, Zip Slip é uma vulnerabilidade clássica onde um arquivo zip malicioso contém paths relativos com “../” que permitem escrever ficheiros fora do diretório pretendido. Se um atacante conseguir fazer upload de um backup malicioso, pode potencialmente sobrescrever ficheiros de sistema.
Passwords em plaintext
E como se tudo isto não bastasse, foi reportado que as passwords de utilizadores estavam a ser armazenadas em plaintext na base de dados SQLite. Não com SHA-256 fraco. Não com MD5 antiquado. Em plaintext. A password exatamente como a escreveram, guardada num ficheiro de base de dados. Isto é o ABC da segurança — nunca, mas nunca, guardar passwords sem hashing adequado com Argon2id, bcrypt, ou no mínimo scrypt.
Rate-limiting contornável
O sistema de rate-limiting usa o IP reencaminhado diretamente para identificação, o que significa que pode ser contornado ou distribuído através de spoofing de headers. O espaço de chaves de recuperação é reduzido, usando um formato de palavras humanas mais dois dígitos, o que torna ataques de força bruta viáveis.
A dimensão do problema: Isto não é sobre o Huntarr sozinho
Se estes problemas vos parecem amadores, é porque são. E aqui está onde chegamos ao cerne da questão que eu quero mesmo discutir convosco.
O maintainer do Huntarr afirma trabalhar em cibersegurança. Nas suas próprias palavras, diz ter investido mais de 120 horas nas últimas 4 semanas usando “steering documents to advise along the way from cybersecurity, to hardening, and standards.” Diz ter “a series of steering documents I generated that does cybersecurity checks and provides additional hardening.”
Percebem o que isto significa? Os “steering documents” foram gerados. Gerados por IA. Este é um caso clássico e textbook de vibecoding aplicado a segurança — alguém que pede a um LLM para gerar documentos de boas práticas de segurança, presume que seguir esses documentos é suficiente, e depois despacha código sem nunca o ter verdadeiramente compreendido ou testado.
O investigador que fez a auditoria foi cirúrgico na sua análise: correr bandit no código fonte teria flagged as credenciais hardcoded. Correr qualquer teste de integração HTTP contra qualquer destes endpoints sem um session cookie teria apanhado o resto. As ferramentas mais básicas que existem. Os checks mais elementares que se pode fazer. E nenhum foi feito.
Vibecoding: A ilusão perigosa da competência
E é aqui que eu quero que parem e pensem, porque este é um padrão que estamos a ver repetir-se cada vez mais na comunidade self-hosted e no desenvolvimento de software em geral.
O vibecoding — esse conceito popularizado por Andrej Karpathy onde o developer “dá-se completamente às vibes, abraça os exponenciais e esquece que o código sequer existe” — está a criar uma geração de projetos que parecem funcionais, têm interfaces bonitas, ganham estrelas no GitHub, mas que por baixo da superfície são minas terrestres de segurança à espera de serem detonadas.
Quando pedimos a um LLM para escrever código, ele vai produzir algo que funciona. Vai compilar, vai correr, vai fazer o que pedimos. Mas o LLM não pensa em segurança da forma como um developer experiente pensa. Não considera threat models. Não pensa em como um atacante pode abusar de cada endpoint. Não aplica o princípio do menor privilégio. Não faz revisão de segurança ao seu próprio output. E acima de tudo, não sabe o que não sabe.
O caso do Huntarr é um exemplo perfeito disto. O código funciona. O Huntarr efetivamente encontra media em falta e faz upgrades. A interface é polida. Os módulos são ambiciosos. Mas a autenticação — a camada mais fundamental de segurança em qualquer aplicação web — é um queijo suíço. E isto acontece porque quem escreveu o código não percebe de segurança, usou IA como muleta em vez de como ferramenta, e presumiu que “funcionar” é sinónimo de “ser seguro.”
O investigador rfsbraz foi certeiro quando disse que o maintainer vai provavelmente “prompt these specific problems away” — ou seja, vai alimentar os findings a uma IA e despachar um patch. Mas corrigir 21 findings específicos não corrige o processo que os criou. Sem code review, sem um processo de PRs, sem testes automatizados básicos, sem ninguém que perceba de fundamentos de segurança a rever o que é shipped — a próxima batch de features vai introduzir a próxima batch de vulnerabilidades.
Este é o problema fundamental do vibecoding aplicado a software que gere credenciais e tem acesso a redes: não é que o código de hoje tenha bugs. É que o processo garante que o código de amanhã também vai ter.
Má fé: Censura de reports de segurança
Como se tudo isto não fosse suficiente, o maintainer remove reports de segurança do subreddit r/huntarr, que ele próprio modera, e bane utilizadores que levantam estas preocupações. Isto é o oposto do que qualquer projeto responsável deveria fazer. Quando alguém reporta vulnerabilidades de segurança no vosso software, a resposta correta é agradecer, confirmar, corrigir e divulgar. Não é censurar e banir.
Este comportamento é um red flag enorme e deveria, por si só, ser razão suficiente para qualquer pessoa reconsiderar se quer confiar as suas credenciais a este projeto. Um maintainer que censura reports de segurança não está a proteger os seus utilizadores — está a proteger o seu ego.
O que fazer se usam Huntarr
Se estão a correr o Huntarr na vossa rede neste momento, aqui ficam as minhas recomendações imediatas. Primeiro, verifiquem se a vossa instância está acessível a partir da internet. Se estiver, isolem-na imediatamente ou desliguem-na. Segundo, rodem as API keys de todas as aplicações *arr integradas — Sonarr, Radarr, Prowlarr, Lidarr, todas. Assumam que foram comprometidas. Terceiro, mudem as passwords, especialmente se reutilizaram a password do Huntarr noutros serviços. Quarto, verifiquem os logs das vossas aplicações *arr para acessos suspeitos. Quinto, considerem seriamente se querem continuar a usar este software até que os problemas de segurança sejam resolvidos de forma verificável e o projeto adopte um processo de desenvolvimento que inclua revisão de segurança.
A lição maior: Segurança não se vibecoda
O caso do Huntarr é um microcosmo de um problema muito maior que estamos a enfrentar como comunidade. A democratização do desenvolvimento de software via IA é uma coisa fantástica em muitos aspetos. Permite que mais pessoas construam ferramentas úteis, automatizem tarefas, e resolvam problemas. Mas quando essas ferramentas gerem credenciais, acedem a redes, e correm em infraestrutura partilhada, a fasquia de qualidade não pode ser “funciona.” Tem de ser “funciona e é seguro.”
Segurança não é algo que se adiciona depois. Não é uma checklist que se gera com um LLM. Não é um steering document que se consulta ocasionalmente. Segurança é uma disciplina que requer formação, experiência, e uma mentalidade de adversário — a capacidade de olhar para o vosso próprio código e perguntar “como é que alguém pode abusar disto?”
Se estão a construir software que vai ser usado por outras pessoas, especialmente software que gere credenciais ou acede a serviços, por favor invistam tempo a aprender os fundamentos de segurança. Leiam o OWASP Top 10. Aprendam sobre autenticação e gestão de sessões. Usem ferramentas de análise estática. Escrevam testes. Peçam code reviews a pessoas que percebam de segurança. E se usam IA para gerar código, tratem-na como um junior developer cujo trabalho precisa de ser rigorosamente revisto — não como um oráculo omnisciente que produz código perfeito.
A IA é uma ferramenta extraordinária quando usada por alguém que sabe o que está a fazer. Mas quando usada por alguém que não percebe os fundamentos, amplifica a ignorância na mesma proporção que amplificaria o conhecimento. E no caso da segurança informática, ignorância amplificada traduz-se em vulnerabilidades amplificadas.
O Huntarr é a prova viva disso.
Até ao próximo post, mantenham-se vigilantes, rodem as vossas API keys, e por favor, não confiem as credenciais do vosso media stack a software que não passou por uma auditoria de segurança minimamente séria.
Um abraço, Nuno
P.S.: Se são developers e estão a usar IA para gerar código, lembrem-se: a IA não substitui o conhecimento. Complementa-o. Se não sabem o que é autenticação por sessão, se não sabem porque é que passwords em plaintext são inaceitáveis, se não sabem o que é Zip Slip ou TOTP — então precisam de aprender antes de construir. O vibecoding pode ser divertido para protótipos e projetos pessoais. Mas quando outras pessoas dependem do vosso software para proteger as suas credenciais, “divertido” não é suficiente. “Seguro” é o mínimo.