Sumário Quando o ISR está ativado, o ponto de entrada sem servidor permite que um pedido não autêntico decida qual rota a origem renderiza. A função interna `_isr` lê o parâmetro de consulta `x_astro_path` e reescribe o caminho de solicitação para ele sem qualquer autenticação. Os controles de acesso ao nível de borda só podem ver o caminho `/_isr`, para que não se apliquem à rota que realmente é renderizada. Este é o mesmo problema de assistente confuso que CVE- 2026 - 33768, acessível novamente através do caminho ISR. ## Impacto Isso afeta aplicativos que usam `@ astrojs/vercel` com ` isr: true` e protegem rotas na borda. Duas configurações comuns são afetadas: 1. Regras de caminho ou firewall nega regras configuradas no Vercel (por exemplo, bloqueando `/ admin`). 2. Dividir implantações (`edgeMiddleware: true`) onde a autorização mora no Middleware Astro, uma vez que o Middleware é executado na borda e não na origem.
Um atacante lê qualquer rota GET renderizada solicitando `/_isr?x_astro_path=/the/protected/path`. Não são necessárias credenciais. O conteúdo protegido é produzido por um render de origem fresca, por isso o ataque não depende da resposta ser armazenada primeiro. ## Detalhes `pacotes/integrações/vercel/src/serverless/entrypoint.ts` escolhe o caminho real como este. ```js if (hasValidMiddlewareSecret) { realPath = request.headers.get(ASTRO_PATH_HEADER); // secretamente verificado } se (request.headers.get('x-vercel- isr') === ' 1 ') { realPath = url.searchParams.get(ASTRO_ PATH_ PARAM); // nenhum segredo foi verificado } ```.
O caminho do cabeçalho é portado pelo segredo de cada compilação e está bem. O ramo ISR não é. Dois fatos tornam-no alcançável por qualquer um: 1. A função `_ isr` é publicamente enderecável. 2. Vercel define `x-vercel- isr: 1 ` em solicitações a ele, incluindo solicitações externas diretas, para que o atacante nem sequer precise enviar esse cabeçalho.
Então `GET /_isr?x_astro_path=/admin` configura o caminho interno para `/admin` e o renderiza. A borda viu apenas `/_isr`, que é permitido, então qualquer regra baseada em caminhos em `/ administração ' nunca dispara. Em implantações divididas, o middleware de borda também é executado contra `/_isr`, e a origem não é executada de forma alguma, por isso, o auth baseado no middleware também é pulado. ## Como isso regrediu CVE- 2026 - 33768 foi corrigido em 10.0.2 por commit 335 a 204161 (PR # 15959 ), que requeria o segredo para cada caminho sobrever e removeu a fonte do parâmetro de consulta. Commit aa 266364 fe (PR # 16079, "Fixar o caminho ISR reescrever para prevenir 404 ") trouxe de volta o parâmetro de consulta, guardado apenas pelo cabeçalho `x-vercel- isr`. Esse cabeçalho não é um limite de segurança, por isso a correção foi efectivamente desativada para rotas ISR iniciando em 10.0.3.
Vale a pena notar o contraste: o relatório original tratou o Edge Middleware como a mitigação e analisou o problema para as implantações sem ele. Aqui, para implantações divididas, o Edge Middleware é contornado também, uma vez que o atacante atinge diretamente `/_isr` e o middleware só vê `/_isr` enquanto a origem não executa nenhuma. ## Prova de conceito 1. Crie um aplicativo Astro com ` saída: 'server'' e adaptador `vercel({ ir: true }'. 2. Adicione uma página em `/admin` que retorna conteúdo sensível. 3. Negar `/admin` na borda, por exemplo uma regra de caminho Vercel que retorna 403, ou uma autografia de middleware verificada em uma divisão (`edgeMiddleware: true`) build. 4. Solicite `/ admin`. Está bloqueado ( 403 ). 5. Solicite `/_isr?x_astro_path=/admin`. Ele retorna 200 com o conteúdo do administrador. O cabeçalho de resposta `X- Vercel- Cache: MISS` confirma que foi tornado fresco, não servido a partir de um item de cache existente.
O que não é afetado 1. Intermediário clássico (não dividido). Ele corre dentro da origem contra o caminho reescrito, então ainda se aplica à rota alvo. 2. Diga que mudam os pedidos. Vercel serve funções ISR apenas para GET, e retorna 403 para POST, PUT e DELETE, assim o método de preservação da variante CVE- 2026 - 33768 Não se reproduz aqui. O impacto está limitado à leitura (confidentialidade). 3. Proteção de implantação completa (Vercel SSO ou senha), que também cobre `/_isr`. ## Gravidade Leitura não autenticada de qualquer rota GET que esteja protegida apenas na borda. Nenhum impacto de integridade ou disponibilidade porque o vetor é apenas GET.
Sugerido correção Uma opção seria exigir o segredo novamente para sobreposição do caminho, a forma como PR # 15959 o fiz, assim o ramo ISR para de confiar no cliente fornecido `x_astro_path`. O 404 que RP # 16079 se estava corrigindo, então, precisaria de outra abordagem que não depende da entrada do cliente. Registro de aconselhamento: GHSA-x 27 w- 589 x-frm 2. Identificadores relacionados: CVE- 2026 - 73424.
Tempo: GitHub Advisory Database publicou este registro em 2026 - 07 - 20 T 23: 25: 07.000 Z e lista a sua última modificação como 2026 - 08 - 17 T 17: 12: 10.000 Z. Gravidade: MODERAR. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N.
Informações sobre software e versão afetadas: pacote npm @ astrojs/vercel — ECOSISTEM: introduzido 10.0.3, corrigido 11.0.3. Classificação e evidência: identificadores de fraqueza CWE- 441, CWE- 862. O registro contém 8 suporte de referências nestes tipos: WEB, PACKAGE.