### Resumo A página de autorização OIDC na frente do bolso-id redireciona o navegador para um URL controlado pelo atacante sem consultar a lista de allow redirect_uri backend quando o pedido usa prompt=nem. Um atacante que conhece um cliente_id válido pode criar um link /autorizar que envia uma vítima (ou o navegador de uma vítima fazendo uma re- auth silenciosa) para qualquer URL externa de https, permitindo contrabando de resposta de phishing e OAuth. A validação de lista de permissões que protege o fluxo normal autenticado é evitada porque este caminho é inteiramente manipulado do lado do cliente. ### Detalhes Para um pedido de autorização da OIDC com prompt=none, o SvelteKit frontend curta-circuitos o fluxo antes que o backend valide o redirect_uri contra a lista de chamadas registradas do cliente. Arquivo: frontend/src/routes/authorize/+page.ts (linha 14 ) analisa o parâmetro de consulta redirect_uri bruto da URL entrante.
Arquivo: frontend/src/routes/authorize/+page.svelte - in onMount(), quando o pedido carrega prompt=nem e o usuário não pode ser autorizado silenciosamente (por exemplo, o visitante não está conectado, por isso o login_required deve ser devolvido), a página compila a URL de chamadas de volta a partir do redirect_uri bruto e executa: window.location.href = `${callbackURL}?error=login_required...`. O callbackURL é tirado diretamente do redirection_uri fornecido pelo usuário. O único filtro aplicado é um esquema de verificação que bloqueia o javascript: e os dados: URLs; qualquer http: ou https: origem passa através. O validador de listas de permissão do backend GetCallbackURLFromList (que o caminho de código autenticado usa para confirmar que o redirect_uri corresponde a um dos URLs de chamadas registradas do cliente) nunca é invocado neste ramo. Isto significa que a lista de allow- list de redirection_uri por cliente, o controle central que torna redirection_ uri seguro no OAuth/ OIDC, não é executado para o caminho prompt= nenhum erro de retorno. Um client_id não é um segredo: os metadados do cliente são rastreáveis no /api/oidc/clients/:id/meta, e os client_ids aparecem nos links de autorização de qualquer integração.
Confirmação de que o bypass é puramente frontal: um POST não autenticado para o backend /api/oidc/autorize retorna corretamente 401 ({"erro":"Você não está conectado"), então o backend nunca autoriza o pedido. O redirecionamento acontece no navegador, pois o +page.svelte emite window.location.href antes/sem uma autorização de backend bem- sucedida. Existe uma segunda variante para uma vítima autenticada: quando prompt= ninguém é combinado com uma primeira autorização (ainda não consentida) de um cliente, o mesmo caminho do lado do cliente pode ser alcançado.
Contraste: o fluxo interativo padrão (sem prompt=ninguém) posta para o backend, que valida redirect_ uri contra a lista registrada antes de devolver uma chamada de volta. O defeito é específico para o cliente- lado prompt= nenhum curto-circuito. ### Prerequisitos do PoC: uma instância de sky-id em execução, um cliente registrado da OIDC cujo cliente_id é conhecido pelo atacante (obtêm- se do /api/ oidc/clients/:id/ meta ou qualquer integração existente), e uma vítima cujo navegador abra o link (a vítima não precisa ser logada para o branch login_required).
1. O atacante constrói um URL de autorização apontando para o id do bolso da vítima, fornecendo um redirect_uri externo e prompt=none: 2. A vítima abre o link. A frente autoriza cargas de página, determina que o auth silencioso não pode ser bem sucedido (login_ required), e executa:.
window.location.href = ". 3. O navegador é redirecionado para Resultado esperado em uma compilação fixa: a página recusaria o redirecionamento porque redirection_ uri não corresponde à lista de chamadas registradas do cliente e faria um erro no lugar em vez de navegar fora do origen. Nível de validação: confirmação de nível de código no fc commit 42 f 62. Este é um redirecionamento do browser window.location.href, por isso não é reprodutível com o curl; o backend foi confirmado para rejeitar o pedido não autenticado ( 401 ) enquanto a frente executa a navegação independentemente. Notas de evidências guardadas nas capturas de tela/ 001 _open_redirect_evidence.txt.
### Impacto Atacador não autenticado, interação vítima necessária (clique ou seja redirecionado silenciosamente). O domínio de sky- id confiável é usado para rebotar uma vítima para um site externo arbitrário, o que é eficaz para o phishing credencial (o usuário confia na origem do IdP no link inicial) e para vazar parâmetros de erro/estatuação do OIDC para um endpoint do atacante. O impacto da integridade é limitado ao redirecionamento; nenhuma perda de confidencialidade ou disponibilidade do próprio sky-id. Nota: uma RP abandonada (# 1450 ) abordou um problema relacionado com o protocolo- URL em um caminho diferente do e- mail- redirecionado, mas não foi fundido e não cobre este caminho de página de autorização. Registro de aconselhamento: GHSA- 2 Wvm- 8 mvp- 22 qv. Identificadores relacionados: CVE- 2026 - 55834.
Tempo: GitHub Advisory Database publicou este registro em 2026 - 08 - 28 T 16: 28: 20.000 Z e lista a sua última modificação como 2026 - 08 - 28 T 16: 28: 20.000 Z. Gravidade: MODERAR. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N.
Software afetado e informações de versão: Vá o pacote github.com/pocket-id/pocket-id/backend — ECOSISTEM: introduzido 2.6.0, corrigido 2.9.0. Classificação e evidência: identificadores de fraqueza CWE- 601. O registro contém 4 suporte de referências nestes tipos: WEB, PACKAGE.