A OpenAI lancou em 5 de maio o GPT-5.5 Instant como novo modelo padrao do ChatGPT, substituindo o GPT-5.3 Instant para todos os usuarios, incluindo a API (endpoint chat-latest). A atualizacao foca em tres eixos: precisao factual, concisao nas respostas e personalizacao baseada em contexto acumulado.

O GPT-5.3 permanece acessivel por tres meses antes de ser aposentado, dando tempo para que integracoes e automacoes sejam ajustadas.

Reducao significativa de alucinacoes

O numero mais relevante da atualizacao: em avaliacoes internas da OpenAI, o GPT-5.5 Instant produziu 52,5% menos afirmacoes alucinadas em prompts de alto risco cobrindo medicina, direito e financas. Em conversas que usuarios tinham sinalizado por erros factuais, a reducao de afirmacoes incorretas foi de 37,3%.

Para quem usa modelos de linguagem em fluxos corporativos, esse tipo de melhoria e mais importante do que ganhos em benchmarks academicos. Alucinacoes em documentos juridicos, relatorios financeiros ou orientacoes tecnicas nao sao apenas inconvenientes. Sao riscos operacionais reais que podem gerar retrabalho, decisoes equivocadas ou, no limite, responsabilidade legal.

Respostas mais enxutas

As respostas ficaram 30,2% mais curtas em palavras e 29,2% mais enxutas em linhas, com tom descrito pela OpenAI como “mais natural e pratico”. O modelo faz menos perguntas de acompanhamento desnecessarias e evita formatacao excessiva, como emojis sem contexto e listas onde um paragrafo bastaria.

Para times que consomem a API programaticamente, respostas mais curtas significam menos tokens de saida, o que reduz custo direto por chamada. Para usuarios finais, significa menos tempo filtrando texto irrelevante ate chegar na informacao que importa.

Personalizacao e gerenciamento de memoria

Usuarios Plus e Pro ganham personalizacao aprimorada: o modelo agora utiliza conversas anteriores, arquivos enviados e Gmail conectado para contextualizar respostas. Fontes de memoria sao exibidas em todas as interacoes, permitindo que o usuario corrija ou exclua entradas desatualizadas.

Um detalhe relevante de privacidade: ao compartilhar um chat com outra pessoa, as fontes de memoria nao ficam visiveis para o destinatario. A OpenAI planeja estender o recurso para usuarios Free, Go Business e planos enterprise nas proximas semanas.

Benchmarks e capacidades tecnicas

Alem das melhorias qualitativas, o modelo apresentou ganhos em avaliacoes padronizadas:

• AIME 2025 (matematica): 81,2 pontos, contra 65,4 do GPT-5.3 Instant.
• MMMU-Pro (raciocinio multimodal): 76 pontos, contra 69,2.

O modelo tambem demonstrou melhorias em analise de imagens, perguntas de STEM e na decisao de quando acionar busca na web para complementar respostas com informacoes atualizadas.

O que isso significa para uso corporativo

A tendencia dos ultimos meses e clara: os modelos de linguagem estao convergindo para serem menos impressionantes em demonstracoes e mais confiaveis em uso continuo. A reducao de alucinacoes, respostas mais concisas e melhor gerenciamento de contexto sao exatamente o tipo de melhoria que torna viavel usar IA generativa em processos de negocio com mais confianca.

Para empresas que ja utilizam a API do ChatGPT em automacoes internas, vale testar o GPT-5.5 Instant nos mesmos fluxos do modelo anterior e medir a diferenca em qualidade de saida e custo de tokens. Para quem ainda avalia a adocao, o momento e oportuno: a barra de confiabilidade esta subindo de forma mensuravel, nao apenas em marketing.

O que observar daqui

O prazo de tres meses para aposentadoria do GPT-5.3 Instant exige que times com integracoes via API planejem a migracao. Embora a OpenAI garanta compatibilidade no endpoint chat-latest, mudancas no comportamento do modelo (respostas mais curtas, menos perguntas de acompanhamento) podem afetar pipelines que dependem de formato especifico de saida. Testar antes de migrar em producao continua sendo o caminho mais prudente.

Fontes

• OpenAI
• TechCrunch

The post GPT-5.5 Instant corta alucinacoes pela metade no ChatGPT appeared first on Audaz Tecnologia.

Em 11 de maio de 2026, um grupo de atacantes identificado como “TeamPCP” publicou 84 versoes maliciosas de 42 pacotes do ecossistema TanStack no npm. O TanStack e uma das familias de bibliotecas JavaScript mais populares do mundo, incluindo pacotes como TanStack Query (antigo React Query), TanStack Router e TanStack Table, usados por milhoes de projetos corporativos e open source.

O ataque explorou uma cadeia de tres vulnerabilidades no GitHub Actions: o padrao “Pwn Request” (via pull_request_target), envenenamento de cache entre forks e extracao de tokens OIDC da memoria do runner. O resultado foi acesso direto ao pipeline de publicacao no npm, permitindo que o atacante distribuisse pacotes trojanizados sem alterar o repositorio principal do projeto.

Como a OpenAI foi atingida

A OpenAI confirmou que dois dispositivos corporativos foram comprometidos em consequencia do incidente. Segundo comunicado oficial da empresa a Reuters, material limitado de credenciais foi exfiltrado de repositorios de codigo. Porem, nenhum dado de usuario, propriedade intelectual ou sistema de producao foi afetado.

A causa raiz especifica na cadeia da OpenAI foi uma misconfiguracao no workflow de GitHub Actions usado para assinar o aplicativo macOS do ChatGPT. A configuracao usava uma tag flutuante (@v3) em vez de um hash de commit especifico. Quando a tag foi comprometida, o pipeline da OpenAI puxou automaticamente o codigo malicioso durante o processo de build.

A resposta incluiu isolamento imediato dos sistemas afetados, restricao temporaria de workflows de deploy e revogacao de certificados de assinatura de codigo. Usuarios do ChatGPT Desktop, Codex e Atlas no macOS foram orientados a atualizar seus aplicativos.

Um padrao que se repete

O grupo TeamPCP, que assina seus ataques como “Mini Shai-Hulud”, e o mesmo responsavel pelo comprometimento da ferramenta Trivy e de pacotes da Mistral AI em marco de 2026, usando tecnica similar. O padrao e consistente: projetos open source confiados por milhares de empresas sao comprometidos via seus pipelines de CI/CD, nao via falhas no codigo-fonte em si.

Segundo analise publicada pela Wiz, o ataque ao TanStack foi o primeiro a combinar as tres tecnicas (Pwn Request, cache poisoning e OIDC extraction) em uma unica cadeia no ecossistema npm. A sofisticacao do vetor indica que ataques de supply chain estao evoluindo rapidamente, e que a confianca implicita em dependencias populares precisa ser revisada.

O npm hospeda mais de 2 milhoes de pacotes. A maioria dos projetos corporativos depende de centenas ou milhares deles. Cada dependencia e um vetor de ataque potencial se o pipeline de publicacao do mantenedor nao tiver protecoes adequadas.

O que times de DevOps devem fazer agora

• Fixar dependencias por hash, nunca por tag. Tags e branches sao mutaveis. Um uses: action@v3 pode apontar para codigo diferente amanha. Use o SHA completo do commit: uses: action@abc123def456.
• Auditar workflows que usam pull_request_target. Esse trigger executa o workflow com permissoes do repositorio base, mesmo para PRs vindos de forks. Se combinado com checkout do codigo do PR, abre uma porta direta para injecao de codigo malicioso.
• Monitorar pacotes com ferramentas de SCA. Solucoes como Snyk, Socket.dev ou Dependabot alertam quando versoes suspeitas sao publicadas. O TanStack comprometido foi detectado em menos de seis horas, mas apenas por equipes que tinham monitoramento ativo.
• Revisar permissoes de tokens OIDC. Se seus workflows emitem tokens OIDC para autenticacao com servicos cloud (AWS, Azure, GCP), valide que o escopo segue o principio de privilegio minimo.

O que observar daqui

Ataques de supply chain se tornaram o vetor preferido de grupos sofisticados porque oferecem alcance massivo com esforco concentrado. Comprometer uma dependencia popular atinge todos que a consomem, de startups a gigantes como a OpenAI.

Para empresas que operam pipelines de CI/CD em ambientes criticos, a mensagem e clara: a seguranca da cadeia de dependencias precisa ser parte do checklist basico, ao lado de testes automatizados e controle de acesso. Auditar workflows de GitHub Actions, fixar versoes por hash e monitorar pacotes com SCA nao sao praticas avancadas. Sao o minimo necessario para nao ser a proxima vitima de um incidente como este.

Fontes

• OpenAI Says No User Data Breached After Security Issue With Open-Source Library
• Postmortem: TanStack npm supply-chain compromise
• Mini Shai-Hulud Strikes Again: TanStack + more npm Packages Compromised

The post Ataque supply chain ao TanStack npm expoe riscos em pipelines appeared first on Audaz Tecnologia.

No Google I/O 2026, realizado em 19 e 20 de maio, o Google apresentou o Gemini 3.5 Flash como o primeiro modelo da familia 3.5. Posicionado como “um salto importante para agentes inteligentes”, o modelo combina desempenho de fronteira com custo reduzido: US$ 1,50 por milhao de tokens de entrada e US$ 9,00 por milhao de tokens de saida, com cache a US$ 0,15.

O contexto suporta ate 1 milhao de tokens de entrada e 65 mil tokens de saida. O recurso de “thinking dinamico” vem ativado por padrao, alocando mais computacao automaticamente para problemas complexos. O modelo aceita texto, imagem, audio e video como entrada, com cutoff de conhecimento em janeiro de 2026.

Benchmarks que chamam atencao

Os numeros de benchmark posicionam o Flash acima do antigo Gemini 3.1 Pro, que era o tier premium anterior:

• 76,2% no Terminal-Bench 2.1: benchmark de performance em codigo, indicando capacidade solida para tarefas de programacao e automacao.
• 1656 Elo no GDPval-AA: mede performance em tarefas agentivas do mundo real, como navegacao de interfaces e execucao de workflows.
• 83,6% no MCP Atlas: avalia uso confiavel de ferramentas em escala, um requisito critico para agentes que interagem com APIs e servicos.
• 84,2% no CharXiv Reasoning: compreensao multimodal avancada.

O ponto mais relevante e a relacao custo-performance: o Google afirma que o Flash e 4x mais rapido na geracao de tokens e que tarefas frequentemente custam menos da metade em comparacao com modelos anteriores.

O que muda na pratica para empresas

Para CTOs e heads de infraestrutura que avaliam integracao de IA em operacoes, o Gemini 3.5 Flash sinaliza tres mudancas concretas:

Agentes de IA ficam economicamente viaveis. Com custo de entrada a US$ 1,50 por milhao de tokens e cache a US$ 0,15, cenarios como triagem automatizada de alertas, analise de logs e geracao de relatorios deixam de ser experimentos caros. Um agente que processa 10 mil alertas por dia, consumindo cerca de 500 tokens por alerta, custaria menos de US$ 10 por dia em tokens de entrada.

Assistentes de codigo ganham substancia. O score de 76,2% no Terminal-Bench sugere que o modelo e competente o suficiente para tarefas como geracao de scripts de automacao, revisao de configuracoes de infraestrutura e debugging assistido. Empresas como Shopify, Salesforce e Databricks ja estao adotando o modelo em seus fluxos de desenvolvimento.

Multimodalidade abre novos casos de uso. A capacidade de processar video e audio, combinada com o contexto de 1 milhao de tokens, permite cenarios como analise automatizada de dashboards de monitoramento, transcricao e resumo de reunioes tecnicas, e processamento de documentacao legada em formatos variados.

Contexto: a corrida por IA mais barata

O lancamento do Flash acompanha uma tendencia clara no mercado. O Google tambem reduziu o preco do plano AI Ultra no Brasil de R$ 1.209,90 para R$ 779,90 mensais, e lancou um tier intermediario global a US$ 100 por mes. A Anthropic, por sua vez, projeta seu primeiro trimestre lucrativo com receita estimada de US$ 10,9 bilhoes no segundo trimestre de 2026, indicando que o mercado de modelos de fronteira esta amadurecendo comercialmente.

A mensagem para o mercado corporativo e que IA generativa esta saindo da fase de experimentacao cara para se tornar infraestrutura acessivel. Para empresas de medio porte que ainda nao incorporaram IA em seus processos operacionais, o custo deixou de ser a barreira principal. A questao agora e definir onde aplicar, como governar o uso e como medir o retorno.

Fontes

• MarkTechPost
• Tecnoblog

The post Gemini 3.5 Flash: o modelo de IA 4x mais rapido do Google I/O appeared first on Audaz Tecnologia.

O kernel Linux esta na versao 7.0. A proxima versao, 7.1, ja chegou a quinta release candidate (rc5), fase que normalmente antecede o lancamento final e deveria focar exclusivamente em correcao de regressoes. O problema, segundo Linus Torvalds, e que o rc5 esta “consideravelmente maior do que os rc5 tradicionalmente costumam ser”.

Em mensagem na lista de discussao do kernel (LKML), Torvalds identificou a causa: uma enxurrada de correcoes nao criticas para problemas antigos, muitas delas motivadas por ferramentas de analise de codigo baseadas em inteligencia artificial.

O problema: ruido de IA no processo de revisao

Ferramentas automatizadas de deteccao de bugs alimentadas por IA tem sido cada vez mais usadas por contribuidores do kernel. Em tese, e uma boa pratica. Na pratica, o volume de reports gerados inclui problemas ja conhecidos, de baixa prioridade ou ja corrigidos.

O resultado e que mantenedores do kernel gastam tempo revisando pull requests que nao deveriam existir nesta fase do ciclo. Torvalds ja havia alertado sobre o problema na semana anterior, mas a situacao nao melhorou. O Linux conta com sete versoes release candidate antes do lancamento oficial. Se o rc5 nao atingir o patamar esperado, o lancamento do kernel 7.1 pode atrasar ou exigir uma oitava release candidate, algo incomum.

A posicao de Torvalds

“Para surpresa de absolutamente ninguem a esta altura, o rc5 esta muito grande. Consideravelmente maior do que os rc5 tradicionalmente costumam ser. Entao acho que vou comecar a ser um pouco mais rigoroso com esse tipo de movimentacao desnecessaria tao tarde no processo. O que deveriamos procurar sao regressoes. Correcoes nao criticas para problemas antigos simplesmente nao sao apropriadas para este ponto avancado do ciclo de lancamento.”

E completou: “Sim, varias dessas series foram motivadas por revisao de codigo feita por IA. Entao, pessoal: comecem a analisar melhor seus pull requests e perguntem a si mesmos: isso realmente e uma regressao ou algo serio o bastante?”

Torvalds nao e contra o uso de IA para analise de codigo. Sua critica e sobre a falta de julgamento humano na triagem. O problema nao e a ferramenta, e o uso sem criterio.

Licao para equipes de desenvolvimento

A situacao do kernel Linux reflete um desafio crescente para equipes de DevOps e desenvolvimento. Ferramentas como GitHub Copilot, CodeRabbit e scanners SAST alimentados por IA facilitam a geracao de codigo e a identificacao de problemas. O volume de output cresce, mas o custo de revisao tambem. Em projetos com multiplos contribuidores, o ruido pode ser mais danoso que o silencio.

Tres pontos praticos emergem do episodio:

• Triagem humana continua essencial: ferramentas de IA para revisao de codigo sao uteis, mas cada finding precisa de validacao humana antes de virar um pull request ou ticket.
• Timing importa: correcoes nao criticas enviadas no momento errado do ciclo de desenvolvimento sao pior do que nenhuma correcao. Em sprints de estabilizacao, so regressoes deveriam entrar.
• Qualidade sobre quantidade: um PR bem fundamentado vale mais que dez PRs gerados automaticamente. A pressao por metricas de contribuicao pode incentivar exatamente o comportamento que Torvalds esta combatendo.

O que observar daqui

Se nada mais der errado, o kernel Linux 7.1 deve chegar em junho de 2026. Mas o episodio deixa uma marca no ecossistema open source. A medida que ferramentas de IA se tornam onipresentes no desenvolvimento de software, a comunidade precisara de politicas mais explicitas sobre como e quando aceitar contribuicoes geradas ou assistidas por inteligencia artificial.

Para empresas que adotam IA no ciclo de desenvolvimento, o recado e claro: automatizar a geracao de codigo e de reports e o passo facil. O passo dificil, e o que realmente importa, e manter criterio humano no loop. Pipelines de CI/CD bem configurados, com gates de qualidade e revisao obrigatoria, sao a primeira linha de defesa contra a inflacao de PRs de baixa qualidade.

Fontes

• Tecnoblog: Linus Torvalds endurece tom contra uso de IA no kernel Linux
• LKML: Linus Torvalds – Linux 7.1-rc5

The post Linus Torvalds vai rejeitar codigo gerado por IA no kernel Linux appeared first on Audaz Tecnologia.

Tradicionalmente, a segurança corporativa concentra esforços em proteger ambientes de produção: servidores, bancos de dados, APIs e perímetros de rede. Esse modelo pressupõe que atacantes tentarão invadir o que já está em execução. No entanto, uma tendência preocupante está mudando esse cenário: estações de trabalho de desenvolvedores se tornaram vetores prioritários de ataque na cadeia de suprimento de software.

A lógica dos atacantes é simples e eficiente. Uma máquina de desenvolvimento tipicamente tem acesso a credenciais de cloud, chaves SSH, tokens de API, repositórios de código-fonte e pipelines de CI/CD. Comprometer um único laptop de desenvolvedor pode significar acesso direto a toda a esteira de entrega de software da empresa, desde o commit até a produção.

Três campanhas, 48 horas, três registros comprometidos

A gravidade deixou de ser teórica. Nas últimas semanas, três campanhas distintas atingiram os registros npm, PyPI e Docker Hub em uma janela de apenas 48 horas. Todas visavam segredos armazenados em ambientes de desenvolvimento e pipelines de CI/CD: chaves de API, credenciais de cloud, chaves SSH e tokens de acesso.

O caso mais emblemático é o do worm “Mini Shai-Hulud”, que comprometeu pacotes de projetos amplamente utilizados como TanStack, Mistral AI e Guardrails AI. O pacote React Router do TanStack, sozinho, acumula mais de 12 milhões de downloads semanais, colocando código malicioso no coração da cadeia de suprimento de aplicações corporativas modernas. A investigação inicial da Mistral AI confirmou que “um dispositivo de desenvolvedor afetado esteve envolvido” no comprometimento.

Em paralelo, quatro pacotes npm maliciosos foram identificados distribuindo infostealers e o malware de botnet DDoS “Phantom Bot”. O padrão é consistente: atacantes estão mirando o elo mais fraco da cadeia, que não é o servidor de produção com WAF e EDR, mas sim o notebook do desenvolvedor que tem acesso privilegiado a tudo.

IA amplia a superfície de ataque

A proliferação de ferramentas de IA para desenvolvimento agravou o problema. Agentes de IA que operam com acesso ao sistema de arquivos, terminal e credenciais representam novos riscos que muitas organizações ainda não mapearam. Essas ferramentas frequentemente precisam de permissões amplas para funcionar, e cada permissão concedida é uma porta potencial para exfiltração de dados ou execução de código malicioso.

O modelo tradicional de segurança, focado em proteger o que já está rodando, não foi desenhado para lidar com ambientes de desenvolvimento que agora incluem dezenas de plugins, extensões de IDE e agentes autônomos com acesso ao sistema.

Como proteger seu ambiente de desenvolvimento

A resposta para equipes de infraestrutura e DevOps é direta: máquinas de desenvolvimento precisam do mesmo rigor de segurança que ambientes de produção. Na prática, isso significa:

• Auditoria contínua de dependências: ferramentas como npm audit, pip-audit e scanners de containers devem rodar automaticamente em pipelines e também nas máquinas locais dos desenvolvedores, não apenas no CI.
• Controle de acesso a credenciais: segredos não devem ficar em variáveis de ambiente locais ou arquivos .env sem proteção. Cofres de segredos com rotação automática reduzem o impacto de um comprometimento.
• Inventário de ferramentas de terceiros: cada extensão de IDE, plugin de IA ou ferramenta CLI instalada por um desenvolvedor é um potencial vetor de ataque. Manter um inventário aprovado e auditar periodicamente o que está instalado é fundamental.
• Isolamento de ambientes: containers e ambientes virtuais dedicados para cada projeto limitam o raio de explosão de um comprometimento. Se um pacote malicioso executa dentro de um container descartável, o dano potencial é contido.
• Monitoramento de endpoints de desenvolvimento: soluções de EDR e monitoramento, como Wazuh, devem cobrir laptops de desenvolvedores com a mesma prioridade que servidores de produção.

Uma mudança de mentalidade necessária

O padrão dos ataques recentes é claro: comprometer a cadeia de suprimento na fase de desenvolvimento é mais eficiente do que atacar sistemas em produção. Um único pull request malicioso pode afetar milhares de projetos dependentes. Uma única máquina comprometida pode expor toda a infraestrutura de entrega de software.

Tratar máquinas de desenvolvimento como endpoints não gerenciados, prática ainda comum em muitas empresas de médio porte, é um risco que os últimos meses provaram ser real e recorrente. Quem opera pipelines de CI/CD e ambientes DevOps em escala precisa repensar suas políticas de acesso, monitoramento e governança de dependências antes que o próximo ataque à cadeia de suprimento torne essa decisão inevitável.

Fontes

• Developer Workstations Are Now Part of the Software Supply Chain (The Hacker News)
• The Software Supply Chain Is the New Perimeter (OpenVPN Blog)
• Mini Shai-Hulud malware compromises hundreds of open-source packages (CyberScoop)

The post Máquinas de desenvolvedores viram alvo na cadeia de suprimento de software appeared first on Audaz Tecnologia.

Pesquisadores da firma de seguranca depthfirst descobriram uma vulnerabilidade critica no NGINX que existia desde 2008, sem deteccao, por 18 anos. A falha (CVE-2026-42945, CVSS 9.2) permite execucao remota de codigo (RCE) e afeta todas as versoes do NGINX Open Source de 0.6.27 ate 1.30.0, alem de multiplos produtos da F5 como NGINX Plus, NGINX Ingress Controller e NGINX Gateway Fabric.

Um exploit funcional ja foi publicado no GitHub, e a combinacao de severidade alta com ampla superficie de ataque torna essa uma das CVEs mais urgentes de 2026 para equipes de infraestrutura.

Como a falha funciona

A vulnerabilidade e um heap buffer overflow no modulo ngx_http_rewrite_module, responsavel por reescrita de URLs e atribuicao de variaveis. O motor interno do NGINX processa diretivas rewrite e set em duas passagens: a primeira calcula o tamanho da memoria necessaria e a segunda escreve os dados no buffer alocado.

O problema ocorre quando uma diretiva rewrite contem um caractere de interrogacao (?). Esse caractere ativa permanentemente uma flag is_args = 1 no motor principal. Porem, na primeira passagem (calculo de tamanho), um sub-motor zerado e utilizado, fazendo com que is_args seja efetivamente zero. O tamanho e calculado sem considerar o escape de URI.

Na segunda passagem, o motor principal roda com is_args = 1, e a funcao ngx_escape_uri expande cada byte escapavel de 1 para 3 bytes. O resultado: muito mais dados sao escritos no buffer do que o espaco alocado comporta, causando o overflow classico de heap. A arquitetura multi-processo deterministica do NGINX facilita a exploracao, permitindo heap spray previsivel via corpos POST.

Impacto e produtos afetados

O padrao de configuracao que dispara a falha (uso combinado de rewrite e set) e extremamente comum em deployments de API gateway e reverse proxy. A lista de produtos afetados inclui:

• NGINX Open Source: versoes 0.6.27 a 1.30.0
• NGINX Plus: R32 a R36
• NGINX Instance Manager: 2.16.0 a 2.21.1
• F5 WAF para NGINX: 5.9.0 a 5.12.1
• NGINX App Protect WAF: 4.9.0 a 4.16.0 e 5.1.0 a 5.8.0
• NGINX Gateway Fabric: 1.3.0 a 1.6.2 e 2.0.0 a 2.5.1
• NGINX Ingress Controller: 3.5.0 a 3.7.2, 4.0.0 a 4.0.1, 5.0.0 a 5.4.1

A auditoria revelou ainda tres CVEs adicionais no mesmo ciclo: CVE-2026-42946 (severidade alta, CVSS 8.3, crash por alocacao massiva nos modulos SCGI/uWSGI), CVE-2026-40701 (media, use-after-free via OCSP no modulo SSL) e CVE-2026-42934 (media, leitura fora dos limites no modulo charset). No total, a F5 corrigiu mais de 50 vulnerabilidades em produtos BIG-IP, BIG-IQ e NGINX nesta rodada.

O que fazer agora

1. Atualize imediatamente para NGINX 1.30.1 ou 1.31.0. A F5 publicou o advisory oficial K000161019 em 13 de maio de 2026.
2. Audite configuracoes que utilizem diretivas rewrite e set em conjunto, especialmente em setups de API gateway e reverse proxy expostos a internet.
3. Considere protecao adicional via WAF enquanto o patch nao for aplicado, restringindo deployments NGINX expostos diretamente.
4. Atualize produtos derivados (NGINX Plus, Ingress Controller, Gateway Fabric) para as versoes corrigidas listadas no advisory da F5.

O que observar daqui

Uma vulnerabilidade que existia ha 18 anos em um dos web servers mais utilizados do mundo levanta questoes serias sobre a auditoria de codigo em projetos de infraestrutura critica. O NGINX e o web server ou reverse proxy padrao em uma parcela significativa dos servidores de producao globais, incluindo ambientes Kubernetes (via Ingress Controller) e API gateways corporativos.

O fato de que o padrao de configuracao que dispara a falha e comum em deployments reais, combinado com a disponibilidade publica de um exploit funcional de RCE, torna essa CVE especialmente perigosa para organizacoes que nao aplicarem o patch rapidamente. A equipe da AlmaLinux ja reproduziu o problema independentemente em todas as releases suportadas, confirmando a viabilidade pratica da exploracao.

Equipes de infraestrutura devem tratar essa atualizacao como prioridade maxima. Para ambientes que utilizam NGINX como ponto de entrada para APIs e servicos criticos, o risco de exposicao e real e imediato.

Fontes

• Cryptika – Critical 18-Year-Old NGINX Vulnerability Enables Remote Code Execution Attacks
• SecurityWeek – F5 Patches Over 50 Vulnerabilities
• NGINX Official Security Advisories

The post Vulnerabilidade critica de 18 anos no NGINX exige patch imediato appeared first on Audaz Tecnologia.

A Cisco reportou resultados do terceiro trimestre fiscal que superaram todas as expectativas de analistas. A receita atingiu US$ 15,84 bilhoes (crescimento de 12% ano a ano), com lucro por acao ajustado de US$ 1,06 contra US$ 1,04 esperados pelo consenso. As acoes subiram 15% no dia, o melhor desempenho diario da empresa desde 2011.

O destaque ficou com o segmento de networking, que cresceu 25% para US$ 8,82 bilhoes, superando o consenso de US$ 8,47 bilhoes. Os pedidos acumulados de infraestrutura de IA vindos de hiperscalers atingiram US$ 5,3 bilhoes nos tres primeiros trimestres do ano fiscal 2026. A Cisco ja atingiu sua meta anual de receita de hiperscalers com um trimestre fiscal ainda pela frente.

O que significa “superciclo de redes”

O CEO Chuck Robbins usou o termo “superciclo de redes” para descrever o momento atual. Em entrevista a CNBC, Robbins foi direto: a explosao de demanda por infraestrutura de IA esta criando uma onda de investimento em equipamentos de rede que rivaliza com os maiores ciclos de expansao da historia do setor.

A logica e simples. Clusters de GPUs para treinamento e inferencia de modelos de IA exigem conectividade de altissima largura de banda e baixa latencia entre nos. Datacenters de hiperscalers estao sendo expandidos ou construidos do zero, e cada novo rack de GPUs precisa de switches, roteadores e infraestrutura de rede proporcionais. A Cisco, como maior fabricante mundial de equipamentos de rede, esta no epicentro desse movimento.

Em resposta a demanda, a empresa elevou sua meta anual de pedidos de IA de US$ 5 bilhoes para US$ 9 bilhoes e a projecao de receita de IA de US$ 3 bilhoes para US$ 4 bilhoes. Para o quarto trimestre fiscal, a Cisco projeta receita entre US$ 16,7 bilhoes e US$ 16,9 bilhoes.

Alem do hardware de rede

A Cisco tambem expandiu sua atuacao no ecossistema de IA para alem do hardware. A empresa integra o Project Glasswing da Anthropic, iniciativa que deu acesso a um grupo seleto de organizacoes para testar o modelo Mythos e suas implicacoes de ciberseguranca. No mesmo trimestre, a Cisco lancou um leaderboard para classificar modelos de IA generativa com base em sua robustez contra ataques ciberneticos.

Esse posicionamento duplo, fornecedora de infraestrutura fisica e participante ativa no ecossistema de seguranca de IA, diferencia a Cisco de concorrentes que atuam apenas em uma das frentes.

O que isso significa para times de infraestrutura

O superciclo de redes anunciado pela Cisco tem implicacoes praticas para equipes de TI de empresas de medio e grande porte:

• Pressao na cadeia de fornecimento: quando hiperscalers como AWS, Azure e Google absorvem volumes massivos de equipamentos de rede, prazos de entrega para empresas menores podem se estender. Equipes que planejam upgrades de infraestrutura de rede devem antecipar pedidos.
• Requalificacao de rede: mesmo empresas que nao operam clusters de IA podem se beneficiar das inovacoes que o ciclo traz. Novas geracoes de switches e roteadores projetados para cargas de IA tendem a melhorar desempenho e eficiencia energetica para qualquer workload.
• Planejamento orcamentario: o aumento de demanda pode pressionar precos de equipamentos de rede no medio prazo. CTOs devem avaliar se renovacoes de infraestrutura planejadas para 2027 deveriam ser antecipadas.
• Convergencia rede e seguranca: a entrada da Cisco no ecossistema de seguranca de IA (via Glasswing e o leaderboard de robustez) sinaliza que equipamentos de rede serao cada vez mais integrados a camadas de protecao inteligente, algo que equipes de infra precisam considerar na arquitetura.

O que observar daqui

O cenario reforca um ponto que ja vinha se desenhando: a infraestrutura de rede, historicamente tratada como commodity, volta ao centro das decisoes estrategicas de TI. Empresas que dependem de conectividade de alta performance, seja para ambientes Kubernetes, APIs criticas ou workloads de dados, devem acompanhar de perto como esse ciclo de investimento afeta disponibilidade e precificacao de equipamentos nos proximos trimestres.

Com a Cisco projetando receita recorde no Q4 e a meta de pedidos de IA quase dobrando dentro do mesmo ano fiscal, o superciclo parece ter sustentacao real, nao apenas otimismo de mercado. A questao agora e quanto dessa onda de investimento em hiperscalers transborda para o mercado corporativo em geral.

Fontes

• CNBC – Cisco posts best day since 2011 on strong AI demand
• CNBC – Cisco (CSCO) Q3 earnings report 2026
• Reuters – Anthropic’s Mythos sends U.S. banks rushing to plug cyber holes

The post Cisco dispara 15% e anuncia superciclo de redes impulsionado por IA appeared first on Audaz Tecnologia.

Os maiores bancos dos Estados Unidos estao vivendo uma corrida sem precedentes. Com acesso ao modelo Mythos da Anthropic, essas instituicoes estao descobrindo centenas a milhares de vulnerabilidades em seus sistemas, muitas delas desconhecidas ate agora. O prazo de correcao, que antes era medido em semanas, esta sendo comprimido para dias.

Segundo a Reuters, os bancos que possuem acesso ao Mythos estao compartilhando as descobertas com instituicoes menores, que nao tem recursos para operar o modelo. O custo e proibitivo para a maioria: US$ 25 por milhao de tokens de entrada e US$ 125 por milhao de tokens de saida, cinco vezes mais caro que o Opus 4.7 da Anthropic.

Falhas menores combinadas viram risco critico

Uma das capacidades mais preocupantes do Mythos e o encadeamento de vulnerabilidades. Falhas classificadas individualmente como baixo ou medio risco se transformam em vetores de ataque criticos quando combinadas. Essa tecnica invalida a pratica comum de ignorar CVEs com pontuacao CVSS inferior a 7.

O modelo tambem se destaca em encontrar falhas em codigo proprietario e em bibliotecas open-source, pressionando bancos que ainda operam com sistemas legados sem suporte ativo de software. A velocidade exigida para aplicar correcoes nao tem precedente no setor.

“O risco cibernetico agora se move na velocidade das maquinas, enquanto boa parte da defesa bancaria ainda opera na velocidade humana”, afirmou Nitin Seth, CEO da Incedo.

Capacidade ja existia em modelos anteriores

Apesar do alarme em torno do Mythos, especialistas ouvidos pela CNBC alertam que a capacidade de encontrar vulnerabilidades em escala ja estava disponivel em modelos anteriores, incluindo versoes mais antigas da propria Anthropic e da OpenAI.

“Os modelos que temos agora ja sao poderosos o suficiente para detectar zero-days em larga escala, e isso ja e assustador o bastante”, disse Klaudia Kloc, CEO da Vidoc Security. Segundo ela, essa capacidade existe ha “alguns meses, se nao um ano”.

Ben Harris, CEO da watchTowr, complementou: “O que estamos vendo e que pessoas conseguem reproduzir as vulnerabilidades encontradas pelo Mythos por meio de orquestracao inteligente de modelos publicos”. A reacao da OpenAI foi rapida: poucos dias depois, Sam Altman anunciou o GPT-5.5-Cyber, um modelo voltado especificamente para defesa cibernetica.

Janela de seis a doze meses

O CEO da Anthropic, Dario Amodei, alertou que organizacoes tem de seis a doze meses para corrigir falhas antes que modelos chineses de IA desenvolvam capacidades equivalentes. Para ampliar o acesso defensivo, a empresa lancou o programa Claude Security, uma ferramenta de varredura disponivel para mais organizacoes.

O Secretario do Tesouro americano, Scott Bessent, reiterou a mensagem ao afirmar que os bancos devem “levar o modelo Mythos a serio” e usa-lo para encontrar brechas em suas defesas.

O que isso significa para times de infra no Brasil

A realidade revelada pelo Mythos nao e exclusiva do setor bancario americano. Qualquer organizacao que dependa de sistemas legados, codigo open-source sem auditoria recente ou ciclos longos de patch esta exposta ao mesmo tipo de risco.

Para equipes de seguranca e infraestrutura em empresas brasileiras, tres acoes se destacam:

• Reduzir o tempo medio de correcao. Se o ciclo atual de patches e mensal, comprima para semanal nos componentes criticos. Ferramentas como Wazuh e Zabbix ajudam a priorizar o que corrigir primeiro com base em severidade e exposicao real.
• Auditar dependencias open-source. Bibliotecas desatualizadas sao o alvo favorito de varreduras automatizadas. Pipelines DevSecOps com verificacao continua de CVEs (Horusec, Trivy, Grype) reduzem a superficie de ataque antes que um modelo de IA a encontre.
• Tratar vulnerabilidades de baixo risco como risco real. O encadeamento demonstrado pelo Mythos mostra que falhas moderadas combinadas podem abrir portas criticas. A priorizacao por CVSS isolado nao e mais suficiente.

A corrida entre ofensiva e defensiva em ciberseguranca ganhou um novo capitulo. A IA nao criou vulnerabilidades novas. Ela tornou visiveis as que ja existiam, em uma velocidade que a maioria das organizacoes nao consegue acompanhar. Quem ainda trata gestao de vulnerabilidades como tarefa trimestral precisa rever sua estrategia antes que a proxima geracao de modelos torne essas falhas acessiveis a qualquer atacante com um terminal e um modelo publico.

Fontes

• Anthropic’s Mythos sends US banks rushing to plug cyber holes
• Anthropic’s Mythos set off a cybersecurity ‘hysteria.’ Experts say the threat was already here
• Banks Slash Patch Times as Anthropic’s Mythos Exposes Security Gaps

The post IA acelera descoberta de falhas e pressiona ciclos de correcao appeared first on Audaz Tecnologia.

A OpenAI anunciou nesta semana a criacao da OpenAI Deployment Company, uma nova unidade dedicada a ajudar organizacoes a construir e implantar sistemas de IA em escala. O projeto nasce com US$ 4 bilhoes em capital inicial e a participacao de 19 firmas globais de investimento, consultorias e integradoras de sistemas.

A lideranca financeira ficou com a TPG, ao lado de Advent, Bain Capital e Brookfield como co-lideres fundadores. Goldman Sachs, SoftBank Corp., Warburg Pincus e Emergence Capital tambem participam do consorcio. Grandes consultorias como Bain & Company, Capgemini e McKinsey & Company entraram como parceiras de integracao, dando a OpenAI acesso direto a empresas que ja passam por transformacao digital.

O movimento e significativo porque marca uma mudanca de estrategia. Ate agora, a OpenAI era essencialmente uma fornecedora de modelos via API. Empresas acessavam o ChatGPT ou o GPT-4 e construiam suas solucoes por conta propria. A Deployment Company muda essa logica ao colocar engenheiros da OpenAI diretamente dentro das equipes dos clientes para identificar casos de uso de alto impacto e redesenhar fluxos de trabalho criticos.

Aquisicao da Tomoro acelera a execucao

Simultaneamente, a OpenAI adquiriu a Tomoro, consultoria de IA aplicada que atende clientes como Mattel, Red Bull, Tesco e Virgin Atlantic. A aquisicao traz cerca de 150 engenheiros com experiencia em implantacao corporativa desde o primeiro dia.

O desafio agora e ajudar empresas a integrar esses sistemas na infraestrutura e fluxos que movem seus negocios, afirmou Denise Dresser, CRO da OpenAI. A declaracao reflete uma tendencia mais ampla: fabricantes de modelos estao migrando de simples acesso via API para integracao direta nas operacoes corporativas, competindo com consultorias tradicionais de TI.

O contexto fica ainda mais claro quando se olha os investimentos recentes. A Nvidia comprometeu mais de US$ 40 bilhoes em participacoes no ecossistema de IA em 2026, incluindo US$ 30 bilhoes na propria OpenAI. O capital disponivel para implantacao empresarial de IA atingiu um patamar sem precedentes.

Parceria com a Microsoft ganha novos contornos

A iniciativa vem acompanhada de uma renegociacao importante com a Microsoft. As duas empresas estabeleceram um teto de US$ 38 bilhoes em pagamentos de receita compartilhada, que continuarao ate 2030. A Microsoft mantera licenca sobre a propriedade intelectual dos modelos ate 2032, porem sem exclusividade.

Na pratica, isso significa que a OpenAI agora pode atender clientes em qualquer provedor de cloud, incluindo Amazon e Google. A flexibilidade e estrategica: muitas empresas operam em ambientes multi-cloud e resistem a depender exclusivamente do Azure para consumir IA. Denise Dresser reconheceu que a parceria anterior “limitou nossa capacidade de atender empresas onde elas estao”.

A Microsoft continua como provedora principal de cloud e mantem prioridade nos lancamentos, mas perde a exclusividade que sustentou seu diferencial competitivo em IA nos ultimos anos.

O que isso significa para times de TI no Brasil

Para CTOs e heads de infraestrutura, a mensagem e clara: o mercado de IA corporativa esta migrando de experimentacao para implantacao estruturada. O modelo de “consultoria embarcada” que a OpenAI esta criando provavelmente sera replicado por concorrentes como Anthropic e Google.

As implicacoes praticas para equipes de TI incluem:

• Demanda crescente por profissionais que saibam integrar modelos de IA em pipelines existentes de CI/CD e observabilidade
• Necessidade de revisao de arquitetura de dados antes de adotar solucoes de IA em escala
• Avaliacao cuidadosa de lock-in ao escolher entre provedores de IA e cloud
• Preparacao para um cenario onde consultorias de IA embarcada competem com equipes internas pelo mesmo escopo

A corrida por clientes enterprise esta acelerando. Empresas com infraestrutura moderna, processos bem definidos e dados organizados terao vantagem na hora de capturar valor real da inteligencia artificial. Quem ainda depende de ambientes legados e silos de dados vai enfrentar uma barreira de entrada cada vez maior.

Fontes

• TechStartups – OpenAI launches $4B enterprise AI unit to accelerate corporate adoption
• CNBC – OpenAI shakes up partnership with Microsoft, capping revenue share payments
• LLM Stats – AI News (Nvidia investments)

The post OpenAI cria unidade de US$ 4 bilhoes para implantar IA nas empresas appeared first on Audaz Tecnologia.

Em 7 de maio de 2026, uma falha termica na zona de disponibilidade use1-az4 da regiao US-EAST-1 da AWS provocou perda de energia que danificou instancias EC2 e volumes EBS. O evento comecou as 17h25 (horario do Pacifico) e a recuperacao total levou entre 18 e 20 horas, um intervalo extenso para a maior provedora de nuvem publica do mundo.

A Coinbase reportou falhas em multiplas zonas AWS que causaram interrupcao prolongada dos servicos de trading. FanDuel e CME Group tambem foram atingidos. Para quem depende de infraestrutura cloud em producao, o incidente e um lembrete incomodo: uma unica zona de disponibilidade pode derrubar operacoes inteiras quando a arquitetura nao esta preparada.

Por que US-EAST-1 importa tanto

US-EAST-1, localizada no norte da Virginia, e a regiao mais antiga e mais utilizada da AWS. Ela processa uma parcela do trafego global da internet maior do que qualquer outra instalacao de data center individual. Muitas APIs da propria AWS tem dependencias implicitas nessa regiao, e uma quantidade significativa de servicos SaaS de terceiros roda ali por padrao.

Isso cria um efeito de concentracao: quando algo da errado em US-EAST-1, o raio de explosao vai muito alem dos clientes que escolheram deliberadamente aquela regiao. Servicos que voce nem sabia que dependiam de la podem parar de funcionar.

O mecanismo da falha

A AWS ainda nao publicou post-mortem detalhado, mas o que se sabe e que superaquecimento causou perda de energia localizada na zona use1-az4. O calor excessivo provavelmente ativou protecoes automaticas que desligaram equipamentos para evitar danos permanentes ao hardware.

O resultado pratico: instancias EC2 foram encerradas de forma abrupta e volumes EBS ficaram inacessiveis ou corrompidos. Para workloads que dependiam exclusivamente dessa zona, nao houve failover automatico. A restauracao de volumes EBS em cenarios assim pode levar horas, mesmo depois que a infraestrutura fisica volta a operar normalmente.

O que times de infra devem revisar agora

Incidentes termicos em data centers nao sao novidade, mas cada um reacende a mesma lista de perguntas que muitos times evitam responder ate que seja tarde demais:

• Distribuicao entre zonas de disponibilidade: servicos criticos devem rodar em pelo menos duas AZs, com Auto Scaling Groups configurados para rebalancear automaticamente. Se o custo de multi-AZ parece alto, compare com o custo de 20 horas fora do ar.
• Snapshots de EBS entre regioes: volumes EBS sao replicados dentro de uma unica AZ. Se a AZ cai, o volume pode ficar indisponivel. Snapshots em outra regiao sao a unica protecao real contra esse cenario.
• Testes de failover: simular a perda de uma AZ inteira e um exercicio que poucos times fazem com regularidade. Chaos engineering nao e luxo reservado para Big Tech.
• Monitoramento de saude da infraestrutura: ferramentas como Zabbix e CloudWatch podem detectar degradacao termica e de desempenho antes que ela vire indisponibilidade total. Alertas proativos reduzem tempo de reacao de forma significativa.
• Plano de continuidade documentado: quem pode tomar a decisao de failover? Qual o RTO aceitavel? Se a resposta nao esta escrita, o tempo de recuperacao sera ditado pela improvisacao.

E para quem opera no Brasil?

Muitas empresas brasileiras ainda concentram cargas de trabalho em US-EAST-1 por custo ou por habito, mesmo tendo a regiao sa-east-1 (Sao Paulo) disponivel. Vale reavaliar essa escolha: alem de latencia menor, sa-east-1 facilita a conformidade com a LGPD ao manter dados em territorio nacional.

Para cargas que exigem disponibilidade acima de 99,9%, considerar uma arquitetura multi-regiao pode ser o que separa um incidente gerenciavel de uma crise operacional. O custo adicional de replicacao entre regioes e mensuravel. O custo de uma interrupcao de 20 horas em producao, na maioria dos casos, nao e.

O que observar daqui

Quando a AWS publicar o post-mortem, preste atencao em dois pontos: se o mecanismo de isolamento entre AZs funcionou conforme projetado e se houve cascata para servicos gerenciados que dependem de US-EAST-1 implicitamente. Independentemente das conclusoes, este incidente e um bom gatilho para revisar seu plano de disaster recovery antes que a proxima falha decida faze-lo por voce.

Fontes

• The Tech Marketer
• CNBC

The post Falha termica na AWS derrubou us-east-1 por quase 20 horas appeared first on Audaz Tecnologia.