Em resumo: Com o unattended-upgrades no Debian e no Ubuntu e o dnf-automatic na família RHEL, os servidores Linux aplicam por si as atualizações de segurança. Para que uma atualização também atue, os serviços afetados, como o PHP-FPM, têm de reiniciar depois; verifique-o com o needrestart ou com as horas de arranque dos processos. As fontes de terceiros, como o sury.org, têm de ser libertadas expressamente; contentores e mudanças de versão principal não são cobertos pela automatização.
Do patch ao servidor: a automatização poupa tempo
Quando o php.net publicou, a 21 de outubro de 2026, às 16 horas, hora alemã, os patches contra o PHP2Shell, começou para os administradores uma corrida. Segundo relatos, as distribuições entregaram os seus backports em parte ainda no mesmo dia. Os servidores com atualizações de segurança automáticas puderam instalar os novos pacotes na execução planeada seguinte, sem que ninguém tivesse de intervir.
Esta é a boa notícia. A menos boa: instalado não significa eficaz. Um serviço PHP-FPM que corre há semanas continua a trabalhar com o código antigo na memória até ser reiniciado. E os pacotes de fontes de terceiros, os contentores ou os painéis de alojamento com gestão própria do PHP ficam muitas vezes fora da automatização.
Este artigo mostra como configurar atualizações de segurança automáticas e completá-las de modo que protejam realmente num caso grave.
unattended-upgrades no Debian e no Ubuntu
No Ubuntu, o pacote unattended-upgrades está instalado por defeito e aplica atualizações de segurança. No Debian, instala-o quando necessário. É controlado através de dois ficheiros em /etc/apt/apt.conf.d/.
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
O ficheiro 20auto-upgrades define se e com que frequência as listas de pacotes são atualizadas e as atualizações aplicadas. O valor é o número de dias; "1" significa diariamente:
// /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
Em 50unattended-upgrades consta de que fontes as atualizações podem vir, se depois se reinicia e quem recebe uma mensagem. Por defeito, só estão libertadas as fontes de segurança oficiais da distribuição. Segundo a documentação do Ubuntu, não basta integrar mais um repositório: tem de constar também desta lista, caso contrário é ignorado pela automatização. Isto afeta, por exemplo, o repositório de terceiros sury.org, que, segundo relatos, disponibilizou builds do PHP para todos os ramos de 5.6 a 8.5. O contexto está no artigo O repositório sury.org.
Se tudo está certo mostra-o uma execução de teste que não altera nada:
sudo unattended-upgrade -v --dry-run
# Registos das execuções reais
ls -l /var/log/unattended-upgrades/
dnf-automatic no RHEL, AlmaLinux e Rocky Linux
Na família RHEL, o dnf-automatic assume a mesma tarefa. A configuração está em /etc/dnf/automatic.conf. Segundo a documentação, upgrade_type = security verifica apenas atualizações com aviso de segurança, e apply_updates está por defeito desativado.
# /etc/dnf/automatic.conf (excerto)
[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
reboot = never
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers 'dnf-automatic*'
Além do dnf-automatic.timer, que segue o ficheiro de configuração, existem temporizadores que apenas comunicam, apenas descarregam ou instalam sempre. Para começar, o temporizador com ficheiro de configuração é o mais rastreável.
A parte subestimada: reiniciar serviços
O gestor de pacotes substitui ficheiros no disco. Os processos em execução mantêm o código antigo na memória. No PHP, isto significa: enquanto o PHP-FPM ou o Apache com mod_php não forem reiniciados, a vulnerabilidade permanece aberta.
| Ferramenta | Sistema | O que faz |
|---|---|---|
| needrestart | Debian, Ubuntu | reconhece serviços com ficheiros desatualizados; no Ubuntu, a partir da 24.04, reinicia-os por defeito automaticamente |
dnf needs-restarting -s |
família RHEL | lista serviços que deveriam ser reiniciados |
Automatic-Reboot |
unattended-upgrades | reinicia o servidor quando uma atualização o exige; por defeito desligado |
reboot |
dnf-automatic | never, when-changed ou when-needed |
Segundo a documentação do Ubuntu, os serviços excluídos pelo needrestart continuam a correr com ficheiros antigos até ao reinício manual. Verifique por isso, após cada atualização do PHP, a hora de arranque dos processos, como descrito em Reiniciar o PHP-FPM e todos os workers.
Nos backports, o número de versão do PHP apresentado mantém-se muitas vezes igual. O patch comprova-se através do changelog do pacote com os números CVE, por exemplo com apt-get changelog ou rpm -q --changelog. Como se faz em pormenor mostra-o Debian e Ubuntu: o meu pacote PHP está corrigido?.
O que a automatização não cobre
As atualizações automáticas são uma peça, não uma gestão de patches completa. Algumas áreas precisam de procedimentos próprios:
- Contentores: o PHP em imagens Docker não é atualizado por atualizações do anfitrião. Reconstruir as imagens, recriar os contentores.
- Painéis de alojamento: Plesk, cPanel e painéis semelhantes gerem o PHP em parte através de pacotes e mecanismos próprios.
- Versões principais: a mudança, por exemplo, do PHP 8.2, que atinge o fim do suporte a 31/12/2026, para uma versão mais recente não acontece automaticamente.
- Aplicações: CMS, plugins e dependências do Composer têm caminhos de atualização próprios.
- Controlo: alguém tem de ler os registos e as mensagens de erro da automatização. Uma execução que falha em silêncio é pior do que nenhuma, porque simula segurança.
Como estas partes se juntam num processo é descrito em Gestão de patches como processo em vez de bombeiros.
Conclusão: automatização sim, confiança cega não
As atualizações de segurança automáticas pertencem a qualquer servidor Linux acessível a partir da Internet. O PHP2Shell mostrou quão escasso o tempo pode ficar: segundo notícias dos meios de comunicação, foi observada uma primeira tentativa de ataque já a 17 de outubro, quatro dias antes dos patches. Quem, depois disso, ainda espera por uma janela de manutenção manual perde tempo valioso.
A automatização só lhe tira o trabalho de aplicar. O reinício dos serviços, a comprovação do nível de patches, os contentores, os painéis e a mudança atempada para versões suportadas continuam a ser tarefas pelas quais alguém tem de ser responsável. Defina esta responsabilidade por escrito e verifique por amostragem se os registos da automatização são realmente lidos. Só a combinação de automatização e controlo torna as atualizações fiáveis.
Como ajuda concretamente a PHP SOS?
- Configurar: configuramos o unattended-upgrades ou o dnf-automatic de acordo com os seus servidores, incluindo as fontes de terceiros libertadas.
- Garantir os reinícios: configuramos o needrestart ou verificações equivalentes e controlamos, após atualizações do PHP, as horas de arranque dos processos.
- Fechar lacunas: integramos contentores, painéis e mudanças de versão principal num procedimento de manutenção fixo.
- Controlar: no contrato de manutenção de segurança, verificamos os registos da automatização e comunicamos anomalias.
Perguntas frequentes
As atualizações automáticas não são demasiado arriscadas em servidores de produção?
Limitado às atualizações de segurança da distribuição, o risco é em regra menor do que o de uma vulnerabilidade aberta. Estas atualizações não devem trazer novas funcionalidades, mas corrigir erros. Para sistemas críticos, fazem parte cópias de segurança, monitorização e um sistema de teste.
O unattended-upgrades reinicia o PHP-FPM após uma atualização?
Não necessariamente por si. No Ubuntu, a partir da versão 24.04, a ferramenta needrestart reinicia por defeito automaticamente os serviços afetados, mas os serviços excluídos continuam a correr com ficheiros antigos. Após cada atualização do PHP, verifique a hora de arranque de todos os processos PHP.
Os pacotes do sury.org ou de outras fontes de terceiros são atualizados automaticamente?
Só se libertar expressamente a fonte. Segundo a documentação do Ubuntu, não basta acrescentar um repositório; tem de constar também da lista de origens permitidas do unattended-upgrades.
A automatização sobe também o PHP 8.2 para 8.3?
Não. As atualizações de segurança automáticas ficam dentro das versões de pacote instaladas. Uma mudança da versão principal do PHP, por exemplo antes do fim do suporte ao PHP 8.2 a 31/12/2026, continua a ser um projeto planeado, com testes.
E os contentores Docker?
As atualizações no anfitrião não atualizam a versão do PHP nos contentores. As imagens de contentor têm de ser reconstruídas ou novamente descarregadas e os contentores recriados.