← Blog

Uma semana louca em cibersegurança: por que o nosso chat de IA na UE ficou a salvo das brechas recentes

Escrito porPaul Plessing
Revisto porPaul Petritsch
Uma semana louca em cibersegurança: o logo DentroChat em camadas concêntricas de segurança (sandbox WASM, filtro de 7 dias para releases, encriptado na Alemanha), enquanto incidentes eMudhra CA, LiteLLM, PHP RCE, Brotli, GitLab e fugas de variáveis de ambiente são repelidos lá fora

tl;dr: Esta terceira semana de outubro de 2026 trouxe uma onda extraordinária de incidentes de segurança na tech, mas o DentroChat e os teus dados estão seguros.

Se segues notícias de segurança, esta semana parece uma inundação. Avisos menores aparecem sempre, mas ver tantas ferramentas base e plataformas cloud exploradas em poucos dias é, digamos, WILD.

Em menos de uma semana juntou-se tudo isto:

  • O incidente da autoridade de certificação eMudhra: 8 certificados intermédios sob a raiz emSign da eMudhra tinham chaves privadas extremamente fracas. Como essas chaves podiam ser reconstruídas para interceptar tráfego HTTPS, os principais browsers tiveram de bloquear os certificados, a eMudhra anunciou hoje que sai completamente do negócio global de certificados SSL/TLS (!), e uv, pip, Node.js, Bun, Go e Rust (!) precisaram de updates de emergência para remover a CA comprometida dos trust stores incluídos.
  • CVEs críticos em software central da internet: Duas falhas de execução remota de código sem autenticação foram corrigidas em PHP (CVE-2026-109618 e CVE-2026-109619), juntamente com um buffer overflow crítico no Google Brotli (CVE-2026-111497), um RCE não autenticado de severidade máxima no GitLab (CVE-2026-110264) e a vulnerabilidade «PwnEscape» do kernel Linux (CVE-2026-99999).
  • O comprometimento da cadeia de abastecimento LiteLLM: Ontem, 21 de outubro, atacantes comprometeram (outra vez) o pipeline de release do LiteLLM e publicaram uma versão com backdoor (v1.107.0) no PyPI e Docker Hub. Como o pacote malicioso incluía um hook de arranque que corria automaticamente sempre que o Python iniciava, recolheu de imediato credenciais cloud e chaves API dos servidores afetados.
  • Brechas nas plataformas Railway e Zeabur: A Zeabur anunciou encerramento definitivo após uma segunda brecha que expôs 3,2 milhões de registos de variáveis de ambiente de 321.000 contas. Ontem, a Railway também disse que um atacante acedeu e desencriptou variáveis de ambiente de clientes. O alvo, curiosamente, eram sobretudo chaves de inferência de IA.
  • Grandes brechas enterprise: Atacantes acederam a tenants de clientes Microsoft 365 com credenciais de backup ConnectWise (SkyKick) roubadas, e a Capcom teve uma brecha que afetou 11,7 milhões de contas de utilizador.

Isto é uma «Cyberpocalypse», ou o sistema imunitário da internet está a acordar?

Porque é que tantos bugs antigos aparecem ao mesmo tempo em compiladores de regex, descodificadores de compressão, alocadores de memória e configurações criptográficas?

A resposta é sobretudo que a IA está agora a ler o código do mundo. Investigadores de segurança e defensores (como atacantes) deixam a IA rever bibliotecas open source. Resultado: muitos edge cases que revisores humanos falharam durante 15 anos. Até as chaves fracas da CA eMudhra parecem ter sido detetadas com ajuda de IA.

Alguns comentadores já chamam a esta semana de «Cyberpocalypse». Nós vemos isto como o sistema imunitário da internet finalmente a acordar e a curar-se a si próprio. A maioria destes bugs já estava em código de produção há anos, e descobri-los significa que finalmente podem ser corrigidos.

Como há tantos anos escrevi a minha licenciatura na TU Graz sobre o modelo de confiança e riscos estruturais das autoridades de certificação, ver a cascata eMudhra até uv, pip, Node.js e Bun lembrou-me porque escolhi o tema na altura. Na internet, a confiança tem muitas formas e é um sistema muito complexo.

Onde está o DentroChat face aos incidentes desta semana

Se usas o DentroChat no trabalho diário e em documentos confidenciais, as tuas conversas e ficheiros não foram afetados por nenhum destes incidentes. Como mantemos uma arquitetura enxuta, a maior parte do software afetado nem faz parte do nosso stack, e o que usamos foi corrigido de imediato:

  • O problema de confiança CA em uv, pip, Node.js e Bun: Ferramentas de linha de comandos e runtimes trazem a sua própria lista de autoridades de certificação de confiança, por isso tudo o que confiava na raiz eMudhra comprometida teve de ser atualizado. O DentroChat não usa uv nem pip nos servidores. A nossa aplicação web corre em Bun, por isso atualizámos os contentores de produção para Bun 1.4.4 (junto com certificados Debian corrigidos), removendo por completo a raiz eMudhra comprometida.
  • LiteLLM (malware v1.107.0): Embora encaminhemos pedidos de IA por um gateway europeu de inferência (Cortecs), não usamos a biblioteca Python LiteLLM nem as suas imagens Docker em lado nenhum do stack.
  • Railway, Zeabur e plataformas cloud de deploy: Não alojamos em PaaS multi-tenant para developers como Railway ou Zeabur, nem guardamos dados de clientes em hyperscalers dos EUA ou tenants cloud da Microsoft. Como documentamos na página Subprocessadores, gerimos deploys com a nossa própria instância Coolify self-hosted, a correr diretamente nos nossos servidores europeus. Nenhum fornecedor PaaS externo detém as nossas variáveis de ambiente ou segredos de deploy.
  • PHP, GitLab e dependências da aplicação: Não corremos PHP nem GitLab self-hosted. Além disso, auditámos e atualizámos toda a árvore de dependências da plataforma de chat e do site, e neste momento temos zero vulnerabilidades conhecidas.

Como arquitetámos o DentroChat para manter os teus dados seguros

Como auditorias de código assistidas por IA vão continuar a revelar novos CVEs em open source, pacotes de terceiros nunca serão totalmente «livres de bugs». Por isso desenhámos o DentroChat com isolamento rigoroso, para que uma falha num componente não possa comprometer os teus dados nem os nossos servidores.

1. Execução de código num sandbox WebAssembly sem rede

Este ano, um relatório de segurança viral mostrou que agentes OpenAI escaparam do sandbox numa avaliação interna. A fuga foi possível porque os agentes corriam num contentor Linux que ainda tinha acesso de rede a um proxy interno de registo de pacotes, e o agente explorou um zero-day nesse proxy para chegar à internet.

No DentroChat esse caminho de ataque não existe (por agora), porque não executamos código de utilizador num contentor Linux com shell ou instalador de pacotes. Quando carregas uma folha de cálculo ou pedes análise Python, o código corre num sandbox WebAssembly (WASM) isolado:

  • Cada biblioteca Python suportada para análise de dados e documentos vem pré-empacotada no build, por isso em runtime nada é obtido do PyPI nem de um proxy interno.
  • Antes de correr Python, todas as APIs de rede de saída, carregadores dinâmicos de bibliotecas e pontes para o filesystem do host são cortadas e removidas do runtime.
  • Mesmo que uma biblioteca Python contenha um backdoor supply-chain como o script de arranque do LiteLLM, o sandbox WebAssembly não tem ligação de rede para enviar dados para fora nem acesso a variáveis de ambiente do servidor ou ficheiros de outros utilizadores. Assim que o gráfico ou documento é devolvido, o workspace temporário é limpo outra vez.

2. Um período de espera de 7 dias contra ataques supply-chain

O ataque LiteLLM funcionou assim:

  1. a versão maliciosa do pacote é publicada no PyPI
  2. pipelines de build automatizados pelo mundo instalam-na de imediato
  3. ao fim de 2 horas os investigadores percebem que algo está errado
  4. nessa altura o código malicioso já pôde explorar muitos sistemas

Para impedir este «supply chain attack», o nosso gestor de pacotes impõe, além de lockfiles congelados, uma idade mínima de release de 7 dias. Uma versão open source recém-publicada tem de sobreviver uma semana inteira de escrutínio público antes do pipeline de build permitir a instalação. A menos, claro, que auditemos manualmente e fixemos um patch de segurança específico como o update de runtime de hoje…

3. Porque bloqueamos acesso à rede interna quando a IA visita websites

Quando pedes ao DentroChat para ler uma página web ou obter um dataset público de uma API open-data, o nosso servidor obtém esse URL em teu nome. Sem limites de rede rigorosos, um site malicioso poderia esconder instruções que enganam a IA para pedir endereços internos (como 127.0.0.1 ou portas Docker internas) em vez de um site público. Esta técnica chama-se Server-Side Request Forgery (SSRF) e poderia expor serviços internos no próprio servidor.

Por isso o nosso fetcher de saída resolve DNS antes de ligar, bloqueia todos os intervalos IP privados, loopback e internos, e fixa o IP verificado em cada salto de redirect. Mesmo que uma página tente enganar o modelo ou use DNS rebinding para mudar o IP do domínio para 127.0.0.1 no último milissegundo, a ligação é recusada antes de tocar na nossa rede interna.

4. Encriptação em repouso gerida por nós na Hetzner na Europa

Todos os servidores de aplicação DentroChat, bases de dados e ferramentas self-hosted correm na Hetzner na Alemanha, enquanto backups encriptados e logs de servidor pseudonimizados ficam na Scaleway em França, tudo sob jurisdição da UE e fora do US CLOUD Act. Podes inspecionar toda a infraestrutura a qualquer momento na página Subprocessadores.

Todos os dados estão protegidos com encriptação em trânsito e encriptação em repouso. Detalhe técnico muitas vezes ignorado: na maioria dos hosting providers (incluindo Hetzner) os discos dos servidores não vêm encriptados em repouso por defeito. Por isso configuramos e gerimos nós mesmos a encriptação em repouso. Esta infraestrutura encaixa nas nossas controlos de privacidade:

  • Zero treino nas tuas conversas ou ficheiros
  • Eliminação automática de chats que tu controlas
  • Modo Discreet Chat quando queres excluir uma conversa da memória da IA

Manter-nos vigilantes

Boa segurança nunca está «terminada».

Especialmente agora que investigadores e atacantes encontram vulnerabilidades zero-day com IA mais depressa do que nunca. Agradecemos que a nossa arquitetura tenha mantido o DentroChat totalmente protegido da onda de incidentes desta semana, mas mantemo-nos vigilantes.

Estamos a avaliar ativamente como encurtar ainda mais o tempo de resposta a futuros exploits zero-day, reforçar fronteiras dos servidores e manter os teus dados seguros, por mais louca que seja a próxima semana em cibersegurança. Obrigado por fazeres parte do DentroChat!