Alimezar

Ocorre uma gravação fora dos limites do heap ao processar uma fonte especialmente criada. O problema reside na função `RenderSDF()` (include/mapbox/glyph foundry impl.hpp), onde o tamanho da alocação do bitmap SDF (signed distance fields) é calculado como `buffered width` * `buffered height` usando um inteiro não assinado de 32 bits. Como as dimensões do glifo são derivadas da caixa delimitadora do contorno da fonte sem um limite superior, um glifo suficientemente grande pode fazer com que o cálculo exceda 2³², resultando em um wrap-around de inteiro para um valor pequeno. Isso leva a um buffer subalocado, enquanto o loop de renderização continua a gravar um byte por pixel, causando a corrupção do heap e a falha do processo.

Um Server-Side Request Forgery (SSRF) cego existe quando a configuração `[oauth2 client] UPDATE AVATAR = true` está habilitada. O problema ocorre porque o servidor busca a URL do avatar fornecida por um provedor OAuth2/OIDC — geralmente a claim `picture` — usando o cliente HTTP padrão do Go sem aplicar restrições de host ou IP de saída. Um usuário com baixos privilégios que consiga influenciar sua própria claim `picture` pode forçar o servidor Gitea a fazer requisições HTTP GET arbitrárias para endereços de loopback, endereços de rede privada RFC 1918 e endereços link-local IPv4, como `169.254.169.254`. Detalhes técnicos incluem: - **Função Vulnerável**: `oauth2UpdateAvatarIfNeed()` em `routers/web/auth/oauth.go` e `oauth2SignInSync()` em `routers/web/auth/oauth signin sync.go`. - **Variável Vulnerável**: `gothUser.AvatarURL`. Embora o problema seja primariamente cego, pois respostas que não sejam imagens são rejeitadas, o impacto aumenta se o servidor conseguir alcançar serviços de metadados de nuvem ou serviços internos que retornem dados de imagem válidos, que poderiam então ser armazenados como o avatar do usuário.

A proteção contra força bruta da API do servidor Wazuh para o endpoint 'POST /security/user/authenticate' pode ser burlada através do envio de solicitações de autenticação simultâneas. Embora o limite `max login attempts` seja aplicado corretamente para solicitações sequenciais, um surto paralelo permite que mais tentativas de login malsucedidas sejam processadas antes que o bloqueio de IP seja aplicado, permitindo mais tentativas de senha do que a política configurada prevê.

Um estouro de buffer baseado em pilha (stack-based buffer overflow) existe na função `print hex string()` no wazuh-remoted. Isso ocorre ao formatar bytes controlados por um invasor usando `sprintf()` em plataformas onde o caractere é tratado como assinado e o código compilado estende o sinal dos bytes antes da chamada variádica. Por exemplo, bytes de entrada como 0xFF podem resultar na emissão de "ffffffff" em vez de "ff", levando a uma gravação fora dos limites de um buffer de pilha fixo de 2049 bytes. Este caminho é acessível remotamente via TCP/1514 antes da autenticação ou registro do agente, quando um prefixo de comprimento excessivo aciona o caminho de diagnóstico "unexpected message (hex)". Além disso, esse mesmo caminho não autenticado permite a amplificação remota de logs ao registrar dumps hexadecimais controlados por um invasor em `/var/ossec/logs/ossec.log`, o que pode consumir recursos de disco/IO e degradar a fidelidade do monitoramento.

Um problema de path traversal existe na rotina de extração de sincronização de cluster, especificamente na função `decompress files()`. Isso permite que um peer de cluster autenticado escreva arquivos arbitrários fora do diretório de extração pretendido em outros nós do cluster. A falha pode ser escalada para a execução remota de código no contexto do serviço Wazuh ao sobrescrever módulos Python carregados pelos componentes do Wazuh. Em ambientes onde o daemon do cluster opera com privilégios elevados, um comprometimento total do sistema é possível. Mais de 3.500 instâncias não corrigidas foram identificadas em 10/05/2026.

A função `safe join` no Werkzeug, uma biblioteca de aplicação web WSGI, manipula incorretamente nomes de dispositivos do Windows quando usados como nomes de arquivos, particularmente quando precedidos por outros segmentos de caminho. Especificamente, a função permite nomes de dispositivos do Windows como nomes de arquivos, o que pode levar a um bloqueio indefinido durante a leitura de arquivos se a aplicação estiver em execução no Windows e o caminho solicitado terminar com um nome de dispositivo especial. A função `send from directory` utiliza `safe join` para servir arquivos, tornando-a suscetível a este problema.