CIFSwitch, rsync e Flowise: o helper virou fronteira de produção

Tem ferramenta que parece pequena porque fica no meio do caminho.

Ela fica fora da aplicação principal, sem botão bonito, fora do print do lançamento e quase nunca ganha reunião própria. Só que ela roda com permissão alta, encosta em credencial, decide se um arquivo vai ser copiado, monta um caminho de rede, abre um processo ou ajuda alguém a entrar no servidor pela primeira vez.

Quando tudo funciona, ninguém lembra que essa peça existe. Quando falha, a gente descobre que o “detalhe” estava segurando backup, deploy, acesso remoto, automação de IA e metade daquele script que alguém escreveu em 2019 com pressa e café ruim.

O domingo veio com esse tipo de notícia. A tecnologia nova e reluzente ficou fora do centro da mesa; quem roubou a atenção foi a ferramenta auxiliar, o utilitário antigo, a configuração de bootstrap e o painel de fluxo que pareciam só apoio. A diferença é que apoio também executa. Apoio também custa. Apoio também quebra produção se a fronteira de confiança estiver mal desenhada.

Esse tipo de problema é ruim porque não parece problema. A equipe põe a peça ali para tirar atrito: montar uma pasta, copiar arquivo, conectar servidor, abrir uma ferramenta para o agente trabalhar. Depois o atalho ganha permissão, fica no caminho quente e passa anos sem ninguém redesenhar a fronteira.

Também tem o lado financeiro e de manutenção. Se a automação consegue fazer mais coisa sozinha, alguém precisa medir custo. Se a ferramenta antiga muda mais rápido, alguém precisa testar se o script velho ainda entende o idioma. A parte chata da engenharia continua mandando boleto.

Por isso a edição de hoje olha para cantos onde a confiança já estava instalada e pergunta se alguém lembra por que ela foi dada. Quando a resposta é “sempre foi assim”, eu já começo a procurar release note, advisory e opção de desligar. Faço isso por experiência acumulada em sistemas que quebram exatamente no lugar em que ninguém queria mexer.

Pânico não ajuda muito aqui. Ajuda saber quem pode iniciar processo, quem roda com privilégio, quem atualiza utilitário crítico e quem mede gasto de uma sessão longa. São perguntas sem glamour, mas elas impedem que “sempre foi assim” vire relatório de incidente com horário marcado. Se alguma delas parece burocrática, ótimo: burocracia bem colocada é o nome feio de uma proteção que alguém vai agradecer quando precisar restaurar backup ou trocar credencial sem correria.

Com isso em mente, dá para olhar para os casos do dia. O primeiro vem do Linux, com uma falha local em um caminho de compartilhamento de rede que pode chegar a root quando as condições certas se alinham. O segundo passa pelo rsync, um nome que muita gente trata como parte do chão da casa. O terceiro olha para Flowise e MCP, onde uma facilidade útil para agentes pode virar execução de comando no servidor.

No fim da lista ainda aparecem custo de Copilot, primeiro SSH em VPS, NixOS mexendo no boot inicial, Rust Coreutils tentando endurecer ferramentas básicas e uma checklist de site que já pensa em gente e agente lendo a mesma web.

Domingo tranquilo, claramente.

CIFSwitch mostrou root local no Linux pelo caminho CIFS

A história mais urgente é o CIFSwitch, divulgado por Asim Viladi Oglu Manizada no fim de maio. É uma escalada local de privilégio no Linux envolvendo o cliente CIFS do kernel e o cifs.upcall, helper do pacote cifs-utils.

Traduzindo sem derrubar tudo de uma vez: CIFS é o caminho usado para montar compartilhamentos SMB, aquele mundo de pasta de rede que muita gente associa a ambiente Windows, NAS, servidor de arquivo e integração legada. O cifs.upcall ajuda o sistema a lidar com autenticação nesse caminho. O problema aparece quando uma fronteira de confiança entre kernel e espaço de usuário aceita uma solicitação que parece legítima, mas foi criada por um processo local.

Na análise, o kernel aceitava descrições de chave cifs.spnego sem validar direito se elas tinham vindo do caminho real do CIFS no kernel. Isso podia acionar o helper privilegiado em cima de dado controlado pelo atacante. A cadeia ainda passa por namespaces de usuário e de montagem, NSS e comportamento de distribuição. É técnica, sim. O resumo operacional é mais direto: em algumas configurações, um usuário local com pouco privilégio pode virar root.

A falha se comporta como escalada local de privilégio, não como verme remoto atravessando a internet sozinho. A exploração depende de combinação: kernel vulnerável, cifs-utils, user namespaces habilitados e política de distribuição permissiva o bastante. Em alguns testes citados nas fontes, defaults de SELinux ou AppArmor bloquearam o caminho. Em outros ambientes, a superfície ficou aberta.

Isso importa para VPS, runner de CI, desktop de desenvolvimento, host multiusuário, servidor compartilhado e qualquer máquina onde uma conta local comprometida já seja ruim, mas root seja muito pior. Se você usa compartilhamento SMB/CIFS, o item entra na fila de patch. Se não usa, talvez seja a hora de perguntar por que o módulo e o helper estão ali sorrindo para você.

As mitigações citadas pelas fontes são as esperadas para esse tipo de falha: aplicar kernel corrigido pela distribuição, remover cifs-utils quando não for necessário, bloquear o carregamento do módulo CIFS, alterar a regra request-key ligada a cifs.spnego ou desabilitar user namespaces sem privilégio quando isso for aceitável no seu ambiente.

Tem ainda um detalhe moderno na descoberta. O pesquisador descreve uso de um harness com grafo semântico assistido por LLM para ajudar a encontrar a cadeia. É interessante, mas não precisa virar mágica no título. O que salva máquina é correção, configuração, política de distribuição e inventário. O resto é ferramenta de pesquisa fazendo ferramenta de pesquisa.

No momento da divulgação pública, as fontes verificadas ainda não traziam um CVE atribuído. Então vale acompanhar advisory da sua distribuição em vez de procurar só por um identificador bonito.

Fontes: Asim Manizada, oss-security / Openwall, AlmaLinux e Diolinux.

A briga do rsync virou conversa séria sobre release e confiança

O rsync entrou no dia por um caminho menos limpo do que uma vulnerabilidade com advisory. Um issue aberto no GitHub em 30 de maio, com título bem mais nervoso do que esta frase aqui, virou ponto de encontro para reclamações sobre direção do projeto, regressões e uso de assistência de IA na manutenção.

Esse tipo de discussão é fácil de estragar dos dois lados. De um lado, dá para transformar qualquer bug em prova de que IA destruiu o software. Do outro, dá para tratar usuário irritado como barulho porque o comentário veio quente. As fontes verificadas sustentam uma história mais útil: existe reação pública, existem commits recentes com Co-Authored-By para Claude Opus 4.7 e existem problemas concretos abertos em torno da fase do rsync 3.4.3.

Um deles envolve openat2() e build em Linux anterior ao 5.6. A lista também cita dor em plataformas mais antigas, como Darwin. Isso não prova que Claude causou o defeito. Prova que um utilitário muito confiável mudou o bastante para usuários começarem a se perguntar se a disciplina de release, compatibilidade e revisão está acompanhando a velocidade.

rsync está longe de ser brinquedo. Ele aparece em backup, deploy, cópia entre servidores, NAS, script antigo, distro, automação doméstica e coisa que ninguém lembra até faltar arquivo. Ferramenta desse tipo tem uma característica cruel: o melhor comportamento dela é ser esquecível. Quando o usuário precisa reaprender o risco no meio de uma restauração, já passou da hora boa.

A saída razoável para quem depende de rsync é tratar como infraestrutura. Leia release notes, teste versão nova no seu conjunto de flags, acompanhe orientação da distro, faça rollout pequeno e evite atualizar o comando que mexe no backup mais importante no mesmo dia em que você descobriu a thread.

Também apareceu openrsync como contexto possível. Ele é uma implementação BSD, usada no OpenBSD e compatível com subconjuntos modernos do protocolo rsync. Isso não faz dele substituto universal. Se você usa flags específicas, comportamento GNU antigo ou scripts cheios de detalhes, alternativa também precisa de teste. Software antigo não vira simples porque alguém abriu outro repositório.

O caso todo é uma aula de manutenção: quando uma ferramenta é crítica, IA pode ajudar em commit, limpeza, CI e documentação, mas ela não compra confiança sozinha. Confiança vem de teste chato, ramo estável, compatibilidade preservada, changelog claro e mantenedor dizendo, com evidência, o que mudou e por quê.

Fontes: issue #929 do RsyncProject, rsync v3.4.3, commit com coautoria de Claude, issue #924 sobre openat2() e openrsync.

Flowise expôs o lado perigoso do MCP stdio em servidor

No dia 27, falamos de contenção de agentes e credenciais com escopo pequeno. O Flowise entra como o outro lado da mesma conversa: o que acontece quando uma interface de automação deixa dado de menor confiança influenciar um runtime de maior confiança.

Flowise é uma plataforma open source para criar fluxos com LLMs e agentes. A vulnerabilidade rastreada como CVE-2026-40933 envolve o comportamento de adaptadores MCP usando transporte stdio. Esse detalhe importa porque stdio, nesse contexto, vai além de um campo simpático de configuração. Ele pode significar iniciar um processo local para conversar com uma ferramenta.

A Obsidian Security descreveu um caminho em que um chatflow compartilhado ou importado podia levar um servidor Flowise self-hosted a executar comando durante importação ou renderização do canvas. A advisory do GitHub rastreia a falha como RCE autenticado via MCP adapters e cita versões anteriores à 3.1.0 no escopo original. A SecurityWeek reportou que código de exploração foi publicado.

Vamos manter sem receita de ataque, porque ninguém precisa de tutorial acidental no café. A consequência já basta: se o processo do Flowise consegue ler variáveis, acessar API keys, falar com banco, chamar SaaS interno ou alcançar cloud, execução no servidor vira problema de credencial e movimento lateral.

A nuance é importante. MCP não vira vulnerabilidade por existir. O risco aparece quando uma configuração, fluxo importado ou usuário com menos confiança consegue dirigir o que um servidor confiável vai lançar. O mesmo mecanismo que deixa ferramenta local conveniente precisa de isolamento quando mora perto de segredo.

Segundo a Obsidian, Flowise Cloud não foi afetado porque stdio MCP fica desabilitado ali. Para self-hosted, as recomendações giram em torno de desabilitar stdio MCP quando não for necessário, por exemplo usando CUSTOM_MCP_PROTOCOL=sse nos cenários apropriados, restringir quem pode importar ou editar chatflows, revisar configurações MCP como código executável e acompanhar a advisory do Flowise.

Como a leitura entre advisory e análise de pesquisador ainda tem bordas em movimento, vale escrever com cuidado: siga a orientação oficial do projeto, mas não trate JSON de fluxo, conector e configuração de ferramenta como decoração. Se algo pode abrir processo, já está mais perto de código do que de preferência visual.

Fontes: Obsidian Security, GitHub Advisory GHSA-c9gw-hvqq-f33r e SecurityWeek.

Destaques rápidos para hoje.

• O GitHub Copilot muda para cobrança baseada em uso em 1 de junho de 2026. Os antigos premium request units dão lugar a GitHub AI Credits, calculados por consumo de tokens, incluindo entrada, saída e tokens em cache; o preço base dos planos continua igual segundo o GitHub, mas crédito incluído, uso em pool e limite administrativo passam a mandar no susto da fatura. A reação pública reportada pela TechCrunch é real como reação, mas prints virais de custo continuam sendo anedota até prova melhor. Fontes: GitHub Blog e TechCrunch.

• A primeira conexão SSH em uma VPS continua sendo aquele momento do yes que muita gente digita no automático e depois finge que validou a impressão digital. Joachim Schipper propôs um padrão com cloud-init, chave de host temporária e rotação do OpenSSH: você confia na chave curta só para o bootstrap e não deixa a chave privada de longo prazo perdida em userdata. É hardening prático, não CVE novo, e merece teste em VM descartável antes de virar hábito. Fonte: Joachim Schipper.

• O NixOS 26.05 Yarara foi anunciado em 30 de maio com uma mudança que parece pequena até afetar boot: o Stage 1, também chamado de initrd, agora usa systemd por padrão. O release também traz GNOME 50, GCC 15 e uma grande atualização do Nixpkgs, mas o detalhe que pede leitura calma é a migração do boot inicial, com caveats para LUKS e parâmetros; o caminho antigo fica deprecado e tem remoção planejada para 26.11. Fontes: NixOS e release notes.

• O uutils/Rust Coreutils 0.9.0 saiu com foco em segurança, redução de unsafe, migração para rustix, endurecimento contra TOCTOU e trabalho de I/O zero-copy com splice, tee e pipe. É progresso sério, ainda mais com a trajetória de adoção em distros como Ubuntu, mas coreutils é aquele tipo de chão onde scripts tropeçam em detalhes pequenos; as próprias notas de release falam de compatibilidade com a suíte GNU e testes novos que ainda falham. Fontes: uutils/coreutils e Phoronix.

• The Website Specification apareceu como uma checklist plataforma-agnóstica para qualidade técnica de sites, com 128 tópicos passando por fundamentos, SEO, acessibilidade, segurança, performance, privacidade, URIs bem conhecidas e prontidão para agentes. Tem llms.txt, links para referências, checklist e um servidor MCP somente leitura. Útil para auditar site próprio; o cuidado é lembrar que o projeto funciona como checklist, sem status de padrão oficial da web. Fonte: The Website Specification.

Acompanhamento de tendências do dia.

O texto de Aaron Brethorst sobre conhecimento de domínio encaixa bem no pacote, desde que a gente não transforme isso em palestra motivacional. A tese dele é que agentes barateiam a passagem de ideia para código, mas não barateiam do mesmo jeito a capacidade de saber se o resultado está certo.

Esse “certo” muda de assunto para assunto. Em folha de pagamento, certo é regra trabalhista e fiscal. Em transporte, é rota, atraso, escala e operação real. Em segurança de Linux, é fronteira entre kernel, helper e política da distro. Em rsync, é compatibilidade que mantém backup confiável. Em Flowise, é entender que uma configuração de ferramenta pode abrir processo no servidor.

O fio do dia passa por julgamento. Não julgamento bonito de post de carreira, julgamento de produção mesmo: que helper roda como root, que utilitário posso atualizar, que fluxo importado enxerga segredo, que sessão de agente vai consumir crédito, que mudança de boot quebra disco criptografado.

Quando tudo parece plausível, conhecer a fronteira vira habilidade técnica. O resto é ler fonte, testar com calma e manter um pouco de desconfiança saudável. Chato? Bastante. Mas é melhor do que descobrir no restore.

Fonte: Aaron Brethorst.

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