SCA Deep Dive #1 — Axios (CVE-2025-27152) - Requisições vulneráveis a possível SSRF e vazamento de credenciais via URL absoluta

Em 7 de março de 2025, foi publicada a CVE-2025-27152, denominada axios Requests Vulnerable To Possible SSRF and Credential Leakage via Absolute URL. Trata-se de uma vulnerabilidade de alta gravidade na biblioteca Axios, uma das mais baixadas do mundo, que permitia a um atacante manipular uma requisição HTTP para induzir a aplicação a enviar requisições para um endereço arbitrário. Em determinadas configurações, isso poderia resultar em Server-Side Request Forgery (SSRF), possibilitando o acesso a recursos internos que normalmente não estariam expostos externamente, além do potencial vazamento de credenciais presentes nos cabeçalhos das requisições.

Como a vulnerabilidade funcionava

O problema estava relacionado à forma como o Axios lidava com URLs fornecidas pelo usuário durante a construção de requisições. Em determinadas condições, uma URL absoluta fornecida como entrada podia substituir a URL base definida pela aplicação.

Isso é particularmente relevante em aplicações que utilizam o Axios para acessar APIs externas e incorporam dados controlados pelo usuário na URL de destino. Se esses dados não fossem devidamente validados, um atacante poderia fornecer uma URL especialmente criada e fazer com que o servidor realizasse uma requisição para um destino diferente daquele originalmente esperado pela aplicação.

Cabeçalhos e credenciais

Além do redirecionamento da requisição, havia um segundo fator de risco: determinados cabeçalhos, incluindo credenciais utilizadas pela aplicação, poderiam ser enviados na requisição para o destino controlado pelo atacante. Dessa forma, o problema poderia deixar de ser apenas uma requisição indevida e resultar também na exposição de informações sensíveis.

Por que isso pode resultar em SSRF?

Em um cenário de SSRF, o atacante não realiza diretamente a requisição contra o alvo interno. Em vez disso, ele utiliza o servidor vulnerável como intermediário.

Por exemplo, uma aplicação pode esperar receber uma URL para buscar informações de uma API:

https://api.exemplo.com/users/123

Se a aplicação aceitar uma URL absoluta controlada pelo usuário sem realizar as validações necessárias, o comportamento esperado pode ser alterado. Em vez de acessar apenas o domínio permitido, o servidor pode acabar realizando uma requisição para outro destino.

Isso é especialmente perigoso em ambientes nos quais o servidor possui acesso a serviços internos, endpoints administrativos ou outros recursos que não deveriam estar acessíveis diretamente pela Internet.

Explorando o comportamento

Para entender melhor o problema, imagine uma aplicação que utiliza o Axios para buscar o conteúdo de uma URL fornecida pelo usuário. A aplicação pode definir uma URL base para garantir que as requisições sejam direcionadas para um serviço específico:

const api = axios.create({
    baseURL: "https://api.exemplo.com"
});

Em condições normais, a aplicação espera trabalhar com caminhos relativos:

api.get("/users/123");

Nesse caso, a requisição é direcionada para:

https://api.exemplo.com/users/123

O problema aparece quando uma entrada controlada pelo usuário é interpretada como uma URL absoluta. Em vez de permanecer limitada à URL base configurada pela aplicação, a requisição pode ser direcionada para um domínio diferente.

Em uma aplicação vulnerável, por exemplo, uma entrada como:

https://servidor-controlado-pelo-atacante.example/

poderia fazer com que o Axios realizasse a requisição para esse endereço em vez de utilizar o domínio originalmente definido em baseURL.

Isso se torna ainda mais relevante quando a aplicação adiciona automaticamente cabeçalhos de autenticação às requisições. Nesse cenário, uma requisição que deveria ser enviada exclusivamente para a API confiável poderia acabar sendo direcionada para um servidor externo.

O impacto

O impacto da vulnerabilidade depende de como o Axios é utilizado pela aplicação. O problema não significa que qualquer aplicação que utilize Axios esteja automaticamente vulnerável a SSRF.

O risco surge principalmente quando uma aplicação combina o comportamento afetado com entradas controladas pelo usuário e informações sensíveis adicionadas automaticamente às requisições.

Um cenário particularmente preocupante ocorre quando a aplicação utiliza um token de autenticação em um cabeçalho:

Authorization: Bearer <token>

Se uma requisição puder ser redirecionada para um destino controlado por um atacante e esse cabeçalho for incluído na requisição, o token poderá ser exposto.

Além do possível vazamento de credenciais, a capacidade de fazer o servidor realizar requisições para destinos arbitrários pode permitir acesso indireto a serviços que não estão disponíveis externamente. O impacto real dependerá das permissões e da conectividade disponíveis para o servidor vulnerável.

Versões afetadas do Axios

A CVE-2025-27152 atinge as duas linhas principais do Axios: a série 0.x e a série 1.x.

Na série 0.x, as versões até 0.29.0 estão afetadas. A correção nessa linha chegou na 0.30.0.

Na série 1.x, as versões anteriores à 1.8.2 estão afetadas, incluindo o intervalo de 1.0.0 até 1.7.9. A primeira versão publicada como correção foi a 1.8.2, mas ela cobriu apenas o adaptador HTTP usado no Node.js. Os adaptadores xhr e fetch, usados principalmente no navegador, só passaram a respeitar a restrição na 1.8.3.

Quem ainda está na linha 0.x precisa ir para 0.30.0 ou posterior. Quem está na linha 1.x deve ir para 1.8.3 ou posterior, e não parar na 1.8.2 se a aplicação também dispara requisições via xhr ou fetch.

A correção

A correção desse tipo de problema envolve impedir que uma URL absoluta fornecida como entrada consiga substituir silenciosamente a origem definida pela aplicação.

Além da atualização do Axios para uma versão corrigida, aplicações que recebem URLs ou caminhos controlados pelo usuário devem aplicar validações próprias. É importante definir quais destinos são permitidos e não confiar apenas na existência de uma baseURL para restringir o destino final de uma requisição.

Uma abordagem de defesa em profundidade também pode incluir restrições de rede no ambiente onde a aplicação está sendo executada. Dessa forma, mesmo que uma aplicação apresente uma falha de SSRF, o servidor terá acesso limitado a recursos internos e serviços que não deveriam ser alcançáveis.

Encontre dependências vulneráveis nos seus projetos com a runtz

Escaneie as dependências dos seus projetos agora. Comece em runtz.dev.