Em resumo: O repositório PHP Remi fornece versões atuais do PHP para o Fedora e a família RHEL, seja como stream de módulo, que substitui o PHP do sistema, seja como Software Collection, que instala várias versões em paralelo. As correções do PHP2Shell 8.2.35, 8.3.36, 8.4.27 e 8.5.12 foram aí anunciadas a 22 de outubro de 2026. Verifique cada versão instalada individualmente e reinicie cada serviço correspondente.
Porque é que tantos servidores RHEL obtêm o PHP do Remi
As distribuições empresariais como o RHEL, o AlmaLinux e o Rocky Linux apostam na estabilidade de longo prazo. Fornecem poucos ramos do PHP e mantêm-nos durante anos. Muitas aplicações exigem, porém, versões mais recentes do que a distribuição oferece. É aqui que entra o repositório de Remi Collet, há muito responsável por pacotes PHP no meio Fedora e RHEL.
O Remi compila as versões do PHP em rápida sequência após os lançamentos oficiais. Sobre o PHP2Shell, o blogue do repositório publicou a 22 de outubro de 2026 um artigo sobre as versões 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Nele são indicadas as duas vulnerabilidades críticas CVE-2026-109618 e CVE-2026-109619 e a atualização é recomendada com urgência. Os avisos de segurança da Red Hat não se aplicam a estes pacotes; o que a Red Hat comunica para os seus próprios pacotes está no artigo RHEL, AlmaLinux e Rocky Linux: verificar o patch do PHP.
Dois caminhos: stream de módulo ou Software Collection
Segundo o blogue do Remi, as compilações para Enterprise Linux a partir da versão 8 estão disponíveis por dois caminhos. Qual é usado no seu servidor determina como verifica e reinicia.
| Caminho | Repositório | Efeito | Serviço típico |
|---|---|---|---|
Stream de módulo, por exemplo php:remi-8.3 |
remi-modular | substitui o PHP do sistema, uma versão por defeito | php-fpm |
Software Collection, por exemplo php83 |
remi-safe | versão adicional em paralelo, em caminho próprio | serviço próprio por versão, por exemplo php83-php-fpm |
| Pacotes de teste e release candidates | remi-modular-test, remi-test | pré-versões | não para produção |
As Software Collections estão tipicamente em /opt/remi/phpXY, a sua configuração em /etc/opt/remi/phpXY. É prático para operar aplicações antigas e novas num servidor. Mas é também a razão mais frequente para uma versão ser esquecida na atualização.
Uma nota sobre a linha de comandos: as Software Collections não ficam automaticamente disponíveis sob o comando php. Consoante a configuração, as tarefas cron e os scripts chamam-nas através de um comando próprio ou de um caminho completo. Verifique por isso também crontabs e scripts de deployment, se quiser saber que coleção é usada para quê.
Verificar o repositório PHP Remi depois do PHP2Shell
Os comandos seguintes são apenas de leitura e mostram que pacotes Remi estão instalados e em que estado.
# Fontes de pacotes ativas: o remi-modular ou o remi-safe está incluído?
dnf repolist
# Stream de módulo ativo para o PHP
dnf module list --enabled php
# Pacotes de base e Software Collections instaladas em paralelo
rpm -qa 'php-*' 'php[0-9][0-9]-php-*' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' | sort
# Versão de cada coleção instalada
for b in /opt/remi/php*/root/usr/bin/php; do echo "$b"; "$b" -v | head -1; done
Nos ramos suportados, a situação é inequívoca: se aí estiver 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ou mais recente, a correção está incluída. No Remi, o número de versão corresponde em regra à versão upstream, ao contrário dos pacotes da distribuição, que muitas vezes mantêm o seu número antigo.
Para coleções mais antigas como php81, php80 ou php74 não há versão de destino oficial. O Remi classifica o PHP 8.1 como End-of-Life. Se um pacote instalado contém uma correção contra o PHP2Shell, esclareça-o no registo de alterações, por exemplo com rpm -q --changelog php81-php-fpm | grep -E "CVE-2026-10961[89]". Sem resultado, trate o pacote como por esclarecer. Como comprovar tais resultados de forma limpa é descrito no artigo Comprovar números CVE no registo de alterações do pacote.
Não ative repositórios de teste como remi-test ou remi-modular-test de forma duradoura em servidores de produção. Fornecem release candidates, destinados a testes.
Atualização e reinício de cada versão
A atualização em si é, no Remi, normalmente pouco espetacular: dnf upgrade obtém novos pacotes para o stream e as coleções. A parte crítica vem depois. Cada coleção tem o seu próprio serviço FPM, e cada um tem de ser reiniciado.
# Listar todos os serviços PHP-FPM, também os das coleções
systemctl list-units --type=service --all | grep -E "php.*fpm"
# Verificar as horas de arranque de todos os processos PHP
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Horas de arranque anteriores à atualização significam: este serviço continua a trabalhar com código antigo. Porque é que recarregar não basta é explicado na página Reiniciar o PHP-FPM e todos os workers.
Remi e distribuição: quem é responsável?
Quem muda por stream de módulo para o Remi muda de fornecedor para o PHP. Os avisos de segurança da Red Hat, do AlmaLinux ou do Rocky Linux deixam então de se referir aos pacotes PHP instalados. Inversamente, o Remi não comunica problemas noutros pacotes do sistema. Tem, portanto, de acompanhar as duas fontes.
De onde vem um pacote instalado mostra a base de dados de pacotes, por exemplo com rpm -qi php-fpm nos campos de fornecedor e empacotador. Como não há errata no sentido da Red Hat para pacotes Remi, o blogue do repositório presta-se como canal de notificação; pode ser subscrito por feed RSS. No PHP2Shell, o aviso apareceu aí um dia depois dos lançamentos oficiais.
Para as empresas, esta divisão não é obstáculo, mas tem de estar documentada. Registe que servidores obtêm o PHP do Remi, quem lê os avisos e quem reinicia os serviços após uma atualização. Caso contrário, cada um confia no outro.
Manter a ordem: menos versões, menos risco
As Software Collections convidam a deixar simplesmente versões antigas ficar. Depois do PHP2Shell é uma boa altura para arrumar:
- Para cada coleção, esclarecer que site ou tarefa cron a usa.
- Desativar as coleções não usadas e removê-las após um período de observação.
- Levar as aplicações em coleções antigas para um ramo suportado.
- Documentar as versões restantes com finalidade e responsável.
Como manter a visão geral de muitas versões em paralelo é descrito no artigo Várias versões do PHP num servidor.
Como ajuda concretamente a PHP SOS?
- Levantamos todos os streams e coleções Remi nos seus servidores e atribuímo-los a sites e tarefas cron.
- Verificamos o estado do PHP2Shell por versão através da versão do pacote e do registo de alterações.
- Aplicamos atualizações, reiniciamos cada serviço e comprovamo-lo com as horas de arranque dos processos no âmbito do serviço de patches PHP.
- As coleções que já não são necessárias removemo-las de forma controlada, após acordo.
Perguntas frequentes
O Remi disponibilizou as versões do PHP2Shell?
Sim. No blogue do repositório foram anunciadas, a 22 de outubro de 2026, as versões 8.2.35, 8.3.36, 8.4.27 e 8.5.12, com a indicação de duas vulnerabilidades críticas, CVE-2026-109618 e CVE-2026-109619, e a recomendação urgente de atualizar.
Qual é a diferença entre stream de módulo e SCL no Remi?
Com um stream de módulo, substitui o PHP do sistema por uma versão do Remi, ficando então uma versão do PHP como predefinida. As Software Collections instalam outras versões em paralelo, em caminhos próprios, cada uma com serviço próprio.
O PHP 8.1 do Remi ainda recebe atualizações?
O Remi classifica o PHP 8.1 como End-of-Life, e o projeto PHP já não mantém o ramo. Se um determinado pacote 8.1 contém uma correção contra o PHP2Shell, verifique-o no registo de alterações do pacote instalado. Sem entrada, o estado conta como por esclarecer.
Tenho de reiniciar cada versão do PHP após uma atualização do Remi?
Sim. Cada versão instalada em paralelo tem um serviço FPM próprio. Se só for reiniciado o serviço da versão principal, as outras continuam a correr com código antigo.