O que a Apple publicou a 27 de julho
As páginas de segurança da Apple encheram-se num único bloco a 27 de julho. O macOS Tahoe 26.6 chegou como compilação 25G72 com 155 identificadores CVE únicos, acompanhado do Safari 26.6. O iOS 26.6 e o iPadOS 26.6 enumeraram 78 entradas distintas de vulnerabilidade ligadas a 87 CVE únicos. As atualizações do watchOS, do tvOS e do visionOS 26.6 somaram outras 194 depois de removida a sobreposição entre plataformas.
Os componentes citados leem-se como um inventário do sistema inteiro e não como um único canto frágil. No telefone, as correções tocam o núcleo, o WebKit, a ligação sem fios, a Siri, a App Store, o MediaRemote, o ImageIO, o SceneKit, a libc, a CloudAttestation, o Game Center, a Acessibilidade e os Contactos. No Mac, as descrições são mais cruas: falhas que podiam permitir a uma aplicação obter privilégios de administração, sair do seu ambiente isolado, contornar o Gatekeeper, passar ao lado das preferências de privacidade ou alcançar dados protegidos.
A Apple não afirma que alguma delas estivesse a ser explorada antes de as atualizações saírem, e nenhum órgão de comunicação apresentou prova em contrário. Contá-las é curiosamente difícil: publicações especializadas que trabalham sobre o mesmo documento da Apple chegam a números entre cerca de 130 e 155, consoante contem entradas ou identificadores. Essa amplitude é um pormenor, mas mostra que o inventário está escrito para ser lido por uma pessoa e não processado por uma ferramenta.
As sete tentativas são a parte que importa ler
O que decide não está no número de CVE. O macOS Sequoia 15.7.8 e o macOS Sonoma 14.8.8 saíram no mesmo dia, e só chegaram à publicação depois de a Apple ter emitido sete candidatas a versão final. Uma quinta candidata a 13 de julho já era invulgar o bastante para ser noticiada como rara por si só. Seguiram-se mais duas.
Leia isto como um sinal de engenharia e não como uma curiosidade. Uma candidata a versão final é a compilação que o fornecedor considera terminada. Emitir sete significa que a Apple acreditou repetidamente que a retroportagem estava concluída e descobriu repetidamente que não estava. O ramo atual, o Tahoe, não precisou desse vaivém: foi escrito uma só vez contra o código para o qual as correções tinham sido pensadas.
Em conjunto, o Sequoia 15.7.8 e o Sonoma 14.8.8 resolvem mais de 138 vulnerabilidades distintas. O volume é comparável ao do Tahoe. O que difere é a dificuldade de o levar até lá, e as notas de versão da Apple para os dois ramos antigos quase nada dizem sobre isso: limitam-se a referir que se trata de correções de segurança importantes, recomendadas a todos os utilizadores que ainda trabalham neles.
O argumento da estabilidade funciona ao contrário
A maioria dos parques que fica uma versão atrás fá-lo de propósito. O raciocínio é conhecido e habitualmente sensato: deixar que sejam outros a encontrar as regressões, manter o parque numa compilação que já está no mundo há tempo suficiente para ser aborrecida e atualizar quando o negócio tiver uma semana calma. Aplicada às funcionalidades, essa lógica aguenta-se.
Aplicada às correções de segurança, o dia 27 de julho inverte-a. O ramo antigo não é o mais assente. É aquele que exigiu sete tentativas, porque uma retroportagem não é o mesmo trabalho que uma correção: a falha é encontrada e reparada no código atual e depois transportada para trás, para uma base de código que entretanto avançou. Cada versão de distância entre o seu parque e a linha da frente da Apple é distância técnica que alguém tem de vencer sob pressão de tempo, e este mês foram precisas sete passagens.
A consequência de segunda ordem tem que ver com prova e não com apetite pelo risco. A NIS2 exige às organizações abrangidas que tratem as vulnerabilidades como um processo documentado e não como um instinto, e a pergunta de uma auditoria raramente é se aplicou a correção. É quando soube, o que decidiu e porquê. "Ficamos uma versão atrás por estabilidade" só é uma resposta defensável até o registo mostrar que o ramo antigo recebe as correções de forma mais lenta e mais frágil. Em Portugal, esse registo é lido pelo CNCS.
A ordem de trabalho desta semana
Comece pelas máquinas já expostas e não pelas mais fáceis de alcançar. Tudo o que use o Safari ou o WebKit contra páginas sem confiança, qualquer Mac em que um utilizador comum possa plausivelmente ser levado a abrir um ficheiro forjado e qualquer equipamento fora da rede do escritório pertence à primeira vaga. Os contornos do Gatekeeper e das preferências de privacidade pesam sobretudo nos portáteis que saem do edifício.
Depois trate o parque antigo com honestidade. Se um conjunto de Mac está no Sonoma ou no Sequoia porque o equipamento não suporta o Tahoe, isso é um facto que se planeia e que a certa altura se orçamenta, não uma posição que se defende. Se estão numa versão antiga por opção, este é o mês de perguntar se essa opção ainda compra aquilo que devia comprar.
Uma coisa para registar. Anote a data em que as notas foram publicadas e a data em que cada grupo de equipamentos foi atualizado, porque a distância entre esses dois números é a única parte disto que uma auditoria poderá verificar mais tarde, e a única que está sob o seu controlo.
Leia a seguir: A correção do nginx saiu, o exploit chega em agosto | Duas falhas do Cursor com nota 9.8 entregam a máquina do programador aos atacantes



