O que aconteceu

Em setembro de 2025, tres vulnerabilidades de segurança críticas foram divulgadas no ash-project, um popular framework declarativo de camada de dados para aplicações Elixir/Phoenix. As falhas, identificadas como CVE-2025-48042, CVE-2025-48043 e CVE-2025-48044, são classificadas como Incorrect Authorization e permitem que atacantes contornem controles de autenticação em sistemas que utilizam versões vulneráveis da biblioteca.

O ash-project e amplamente adotado no ecossistema Elixir para modelar recursos, definir políticas de acesso e orquestrar fluxos de dados em APIs REST e GraphQL. A existencia de tres CVEs distintos para o mesmo tipo de falha, cobrindo faixas de versões diferentes, indica que o problema foi reintroduzido ou persistiu por multiplos ciclos de desenvolvimento, tornando a superficie de ataque mais ampla do que o habitual.

Desenvolvedores e equipes de segurança que utilizam o ash-project devem verificar imediatamente a versão instalada e aplicar os patches disponibilizados pelos mantenedores.

Como funciona

As tres vulnerabilidades compartilham a mesma classe de problema: autorização incorreta (CWE-863). No ash-project, políticas de acesso são declaradas por meio de macros DSL que definem quem pode executar quais ações sobre determinados recursos. O bypass ocorre quando a avaliação dessas políticas e ignorada ou circunnavegada sob certas condições de uso da API interna do framework.

De forma simplificada, o fluxo esperado e:

  1. A aplicação chama uma ação (ex: MyApp.User.read!)
  2. O Ash avalia as políticas declaradas (policy e authorize_if)
  3. Se o ator não satisfaz a política, a ação e negada com Ash.Error.Forbidden

Nas versões afetadas, determinados caminhos de execução - especialmente em ações que encadeiam chamadas a sub-recursos ou que usam o contexto de autorização de forma implicita - não propagavam corretamente o estado de autorização. O resultado e que a verificação era saltada silenciosamente, permitindo acesso não autorizado a dados ou operações protegidas.

CVE-2025-48043 afeta versões de 0.1.1 até 3.6.2 (não incluso). CVE-2025-48044 afeta versões 3.6.3 até 3.7.1 (não incluso). CVE-2025-48042 afeta versões de 0.1.1 até 3.5.39 (não incluso), sendo especificamente categorizado como Exploiting Incorrectly Configured Access Control Security Levels.

Quem foi afetado

Qualquer aplicação Elixir/Phoenix que utilize o ash como camada de recursos e defina políticas de autorização para proteger dados sensiveis pode estar exposta. O impacto prático depende de como a aplicação utiliza o framework:

  • APIs REST/GraphQL: endpoints que dependem do Ash para autorizar leitura ou escrita de registros podem expor dados de outros usuários.
  • Operações administrativas: ações restritas a administradores podem se tornar acessíveis a usuários comuns.
  • Multitenancy: aplicações que isolam dados por tenant usando políticas Ash correm risco de cross-tenant data exposure.

O ecossistema Ash e popular em startups e produtos SaaS construidos com Phoenix LiveView e API do ash-graphql. Embora o número exato de sistemas afetados não seja público, o pacote possui dezenas de milhares de downloads mensais no Hex.pm, o repositório de pacotes Elixir.

Como identificar

Para verificar se sua aplicação está exposta, siga os passos abaixo:

1. Verifique a versão instalada:

# No mix.exs ou mix.lock, localize a linha do ash
grep -E '"ash"' mix.lock

Se a versão for anterior a 3.5.39, 3.6.2 ou 3.7.1 (dependendo da linha de versão que você usa), seu sistema está vulnerável.

2. Audite o uso de políticas:

grep -rn "policy\|authorize_if\|forbid_if" lib/

Recursos com políticas que dependem de contexto de ator ou de propagação de autorização entre recursos são os mais suscetiveis.

3. Análise logs de acesso: Procure por ações bem-sucedidas em endpoints protegidos por usuários que não deveriam ter permissão. Logs de auditoria de banco de dados podem revelar acessos anomalos a registros de outros usuários.

4. Execute testes de autorização: Crie um usuário sem privilegios e tente acessar ações protegidas por política. Se a ação for bem-sucedida sem o ator correto, a vulnerabilidade está presente.

Como se proteger

A mitigação primaria e atualizar o ash para uma versão corrigida. Os mantenedores disponibilizaram patches nas seguintes versões:

  • Para a linha 3.5.x: atualize para 3.5.39 ou superior.
  • Para a linha 3.6.x: atualize para 3.6.2 ou superior.
  • Para a linha 3.7.x: atualize para 3.7.1 ou superior.

Para atualizar via Mix:

# Atualize o ash no mix.exs para a versão corrigida
{:ash, "~> 3.7.1"}

# Atualize as dependências
mix deps.update ash

Após a atualização, execute os testes da sua aplicação para garantir que as políticas continuam funcionando conforme esperado. Em alguns casos, a correção altera o comportamento de autorização - ações que passavam silenciosamente podem começar a lançar Ash.Error.Forbidden.

Medidas complementares enquanto o patch não e aplicado:

  • Adicione camadas adicionais de autorização no nível do controller Phoenix (plug de autenticação manual).
  • Ative rate limiting em endpoints sensiveis para reduzir a janela de exploração.
  • Monitore logs de acesso em tempo real para detectar padrões anomalos.

Comparação com casos anteriores

Vulnerabilidades de autorização incorreta em frameworks de dados não são novidade. Em 2023, o CanCan (Ruby on Rails) teve um problema similar onde ações de mass assignment bypassavam verificações de autorize! em certas configurações. Em 2024, o Laravel Sanctum passou por auditoria após relatos de que middlewares de autorização podiam ser ignorados em rotas com parâmetros opcionais.

O padrão comum nesses casos e a complexidade de propagar estado de autorização atraves de multiplas camadas de abstração. Quanto mais magica o framework faz por você, maior o risco de um caminho de código não esperado pular uma verificação crítica.

O que diferencia o caso do ash-project e a extensão: tres CVEs cobrindo faixas de versão distintas sugerem que a correção foi incompleta nas primeiras tentativas, ou que novos caminhos vulneráveis foram introduzidos em refatorações posteriores. Isso e um sinal de que o projeto pode se beneficiar de um suite de testes de autorização mais abrangente e revisoes de segurança focadas.

Análise técnica

As tres vulnerabilidades pertencem ao CWE-863: Incorrect Authorization, que descreve situações onde o software não verifica ou verifica incorretamente se um ator possui autorização para acessar um recurso.

No contexto do Ash, a autorização funciona por meio de um grafo de políticas avaliado em runtime. Cada ação de um recurso pode ter multiplas políticas com condições compostas. A falha parece estar relacionada a como o Ash propaga o Ash.Query.set_actor/2 ou contexto equivalente atraves de carregamentos relacionados (Ash.load/3), possivelmente permitindo que um subquery seja executado sem o ator configurado, ou com um ator padrão que possui permissões mais amplas.

Sem um PoC público confirmado no momento desta publicação, a exploração exata permanece especulativa. No entanto, o fato de os mantenedores terem emitido patches prioritarios e a classificação como Authentication Bypass indicam severidade alta.

CVSS estimado: Sem score oficial publicado nas fontes consultadas. Pela natureza da falha (bypass de controle de acesso, sem necessidade de privilegios previos em alguns cenários), um CVSS base entre 7.5 e 9.1 seria consistente com vulnerabilidades similares da mesma classe.

Impacto e consequencias

O impacto de um bypass de autorização depende do que os dados protegidos representam. Em aplicações SaaS tipicas construidas com Ash:

  • Exposição de dados de clientes: usuários podem acessar registros de outros tenants, violando acordos de confidencialidade e a LGPD (Lei 13.709/2018) no Brasil.
  • Escalada de privilegios: usuários comuns podem executar ações administrativas (deleção de contas, acesso a paineis internos).
  • Impacto reputacional: a divulgação de uma brecha desse tipo pode gerar perda de confianca de clientes, especialmente em setores regulados como fintech e saude.
  • Responsabilidade juridica: a LGPD prev multas de até 2% do faturamento (limite de R$ 50 milhoes por infração) em casos de vazamento por falha técnica evitavel.

Dicas práticas e boas práticas

Além de aplicar o patch imediatamente, considere as seguintes práticas para fortalecer a segurança de autorização em aplicações Ash:

  • Testes de autorização automatizados: inclua no seu CI testes que verificam que usuários sem permissão recebem Ash.Error.Forbidden em todas as ações protegidas.
  • Principio do mínimo privilegio: use forbid_if always() como política padrão e libere explicitamente apenas o que é necessário.
  • Auditoria de políticas: periodicamente revise os blocos policy de cada recurso com olhos de segurança, não apenas de funcionalidade.
  • Monitoramento de anomalias: integre alertas para ações bem-sucedidas fora do padrão de uso esperado (ex: usuário acessando registro de outro usuário).
  • Dependabot ou mix audit: configure atualizações automáticas de dependências para receber patches de segurança sem delay manual.
  • Revisao de changelogs: acompanhe o CHANGELOG do ash-project e monitore o repositório GitHub por issues com tag security.

Conclusao: o que fazer agora

Se você usa o ash-project em produção, a ação mais urgente e verificar a versão instalada e atualizar para a linha corrigida (3.5.39+, 3.6.2+ ou 3.7.1+). Não espere o próximo ciclo de manutenção planejado - vulnerabilidades de bypass de autenticação possuem alto potencial de exploração assim que são divulgadas publicamente.

Após o patch, execute os testes de autorização existentes e adicione novos casos que cubram os cenários de sub-recurso e carregamento relacional. Documente a correção no seu registro de vulnerabilidades interno e notifique a equipe de segurança.

Por fim, use este incidente como oportunidade para revisar a maturidade do processo de atualização de dependências na sua organização. Ferramentas como mix hex.audit, Dependabot e Snyk podem automatizar a detecção de novas CVEs antes que se tornem um problema ativo em produção.