---
title: "PHP2Shell: como proteger servidores empresariais"
locale: pt
category: how_to
category_name: "Como Fazer"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/php2shell-enterprise-security-patch-response-guide
published_at: 2026-10-24T16:09:48+09:00
---

# PHP2Shell: como proteger servidores empresariais

> A resposta ao PHP2Shell começa pela atualização e reinicialização do PHP no serviço web em produção. Se houver suspeita de invasão, preserve primeiro as evidências. Mesmo após a correção, é necessário verificar os logs e trocar as credenciais.

## Key Points

- Verifique o uso de PHP nos servidores em produção e nos produtos que o incorporam.
- Se houver suspeita de invasão, isole o servidor e preserve as evidências antes de reiniciá-lo.
- Instale uma versão corrigida ou aplique a medida provisória oficial até realizar a atualização.
- Reinicie o serviço que executa o PHP e confirme se a correção foi aplicada ao serviço web em produção.
- Revise os logs anteriores e troque as credenciais dos servidores expostos.

A resposta ao PHP2Shell começa pela identificação dos ambientes que usam PHP e pela aplicação das versões corrigidas. Após a atualização, reinicie os serviços que executam o PHP. Se houver suspeita de comprometimento, preserve as evidências antes de reiniciar. Mesmo após a correção, é necessário verificar os logs e trocar as credenciais.

As versões e configurações seguem o comunicado da KISA de 22 de outubro de 2026 e o comunicado adicional do PHP de 23 de outubro.

## Que tipo de vulnerabilidade é o PHP2Shell?

PHP2Shell é uma vulnerabilidade do PHP que permite executar código no servidor sem autenticação. Trata-se de um problema de gerenciamento de memória durante o processamento de requisições pelo servidor web. O sucesso do ataque depende do ambiente de execução e das configurações.

| Categoria | Identificador | Natureza do problema |
| --- | --- | --- |
| Problema no tratamento de falta de memória | CVE-2026-109618 | Processamento de dados internos incompletos em situações de falta de memória |
| Problema de estado remanescente entre requisições | CVE-2026-109619 | Uso, em requisições posteriores, de um estado que aponta para memória já liberada |

A KISA informa que as duas vulnerabilidades têm gravidade de 9.2 pontos no CVSS. Um ataque bem-sucedido pode permitir a instalação de um web shell ou o vazamento de dados de clientes. Um web shell é um arquivo usado de forma maliciosa para controlar um servidor remotamente. O ataque também pode levar à alteração indevida de sites e à invasão da rede interna.

A KISA informou sobre o vazamento de informações e as tentativas de ataque antes da distribuição das correções. Os pesquisadores divulgaram o processo de descoberta das vulnerabilidades com o uso de IA. O problema está no próprio PHP e não se limita a um produto específico para sites. [Diretrizes de resposta da KISA para empresas](https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&menuNo=205020&nttId=72230), [Explicação dos pesquisadores sobre o PHP2Shell](https://www.php2shell.com/)

## Ordem de resposta conforme a situação

A ordem entre atualizar e preservar evidências depende da existência de suspeita de comprometimento. Em uma aplicação rotineira de correções, faça os testes e depois atualize e reinicie. Servidores com suspeita de comprometimento devem ser isolados primeiro.

| Situação atual | Primeira ação | Próxima ação |
| --- | --- | --- |
| Servidor exposto à internet sem sinais de comprometimento | Avaliar a compatibilidade e aplicar a versão corrigida | Reiniciar, verificar a versão efetivamente em uso e analisar os logs |
| Descoberta de web shell ou conexão suspeita | Isolar da rede e notificar o incidente | Preservar as evidências e depois executar as medidas de recuperação |
| Servidor que não pode ser atualizado imediatamente | Aplicar as configurações temporárias oficiais e limitar requisições na camada de entrada | Definir um cronograma de correção e aplicá-la |
| Servidor em que nem medidas temporárias são viáveis | Avaliar o bloqueio do acesso externo ou a suspensão temporária | Decidir sobre a retomada após a correção |
| Ambiente gerenciado por uma empresa de hospedagem ou pelo fabricante | Confirmar com a empresa responsável se a correção foi aplicada | Obter comprovação de que a correção está ativa no ambiente de execução |

Reiniciar após a atualização é o procedimento necessário para executar o código corrigido. Durante a resposta a um incidente, o reinício é adiado para preservar evidências. Mesmo no mesmo servidor, siga esta última ordem se houver suspeita de comprometimento.

## Como identificar os ambientes que usam PHP

Confira tanto o inventário de ativos quanto os servidores que estão efetivamente em operação. Verificar apenas o site principal pode deixar passar servidores fora do controle de gestão. Equipamentos e contêineres que incluem PHP também devem ser verificados.

1. Liste os sites e sistemas expostos à internet.
2. Verifique os sites desenvolvidos por terceiros e os sites antigos.
3. Verifique os servidores de eventos e testes e as páginas de administração.
4. Verifique se as interfaces de administração de equipamentos e as soluções incluem PHP.
5. Verifique as imagens de contêiner e os contêineres em execução.
6. Registre a versão do PHP e o responsável pela administração de cada ambiente.

Se você usa hospedagem, peça à empresa que confirme se a correção foi aplicada. Para o PHP incluído em equipamentos, verifique as atualizações do fabricante. Inspecione também os sistemas internos, mas priorize as medidas nos servidores expostos à internet.

## Versões corrigidas do PHP e critérios de fim de suporte

A versão corrigida da série 8.5 no comunicado oficial do PHP é a **8.5.12**. O texto original da KISA informa a mesma versão. Isso não significa que seja necessário esperar pela 8.5.13 para aplicar a correção.

| Série em uso | Versão com correção das duas vulnerabilidades | Critério de resposta |
| --- | --- | --- |
| PHP 8.5 | 8.5.13 ou superior | Verificar a versão de segurança mais recente da série |
| PHP 8.4 | 8.4.27 ou superior | Verificar a versão de segurança mais recente da série |
| PHP 8.3 | 8.3.36 ou superior | Verificar a versão de segurança mais recente da série |
| PHP 8.2 | 8.2.35 ou superior | Aplicar a correção e preparar a migração para uma série mais recente |
| PHP 8.1 ou anterior | Suporte regular de segurança encerrado | Migrar para uma série com suporte ou verificar as correções do fornecedor |

A tabela se baseia nas versões corrigidas anunciadas em 21 de outubro de 2026. Os pacotes das distribuições podem manter o mesmo número de versão exibido. Nesse caso, verifique no histórico de alterações se os dois CVEs foram corrigidos. [Comunicado de versões de segurança do PHP](https://www.php.net/archive/2026.php)

O suporte de segurança do PHP 8.2 termina em 31 de dezembro de 2026. A KISA recomenda a migração para PHP 8.3 ou superior. Antes da migração, teste a compatibilidade da aplicação. [Cronograma de suporte do PHP](https://www.php.net/supported-versions.php)

O suporte regular de segurança do PHP 8.1 e das versões anteriores já terminou. As correções da distribuição ou de empresas de suporte de longo prazo devem ser verificadas separadamente. Os patches de código-fonte para versões antigas divulgados nesta ocasião também não significam a retomada do suporte regular.

## Como atualizar e reiniciar

Após substituir os arquivos de instalação, é necessário reiniciar os serviços que executam o PHP. Os processos existentes podem continuar executando o código que permanece na memória. Se houver suspeita de comprometimento, preserve as evidências antes de realizar as etapas abaixo.

1. Avalie o impacto da correção nas funcionalidades existentes.
2. Verifique a compatibilidade do serviço em um ambiente de testes.
3. Aplique os pacotes corrigidos, começando pelos servidores expostos à internet.
4. Reinicie todos os serviços que executam o PHP.
5. Em ambientes de contêineres, faça uma nova implantação com a imagem corrigida.
6. Confirme se a atualização está ativa no PHP que efetivamente processa as requisições web.

Os serviços a reiniciar incluem PHP-FPM e Apache mod_php. Verifique também php-cgi, FrankenPHP e LiteSpeed. Se houver vários ambientes PHP no servidor, cada um deve ser verificado.

`php -v` mostra a versão do PHP executada na linha de comando. Ela pode ser diferente da usada pelo serviço web. Não considere a atualização concluída apenas com base na saída da linha de comando.

## Critérios para configurações temporárias antes da atualização

As medidas temporárias ajudam a reduzir alguns caminhos de ataque. Elas não resolvem todas as vulnerabilidades. Se for difícil aplicar as configurações, avalie bloquear o acesso externo.

### Como aplicar a configuração memory_limit?

A recomendação temporária oficial para esta vulnerabilidade é `memory_limit=-1`. Esse valor remove o limite de uso de memória do próprio PHP. Não o trate como uma configuração normal de operação.

A remoção do limite reduz determinados caminhos que provocam falta de memória. A configuração não impede falhas reais de alocação de memória. Também é necessário avaliar limites de tamanho de requisição e medidas de gerenciamento de recursos. [Aviso sobre a vulnerabilidade de falta de memória do PHP](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)

| Item | Medida temporária oficial | O que verificar ao aplicar |
| --- | --- | --- |
| `memory_limit` | Definir como `-1` | Aplicar uma configuração administrativa para impedir alterações pela aplicação |
| `session.upload_progress.enabled` | Definir como `0` | Usar um local de configuração aplicado antes do processamento das requisições |
| `post_max_size` | Exemplo de `8M` quando uploads não são necessários | Avaliar os requisitos reais do serviço junto com os limites da camada de entrada |
| `upload_max_filesize` | Definir um valor menor que `post_max_size` | Verificar o impacto na funcionalidade de upload de arquivos |
| `fatal_error_backtraces` | Definir como `0` no PHP 8.5 | Não aplicar indiscriminadamente às outras séries |

Os valores da tabela seguem os comunicados oficiais de resposta de outubro de 2026. `8M` é um exemplo apresentado para serviços que não precisam de uploads. Não é um padrão de tamanho a ser aplicado a todos os serviços.

1. Limite o tamanho das requisições no firewall de aplicações web, no servidor web e no proxy.
2. Verifique se os limites também se aplicam a requisições sem informação de tamanho.
3. Se uploads não forem necessários, bloqueie requisições multipart na camada de entrada.
4. Verifique as regras de bloqueio mais recentes do firewall de aplicações web.
5. Aplique as configurações em locais como `php.ini` ou o pool do PHP-FPM.
6. Verifique se é necessário preservar evidências e depois reinicie os processos PHP.

Não aplique as configurações temporárias apenas com `ini_set()`. Configurações necessárias antes do processamento das requisições podem ser aplicadas tarde demais. Também não espere que o `.user.ini` do PHP-FPM cumpra esse papel. [Medidas temporárias oficiais do PHP](https://www.php.net/archive/2026.php)

### O que verificar no comunicado adicional de 23 de outubro

No comunicado adicional, o PHP recomendou desativar a funcionalidade de progresso de upload. O aviso trata de um caminho de execução separado que permanece em algumas combinações de configurações. Se a funcionalidade já estiver desativada, a orientação é mantê-la assim até a próxima versão regular de correção.

As condições incluem a alteração do método de serialização de sessões durante a execução. Nem todas as instalações do PHP atendem às mesmas condições. Consulte o comunicado adicional para decidir se as configurações devem ser restauradas após a correção. (Valor verificado: recomendação de manter session.upload_progress.enabled=0 até a próxima versão regular de correção de bugs · fonte php.net · verificado em 2026-10-23) [Comunicado adicional sobre PHP Session upload progress](https://www.php.net/archive/2026.php)

## Como verificar os logs e trocar as credenciais

A KISA recomenda verificar, no mínimo, os registros **a partir de 20 de outubro de 2026**. Se possível, verifique também os registros anteriores. A correção não reverte comprometimentos ou vazamentos de informações que já ocorreram.

| Alvo da verificação | Indícios a procurar |
| --- | --- |
| Logs do servidor web | Erros HTTP 500 repetidos |
| Registros de execução do PHP | Encerramentos anormais e segfault |
| Pastas web, de upload e temporárias | Arquivos PHP novos ou alterados |
| Registros de execução de processos | Execução de sh, bash ou ferramentas de download pelo servidor web |
| Conexões de rede | Indícios de novas conexões com endereços externos desconhecidos |
| Site e páginas de administração | Scripts externos adicionados sem autorização |

A existência de erros, por si só, não confirma um comprometimento. Da mesma forma, a ausência de registros anormais não garante a segurança. A KISA orienta o seguinte:

> Mesmo sem anormalidades nos registros, a segurança não está garantida; por isso, realizar a atualização e a troca de credenciais em conjunto
>
> KISA, “Diretrizes de resposta de segurança para empresas sobre as vulnerabilidades de segurança do PHP (PHP2Shell)”

Recomenda-se trocar as credenciais dos servidores que estavam expostos à internet antes da correção. Nos servidores em que forem encontrados indícios de comprometimento, a troca é obrigatória. Isso inclui senhas do banco de dados e de administradores. Verifique também a possibilidade de exposição de chaves de API e tokens de acesso.

Nos serviços conectados a um banco de dados com dados pessoais, verifique também os registros do banco. É necessário procurar indícios de consultas em massa e extração de dados. Restrinja também o acesso direto ao phpMyAdmin pela internet. Reduza as permissões da conta do serviço web no banco de dados ao necessário. [Orientações de medidas preventivas da 개인정보보호위원회](https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074&mCode=C010010000&nttId=12588)

## Ordem de resposta em caso de suspeita de comprometimento

Se houver suspeita de comprometimento, não desligue nem reinicie o servidor imediatamente. O reinício pode apagar vestígios do ataque que permanecem na memória. Isole o servidor da rede e depois colete as evidências.

1. Bloqueie o acesso externo do servidor na rede.
2. Empresas na Coreia devem notificar o incidente pelo menu de notificação de incidentes de segurança do 보호나라.
3. Preserve os logs e a lista de programas em execução.
4. Preserve também as informações das conexões de rede atuais.
5. Após coletar as evidências, atualize e reinicie.
6. Remova os web shells e troque as credenciais.

O canal de atendimento na Coreia é o KISA 118. O caminho do menu é 보호나라 > Notificação de incidente de segurança > Enviar notificação. Se a operação estiver no exterior, verifique o canal de notificação da região.

## Comparação de erros comuns

Para confirmar a aplicação da correção, é necessário verificar também o estado de execução e o histórico de alterações. A mensagem de instalação concluída, por si só, não encerra a verificação. Inclua os pontos abaixo na lista de verificação.

| Conclusão comum | O que deve ser verificado |
| --- | --- |
| Se `php -v` mudou, está concluído | Verificar o PHP efetivamente usado pelo serviço web |
| Basta instalar o pacote para concluir | Confirmar o reinício dos serviços que executam o PHP |
| Se o número da versão não mudou, nenhuma medida foi tomada | Verificar a correção dos CVEs no histórico de alterações da distribuição |
| Com um firewall de aplicações web, é possível dispensar a correção | Verificar as regras mais recentes e atualizar o PHP em conjunto |
| Se os logs estão limpos, não houve vazamento | Avaliar também a possibilidade de exposição das credenciais |
| A empresa terceirizada cuida dos sites por conta própria | Solicitar comprovação da aplicação por serviço |

Não execute em servidores de produção códigos de verificação encontrados na internet. A KISA alerta sobre PoCs falsas que contêm malware. Uma PoC é um código de verificação que demonstra a possibilidade de exploração de uma vulnerabilidade. Para verificar se o ambiente está vulnerável, comece pela versão e pelo histórico de correções.

## Lista de verificação da conclusão das medidas em ambientes terceirizados e de hospedagem

É recomendável registrar, no relatório de conclusão das medidas, as comprovações de cada serviço. A tabela abaixo organiza as diretrizes de resposta da KISA em itens de verificação operacional. Não se trata de um formulário oficial separado para envio.

| Item de verificação | O que solicitar à empresa ou ao responsável |
| --- | --- |
| Possíveis ambientes não verificados | Lista de verificação dos sites, páginas de administração e servidores de testes |
| Correção das vulnerabilidades | Versão aplicada ou histórico de alterações do pacote que mencione os dois CVEs |
| Estado de execução | Registro de reinício do serviço ou de nova implantação do contêiner |
| Aplicação efetiva | Ambiente de execução do PHP verificado no serviço web |
| Verificação de comprometimento | Período dos logs analisados e resultados encontrados |
| Credenciais | Credenciais a trocar e confirmação da conclusão |
| Tarefas pendentes | Servidores com apenas medidas temporárias e plano de correção posterior |

Por exemplo, suponha que a empresa tenha informado apenas a conclusão da instalação do pacote. Nesse caso, solicite os resultados da verificação do reinício e do ambiente de execução web. A análise dos logs e a troca de credenciais podem ser confirmadas como itens separados.

## FAQ

### É possível bloquear PHP2Shell alterando a senha de login?
Como pode ser explorado sem login, apenas alterar a senha não resolve o problema. É necessário aplicar uma atualização de segurança do PHP. A troca das credenciais é uma medida separada para lidar com a possibilidade de vazamento.

### No PHP 8.5, é preciso esperar pela versão 8.5.13?
Os comunicados originais do PHP e da KISA indicam a versão 8.5.13 como a versão que corrige as duas vulnerabilidades. Isso não significa que seja necessário esperar pela 8.5.13. Ao aplicar a atualização, confira também a versão oficial mais recente dessa série.

### Se eu uso PHP-FPM, não preciso fazer a verificação?
O PHP-FPM também deve ser verificado. As condições para um ataque podem variar conforme a forma de execução. Não considere o ambiente seguro apenas pelo nome.

### Se o resultado de php -v mostrar uma versão corrigida, as medidas necessárias estão concluídas?
O PHP da linha de comando pode ser diferente do PHP do serviço web. Verifique o ambiente que realmente processa as requisições web. Também é necessário verificar se o serviço em execução foi reiniciado.

### Se o número da versão continuar igual após a aplicação do patch, isso significa que houve uma falha?
Os pacotes da distribuição ou do fabricante podem incorporar as correções à versão existente. Verifique no histórico de alterações do pacote se as correções para os dois CVEs foram incorporadas.

### A configuração memory_limit=-1 é proibida nas medidas de resposta a esta vulnerabilidade?
As recomendações oficiais de mitigação temporária desta vulnerabilidade incluem essa configuração. É necessário distingui-las das recomendações gerais de operação. Avalie também medidas de limitação de requisições e de gerenciamento de recursos.

### Sites sem upload de arquivos também são afetados?
Não é possível excluir um site do grupo de afetados apenas por ele não ter uma função de upload. Como se trata de uma vulnerabilidade do próprio PHP, verifique a versão utilizada e o estado de aplicação dos patches. O bloqueio de requisições multipart desnecessárias é uma medida temporária.

### Posso continuar usando PHP 8.1 ou anterior se houver um patch do fornecedor?
Os patches do fornecedor devem ser verificados separadamente do encerramento do suporte regular. Mesmo que você aplique esse patch temporariamente, elabore um plano de migração para uma versão com suporte.

### Se não houver anomalias nos logs, posso manter as credenciais?
Não é possível concluir apenas pelos logs que não houve vazamento de informações. A KISA recomenda trocar as credenciais dos servidores que estavam expostos à internet antes da aplicação do patch. Se houver indícios de comprometimento, a troca é obrigatória.

### Há suspeita de comprometimento. Devo atualizar primeiro?
Primeiro, isole o servidor da rede. Após a notificação e a coleta de evidências, prossiga com a atualização. A reinicialização pode apagar os vestígios do ataque que permanecem na memória.

### O que os usuários de serviços de hospedagem devem verificar?
Solicite ao fornecedor comprovação da aplicação dos patches em cada serviço. Peça também os resultados da verificação da reinicialização e do ambiente que realmente executa o PHP na web. Verifique separadamente se os logs foram inspecionados e se as credenciais foram trocadas.

### Posso reativar a configuração de progresso de upload após aplicar o patch?
Consulte o comunicado adicional do PHP de 23 de outubro de 2026. Devido a problemas adicionais em algumas combinações de configurações, recomenda-se manter a funcionalidade desativada. Decida se deve restaurar as configurações somente após verificar as correções posteriores.

## Sources

- [KISA 보호나라: diretrizes de resposta de segurança para empresas em relação à vulnerabilidade de segurança do PHP (PHP2Shell), 22 de outubro de 2026](https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&menuNo=205020&nttId=72230)
- [Comunicado do PHP de 2026: atualização de segurança de 21 de outubro e orientações adicionais de 23 de outubro sobre Session upload progress](https://www.php.net/archive/2026.php)
- [Aviso de segurança do PHP: RCE por corrupção causada por OOM](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)
- [Aviso de segurança do PHP: RCE por estado global obsoleto](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)
- [Versões do PHP com suporte: período de suporte oficial](https://www.php.net/supported-versions.php)
- [PHP2Shell: explicação da vulnerabilidade pelos pesquisadores e abrangência do impacto](https://www.php2shell.com/)
- [개인정보보호위원회: solicitação de medidas para prevenir vazamentos de dados pessoais relacionados à vulnerabilidade de segurança do PHP, 22 de outubro de 2026](https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074&mCode=C010010000&nttId=12588)

## Images

![Uma mulher segura o conector de um cabo Ethernet azul perto da porta de um servidor em uma sala de servidores.](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODIsInB1ciI6ImJsb2JfaWQifX0=--756ccdbcf3c83be470043fadc3bfdf6d3eeeef02/ai-6de3df23.webp)
![Um técnico mais velho verifica um tablet ao lado de um armário aberto com equipamentos de rede numa fábrica.](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODgsInB1ciI6ImJsb2JfaWQifX0=--ab8091216d8ebf858c1dfbe779a6e6a5d3535ae7/ai-61ada64c.webp)