# Que versões do PHP estão afetadas?

> Que versões do PHP o PHP2Shell afeta e quais estão corrigidas: tabela de versões do 8.5 ao 5.4, indicações sobre backports, fim de suporte e como proceder.

Fonte: https://phpsos.de/pt/php2shell/betroffene-php-versionen/  
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:** da vulnerabilidade de segurança PHP2Shell estão afetados os ramos 8.2 a 8.5 até às versões de 21 de outubro de 2026 e, segundo a imprensa especializada, quase todas as versões até ao PHP 5.4. Está corrigida no PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Para o PHP 8.1 e anteriores já não existem atualizações oficiais, apenas backports mínimos do código-fonte para 7.4, 8.0 e 8.1.

## Que versões foram afetadas pela vulnerabilidade do PHP?

O PHP2Shell abrange as duas vulnerabilidades CVE-2026-109618 e CVE-2026-109619, cada uma com CVSS v4.0 de 9,2. Ambas permitem a execução remota de código malicioso, sem autenticação. A 21 de outubro de 2026, às 14:00 UTC (16 horas, hora alemã), o projeto PHP publicou correções para todos os ramos suportados.

| Ramo do PHP | Último nível antes da correção | Corrigido a partir de | Suporte |
|---|---|---|---|
| 8.5 | 8.5.11 | **8.5.12** | oficialmente suportado |
| 8.4 | 8.4.26 | **8.4.27** | oficialmente suportado |
| 8.3 | 8.3.35 | **8.3.36** | oficialmente suportado |
| 8.2 | 8.2.34 | **8.2.35** | termina a 31/12/2026 |
| 8.1, 8.0, 7.4 | todos os níveis | sem versão oficial | apenas backports mínimos do código-fonte |
| 7.3 a 5.4 | segundo a imprensa especializada, quase todos afetados | sem atualização | sem suporte há anos |

As indicações sobre 8.2 a 8.5 provêm dos avisos do php.net. A afirmação sobre as versões até ao PHP 5.4 provém da imprensa especializada; não existe uma lista oficial completa para versões antigas.

Para quem não é técnico, em poucas frases: se no seu servidor está uma versão da coluna “Corrigido a partir de” ou superior e, depois, todos os processos PHP foram reiniciados, o PHP2Shell está fechado. Se aí está um número mais antigo, ou há um backport em jogo, que o seu fornecedor tem de confirmar, ou a vulnerabilidade está aberta. Em caso de dúvida, pergunte à sua equipa de TI ou ao seu fornecedor de alojamento exatamente por estes três pontos: versão, backport, reinício.

## Modos de operação afetados

O número de versão é apenas metade da resposta. Estão afetadas todas as formas habituais de operar o PHP num servidor web: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. A equipa do PHP classifica o risco como o mais elevado no mod_php, porque aí foi demonstrado um exploit antes sequer de o código da aplicação ser executado. Pormenores em [Porque é que o mod_php tem o risco mais elevado](https://phpsos.de/pt/php2shell/mod-php-risiko/).

Não resulta qualquer proteção da aplicação: seja WordPress, Shopware, TYPO3, Laravel ou um desenvolvimento próprio, uma atualização da aplicação não corrige a vulnerabilidade no PHP.

## Backports: quando o número de versão engana

Muitas distribuições Linux e fornecedores de alojamento fornecem o PHP em pacotes próprios. Em vez de saltarem para uma nova versão upstream, incorporam a correção como backport na sua versão existente. Isto tem uma consequência prática: o número apresentado continua antigo. Um exemplo da situação atual é o Plesk, que pode continuar a mostrar 8.2.34, embora o erro esteja corrigido.

Para si, isto significa: a tabela acima vale para as versões oficiais do php.net. Nos pacotes da sua distribuição ou do fornecedor de alojamento, decidem o estado do pacote e a confirmação do fornecedor. Como verificar ambos, mostra-o [Verificar corretamente a versão do PHP e o nível de patch](https://phpsos.de/pt/php2shell/php-version-pruefen/). Para o teste rápido na linha de comandos:

```bash
php -v
apt policy php8.3-fpm        # Debian/Ubuntu, o nome do pacote varia conforme a versão e a fonte
dnf info php-fpm             # família RHEL
```

> **Importante:**
> Uma versão corrigida no disco não significa ainda que esteja em execução. Só depois do reinício de todos os processos PHP o servidor trabalha com o código corrigido.

## O que se aplica ao PHP 8.1 e anteriores?

Para o PHP 8.1, 8.0 e 7.4 existem apenas backports mínimos do código-fonte, ou seja, correções no código-fonte que alguém tem de adotar e compilar por si. Não saem versões oficiais. Algumas distribuições com manutenção de longo prazo incorporam essas correções nos seus pacotes; se isso se aplica ao seu sistema, só se esclarece no changelog do pacote ou junto do fornecedor.

A longo prazo, não há caminho que dispense uma versão suportada. Que versão do PHP o seu CMS ou a sua loja suporta, verifique-o segundo os requisitos de sistema do fabricante, por exemplo em wordpress.org, shopware.com ou typo3.org. Mais informação em [PHP 8.1 e anteriores: o que se aplica agora](https://phpsos.de/pt/php2shell/php-8-1-und-aelter/).

## E a CVE-2026-115560?

A 23 de outubro, o php.net publicou um aviso sobre uma terceira vulnerabilidade. Só atua numa configuração de sessão invulgar. Uma versão corrigida ainda não existe, segundo o estado de 25 de outubro; até à próxima versão regular de correção de erros, a solução é `session.upload_progress.enabled=0`. Uma lista de versões só é esperada com o aviso completo (advisory).

## Como ajuda concretamente a PHP SOS?

- **Inventário:** registamos todas as versões do PHP nos seus servidores, também as instalações secundárias para sites individuais, que facilmente passam despercebidas.
- **Comparação:** para cada instalação, esclarecemos se existe uma versão oficial, um backport de distribuição ou nenhuma correção.
- **Atualização com comprovativo:** através do [serviço de patches PHP](https://phpsos.de/pt/leistungen/php-patch-service/), instalamos a correção e reiniciamos todos os processos.
- **Plano de migração:** para versões sem atualizações oficiais, planeamos a mudança com a [migração do PHP 8.1 e anteriores](https://phpsos.de/pt/leistungen/php-migration-legacy/) e protegemos o servidor até lá.


## Perguntas frequentes

**O PHP 8.3.35 ainda é seguro?**  
Não, a menos que o seu fornecedor tenha aplicado um backport. O 8.3.35 é o último nível antes da correção; o PHP2Shell está corrigido no ramo 8.3 a partir do 8.3.36. Nos pacotes de distribuições, o número pode manter-se igual, apesar de o erro estar corrigido. Nesse caso, contam o changelog do pacote ou a confirmação do fornecedor.

**O PHP 7.4 está afetado pelo PHP2Shell?**  
Segundo a imprensa especializada, estão afetadas quase todas as versões até ao PHP 5.4. Para 7.4, 8.0 e 8.1 existem apenas backports mínimos do código-fonte e nenhuma versão oficial. Mudar para uma versão suportada é o caminho sólido.

**Porque é que o Plesk mostra 8.2.34, apesar de o patch estar aplicado?**  
As distribuições e os fornecedores de alojamento incorporam por vezes as correções como backport nos seus pacotes existentes. O número de versão mantém-se então igual, mas o erro está corrigido. Verifique o estado do pacote ou peça ao fornecedor que lhe confirme o patch.

**Que versão do PHP devo escolher agora?**  
Uma versão suportada que a sua aplicação homologue segundo os requisitos de sistema do fabricante. O PHP 8.2 atinge o fim do suporte a 31/12/2026; quem muda agora de qualquer modo deve contar com isso.

## 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)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)