# Confirmação da atualização PHP do alojamento: como perguntar pelo estado do patch

> Como obter do seu alojamento uma confirmação fiável da atualização do PHP após o PHP2Shell: que dados contam, modelo para copiar e como avaliar a resposta.

Fonte: https://phpsos.de/pt/ratgeber/hoster-patch-status-erfragen/  
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:** após o PHP2Shell, a versão do PHP apresentada, por si só, prova pouco, porque os fornecedores de alojamento instalam muitas vezes as correções como backport. Por isso, peça uma confirmação escrita da atualização PHP do alojamento: estado dos pacotes por ramo do PHP, momento da instalação e reinício de todos os processos PHP. Um modelo para copiar encontra-o mais abaixo.

## Porque é que uma confirmação escrita conta precisamente agora

A 21/10/2026, o projeto PHP publicou os patches para duas vulnerabilidades críticas, conhecidas pelo nome PHP2Shell. Ambas permitem a execução remota de código malicioso sem autenticação. O BSI (Serviço Federal Alemão para a Segurança da Informação) declarou o nível de alerta 3 / laranja e recomenda a atualização imediata.

Quem aloja o seu site num fornecedor muitas vezes não pode instalar a atualização por si. Ao mesmo tempo, enquanto operador, é responsável pelos dados dos seus clientes. Uma confirmação escrita e concreta do fornecedor é, por isso, mais do que uma formalidade. É um elemento da sua documentação, por exemplo perante encarregados da proteção de dados, seguradoras ou a gestão.

Acresce que um patch não remove o software malicioso introduzido antes. Segundo notícias dos meios de comunicação, já a 17/10 houve uma primeira tentativa de ataque observada. O momento exato em que o seu servidor ficou protegido é, por isso, importante para decidir se tem de continuar a verificar.

## Porque é que a versão do PHP apresentada não basta

Estão corrigidas as versões PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Muitas distribuições e fornecedores de alojamento incorporam, porém, a correção como backport no seu próprio pacote. Nesse caso, uma interface como o Plesk continua a mostrar 8.2.34, embora o servidor esteja corrigido.

Inversamente, um número de versão correto pode enganar. Ficheiros novos não protegem enquanto processos PHP antigos correrem na memória. Só depois de reiniciar todos os workers o novo estado fica ativo. Mais sobre isto no artigo [Verificar corretamente a versão do PHP e o nível de patch](https://phpsos.de/pt/php2shell/php-version-pruefen/).

| Declaração do fornecedor | O que comprova | O que ainda falta |
|---|---|---|
| “Todos os sistemas estão atualizados.” | pouco | versão ou estado do pacote, data, reinício |
| “O PHP 8.3.36 está instalado.” | versão | data, reinício, servidores afetados |
| “Backport no pacote xy, reinício em …” | patch e ativação | se aplicável, dados sobre o PHP 8.1 e anteriores |

## Que dados precisa do fornecedor de alojamento

Peça resposta a estes pontos, se possível por site ou por contrato:

- Que ramos e versões do PHP estão ativos para os seus sites, incluindo os mais antigos que correm apenas para algumas pastas?
- As correções para o CVE-2026-109618 e o CVE-2026-109619 estão incluídas, como versão oficial ou como backport?
- Quando foi instalada a atualização e quando foram reiniciados todos os processos PHP (pools FPM, Apache, LiteSpeed)?
- O `session.upload_progress.enabled` está desativado por causa do CVE-2026-115560?
- Que modo de operação usa o seu plano, por exemplo PHP-FPM ou Apache com mod_php? No mod_php, a equipa do PHP vê o risco mais elevado.
- Que registos de acesso e de erros a partir de 20/10/2026 são conservados e como os pode obter?

Se um site ainda correr no PHP 8.1 ou anterior, pergunte em separado. Para esses ramos já não existem atualizações oficiais, apenas backports mínimos do código-fonte para 7.4, 8.0 e 8.1.

## Modelo: pedir a confirmação da atualização PHP ao alojamento

Copie o texto para um ticket de suporte ou um e-mail ao seu fornecedor de alojamento. Complete os dados entre parênteses retos.

```text
Assunto: Pedido de confirmação do estado de atualização do PHP (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)

Exmos. Senhores,

temos junto de V. Exas. os seguintes sites / contratos:
[Número de cliente, contrato, domínios]

No âmbito das vulnerabilidades de segurança do PHP CVE-2026-109618 e
CVE-2026-109619 (PHP2Shell, patches de 21.10.2026), bem como do aviso
sobre o CVE-2026-115560 de 23.10.2026, solicitamos uma confirmação
por escrito sobre os seguintes pontos:

1. Que versões do PHP ou estados de pacotes estão ativos para os nossos sites?
2. Incluem estes as correções (versão oficial ou backport)?
3. Data e hora da instalação.
4. Data e hora do reinício de todos os processos PHP (FPM, Apache,
   LiteSpeed ou semelhantes).
5. O session.upload_progress.enabled está desativado no servidor?
6. Que modo de funcionamento do PHP é utilizado (p. ex. PHP-FPM, mod_php)?
7. Os registos de acesso e de erros são conservados a partir de 20.10.2026 e
   como os podemos obter?
8. Se algum site ainda utilizar PHP 8.1 ou anterior: que proteção existe
   nesse caso e que migração recomendam?

Precisamos destas informações para a nossa documentação interna.

Agradecemos desde já e apresentamos os melhores cumprimentos
[Nome, empresa, função]
```

## Avaliar corretamente a resposta e verificar por si

Uma boa resposta indica estados, datas e horas concretos. Formulações gerais como “reagimos” não bastam para o seu processo. Nesse caso, pergunte com cortesia pelos pontos em falta.

Se o seu plano o permitir, verifique também por si. Com acesso SSH, estes comandos costumam bastar:

```bash
# Versão da linha de comandos (pode diferir da versão web)
php -v
# Estado dos pacotes em Debian/Ubuntu
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Estado dos pacotes em RHEL, Alma, Rocky
rpm -qa | grep -i php
# Desde quando correm os processos PHP-FPM?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
```

Se a hora de arranque dos processos PHP for anterior à data de instalação confirmada, o reinício não foi completo.

### Se o fornecedor não responder ou responder de forma evasiva

Se a resposta não chegar ou faltarem os dados decisivos, não deve considerar a situação esclarecida. O BSI recomenda retirar temporariamente os servidores web da rede quando uma atualização não é possível de imediato. Se isso é proporcionado para o seu site, decide a gestão, de preferência por escrito e com data.

Em paralelo, vale a pena procurar possíveis vestígios de um ataque, porque o momento do patch continua em aberto. Pistas encontra-as no artigo [Já fui comprometido?](https://phpsos.de/pt/php2shell/bin-ich-gehackt-anzeichen/). Sem acesso SSH, a confirmação escrita continua a ser a sua prova mais importante. Que obrigações cabem ao fornecedor e quais cabem a si, explica-o a página [Alojamento partilhado: o que faz o fornecedor](https://phpsos.de/pt/server/shared-hosting/); para servidores com gestão, ajuda [Servidor gerido: esclarecer a responsabilidade](https://phpsos.de/pt/server/managed-server/).

> **Dica:**
> Guarde o pedido, a resposta e os seus próprios resultados de verificação, com data, numa pasta. Este dossiê ajuda mais tarde em perguntas de seguradoras ou de encarregados da proteção de dados.

## Como ajuda concretamente a PHP SOS?

- Formulamos consigo o pedido ao fornecedor de alojamento e avaliamos tecnicamente a resposta.
- Onde há acesso, verificamos nós próprios o estado dos pacotes, o modo de operação ativo e o reinício dos processos PHP.
- Se restarem lacunas, aplicamos medidas transitórias ou planeamos a migração para uma versão suportada.
- Registamos o resultado e os momentos num comprovativo que pode transmitir internamente.

Como decorre a atualização com reinício e comprovativo, descreve-o o nosso [serviço de patches PHP](https://phpsos.de/pt/leistungen/php-patch-service/).


## Perguntas frequentes

**Basta o meu fornecedor de alojamento escrever que está tudo atualizado?**  
Para a sua documentação, dificilmente. Peça dados concretos: estado dos pacotes ou versão por ramo do PHP, data da instalação e data do reinício de todos os processos PHP. Só com isto pode delimitar a janela de vulnerabilidade.

**Porque é que a minha interface de alojamento ainda mostra o PHP 8.2.34?**  
As distribuições e os fornecedores de alojamento instalam por vezes as correções de segurança como backport, sem alterar o número de versão. O Plesk pode então continuar a mostrar 8.2.34, embora o servidor esteja corrigido. Só a confirmação do fornecedor sobre o estado dos pacotes esclarece a situação.

**O que faço se o fornecedor de alojamento não responder?**  
Documente o seu pedido com a data e volte a perguntar passado um prazo razoável. Verifique em paralelo se pode aplicar medidas transitórias por si e combine com a gestão se o site sai do ar até haver esclarecimento, como o BSI recomenda para servidores sem patch.

**Uma atualização do WordPress ou da loja também fecha a vulnerabilidade?**  
Não. O PHP2Shell está no próprio PHP. Uma atualização do CMS ou do software da loja não altera o interpretador PHP que corre no servidor.

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: versões suportadas](https://www.php.net/supported-versions.php)
- [BSI (Serviço Federal Alemão para a Segurança da Informação)](https://www.bsi.bund.de/)