# Como o projeto PHP trata as vulnerabilidades de segurança

> Como o projeto PHP trata as vulnerabilidades: comunicação via GitHub ou security@php.net, classificação, correção na versão e o que os operadores devem retirar daí.

Fonte: https://phpsos.de/pt/php/php-sicherheitsprozess/  
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:** As vulnerabilidades do PHP são comunicadas de forma confidencial, de preferência através do formulário privado de advisories no repositório GitHub `php/php-src` ou, em alternativa, para security@php.net. Os programadores do PHP classificam o achado como alto, médio ou baixo; os erros graves são corrigidos num repositório de segurança separado e só são publicados com a versão, em conjunto com um GitHub Security Advisory e, na maioria dos casos, um número CVE. No PHP2Shell, este processo decorreu a um ritmo acelerado: pré-aviso a 20/10/2026, patches a 21/10/2026, nota complementar a 23/10/2026.

## Quem cuida da segurança no PHP?

O PHP é um projeto de código aberto. A política de segurança na wiki descreve-o como um projeto de voluntários, sem orçamento para prémios. Para cada versão existem release managers, responsáveis pelas publicações. Acresce a PHP Foundation, que, segundo a sua própria descrição, contrata uma equipa de programadores a tempo parcial e a tempo inteiro que trabalha na manutenção, na segurança e em novas funcionalidades do PHP.

Para as empresas, isto significa: não existe um fabricante com contrato, linha de apoio ou tempos de resposta garantidos. Quem precisa de compromissos vinculativos obtém-nos da sua distribuição Linux, do seu fornecedor de alojamento ou de um fornecedor de suporte de longo prazo, não do próprio projeto PHP. Esta cadeia de fornecimento deve ser conhecida.

## Como se comunica uma vulnerabilidade

O caminho está descrito na política de segurança no GitHub:

1. **Comunicar:** através do formulário privado de security advisories no repositório `php/php-src`. Quem não o puder usar, ou quiser discutir um tema que não é um relatório de erro, escreve para security@php.net.
2. **Descrever de forma concisa:** pede-se um exemplo curto que mostre o erro, não um longo relatório sobre possíveis efeitos. Assim a equipa consegue triar mais depressa.
3. **Confidencialidade:** a comunicação permanece privada até à publicação.
4. **Menção:** quem comunica é mencionado como colaborador, segundo o sistema de créditos do MITRE.

A página mais antiga da wiki refere ainda o tradicional rastreador de erros com o tipo «Security». Hoje, o caminho determinante é o do GitHub.

## O que o projeto PHP classifica como vulnerabilidade de segurança

Nem todo o crash é uma vulnerabilidade. A wiki indica quatro critérios: um erro permite ações não autorizadas, ultrapassa fronteiras de segurança, abre o acesso a dados alheios ou prejudica gravemente a disponibilidade ou o desempenho. A classificação faz-se em três níveis:

| Nível | Significado segundo a política | Número CVE |
|---|---|---|
| Alto | terceiros podem comprometer a maioria das instalações, executar código ou ler ficheiros | em regra sim |
| Médio | efeito semelhante, mas só em condições mais raras, por exemplo uma extensão ou configuração rara | na maioria dos casos sim |
| Baixo | teoricamente possível, na prática muito difícil de explorar | na maioria dos casos não |

Igualmente esclarecedora é a lista do que expressamente não é uma vulnerabilidade: código malicioso executado deliberadamente, contornamentos do `open_basedir` e do `disable_functions`, entradas maliciosas passadas ao `unserialize()`, a utilização do FFI e uma interrupção de memória normal em que o `memory_limit` atua e termina apenas o pedido atual. Para os operadores, isto significa: o [disable_functions](https://phpsos.de/pt/ratgeber/disable-functions/) é um hardening sensato, mas não uma muralha de proteção.

## Da correção à publicação

As correções para vulnerabilidades altas e médias são, segundo a wiki, incorporadas num repositório de segurança separado antes de a versão ser criada. Os erros classificados como baixos seguem como correções de erros normais. A vulnerabilidade é publicada segundo o princípio da divulgação responsável: primeiro a correção, depois os detalhes. As versões saem, segundo a wiki, quase sempre às quintas-feiras, muitas vezes no âmbito das publicações mensais regulares.

Com a versão surge um GitHub Security Advisory, com identificador próprio (GHSA) e nível de gravidade. No repositório surgiram, por exemplo, a 24/09/2026, vários advisories sobre stream wrappers, FastCGI e filtros, com gravidades de baixa a alta. Os pacotes de código-fonte no php.net são disponibilizados com somas de verificação SHA-256 e assinaturas GPG dos release managers; as tags Git estão assinadas. Que ramos de versões recebem ainda correções de segurança mostra-o a página sobre [versões do PHP e ciclo de lançamentos](https://phpsos.de/pt/php/release-zyklus/).

## O PHP2Shell como exemplo do caso grave

O PHP2Shell mostra como o processo decorre sob pressão:

- **20/10/2026:** o php.net anuncia uma versão de segurança crítica para 21/10/2026 às 14:00 UTC e reserva-se o direito de publicar mais cedo, caso os detalhes se tornem públicos ou surjam ataques. Segundo vários relatórios, os detalhes tinham de facto sido conhecidos antes do fim do prazo de embargo; os bastidores são analisados em [Por que razão a vulnerabilidade do PHP se tornou conhecida antes do patch](https://phpsos.de/pt/blog/php-luecke-vorzeitig-bekannt/).
- **21/10/2026:** saem o PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, bem como os advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) e GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), ambos classificados como críticos. Segundo o php.net, as distribuições Linux e os fornecedores de suporte de longo prazo tinham recebido as correções antecipadamente. Para o 7.4, 8.0 e 8.1 existem backports mínimos.
- **23/10/2026:** uma nota informativa sobre a CVE-2026-115560 recomenda `session.upload_progress.enabled=0`; o advisory completo segue com a próxima versão.

## O que os operadores devem retirar daqui

1. **Subscrever as fontes:** php.net, os advisories GitHub do `php/php-src` e os avisos de segurança da sua distribuição.
2. **Conhecer a cadeia de fornecimento:** quem fornece o seu pacote PHP e com que rapidez chegam lá os backports?
3. **Planear a janela temporal:** as versões críticas podem chegar fora do ritmo habitual; uma janela de patches tem de ser possível a curto prazo.
4. **Prever o reinício:** uma atualização só produz efeito quando todos os processos PHP foram reiniciados.
5. **Assegurar a prova:** documentar a versão, o estado dos pacotes e o momento.

## Como ajuda concretamente o PHP SOS?

Com o [serviço de patches PHP](https://phpsos.de/pt/leistungen/php-patch-service/), assumimos a parte que cabe a si:

- **Acompanhar os avisos:** observamos o php.net, os advisories e os avisos das distribuições e avaliamos se os seus sistemas estão afetados.
- **Aplicar o patch:** atualização a partir da fonte adequada, reinício de todos os processos, verificação da versão em execução.
- **Proteger a transição:** onde a atualização encalha, aplicamos as medidas provisórias oficiais.
- **Documentar:** recebe uma prova com versões, estados de pacotes e momentos.


## Perguntas frequentes

**Como se comunica uma vulnerabilidade de segurança no PHP?**  
De preferência através do formulário privado de security advisories no repositório GitHub php/php-src. Quem não o puder usar escreve para security@php.net. A comunicação permanece confidencial até à publicação.

**O projeto PHP paga um prémio por vulnerabilidades encontradas?**  
Não. Segundo a política de segurança, o PHP é um projeto de voluntários, sem dinheiro para bug bounties. Quem comunica é, porém, mencionado como colaborador.

**Contornar o disable_functions é uma vulnerabilidade de segurança?**  
Segundo a política do projeto PHP, não. Os contornamentos do open_basedir e do disable_functions não são considerados um problema de segurança do PHP. As definições são hardening, mas não uma fronteira de segurança fiável.

**Onde me informo sobre novas vulnerabilidades do PHP?**  
Na página inicial do php.net, com os avisos de lançamento, e nos security advisories do repositório GitHub php/php-src. Quem obtém o PHP da distribuição acompanha também os avisos de segurança desta.

**Porque é que o PHP2Shell foi publicado a uma quarta-feira?**  
Segundo a wiki, as versões costumam sair às quintas-feiras. Para o PHP2Shell, o php.net anunciou a 20/10/2026 uma versão de segurança para quarta-feira, 21/10/2026, às 14:00 UTC, e reservou-se o direito de publicar mais cedo caso os detalhes se tornassem públicos.

## Fontes

- [php-src: política de segurança e advisories (GitHub)](https://github.com/php/php-src/security)
- [Wiki do PHP: política de segurança](https://wiki.php.net/security)
- [php.net: avisos de 20 a 23/10/2026](https://www.php.net/)
- [php.net: versões suportadas](https://www.php.net/supported-versions.php)