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.
# 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.
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.
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:
# 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.
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.enabledestá comentada na configuração fornecida, pelo que a funcionalidade está ativa por defeito. O valor0tem de ser definido expressamente. - Definir de forma não sobreponível: através de
php_admin_valueno pool PHP-FPM, com mod_php na configuração do Apache. Não através deini_set()nem de.user.ini. - Procurar os opositores: A Red Hat recomenda verificar ficheiros
.htaccess, VirtualHosts e ficheiros.user.iniquanto a voltarem a ativar as definições afetadas. - Definir limites também à frente: Além de
post_max_sizeno 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.
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.
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.
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.