(mas também nos ajuda a atualizar mais rápido)

Nos últimos dois anos, a promessa da inteligência artificial no software era que ia escrever o nosso código e corrigir os nossos erros enquanto dormíamos. Esta última semana mostrou o que realmente acontece. A IA está a encontrar falhas mais depressa do que as pessoas que mantêm o software as conseguem corrigir e, ao mesmo tempo, tornou-se a única forma de os pequenos operadores acompanharem o ritmo das atualizações.

A primeira parte da história veio do PostgreSQL. A versão 19 devia sair dentro do prazo, mas foi adiada para novembro (e entre oito a dez funcionalidades foram retiradas e empurradas para a versão 20). A razão é simples. Começaram a usar revisões de código assistidas por IA no código novo, e a IA encontrou mais erros reais do que a equipa humana tinha tempo para corrigir antes da data limite.

É uma boa notícia que sabe a má notícia. Queremos que os erros sejam descobertos antes de a base de dados sair, claro, mas uma máquina consegue ler um milhão de linhas de código C numa tarde. Uma equipa humana continua a ter de ler cada relatório, escrever a correção, testar tudo e garantir que a emenda não estraga outra coisa qualquer.

A segunda parte da história bateu à porta dos nossos próprios servidores na quarta-feira, 21 de outubro.

O projeto PHP divulgou duas falhas críticas de execução remota de código chamadas php2shell (CVE-2026-109618 e CVE-2026-109619, com gravidade 9.2). Tiveram de lançar as versões corrigidas um dia mais cedo porque os detalhes vieram a público antes do tempo. Mais tarde nessa semana, a Amazon informou que os seus sensores apanharam alguém a tentar explorar a falha no dia 17 de outubro, quatro dias inteiros antes de a atualização ser pública.

Administro servidores Linux desde que a Le e eu começámos a RogerLe.com em outubro de 1996. Há trinta anos, quando saía um erro destes, tínhamos alguns dias para ler a lista de correio, testar a atualização e marcar uma janela de manutenção. Hoje a janela é de menos quatro dias.

Quando estamos contra ataques automáticos que começam antes de a correção existir, temos de usar a nossa própria automação do lado da defesa. Na nossa frota, temos servidores com PHP 8.3, 8.4 e 8.5 (e, até esta semana, ainda tínhamos uma máquina antiga com PHP 7.4). Foi assim que lidámos com o php2shell quando a notícia saiu:

  1. Antes de os pacotes oficiais estarem prontos em todo o lado, pedi a um dos elementos da minha equipa de IA para aplicar de imediato as mitigações recomendadas em todos os servidores, para não ficarmos expostos.
  2. Configurámos um vigilante automático nos repositórios para esperar pelos pacotes corrigidos, instalar as atualizações (8.3.36, 8.4.27 e 8.5.12) e reiniciar o php-fpm no exato minuto em que saíssem.
  3. Reformámos finalmente aquele último servidor com PHP 7.4. Como o 7.4 já chegou ao fim de vida, não recebeu correção oficial para o php2shell, e manter um servidor sem atualização hoje em dia é pedir problemas.

Tem graça ouvir dizer que a IA vai substituir os administradores de sistemas. O que fez, na verdade, foi acelerar os dois lados do relógio. A IA está a entregar à equipa do PostgreSQL mais relatórios de erros do que as horas que o dia tem para os resolver, e a ajudar atacantes a sondar servidores PHP quatro dias antes do tempo.

Ao mesmo tempo, permitiu-me aplicar mitigações em toda a nossa frota e deixar um vigilante pronto para instalar as correções reais no minuto em que chegaram ao repositório. O trabalho não vai desaparecer, só já não dá para o fazer à mão.