preparo para a era da IA
13 artigos com esta tag
CVE-2026-98432 do kernel do Linux: um use-after-free de TCP acionável pela rede (CVSS 9.8); instale o kernel corrigido, reinicie e verifique o MPTCP
CVE-2026-98432 é um use-after-free no código TCP IPv4 do kernel do Linux, publicado em 15 de outubro de 2026. A CNA do projeto do kernel o pontua com CVSS v3.1 9.8 (rede, sem privilégios, sem interação do usuário). Segundo relatos, pesquisadores de uma empresa de IA demonstraram, em laboratório e conforme seu próprio relatório, a execução remota de código como root contra um servidor com um listener Multipath TCP (MPTCP). O BleepingComputer diz que a execução remota de código em servidores TCP comuns não foi demonstrada publicamente e que nenhuma exploração ativa foi confirmada, e este site não encontrou o CVE no catálogo KEV da CISA em 1º de novembro. As correções upstream estão em 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 e 7.2.10 e posteriores. Em 1º de novembro, o Debian tem kernels corrigidos, a SUSE tem alguns, e Ubuntu e Red Hat listam as correções como em andamento. Desativar apenas o MPTCP não é uma correção completa. Conclusão deste site: atualize os servidores Linux expostos à internet conforme as correções forem chegando, reinicie e use uma medida provisória do fornecedor apenas até lá.
Segurança para a era da IA: os fundamentos para blindar agora (checklist por prioridade)
A IA em sua maior parte amplifica ataques sobre fraquezas EXISTENTES (CVEs sem correção, senhas reutilizadas, segredos expostos) em vez de inventar novas — encontradas de forma automática, rápida e em escala. Então a melhor preparação é blindar os fundamentos na ordem certa: correção de CVE + monitoramento de dependências, parar de reutilizar senhas + MFA, remover segredos expostos, menor privilégio, reduzir a superfície pública, logs/IOCs, backups.
Medidas de segurança na era da IA que funcionam e as que não funcionam: por que sites pequenos também são alvo
Quatro equívocos da era da IA corrigidos: (1) pequeno demais para ser alvo → ataques automatizados não precisam de um humano para escolher o alvo; (2) precisa de um novo controle especial → o básico ainda funciona melhor; (3) um produto te deixa seguro → design de prevenção antes da detecção; (4) código de IA é rápido então é seguro → ele pode vir com vulnerabilidades, então revise antes de publicar. O que funciona é o básico tedioso na ordem certa.
Spoofing de e-mail com o seu próprio domínio: como distinguir de uma invasão, e como SPF, DKIM e DMARC o impedem
Um e-mail suspeito que parece vir do seu próprio domínio geralmente não é uma invasão — é um From falsificado, porque o SMTP deixa qualquer um escrever a linha From. Ler os headers (Authentication-Results, Received, Reply-To) distingue invasão de falsificação. A principal razão de ele chegar à caixa de entrada é uma política DMARC ausente. Corrija com SPF → DKIM → DMARC (p=none → reject).
Fundamentos de backup: a regra 3-2-1 e um plano de recuperação que sobrevive a ransomware
'Tenho um backup' não basta — só um backup que você verificou ser restaurável é útil. O básico: a regra 3-2-1 (três cópias, dois tipos de mídia, uma fora do local). Para ransomware você também precisa de ao menos uma cópia 'offline ou imutável' — um backup sempre conectado é criptografado junto com o original. Sincronização na nuvem não é backup (ela replica exclusões e criptografia também). Versionamento e um teste de restauração periódico completam a prática.
Escolhendo MFA do jeito certo: o que significa 'resistente a phishing' e por que o SMS é fraco
MFA combina categorias diferentes de fatores. Códigos digitados podem ser retransmitidos por phishing; SMS também depende do controle do número. Para contas importantes, prefira métodos resistentes a phishing, como passkeys ou chaves FIDO2, e confira a verificação do usuário e a recuperação.
Corrigindo CVEs de dependências de verdade: varrer, corrigir, isolar e seguir vigiando
O trabalho de vulnerabilidade não termina quando você 'corrige'. Pronto = 1) varrer, 2) corrigir, 3) isolar/repassar, 4) monitorar. Até o monitoramento (detecção de mudança diária) estar no lugar, está incompleto — dependências voltam a ser vulneráveis amanhã. Uma correção perfeita que o próximo deploy sobrescreve vale zero. Equipes pequenas se mantêm seguras com duas disciplinas: detecção de mudança automatizada e 'local→push→deploy'.
Instalando e usando o osv-scanner: encontre CVEs nas suas dependências automaticamente
O osv-scanner escaneia lockfiles e containers para revelar CVEs nas suas dependências, de graça. Este guia percorre a instalação, a execução e a integração ao CI, além de quando usá-lo vs. npm/pnpm audit vs. Dependabot. A visão deste site: qual ferramenta serve depende da sua configuração. Use o osv-scanner em projetos multi-ecossistema ou sem GitHub, e o pnpm audit embutido para uma única árvore npm.
Gerenciadores de senhas são seguros? Como funcionam, nuvem vs. local e como escolher
Um gerenciador de senhas ajuda a usar uma senha forte e diferente para cada serviço. A criptografia de conhecimento zero foi projetada para proteger o conteúdo mesmo se dados criptografados vazarem do provedor, mas a segurança também depende da força da senha-mestra, das configurações de criptografia e da segurança do dispositivo. Use MFA para impedir logins não autorizados e escolha nuvem ou local conforme o uso.
Você deixou um arquivo de segredo em um diretório público? Audite seu webroot
Qualquer coisa no seu webroot pode ser baixada pela URL por qualquer um. Um JSON de token/credenciais esquecido, um .env ou um backup significam exposição instantânea — e se veio de um template compartilhado, todo site tem o mesmo arquivo. Correção: coloque no diretório público só o que pode ser compartilhado, mantenha segredos fora do webroot com permissão 600 e, ao achar um, audite todos os sites e hosts.
A base de segurança para devs independentes e pequenos operadores: os controles padrão em ordem de prioridade
A base não é 'tudo igualmente importante'. A ordem de prioridade deste site: 1) contas de administrador, domínio e e-mail (MFA), 2) segredos e código, 3) o próprio app, 4) corrigir, detectar, recuperar. Com tempo finito, preencha de cima para baixo. A maioria das invasões sérias vem não de ataques inéditos, mas da falta de um destes controles básicos.
Menor privilégio para chaves SSH: mantenha as chaves de root de produção fora de ambientes efêmeros que podem ser comprometidos
Cadastrar uma chave de root em produção a partir de um ambiente efêmero e comprometível (pod de GPU, runner de CI, VM descartável) significa que, no momento em que o ambiente é comprometido, um atacante ganha root em produção. Correção: sem chaves de root em ambientes efêmeros; remova chaves quando não usadas; se precisar de novo, use um usuário sem root mais uma chave restrita a comando que limita a chave a uma operação. Trate uma chave reutilizada como seu ativo mais crítico e nunca construa um cenário em que uma chave vazada abre todos os servidores.
Uma chave de API vazou de código escrito por IA e foi usada para cobranças fraudulentas: a causa foi uma vulnerabilidade CVSS 10.0 sem correção
O pico na fatura era um sintoma. A causa foi um RCE CVSS 10.0 publicado e sem correção. Um caso anonimizado, destilado em lições defensivas.