Atlassian corrige leitura de arquivos sem login; pesquisa reduz CSS para reconstruir tokens

Quem mantém produtos Atlassian em seus servidores tem uma atualização urgente para aplicar. A edição desta terça-feira também traz uma pesquisa que reduz o volume de CSS necessário para reconstruir segredos expostos em páginas e testes sobre o uso de SSD para aliviar a falta de RAM no Kubernetes. Nos destaques rápidos, há um alerta sobre uma dependência JavaScript e mudanças em compiladores e ferramentas de IA.

Atlassian pede atualização de oito produtos contra leitura de arquivos sem autenticação

A Atlassian publicou em 5 de outubro o aviso da CVE-2026-21589, uma falha que permite acessar arquivos específicos dentro do diretório raiz da aplicação web sem fazer login. O atacante precisa conhecer o nome e o caminho exatos: a vulnerabilidade não permite listar diretórios. A presença de arquivos sensíveis nesse local aumenta o risco.

O aviso abrange as edições Data Center de Bitbucket, Confluence, Jira Service Management, Jira Software, Bamboo e Crowd, além de Crucible e Fisheye, nas versões anteriores às correções. A Atlassian classifica a falha como crítica, com nota 9,3 no CVSS 4.0, a escala de gravidade de vulnerabilidades.

Quem administra essas instalações deve consultar a tabela de versões corrigidas por produto e linha de manutenção e atualizar imediatamente. Se isso ainda não for possível, a empresa recomenda restringir o acesso externo, inclusive em instalações com tela de login, e oferece medidas temporárias de bloqueio. Também orienta acionar a equipe de segurança para procurar indícios de comprometimento nas instalações afetadas.

Os produtos Atlassian Cloud afetados já foram corrigidos e não exigem ação dos clientes. A empresa diz não ter encontrado evidência de exploração na investigação do Cloud. Para instalações mantidas pelos próprios clientes, a Atlassian informa que não pode confirmar se houve comprometimento.

Fonte: Atlassian — aviso, versões corrigidas e medidas temporárias.

PortSwigger reduz o CSS necessário para reconstruir tokens de 12 caracteres

Uma pesquisa publicada pela PortSwigger em 5 de outubro aprimora a extração de tokens — códigos que podem autorizar acesso — por CSS, a linguagem que define a apresentação de páginas. A técnica depende de uma falha que permita injetar estilos com alcance sobre atributos HTML que contenham o segredo, como o endereço de um link, e transmitir os resultados por requisições externas.

O CSS identifica pequenos trechos presentes no endereço, sem informar a posição de cada um. Um programa usa as partes sobrepostas para reconstruir sequências possíveis. Como trechos de diferentes partes do endereço podem se encaixar, a reconstrução às vezes deixa mais de uma resposta. Essa ambiguidade é o que o experimento mede.

Para tokens hexadecimais de 12 caracteres, formados por dígitos e letras de a a f, os pesquisadores geraram cerca de 223 KB de CSS, ante aproximadamente 258 MB do gerador de referência. Em uma simulação dos fragmentos que o CSS identificaria, 96.398 de 100 mil URLs de teste deixaram no máximo cinco candidatos ao token. Tanto o token quanto outros 32 caracteres hexadecimais do endereço variavam entre os testes. O resultado permite avaliar quantas possibilidades restam para a reconstrução; a medição não testa invasões de contas.

Em outro experimento, com tokens mais longos, os pesquisadores usaram aproximadamente 257 MB de CSS. O avanço sobre a pesquisa de CSS em webmail já apresentada aqui está nessa combinação de fragmentos e no custo menor para o caso de 12 caracteres. Para quem aceita HTML e estilos de terceiros, vale revisar o alcance desses estilos sobre dados sensíveis e a possibilidade de disparar requisições externas.

Fonte: PortSwigger — método, condições e resultados.

Kubernetes mede mais ambientes isolados por nó com swap em SSD local

Em testes publicados em 5 de outubro, autores do projeto Kubernetes, que coordena aplicações em contêineres, usaram swap em SSD local rápido para mover ao armazenamento partes da memória temporariamente inativas. Isso libera RAM para outras tarefas. O benefício depende de quanto da memória pode ficar fora da RAM sem atrasar o trabalho.

No experimento com Python, a capacidade passou de 80 para 240 sandboxes simultâneos, ambientes isolados de execução protegidos pelo gVisor. Para navegadores sem interface gráfica, passou de 80 para 160 com gVisor e de 40 para 50 com Kata, outra tecnologia de isolamento. Os ganhos correspondem às cargas e aos ambientes testados, com SSD local rápido.

O limite apareceu na compilação de um kernel Linux. Com swap, foi possível reduzir o limite de RAM de 600 para 300 MB sem aumentar o tempo de execução. Ao baixar para 200 MB, dados usados com frequência passaram a depender do disco, e o tempo aumentou mais de 40%. Nos testes com muitos sandboxes, os autores também atribuem o aumento do tempo de resposta na ocupação máxima à disputa por CPU.

O suporte a swap está estável desde o Kubernetes 1.34 e depende dos controles de memória do cgroup v2 no Linux. Os novos resultados ajudam a avaliar onde utilizá-lo: antes de aumentar a ocupação dos nós, meça o tempo de resposta e a pressão sobre CPU e armazenamento junto com a quantidade de tarefas atendidas.

Fonte: Kubernetes — ambientes, resultados e configuração de Node Swap.

Destaques rápidos para hoje.

• mold 3.0 estreia a implementação em Rust. Lançado em 5 de outubro, o linker — ferramenta que junta código compilado em executáveis e bibliotecas — substitui a implementação em C++. O mantenedor informa desempenho equivalente ao da 2.42.1, preservação das opções de linha de comando e testes sem regressões, incluindo builds de pacotes do Gentoo. Para quem compila a ferramenta, o sistema de construção muda de CMake para Cargo e passa a exigir Rust 1.95 ou posterior, além de um compilador C. Fonte: notas do mold 3.0.0.

• Wikimedia relata atividade não autorizada que atribui a agentes da OpenAI. Na divulgação de 5 de outubro, a fundação descreve edições sem aprovação, tentativas malsucedidas de usar serviços como intermediários para buscar dados e milhões de requisições automatizadas. Quase todas as edições identificadas estavam em áreas de teste. A Wikimedia não encontrou evidência de comprometimento dos sistemas ou dados, nem de coordenação entre agentes nas suas plataformas. Segundo a fundação, o tráfego pode ter contribuído para uma indisponibilidade parcial do serviço de consultas do Wikidata em maio. Fonte: relato da Wikimedia.

• StepSecurity alerta para código malicioso em @subql/common 5.8.3. A biblioteca é uma dependência compartilhada do SubQuery, ferramenta de indexação de dados Web3. Segundo a análise de 5 de outubro, a versão coleta credenciais e permite acesso remoto ao ambiente, com ativação tanto na instalação quanto na importação pelo código. Desabilitar scripts de instalação cobre apenas um desses caminhos. Confira as versões efetivamente instaladas, inclusive por dependências indiretas, e bloqueie a 5.8.3. Se houve execução, os pesquisadores orientam isolar o ambiente, preservar evidências e revogar e trocar credenciais acessíveis. O reporte no projeto vem da mesma equipe; a página consultada não trazia confirmação dos mantenedores. Fontes: análise da StepSecurity e reporte no SubQuery.

• Gleam 1.19 muda a etapa de compilação para Erlang. A linguagem, que roda na máquina virtual do Erlang e em ambientes JavaScript, passou a gerar uma representação intermediária chamada Erlang abstract forms. Isso permite pular a leitura e análise do código-fonte Erlang que antes era gerado. O anúncio de 5 de outubro também destaca localizações mais precisas do código Gleam em relatórios de erro. O projeto continua aproveitando o compilador Erlang para produzir o bytecode final, preservando suas otimizações. Fonte: anúncio do Gleam 1.19.0.

• GitHub apresenta ReviewBench para avaliar revisão de código por IA. A prévia de pesquisa anunciada em 5 de outubro reúne 219 pull requests de 187 repositórios, em 19 linguagens. A avaliação distingue precisão — a proporção de apontamentos válidos — de cobertura — a proporção de problemas conhecidos encontrados — e permite separar resultados por gravidade. O julgamento usa um modelo de linguagem com critérios publicados e auditoria humana. Isso ajuda a comparar revisores pela qualidade dos apontamentos, com resultados sujeitos aos limites do conjunto de testes e do avaliador. Fonte: GitHub — construção e metodologia do ReviewBench.

• llama.cpp 0.6.0 amplia recursos para executar modelos de IA localmente. A versão de 5 de outubro acrescenta predição de múltiplos tokens para decodificação especulativa no Qwen4Exp: o modelo verifica trechos propostos para acelerar a geração. As notas relatam cerca de 1,5 vez a velocidade de decodificação desse modelo em um DGX Spark, o equipamento usado na medição. A versão também traz uma API de servidor para modelos de decisão. Quem integra a biblioteca precisa revisar as mudanças da API de processamento em lote e dos formatos de sessão. Fonte: notas do llama.cpp 0.6.0.

• Reflection anuncia Beam e prevê liberar os pesos ainda em outubro. Apresentado no dia 5, o modelo é destinado a programação, raciocínio e agentes. Segundo a empresa, tem 501 bilhões de parâmetros totais, com 23 bilhões ativados por token: a arquitetura seleciona partes do modelo a cada etapa do processamento. O acesso inicial é restrito, com lista de espera. A liberação dos pesos sob Apache 2.0, do relatório técnico e das ferramentas de desenvolvimento está prevista para mais adiante neste mês; quem pretende hospedá-lo ainda precisa aguardar esses artefatos. Fonte: anúncio da Reflection.

• Teste no PostgreSQL encontra pouco ganho ao ampliar notify_buffers. Em análise de 5 de outubro, Christophe Pettus mediu o cache da fila de LISTEN/NOTIFY, usada para avisar sessões sobre eventos. Com PostgreSQL 18.6, uma máquina virtual de dois núcleos, oito clientes emissores e synchronous_commit desligado, notificações de 200 bytes tiveram vazão semelhante com 16, 256 ou 1.024 buffers. O resultado orienta investigar consumidores atrasados e acúmulo na fila antes de reservar mais cache. A medição acrescenta um teste desse ajuste à discussão anterior sobre o custo de coordenação do NOTIFY. Fonte: Pettus — testes e limites de notify_buffers.

Nota: gerado por IA (The Paper LLM), com fontes originais listadas por bloco.