O que é o CVE-2026-90486

O CVE-2026-90486 descreve uma vulnerabilidade de server-side request forgery, conhecida pela sigla SSRF, no projeto openstatusHQ openstatus. O registro consultado informa que o problema afeta o código até o commit f04c827112f30a11d571ebdad3892826034d6265 e associa a falha ao arquivo apps/status-page/src/lib/proxy/resolve-custom-domain-rewrite.ts. A descrição também indica que a manipulação de uma funcionalidade desse arquivo pode levar a SSRF.

O OpenStatus é uma plataforma de código aberto para páginas de status e monitoramento de disponibilidade. A parte relacionada a domínios personalizados precisa interpretar uma solicitação recebida, resolver informações de domínio e encaminhar o visitante ou o serviço para o destino adequado. Quando esse fluxo permite que uma entrada controlada externamente influencie uma requisição feita pelo próprio servidor, a superfície de ataque muda de forma importante. O servidor deixa de ser apenas um receptor de dados e passa a funcionar como possível intermediário para alcançar outros destinos.

O registro lista CVSS 6.3. Esse número ajuda a priorizar a investigação, mas não substitui a análise do ambiente. O dado coletado não informa uma versão corrigida ou um commit de correção. Por isso, administradores não devem inventar um número de versão seguro. É necessário comparar o commit usado na instalação com a orientação mais recente do projeto e do registro da vulnerabilidade.

Como funciona o SSRF neste contexto

Em uma requisição normal, o navegador ou um cliente de API fala diretamente com o serviço que deseja acessar. Em um cenário de SSRF, um atacante fornece ou influencia um endereço que será usado pelo servidor para iniciar uma conexão. O servidor pode ter acesso a redes que não são alcançáveis pela internet, como interfaces administrativas, bancos de dados, serviços internos, endpoints de descoberta de nuvem ou aplicações em uma rede privada.

O risco não depende apenas de o servidor aceitar uma URL completa. A vulnerabilidade pode surgir quando a aplicação monta uma URL a partir de um domínio personalizado, segue redirecionamentos, resolve nomes DNS ou reescreve caminhos sem confirmar que o destino continua dentro da política permitida. Uma validação que verifica somente o texto inicial pode ser enganada por mudanças de resolução, formatos alternativos de endereço, redirecionamentos ou diferenças entre o nome validado e o endereço efetivamente conectado.

O ponto mais importante é separar duas decisões. A primeira é saber se um domínio pode ser cadastrado ou associado a uma página. A segunda é saber para quais endereços o servidor está autorizado a fazer conexões. Misturar essas decisões costuma criar uma proteção frágil. Mesmo que o domínio personalizado seja legítimo, a resolução dele pode mudar depois, apontar para um endereço privado ou redirecionar para outro host. A política de saída precisa ser aplicada no momento da conexão, com validação de DNS, IP, porta, protocolo e redirecionamento.

O nome do arquivo citado no registro sugere que o fluxo de reescrita de domínio personalizado merece atenção especial. Isso é uma inferência sobre a área de código, não uma descrição de uma prova de conceito pública. O registro consultado não confirma exploração ativa nem fornece neste material uma cadeia de ataque completa. A defesa deve tratar a entrada como não confiável e evitar testes ofensivos em produção.

Quem foi afetado e para que serve o OpenStatus

O escopo indicado é o projeto openstatusHQ openstatus em instalações que utilizam código até o commit informado. A condição prática depende de como a implantação expõe a funcionalidade de status page, proxy ou domínio personalizado. Uma cópia local que não habilita esse fluxo pode ter uma exposição diferente de uma instalação que recebe domínios de terceiros e executa reescritas no servidor.

O OpenStatus pode ser usado para acompanhar disponibilidade, latência e incidentes de aplicações. Em uma página de status com domínio personalizado, o serviço normalmente precisa responder pelo host solicitado, localizar a configuração correspondente e renderizar ou encaminhar o conteúdo. Essa conveniência é valiosa para equipes que querem uma identidade própria, mas transforma a entrada do host em um componente de segurança. Cada domínio cadastrado precisa ser tratado como dado potencialmente malicioso até passar por verificação.

Não é correto concluir que todo usuário da plataforma foi comprometido ou que toda instalação está vulnerável da mesma forma. Também não há, nos dados consultados para este artigo, uma lista de vítimas ou evidência de abuso em instalações específicas. O risco é técnico e depende da versão, da configuração, das regras de rede e da forma como a aplicação realiza a requisição.

Como identificar e detectar tentativas

Comece pelo inventário. Registre o commit ou a versão efetivamente executada, o modo de instalação, os componentes publicados, os hosts aceitos como domínios personalizados e as regras de saída do servidor. Não confie apenas no arquivo de configuração ou no manifesto de implantação. Compare o artefato que está em execução com o repositório usado para construir a imagem ou o pacote.

Na aplicação, procure eventos que mostrem criação, alteração, validação e uso de domínios personalizados. Correlacione o usuário responsável, o host informado, o endereço resolvido, a porta, o protocolo, os redirecionamentos e o resultado da requisição. Um mesmo domínio que resolve para redes públicas e privadas em intervalos curtos merece revisão. Mudanças frequentes de DNS, uso de endereços literais, portas incomuns e destinos de loopback também são sinais úteis.

Nos controles de rede, revise logs de firewall, proxy de saída, DNS recursivo e serviço de nuvem. Busque conexões originadas pelo processo do OpenStatus para 127.0.0.1, ::1, faixas privadas, faixas de link local, endereços de metadados de provedores, portas de administração e hosts que não fazem parte da arquitetura. O endereço de destino não deve ser o único indicador. Observe também respostas inesperadas, sequências de redirecionamento, falhas repetidas de resolução e grande quantidade de requisições para hosts recém cadastrados.

Preserve evidências antes de alterar o ambiente. Exporte os eventos relevantes, marque o intervalo de tempo, faça uma cópia segura dos arquivos de configuração e registre o hash da imagem ou do binário em execução. Evite consultar destinos internos como teste de confirmação. A detecção deve usar telemetria e um ambiente isolado, sem enviar requisições que possam acessar dados de terceiros.

Como se proteger e mitigar

A primeira medida é confirmar o alcance do CVE. Identifique se o código executado está em um ponto anterior ou igual ao commit informado no registro e acompanhe o repositório oficial em busca da correção. Se o recurso de domínio personalizado não for indispensável, desabilite-o temporariamente ou limite seu uso a uma lista pequena de hosts verificados. Essa decisão reduz a superfície enquanto a atualização é avaliada.

Implemente uma allowlist de esquemas, portas e destinos. Para esse tipo de fluxo, HTTPS pode ser o único protocolo necessário. Mesmo assim, HTTPS sozinho não impede SSRF. A aplicação deve rejeitar loopback, multicast, link local, redes privadas e endereços de metadados quando esses destinos não forem parte explícita da arquitetura. A validação deve ocorrer depois da resolução DNS e novamente antes de conectar, porque o resultado pode mudar entre a checagem e a requisição.

Desative ou controle redirecionamentos automáticos. Se o produto precisar segui-los, valide cada salto com a mesma política aplicada ao destino original. Bloqueie mudanças de esquema, porta e rede que não tenham sido autorizadas. Também é importante normalizar endereços IPv4 e IPv6, tratar representações equivalentes e não aceitar uma validação baseada somente em prefixos de texto.

Use isolamento de rede como segunda barreira. O processo que renderiza ou encaminha páginas de status deve ter apenas o acesso de saída necessário para o funcionamento do produto. Regras de firewall e proxy devem impedir conexões para serviços internos, painéis administrativos, bancos de dados e endpoints de metadados. Credenciais de nuvem não devem ficar disponíveis para um processo que pode ser induzido a buscar uma URL controlada por terceiros. A aplicação também deve usar uma conta de sistema com o menor privilégio possível.

Depois de atualizar, valide o comportamento em laboratório com domínios controlados pela equipe. Teste resolução para endereços públicos permitidos, redirecionamento para uma rede bloqueada, mudança de DNS, IPv6 e falhas de timeout. Registre o resultado e mantenha o recurso sob observação. Uma atualização sem revisão de egress, logs e permissões deixa uma defesa incompleta.

Comparação com casos e alternativas anteriores

SSRF aparece em muitos tipos de produto porque aplicações modernas fazem requisições em nome do usuário. Webhooks, importadores de imagens, validadores de URL, pré-visualizações, crawlers e integrações com provedores externos têm o mesmo padrão de risco. A diferença deste caso é a proximidade com a resolução de domínios personalizados e com o componente de proxy indicado no registro. A comparação útil não é procurar um caso idêntico, mas reconhecer o mesmo fluxo de entrada não confiável seguido por conexão privilegiada.

Uma alternativa arquitetural mais segura é separar o recebimento do domínio da busca de conteúdo. O cadastro pode verificar a posse por DNS ou por um arquivo específico, enquanto o tráfego de visitantes passa por um proxy dedicado com regras próprias. Outra alternativa é manter a página de status em uma camada estática ou em uma rede isolada, quando os requisitos não exigirem renderização dinâmica. Essas opções reduzem a quantidade de lógica que precisa fazer conexões externas durante uma requisição.

Bloquear somente nomes conhecidos de serviços internos é uma defesa parcial. Ameaças desse tipo evoluem por resolução DNS, IPv6, redirecionamentos e novas faixas de rede. A política deve ser baseada em identidade de destino, rede permitida e menor privilégio, com monitoramento contínuo.

Análise técnica

Os fatos específicos disponíveis são objetivos: o identificador é CVE-2026-90486, o produto é openstatusHQ openstatus, o alcance informado termina no commit f04c827112f30a11d571ebdad3892826034d6265, o arquivo citado é apps/status-page/src/lib/proxy/resolve-custom-domain-rewrite.ts, a consequência descrita é SSRF e o score listado é 6.3. Esses pontos devem ser reproduzidos exatamente em inventários e relatórios. O registro não deve ser ampliado com uma versão corrigida, uma PoC ou uma exploração confirmada que não esteja na fonte.

Para revisar o código, siga a entrada recebida desde o controlador ou rota até a função de reescrita. Documente onde o host é extraído, onde ocorre a resolução DNS, como o endereço é convertido em IP, se redirecionamentos são seguidos e quais portas são permitidas. Verifique se a conexão é feita pelo mesmo endereço que foi validado. Também procure chamadas indiretas em bibliotecas HTTP, clientes de imagem, renderizadores ou adaptadores de status page.

Os testes de segurança devem cobrir condições de corrida entre DNS e conexão, respostas 3xx, nomes com múltiplos registros, IPv4 mapeado em IPv6, portas não padrão, timeouts e erros de resolução. O resultado esperado é uma falha segura, sem acesso ao destino proibido e sem expor detalhes internos na resposta ao cliente. Os logs podem guardar informação suficiente para investigação, mas não devem devolver credenciais, tokens ou conteúdo de serviços internos.

Uma revisão completa também compara o código produzido com o commit de origem e com o patch oficial, quando ele estiver disponível. Dependências transientes precisam ser verificadas porque a função vulnerável pode chamar um cliente HTTP ou um resolvedor que introduz comportamento adicional. O objetivo é entender o caminho real em produção, não apenas marcar o identificador como corrigido em uma planilha.

Impacto e consequências

O impacto de SSRF varia conforme a posição do servidor na rede. Em um ambiente bem segmentado, uma tentativa pode resultar somente em erro e gerar um alerta. Em uma rede ampla, o mesmo fluxo pode permitir reconhecimento de serviços, acesso a painéis internos, leitura de respostas que deveriam ser privadas ou abuso de credenciais disponíveis para o processo. A consequência pode atingir confidencialidade, integridade e disponibilidade, mesmo quando o produto em si é apenas uma página de status.

Há também efeitos operacionais. Requisições abusivas podem consumir conexões, aumentar latência, gerar custos de rede ou fazer o serviço participar involuntariamente de chamadas contra terceiros. Logs insuficientes dificultam distinguir um domínio legítimo de um host usado como intermediário. Em contextos regulados, uma resposta interna contendo dados pessoais ou segredos pode criar obrigação adicional de investigação e comunicação.

O score 6.3 ajuda a indicar prioridade, mas a prioridade real deve considerar exposição pública, privilégios do processo, conectividade interna e dados acessíveis. Uma instalação pública com amplo egress pode exigir contenção imediata, enquanto uma instância isolada pode permitir uma janela curta para atualização planejada.

Dicas práticas e boas práticas

Faça uma revisão curta e repetível. Primeiro, confirme o commit em execução e o uso de domínios personalizados. Segundo, desative o recurso se ele não for essencial. Terceiro, limite egress no firewall ou proxy. Quarto, implemente allowlist de protocolo, porta e rede. Quinto, valide o endereço depois do DNS e em cada redirecionamento. Sexto, ative logs com correlação de requisição, usuário, host e destino. Sétimo, monitore mudanças de DNS e conexões para faixas internas.

Mantenha o painel administrativo separado do serviço público. Não exponha o socket de Docker, bancos de dados, interfaces de gerenciamento ou endpoints de metadados ao processo que atende páginas. Use containers ou máquinas virtuais com permissões mínimas e sem credenciais de nuvem desnecessárias. Se a plataforma precisar de acesso externo, prefira um proxy de saída que aplique regras centralizadas e registre o destino final.

Inclua SSRF no ciclo de desenvolvimento. Toda função que recebe URL, domínio, webhook ou host personalizado deve ter revisão de ameaça, testes unitários de normalização, testes de integração de egress e um caso de redirecionamento. O pipeline deve detectar mudanças na biblioteca HTTP e exigir revisão quando a lógica de resolução for alterada. Documente a decisão de segurança para que uma futura melhoria de custom domain não remova a barreira sem perceber.

Para resposta a incidente, estabeleça critérios claros. Se houver conexão confirmada a um serviço interno, preserve logs, bloqueie o caminho vulnerável, rotacione credenciais potencialmente acessíveis e revise o alcance da rede. Não apague evidências nem faça varreduras agressivas. Depois da contenção, atualize o componente, valide os controles e procure requisições semelhantes no período anterior.

Conclusão: o que fazer agora

O CVE-2026-90486 merece uma revisão objetiva em qualquer instalação do OpenStatus que utilize domínios personalizados ou o fluxo de proxy relacionado. O registro informa SSRF até um commit específico, aponta o arquivo técnico e lista score 6.3. A ação imediata é identificar o código em execução, acompanhar a correção oficial, reduzir a exposição e impedir que o processo alcance redes internas.

Não trate um domínio verificado como destino automaticamente confiável. Valide cada conexão, bloqueie egress desnecessário, limite privilégios e mantenha telemetria suficiente para investigar. Enquanto a versão corrigida não estiver confirmada no ambiente, o recurso deve permanecer restrito ou desativado conforme o risco. Segurança aqui depende da combinação entre atualização, arquitetura de rede e observabilidade.