Pizzastev3

As rotas de tokens de acesso pessoal auto-registradas do Laravel Passport (GET, POST, DELETE '/oauth/personal-access-tokens*') estão expostas utilizando apenas os middlewares 'web' e 'auth:web'. Isso ignora a trava de permissão `self.api` que é normalmente aplicada em outros endpoints de token, como '/account/api' e '/api/v1/account/personal-access-tokens'. Consequentemente, qualquer usuário com uma sessão web válida e um token CSRF correspondente pode enviar uma requisição POST para '/oauth/personal-access-tokens' e gerar um token bearer de longa duração para sua própria conta, mesmo quando um administrador negou a permissão `self.api`. Embora o token emitido ainda esteja sujeito às políticas de autorização existentes e não represente uma escalada de privilégios, ele anula o controle administrativo destinado a bloquear o acesso via API ou scripts no nível de permissão do próprio usuário.

Existe uma falha de bypass de autorização em componentes Livewire que aplicam a autorização apenas no nível da rota, e não nos métodos de ciclo de vida do componente. Um invasor autenticado pode repetir snapshots de componentes assinados através do endpoint 'POST /livewire/update' para invocar métodos protegidos. Isso permite a escalada de privilégios, possibilitando a criação de clientes OAuth, a emissão de tokens de acesso pessoal e o acesso a dados administrativos sensíveis.

Usuários autenticados podem ignorar restrições administrativas para criar solicitações de checkout para modelos de ativos que não estão marcados como solicitáveis. Isso ocorre porque a aplicação falha ao validar a flag requestable ao processar solicitações através do endpoint 'POST /account/request/asset model/{modelId}'.

O controle de acesso insuficiente nas rotas de gerenciamento de clientes OAuth do Laravel Passport permite que qualquer usuário autenticado registre clientes OAuth usando URIs de redirecionamento controladas por um invasor. Isso pode levar a um cenário onde administradores são enganados ao aprovar telas de consentimento, permitindo a troca de códigos de autorização por tokens bearer. Esses tokens podem herdar permissões completas de API administrativa com um período de validade de até 40 anos.

Existe uma condição de corrida (race condition) nos caminhos de checkout de ativos. As funções `ApiAssetsController::checkout()` e `AssetsAssetCheckoutController::store()` chamam `Asset::availableForCheckout()` fora do caminho de mutação e, posteriormente, invocam `Asset::checkOut()` sem implementar um bloqueio de linha (row lock) ou re-verificar a disponibilidade. Consequentemente, duas solicitações de checkout simultâneas para o mesmo ativo disponível podem ser processadas como bem-sucedidas. Isso resulta em linhas de histórico de checkout duplicadas, um `checkout counter` duplicado e dois eventos `CheckoutableCheckedOut` para um ativo de atribuição única, corrompendo a trilha de auditoria e os relatórios de utilização/reconciliação. O valor final de `assigned to` permanece singular, mantendo a atribuição visível intacta. A exploração requer uma sessão autenticada com a permissão `assets.checkout` ou privilégios de superusuário, combinada com um tempo de concorrência preciso.

Um problema de cálculo incorreto no processamento de solicitações de checkout permite que usuários autenticados corrompam o `assets.requests counter`. Isso ocorre quando os usuários enviam solicitações de checkout duplicadas ou chamam repetidamente endpoints de cancelamento sem possuir solicitações ativas. Tais ações podem inflar o contador ou torná-lo negativo, resultando em uma representação incorreta da demanda pendente na fila do administrador.

Atacantes autenticados podem recuperar códigos de barras e enumerar etiquetas de ativos entre locatários, incluindo ativos excluídos logicamente e de outras empresas. Isso ocorre porque a aplicação falha em impor a autorização de visualização de ativos no endpoint 'GET /hardware/{asset}/barcode' ao processar a variável `asset`.

Usuários autenticados podem causar a negação de serviço ao enviar entradas ilimitadas através do campo `note` no endpoint 'POST /account/accept/{acceptance}'. Isso ocorre porque a aplicação falha ao validar o comprimento da entrada antes que ela chegue ao processo de renderização síncrona do CommonMark, que é um sistema para converter texto markdown em HTML. Valores extensos no campo `note` podem esgotar os recursos de CPU do worker PHP durante o pipeline de processamento de markdown.