Os tokens de acesso OAuth do Cloudreve podem evitar a aplicação do escopo OAuth. Este não parece ser o projeto pretendido. A documentação descreve permissões/scopos do cliente OAuth, a API tem um código de erro de alcance insuficiente, e os comentários do código dizem "RequiredScopes(...)" deve verificar escopos quando um token tem escopos, enquanto pulando verificações apenas para autenticação baseada em sessão não-scoped. No entanto, os tokens de acesso OAuth são emitidos sem a reivindicação OAuth `client_id`. Mais tarde, o verificador JWT carrega apenas escopos no contexto de solicitação quando `clama.ClientID!= ""`. Como o token de acesso OAuth não tem `client_id`, seus escopos não são carregados, e `RequiredScopes(...)` trata o pedido como um token de primeira/ sessões não- abrangido e não verifica o escopo. Como resultado, um token de acesso OAuth de baixo alcance, por exemplo um concedido apenas `openid`, pode chamar APIs que requerem escopos mais elevados, tais como arquivo, compartilhamento, fluxo de trabalho, configuração do usuário, conta WebDAV e escopos potencialmente de administrador quando o usuário autor é um administrador. ## Por que isso parece involuntário. A Cloudreve parece ter um modelo explícito de escopo de OAuth:.
1. Os documentos oficiais descrevem permissões/escópios do cliente OAuth e exigem que o pedido de autorização inclua escopos solicitados. 2. A lista de códigos de erro da API inclui um erro de alcance insuficiente do OAuth. 3. `RequiredScopes(...)' é usado em grupos de API sensíveis, como arquivos, compartilhamentos, fluxos de trabalho, configurações de usuário, dispositivos WebDAV e APIs de administração. 4. O comentário do middleware diz que as verificações de escopo são ignoradas apenas quando o ` hasScopes` é falso, por exemplo, a autenticação baseada em sessão. 5. Clientes OAuth criados durante a migração listam explicitamente escopos como `Files.Write`, `Workflow.Write' e `Shares.Write'. Isto sugere que o projeto pretendido é: - Os símbolos de primeira parte/sexão podem não ser abrangidos e não ser verificados o escopo de OAuth. - Os símbolos de acesso de OAuth devem transportar metadados de escopo e ser verificados em relação a `RequiredScopes(...)'. A implementação atual faz com que os tokens de acesso OAuth caiam na primeira categoria por engano. Na troca de código de autorização OAuth, Cloudreve passa tanto o `ClientID` quanto o `Scopes` para emissão de símbolos: ``` go token, err:= tokenAuth.Issue( c, &auth.IssueTokenArgs{ Usuário: usuário, ClientID: s.ClientID, escopos: authCode.Assuntos, atualização doTTLOverride: reviverTTLOverride, }).
- serviço/oauth/oauth.go. Em Edição(...), o token de acesso inclui escopos, mas não inclui ID do cliente: acessoToken, err:= jwt.NewWithClaims(jwt.SigningMethodHS 256, Reclamações{ Tipo de Token: Tipo de TokenAccess, Reclamações Registradas: jwt.RegistredReclamações{ Assunto: uidEncoded, NotAvante: jwt.NewNumericData(dadadaedição), ExpiraAt: jwt.NewNumericData(acessTokenExpired), }, Escopos: args.Scopes, }).FirmadoString(t.secret) Em contraste, o token de atualização inclui ambos. Âmbitos: args.Scopes, ClientID: args.ClientID, Durante a autenticação do pedido, os escopos só são inseridos no contexto do pedido se o ID do cliente estiver presente:.
se reclama.ClientID!= "" { util.WithValue(c, ScopeContextKey{}, reclama.Aplicações) }. Então o CheckScope(...) ignora a aplicação do escopo se nenhum escopo estiver presente no contexto: hasScopes, tokenScopes:= GetScopes FromContext( c) se! hasScopes { retornar nulo }. O RequiredScopes(...) depende desta verificação: se err:= auth.CheckScope( c, oneedScopes...); err!= null { c. JSON( 200, serializer.Err( c, err)) c. Abort() retorna } - Middleware/auth.go. Grupos de rotas sensíveis protegidos por Áreas RequiredScopes() incluem:.
- Arquivos: Arquivos.Leia / Arquivos.Escrever - Compartilhar: Compartilhar.Leia / Compartilhar.Escrever - Fluxos de trabalho: Fluxo de trabalho.Leia / Fluxo de trabalho.Escrever - Configurações do usuário e informações de segurança - Gerenciamento de dispositivos/contas do WebDAV - Admin APIs: Admin.Leia / Admin.Escrever ## Passos de reprodução. 1. Crie ou use um cliente OAuth com um escopo de baixa prioridade, por exemplo apenas openid. 2. Complete o fluxo de código de autorização OAuth para um usuário normal com: 3. Troque o código de autorização por. POST / api/ v 4 /sexão/oauth/token 4. Decodifica o token de acesso devolvido.
Os metadados token esperados devem preservar o suficiente contexto cliente/scope do OAuth para aplicação posterior. - O token de acesso contém os escopos solicitados. - O token de acesso não contém o client_id. 5. Use o símbolo devolvido como símbolo de portador. Autorização: Portador 6. Chame uma API que requer um escopo não concedido ao aplicativo OAuth, por exemplo um endpoint que requer Arquivos.Leia, Arquivos.Escreva, UserInfo.Escreva, ou DavAccount.Escreva.
- O pedido deve falhar com um erro de alcance insuficiente. - A verificação do escopo é omitida porque nenhum escopo foi inserido no contexto do pedido. - O pedido é processado como aquele usuário. Se o usuário autor for um administrador, o mesmo problema pode afetar as APIs de administradores que exigem Admin.Leia ou Admin. Escreva, porque o pedido ainda é executado como o usuário administrador e a verificação de identidade do administrador pode passar enquanto a verificação de escopo de OAuth é ignorada. Isto não é um bypass de autenticação anônimo. O atacante ainda precisa de um token de acesso OAuth válido para um usuário real.
O impacto é um contorno de consentimento/escópio do OAuth. - Um aplicativo OAuth de terceiros pode solicitar um alcance mínimo como openid. - Após o usuário autorizar, o aplicativo recebe um token de acesso. - Esse token pode ser usado como um token de portador mais amplo para a conta Cloudreve do mesmo usuário, apesar de não ter sido concedido os escopos necessários. Para usuários normais, isto pode permitir o acesso ou modificação de arquivos, compartilhamentos, fluxos de trabalho, configurações de usuário e configurações de conta/dispositivo do WebDAV dependendo das APIs disponíveis. Para usuários administradores, ele pode permitir o acesso à funcionalidade Administrator-scoped sem que o aplicativo OAuth seja concedido Admin. Read ou Admin.Write. 1. Inclua ClientID: args.ClientID nas reivindicações de tokens de acesso ao emitir tokens de acesso OAuth:.
acessoToken, err:= jwt.NewWithClaims(jwt.SigningMethodHS 256, Reclamações{ Tipo de Token: Tipo de TokenAccess, Reclamações Registradas: jwt.RegistradoReclamações{ Assunto: uidEncodeado, Não Antes: jwt.NewNumericData(dada edição), ExpiraEm: jwt.NewNumericData(acessoTokenExpirado), }, Escopos: args.Scopes, ClientID: args.ClientID, }.FirmadoString(t.secret) 2. Considere fazer com que o gerenciamento do escopo não seja fechado para os símbolos OAuth com metadados OAuth malformados ou inconsistentes. 3. Adicione testes de regressão para um token de acesso OAuth concedido apenas openid tentando chamar APIs que requerem: - Arquivos.Leia - Arquivos.Escreva - UserInfo.Escrever - DavAccount.Escrever - Admin.Leia - Admin.Escrever Cada um deve falhar com um erro de alcance insuficiente a menos que o escopo correspondente seja concedido. Registro de aconselhamento: GHSA- vgj 4 - 345 g- jcf 8. Identificadores relacionados: CVE- 2026 - 54560.
Tempo: GitHub Advisory Database publicou este registro em 2026 - 07 - 20 T 21: 15: 20.000 Z e lista a sua última modificação como 2026 - 07 - 20 T 21: 15: 20.000 Z. Severidade: ALTAMENTE. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L. Informações sobre software e versão afetadas: Go pacote github.com/cloudreve/Cloudreve/v 4 — ECOSISTEM: introduzido 4.0.0 - 20260114075425 - bc 6845 bd 742 c, corrigido 4.0.0 - 20260606015557 - ed 20843 dc 3 DF. Classificação e evidência: identificadores de fraqueza CWE- 863. O registro contém 5 suporte de referências nestes tipos: WEB, AVISO, EMBALAGAMENTO.