# RHEL, AlmaLinux e Rocky Linux: verificar o patch do PHP

> Verificar o patch do PHP no RHEL, AlmaLinux e Rocky: o que a Red Hat comunica sobre o PHP2Shell, como consultar errata e changelog e reiniciar bem.

Fonte: https://phpsos.de/pt/blog/rhel-almalinux-rocky-php/  
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:** No RHEL, AlmaLinux e Rocky Linux, verifica o patch do PHP contra o PHP2Shell por três vias: os avisos de segurança da distribuição (`dnf updateinfo`), o registo de alterações do pacote (`rpm -q --changelog`) e a hora de arranque dos processos PHP. A Red Hat indica o RHEL 7 a 10 como afetados e comunicou, na consulta, que algumas atualizações estavam disponíveis e outras em curso. Depois da atualização vale: reiniciar por completo, e não apenas recarregar.

## O que a Red Hat publicou sobre o PHP2Shell

A Red Hat emitiu sobre o PHP2Shell o boletim de segurança RHSB-2026-013. Consultámo-lo a 25 de outubro de 2026. Os pontos mais importantes para administradores:

- **Estão afetados** o RHEL 10, 9, 8 e 7, bem como produtos que neles assentam e contentores baseados em imagens RHEL ou UBI.
- **O RHEL 7** está, segundo a Red Hat, afetado apenas pela CVE-2026-109619; o código da CVE-2026-109618 não estaria aí incluído.
- **Não estão afetados** os sistemas sem PHP ou com PHP que não processe pedidos HTTP não fiáveis.
- **Atualizações:** Algumas estavam disponíveis na consulta, outras em curso. O boletim não indicava números de errata concretos, remetendo para as páginas de errata.

A Red Hat avalia a CVE-2026-109618 com um método próprio como “Important” e salienta que as instalações por defeito a partir do RHEL 8 usam PHP-FPM em vez de mod_php. É um enquadramento, não um alívio. O projeto PHP avalia ambas as vulnerabilidades com CVSS v4.0 9,2, e o BSI (Gabinete Federal Alemão para a Segurança da Informação) recomenda a atualização imediata.

## AlmaLinux e Rocky Linux: mesma fonte, ritmo próprio

O AlmaLinux e o Rocky Linux recompilam os seus pacotes a partir das fontes da Red Hat. As correções chegam por isso, em regra, iguais no conteúdo, mas com data própria e sob avisos de segurança próprios. Uma referência a uma errata da Red Hat não significa que o pacote esteja disponível no mesmo dia no seu derivado.

Decisivo é, por isso, o estado no seu sistema. Verifique-o com as ferramentas da gestão de pacotes e não com base em notícias ou fóruns.

Preste ainda atenção a se o servidor usa servidores espelho ou fontes de pacotes internas. Em muitas empresas, os servidores não obtêm as atualizações diretamente do fabricante, mas através de um espelho interno ou de uma ferramenta de gestão. Se esse espelho não estiver atualizado, o `dnf` não encontra novos pacotes, embora estes estejam publicados há muito.

## Verificar o patch do PHP no RHEL e derivados

Os comandos seguintes são apenas de leitura. Os nomes dos pacotes valem para os pacotes PHP da distribuição; os pacotes de fontes de terceiros como o Remi têm por vezes outros nomes.

```bash
# Que streams PHP conhece o sistema, qual está ativo? (RHEL 8 e 9)
dnf module list php

# Pacotes PHP instalados com versão e origem
rpm -qa 'php*' --qf '%{NAME}-%{VERSION}-%{RELEASE}  %{VENDOR}\n' | sort

# Existem avisos de segurança sobre as CVE para este sistema?
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619

# A correção consta do registo de alterações do pacote instalado?
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"
```

O `dnf updateinfo` só mostra avisos de atualizações que ainda não estão instaladas; com `--installed` vê também as já aplicadas. Um resultado vazio pode, portanto, significar duas coisas: a atualização já está lá ou ainda não foi publicada. A comparação com o registo de alterações esclarece-o. Como guardar o resultado como comprovativo é descrito no artigo [Comprovar números CVE no registo de alterações do pacote](https://phpsos.de/pt/blog/cve-im-changelog-nachweisen/).

Como noutras distribuições empresariais, o pacote mantém normalmente a sua versão original do PHP; apenas a indicação de release muda. Um número mais antigo no `php -v` não é, por isso, indício de falta de correção. Indicações gerais sobre a verificação de versões encontram-se em [Verificar corretamente a versão do PHP e o nível de patch](https://phpsos.de/pt/php2shell/php-version-pruefen/).

## Reconhecer o modo de operação certo

A Red Hat indica os modos de operação por defeito: a partir do RHEL 8, o PHP corre através de PHP-FPM; no RHEL 7, como mod_php no serviço Apache `httpd`. Muitos servidores divergem disto, por exemplo por painéis, fontes de terceiros ou configurações antigas.

| Sistema | Por defeito segundo a Red Hat | Reinício após a atualização |
|---|---|---|
| RHEL 8, 9, 10 e derivados | PHP-FPM | `systemctl restart php-fpm` |
| RHEL 7 | mod_php em httpd | `systemctl restart httpd` |
| Contentores com base RHEL ou UBI | consoante a imagem | reconstruir a imagem, substituir o contentor |

Para contentores, a Red Hat recomenda reconstruir as próprias imagens depois de imagens de base atualizadas e substituir contentores ou pods em execução. Uma atualização no contentor em execução não é um caminho fiável.

## Depois da atualização: reinício e controlo

A Red Hat salienta que um reload não basta. Os workers existentes podem manter o estado afetado. Reinicie por isso todos os serviços que carregam PHP e controle o resultado:

```bash
# Mostrar serviços com bibliotecas desatualizadas (dnf-utils ou dnf-plugins-core)
needs-restarting -s

# Comparar a hora de arranque dos processos PHP com a hora da atualização
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
```

Para a configuração, a Red Hat dá uma indicação prática: `php -i` mostra as definições da linha de comandos, e não as do servidor web. Quem quiser verificar se valores provisórios como `session.upload_progress.enabled=0` atuam no contexto web usa, por breve tempo, uma página phpinfo protegida e apaga-a depois. O que mais há a ter em conta no reinício encontra-se em [Reiniciar o PHP-FPM e todos os workers](https://phpsos.de/pt/php2shell/php-fpm-neustart/).

## Medidas provisórias: as indicações da Red Hat

Onde ainda falta uma atualização, a Red Hat remete para as mesmas medidas provisórias que o php.net e acrescenta algumas indicações práticas para sistemas RHEL. Não substituem a atualização.

- **Acrescentar mesmo a linha:** Segundo a Red Hat, a linha de `session.upload_progress.enabled` está comentada na configuração fornecida, pelo que a funcionalidade está ativa por defeito. O valor `0` tem de ser definido expressamente.
- **Definir de forma não sobreponível:** através de `php_admin_value` no pool PHP-FPM, com mod_php na configuração do Apache. Não através de `ini_set()` nem de `.user.ini`.
- **Procurar os opositores:** A Red Hat recomenda verificar ficheiros `.htaccess`, VirtualHosts e ficheiros `.user.ini` quanto a voltarem a ativar as definições afetadas.
- **Definir limites também à frente:** Além de `post_max_size` no PHP, a Red Hat aconselha ponderar limites para o tamanho dos pedidos também no servidor web ou no proxy.

Nos sistemas PHP-FPM, os pools estão em regra em `/etc/php-fpm.d/`. Após cada alteração vale o mesmo que após a atualização: reiniciar por completo todos os workers.

> **Dica:**
> Se no mesmo servidor correr também PHP do repositório Remi, aplicam-se pacotes e serviços próprios. Leia a este respeito o artigo [O repositório Remi](https://phpsos.de/pt/blog/remi-repository-php/).

## Como ajuda concretamente a PHP SOS?

- No RHEL, AlmaLinux e Rocky Linux verificamos todos os pacotes PHP, streams e fontes de terceiros e comparamo-los com os avisos de segurança.
- Aplicamos atualizações, reiniciamos por completo todos os workers e controlamos as horas de arranque dos processos.
- Em ambientes de contentores, reconstruímos imagens e substituímos de forma controlada as instâncias em execução.
- O estado de cada servidor fica registado no comprovativo do [serviço de patches PHP](https://phpsos.de/pt/leistungen/php-patch-service/).


## Perguntas frequentes

**O RHEL 7 está afetado pelo PHP2Shell?**  
Segundo a Red Hat, o RHEL 7 está afetado apenas pela CVE-2026-109619; o código vulnerável da CVE-2026-109618 não existiria aí. No RHEL 7, o mod_php é o modo de operação por defeito, que a equipa do PHP classifica como particularmente arriscado.

**Porque é que a Red Hat avalia a vulnerabilidade mais baixo do que o php.net?**  
A Red Hat usa uma avaliação própria segundo o CVSS v3.1 e classifica a CVE-2026-109618 como Important, porque a exploração exigiria um timing preciso. O php.net avalia com CVSS v4.0 9,2. Ambos consideram possível a execução de código sem autenticação; a atualização é necessária em qualquer caso.

**O AlmaLinux e o Rocky Linux recebem as correções automaticamente?**  
Ambos recompilam os seus pacotes a partir das fontes da Red Hat e publicam avisos de segurança próprios. A data pode divergir da da Red Hat. Por isso, verifique o estado no seu próprio sistema e nos avisos da sua distribuição.

**Basta systemctl reload php-fpm depois da atualização?**  
Não. A Red Hat chama expressamente a atenção para o facto de um reload não bastar, porque os workers existentes podem manter o estado afetado. Reinicie todos os workers; com mod_php, o serviço Apache httpd.

## Fontes

- [Red Hat Security Bulletin RHSB-2026-013](https://access.redhat.com/security/vulnerabilities/RHSB-2026-013)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [php.net: avisos de segurança](https://www.php.net/)