CPU de Julho de 2026: Oracle Corrige 1.449 Vulnerabilidades e Muda o Jogo do Patching
Em julho de 2026, a Oracle publicou o maior Critical Patch Update (CPU) da sua história: 1.449 correções de segurança em uma única leva, cobrindo praticamente todo o portfólio, do Oracle Database ao Fusion Middleware. Para quem administra ambientes Oracle no dia a dia, o número por si só já é um alerta: a era do "patch trimestral e pronto" está claramente no fim.
Este artigo explica o que aconteceu, por que o volume disparou, quais falhas exigem atenção imediata e o que muda na rotina prática de quem é responsável por manter esses ambientes seguros.
Por Que o Volume de Patches Disparou
Dos 1.449 patches, apenas 64 foram reportados por pesquisadores externos. A esmagadora maioria veio dos próprios processos internos da Oracle, num cenário em que especialistas apontam o uso crescente de ferramentas de detecção de vulnerabilidades assistidas por IA como fator central. Não é sinal de que o software da Oracle piorou: é sinal de que a capacidade de encontrar falhas (dentro e fora da empresa) melhorou mais rápido do que a capacidade das equipes de TI de aplicar correções.
A Microsoft viveu o mesmo fenômeno no mesmo mês, com 622 CVEs corrigidos em seu Patch Tuesday de julho. Executivos de segurança já tratam isso como o novo normal: lotes de patch cada vez maiores, com menos tempo de reação para quem precisa aplicá-los.
As Falhas Que Mais Importam
Dez das 1.449 correções receberam a nota máxima de severidade (CVSS 10.0), todas concentradas no Oracle Fusion Middleware. Duas chamaram atenção especial do Centro Nacional de Segurança Cibernética da Holanda (NCSC):
CVE-2026-47056, no Oracle Data Integrator, permite comprometimento por atacante não autenticado.
CVE-2026-60217, no Oracle Coherence, tem o mesmo risco: exploração remota sem necessidade de credenciais.
Ambientes que usam ODI para integração de dados ou Coherence para cache distribuído devem tratar essas duas como prioridade máxima, independentemente de qualquer cronograma de patching já planejado.
O Que Muda na Rotina do DBA
Como resposta ao volume crescente, a Oracle passou a emitir, além do CPU trimestral tradicional, Critical Security Patch Updates (CSPUs) mensais para agilizar a correção das falhas mais urgentes. Na prática, isso significa que o calendário de patching de qualquer ambiente Oracle sério precisa deixar de ser trimestral por padrão.
Um checklist prático para adaptar a rotina:
Migrar de um ciclo de aplicação trimestral para um ciclo de avaliação mensal, mesmo que a aplicação efetiva de alguns patches continue trimestral por questões de janela de manutenção.
Priorizar por CVSS e por exposição real do ambiente, não aplicar tudo de uma vez sem triagem: nem todo patch crítico se aplica ao seu cenário (ex.: um patch de Coherence não importa se você não usa Coherence).
Manter um ambiente de homologação atualizado o suficiente para testar patches críticos em poucos dias, não semanas.
Documentar formalmente quais CVEs foram avaliados e a decisão tomada (aplicar, adiar, não aplicável) — isso vira evidência de governança em auditorias.
Perguntas Frequentes
O recorde de patches significa que o Oracle Database ficou menos seguro?
Não necessariamente. O aumento reflete, em boa parte, uma capacidade maior (da Oracle e do mercado) de encontrar vulnerabilidades antes que sejam exploradas, não necessariamente mais falhas sendo introduzidas.
Preciso aplicar os 1.449 patches no meu ambiente?
Não. A esmagadora maioria não se aplica ao seu cenário específico — a triagem por produto instalado e exposição real é essencial antes de qualquer aplicação.
O que é exatamente um CSPU e em que ele difere do CPU trimestral?
O CSPU (Critical Security Patch Update) é um lançamento mensal focado nas vulnerabilidades mais urgentes, criado para reduzir o tempo de exposição entre a descoberta de uma falha crítica e sua correção, sem esperar o próximo CPU trimestral.
As duas CVEs críticas (ODI e Coherence) afetam todo ambiente Oracle?
Não. Elas afetam especificamente quem usa Oracle Data Integrator e Oracle Coherence. Ambientes que não usam esses produtos não são impactados por essas duas falhas específicas, mas devem revisar as demais 1.447 conforme seu próprio portfólio instalado.
Precisa de ajuda para estruturar um processo de patching contínuo no seu ambiente Oracle, em vez de correr atrás do próximo CPU? Fale com a equipe PeopleDBA Consultoria e agende uma avaliação especializada.
