# Atualizações de segurança automáticas em servidores Linux

> Configurar unattended-upgrades e dnf-automatic: aplicar atualizações de segurança automaticamente, reiniciar serviços e libertar fontes de terceiros de forma dirigida.

Fonte: https://phpsos.de/pt/blog/automatische-sicherheitsupdates/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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/`.

```bash
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:

```text
// /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](https://phpsos.de/pt/blog/sury-repository-php/).

Se tudo está certo mostra-o uma execução de teste que não altera nada:

```bash
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.

```ini
# /etc/dnf/automatic.conf (excerto)
[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
reboot = never
```

```bash
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](https://phpsos.de/pt/php2shell/php-fpm-neustart/).

> **Importante:**
> 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?](https://phpsos.de/pt/blog/debian-ubuntu-paket-gepatcht/).

## 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:

1. **Contentores:** o PHP em imagens Docker não é atualizado por atualizações do anfitrião. Reconstruir as imagens, recriar os contentores.
2. **Painéis de alojamento:** Plesk, cPanel e painéis semelhantes gerem o PHP em parte através de pacotes e mecanismos próprios.
3. **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.
4. **Aplicações:** CMS, plugins e dependências do Composer têm caminhos de atualização próprios.
5. **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](https://phpsos.de/pt/blog/patch-management-prozess/).

## 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](https://phpsos.de/pt/leistungen/security-wartungsvertrag/), 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.

## Fontes

- [Ubuntu Server: atualizações automáticas](https://ubuntu.com/server/docs/how-to/software/automatic-updates/)
- [DNF Automatic](https://dnf.readthedocs.io/en/latest/automatic.html)
- [Debian Security Tracker](https://security-tracker.debian.org/)
- [Ubuntu Security Notices](https://ubuntu.com/security/notices)