Tonghuaroot

Usuários autenticados com acesso de escrita em notas de documentos podem realizar um ataque de cross-site scripting armazenado através do endpoint 'interface/forms/eye mag/report.php'. Ao adicionar notas de documentos não escapadas, um invasor pode armazenar JavaScript malicioso em uma nota de documento de retina. Esse script é executado quando os clínicos geram o relatório do paciente de Exame Ocular, o que pode levar à exposição de cookies de sessão.

O guardião de URL de saída não reconhece endereços IPv4 incorporados em prefixos NAT64, que são usados para permitir que clientes apenas IPv6 se comuniquem com servidores apenas IPv4. Um usuário autenticado com privilégios de gerenciamento de conexão pode fornecer um nome de host ou redirecionamento que resolve para um endereço NAT64 contendo um destino IPv4 privado ou local. Como a política trata incorretamente o endereço NAT64 como público, um gateway NAT64 o traduz para o endereço IPv4 interno após a validação. Isso permite que um invasor leia respostas de metadados de nuvem em 169.254.169.254 e outros hosts e portas IPv4 internos acessíveis via gateway. O problema afeta as solicitações de saída de Conexão de Dados de API roteadas através de `server/modules/outboundTargetPolicy.js` em ambientes que utilizam um caminho de implantação NAT64/DNS64.

Existe um problema onde a função `isPublicIp()` em `AppServicesTraitsValidatesUrls` não reconhece os prefixos NAT64 64:ff9b::/96 e 64:ff9b:1::/48. NAT64 é um mecanismo que permite que clientes apenas IPv6 se comuniquem com servidores apenas IPv4. Consequentemente, um parâmetro de imagem de URI `otpauth` pode conter um literal IPv6 ou um endereço sintetizado por DNS64 cujo alvo IPv4 incorporado seja privado, link-local, loopback ou metadados de nuvem. Em implantações com a busca de imagens habilitada e um caminho de tradução NAT64 para o alvo IPv4 interno, um titular de conta ou um invasor externo pode enviar uma URI manipulada ou um payload de migração. A função `buildFromRemoteImage()` no `IconService` então emite um HTTP GET para o alvo incorporado, permitindo a recuperação de respostas em formato de imagem ou a sondagem cega de outros endpoints.

A lista de bloqueio de validação SQL do PostgreSQL da ferramenta de consulta de IA não inclui funções de sistema de arquivos do PostgreSQL irmãs e não corresponde a formas de identificadores entre aspas duplas de funções negadas. Isso permite que um Proprietário ou Administrador de equipe com uma conexão PostgreSQL habilitada para IA ignore as expressões regulares da lista de negação. Se a função do banco de dados tiver permissões para chamar funções de arquivo do servidor, como um superusuário do PostgreSQL ou a função `pg read server files`, eles podem resolver caminhos absolutos para arquivos legíveis pelo usuário do SO do PostgreSQL. Não superusuários estão limitados ao escopo relativo ao PGDATA. Este problema requer que os recursos de IA estejam habilitados e que o usuário possua privilégios elevados.

Um usuário não administrador autenticado com privilégios `run events`, `create events` ou `edit events` pode fornecer chaves não declaradas em parâmetros de evento através dos endpoints 'api create event', 'api update event' ou 'api run event'. O sistema valida o objeto de parâmetro sem restringir suas chaves e, posteriormente, converte essas chaves para maiúsculas e as aplica ao ambiente do processo filho. Se uma chave coincidir com uma variável de ambiente sensível a segurança, ela pode substituir o contexto de execução do plugin, podendo causar escalonamento de privilégios, execução de código arbitrário, acesso a dados ou interrupção do serviço.

Usuários de estação com permissão de WebHooks podem ignorar a proteção UserUrlFilter por meio dos conectores Mastodon, Telegram, GroupMe e RadioReg. Ao definir as variáveis `instance url`, `api` ou `webhookurl` para endereços internos e acionar o endpoint de teste de webhook, um invasor pode realizar um server-side request forgery (SSRF) para acessar serviços de loopback, rede privada ou metadados de nuvem. SSRF é uma falha que permite que um invasor induza a aplicação do lado do servidor a fazer requisições para um local não pretendido.

Existe um problema na verificação `is private ip` do `FilteringResolver` que falha ao desempacotar endereços IPv6 NAT64, 6to4 e Teredo. Usuários autenticados podem explorar isso disparando requisições HTTP externas via funções http do SurrealQL usando endereços de transição que incorporam alvos IPv4 privados. Isso permite o acesso ao localhost, serviços internos ou endpoints de metadados de nuvem. Server-side request forgery é uma falha que permite que um invasor induza a aplicação do lado do servidor a fazer requisições para um local não pretendido.

Em `internal/telegram/bot.go`, os sites de upload do Telegram concatenam nomes de arquivos de documentos fornecidos pelo usuário em um caminho de destino sem a sanitização adequada. Como o `path.Join` colapsa a travessia de diretórios pai, um usuário remoto do Telegram pode gravar arquivos fora do diretório `uploads/` dentro do espaço de trabalho persistente do agente montado em `/workspace/agent`. Quando a configuração `allow from: []` é utilizada, todos os remetentes são permitidos por padrão, não exigindo autenticação. Isso permite que um invasor sobrescreva ou crie arquivos como `CLAUDE.md`, instruções, habilidades, hooks ou arquivos de configuração, resultando em injeção de instruções armazenadas. O escopo desta gravação arbitrária é limitado ao volume do espaço de trabalho persistente do agente.

Um usuário autenticado pode disparar requisições do lado do servidor para loopback interno, redes privadas e serviços de metadados de nuvem. Isso ocorre quando o sistema processa um feed RSS controlado por um invasor através do endpoint 'POST /api/data/add podcast'. As funções `get podcast values` e `add episodes` em `rust-api/src/database.rs` armazenam a `<enclosure url>` em `Episodes.episodeurl` sem validar o host ou IP de destino. Posteriormente, o endpoint 'POST /api/data/download podcast' aciona `spawn download podcast episode` e `download episode and wait()` em `rust-api/src/services/tasks.rs`, que realiza uma requisição GET para a URL armazenada. Além disso, a função `estimate duration from audio url async()` em `rust-api/src/database.rs` envia uma requisição HEAD não validada durante a adição ou atualização do feed. Como o redirecionamento padrão está habilitado, URLs externas podem redirecionar para alvos internos, permitindo a enumeração de serviços internos, a divulgação de dados confidenciais e o possível roubo de credenciais de metadados.

Um usuário não autenticado pode causar uma Negação de Serviço (DoS) enviando uma requisição HTTP especialmente manipulada. O `LanguageMiddleware` (registrado como um middleware global do gin) processa o cabeçalho `Accept-Language` usando `language.ParseAcceptLanguage` sem impor filtros de tamanho ou de caracteres. Embora exista uma proteção para limitar o número de caracteres `-`, ela não considera os caracteres ` `, que o scanner interno converte para `-` antes do processamento. Um invasor pode burlar essa proteção usando separadores ` ` em uma lista longa de tags de idioma malformadas, desencadeando um comportamento de tempo quadrático no parser. Por exemplo, um payload de 256 KiB pode consumir aproximadamente 27 segundos de CPU do servidor, e um payload de 1 MiB pode exceder 120 segundos. Isso permite que um único invasor com largura de banda limitada trave os núcleos de CPU do servidor indefinidamente. O problema é amplificado pela função `GetLanguagePreference()` e pela chamada `resource.CheckErr()`, que formata toda a entrada maliciosa em uma linha de log quando ocorre uma falha.

A função `JaegerPropagator.extract()` no `opentelemetry-propagator-jaeger` processa valores de bagagem `uberctx-*` recebidos sem impor limites de entrada, bytes por entrada ou bytes totais. Quando um transportador não confiável fornece valores numerosos ou excessivamente grandes, isso pode levar ao uso excessivo de CPU e alocações temporárias de heap. Isso pode resultar em uma negação de serviço se os limites do nível de transporte não restringirem a entrada. O risco é maior para transportes não HTTP, implementações personalizadas de `TextMapGetter` ou ambientes onde os limites de cabeçalho do servidor e do gateway foram aumentados ou desativados.

O `admissionHandler` em `webhook/admission.go` decodifica um AdmissionReview fornecido por um invasor usando `json.NewDecoder(io.TeeReader(r.Body, &bodyBuffer))` dentro de um `http.HandlerFunc` sem implementar um `http.MaxBytesReader` ou um limite de tamanho de corpo similar. Um cliente de rede de pod pode enviar uma requisição POST excessivamente grande para um webhook de admissão, fazendo com que o decodificador e o `bodyBuffer` mantenham cópias amplificadas da requisição. Isso pode resultar no esgotamento da memória do pod controlador e no seu encerramento por OOM-killed (Out-Of-Memory killed), que é um estado onde o sistema operacional encerra um processo por ter consumido muita RAM. Consumidores downstream que utilizam o servidor de webhook compartilhado, como Knative, Tekton, KEDA, Sigstore policy-controller e Kpack, herdam esse comportamento. Dependendo da configuração da `failurePolicy`, isso pode interromper a admissão se configurada como `Fail` ou tornar o webhook afetado indisponível se configurada como `Ignore`.

Um problema de exaustão de recursos permite que clientes de API ignorem o limite de contagem de quadros de video/jpeg. Ao sobrescrever a variável `num frames` através de `media io kwargs`, um invasor pode definir `num frames` como -1 ao fornecer um vídeo inline grande. Isso faz com que a função `VideoMediaIO.load base64()` decodifique todos os quadros, resultando em exaustão de memória e no travamento do frontend da API.

Authlib é uma biblioteca Python utilizada para construir servidores OAuth e OpenID Connect. A função `OctKey.import key()` e o caminho de assinatura e verificação HMAC aceitam material de chave de comprimento zero. Se a busca de segredo de uma aplicação retornar uma string vazia ou bytes vazios, um invasor remoto pode computar assinaturas determinísticas HS256, HS384 ou HS512 para reivindicações de token arbitrárias, fazendo com que a biblioteca trate o token como autêntico.

Uma falha de autenticação ausente existe para uma função crítica, que pode permitir a execução remota de código e a travessia de caminho não autenticada no RPC legacy pipe sendFile.

Ocorre uma leitura fora dos limites do heap na função `smb2 decode file all info()`. Este problema permite que um servidor SMB malicioso ou um invasor realizando um ataque de man-in-the-middle em sessões não assinadas cause a falha do cliente ao enviar uma resposta FileAllInformation manipulada com a variável `FileNameLength` não verificada durante chamadas `smb2 stat` ou `smb2 fstat`.

Um problema de sequestro de conta existe no fluxo de redefinição de senha do cliente no endpoint 'system/controllers/forgot.php'. Atacantes não autenticados que conheçam o nome de usuário de um cliente podem realizar força bruta no `otp code` de 6 dígitos, pois o sistema não possui limites de tentativa ou mecanismos de bloqueio. Ao adivinhar o código com sucesso, o atacante pode recuperar a nova senha definida diretamente da resposta HTTP para sequestrar a conta.

Uma falha de bypass de autorização permite que usuários autenticados realizem operações não autorizadas em cronogramas de fluxo de trabalho, definições de fluxo de trabalho e instâncias de tarefas em diferentes projetos. O sistema verifica as permissões com base no `projectCode` fornecido, mas não confirma se o recurso de destino realmente pertence a esse projeto. Consequentemente, um usuário com permissões em um projeto pode usar o código desse projeto junto com um identificador de recurso de outro projeto para ignorar as restrições de acesso. Isso permite que atacantes alterem a disponibilidade do fluxo de trabalho e interfiram na execução de tarefas em projetos não autorizados através dos seguintes endpoints: - 'POST /projects/{projectCode}/schedules/{id}/online' - 'POST /projects/{projectCode}/schedules/{id}/offline' - 'POST /projects/{projectCode}/workflow-definition/{code}/release'

Existe um problema no endpoint `app.util.ssrf/blocked-address?` onde os predicados Java InetAddress não classificam endereços NAT64, 6to4 ou Teredo e aplicam verificações de CIDR apenas a valores IPv4. Isso permite que um usuário que controle uma URL de importação de mídia ou um administrador que controle uma URL de webhook utilize um endereço de transição IPv6 para incorporar alvos IPv4 de metadados de nuvem, loopback, link-local ou privados, ignorando as restrições de Server-Side Request Forgery (SSRF). SSRF é uma vulnerabilidade onde um invasor pode forçar um servidor a fazer requisições para um local não pretendido. Neste caso, a importação de mídia pode divulgar corpos de resposta, e a entrega de webhooks pode ser usada como um canal lateral de sondagem de rede para expor status de resposta. A exploração requer o roteamento através de um gateway NAT64 ou um registro DNS AAAA controlado pelo invasor, tornando ambientes de nuvem com gateways NAT64 diretamente exploráveis.

Um invasor não autenticado pode realizar um server-side request forgery (SSRF) ao ignorar a proteção de SSRF usando endereços 6to4, NAT64 ou IPv6 compatíveis com IPv4. Isso é possível através da função `validateKeyIdUrl()`. Ao enviar um `Signature keyId` manipulado para a rota pública actor inbox, um invasor pode acessar metadados de nuvem, serviços de loopback ou hosts internos.