{"content_id":"vufynon7qa","slug":"php2shell-enterprise-security-patch-response-guide","locale":"pt","schema_type":"HowTo","category":"how_to","category_name":"Como Fazer","title":"PHP2Shell: como proteger servidores empresariais","summary":"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.","sponsorship_disclosure":null,"affiliate_disclosure":null,"commerce_disclosure":null,"author":{"name":"injoys","url":"https://injoys.com/ko/about"},"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."],"content_markdown":"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.\n\nAs 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.\n\n## Que tipo de vulnerabilidade é o PHP2Shell?\n\nPHP2Shell é 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.\n\n| Categoria | Identificador | Natureza do problema |\n| --- | --- | --- |\n| Problema no tratamento de falta de memória | CVE-2026-109618 | Processamento de dados internos incompletos em situações de falta de memória |\n| 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 |\n\nA 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.\n\nA 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\u0026menuNo=205020\u0026nttId=72230), [Explicação dos pesquisadores sobre o PHP2Shell](https://www.php2shell.com/)\n\n## Ordem de resposta conforme a situação\n\nA 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.\n\n| Situação atual | Primeira ação | Próxima ação |\n| --- | --- | --- |\n| 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 |\n| 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 |\n| 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 |\n| 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 |\n| 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 |\n\nReiniciar 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.\n\n## Como identificar os ambientes que usam PHP\n\nConfira 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.\n\n1. Liste os sites e sistemas expostos à internet.\n2. Verifique os sites desenvolvidos por terceiros e os sites antigos.\n3. Verifique os servidores de eventos e testes e as páginas de administração.\n4. Verifique se as interfaces de administração de equipamentos e as soluções incluem PHP.\n5. Verifique as imagens de contêiner e os contêineres em execução.\n6. Registre a versão do PHP e o responsável pela administração de cada ambiente.\n\nSe 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.\n\n## Versões corrigidas do PHP e critérios de fim de suporte\n\nA 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.\n\n| Série em uso | Versão com correção das duas vulnerabilidades | Critério de resposta |\n| --- | --- | --- |\n| PHP 8.5 | 8.5.13 ou superior | Verificar a versão de segurança mais recente da série |\n| PHP 8.4 | 8.4.27 ou superior | Verificar a versão de segurança mais recente da série |\n| PHP 8.3 | 8.3.36 ou superior | Verificar a versão de segurança mais recente da série |\n| PHP 8.2 | 8.2.35 ou superior | Aplicar a correção e preparar a migração para uma série mais recente |\n| 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 |\n\nA 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)\n\nO 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)\n\nO 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.\n\n## Como atualizar e reiniciar\n\nApó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.\n\n1. Avalie o impacto da correção nas funcionalidades existentes.\n2. Verifique a compatibilidade do serviço em um ambiente de testes.\n3. Aplique os pacotes corrigidos, começando pelos servidores expostos à internet.\n4. Reinicie todos os serviços que executam o PHP.\n5. Em ambientes de contêineres, faça uma nova implantação com a imagem corrigida.\n6. Confirme se a atualização está ativa no PHP que efetivamente processa as requisições web.\n\nOs 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.\n\n`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.\n\n## Critérios para configurações temporárias antes da atualização\n\nAs 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.\n\n### Como aplicar a configuração memory_limit?\n\nA 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.\n\nA 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)\n\n| Item | Medida temporária oficial | O que verificar ao aplicar |\n| --- | --- | --- |\n| `memory_limit` | Definir como `-1` | Aplicar uma configuração administrativa para impedir alterações pela aplicação |\n| `session.upload_progress.enabled` | Definir como `0` | Usar um local de configuração aplicado antes do processamento das requisições |\n| `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 |\n| `upload_max_filesize` | Definir um valor menor que `post_max_size` | Verificar o impacto na funcionalidade de upload de arquivos |\n| `fatal_error_backtraces` | Definir como `0` no PHP 8.5 | Não aplicar indiscriminadamente às outras séries |\n\nOs 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.\n\n1. Limite o tamanho das requisições no firewall de aplicações web, no servidor web e no proxy.\n2. Verifique se os limites também se aplicam a requisições sem informação de tamanho.\n3. Se uploads não forem necessários, bloqueie requisições multipart na camada de entrada.\n4. Verifique as regras de bloqueio mais recentes do firewall de aplicações web.\n5. Aplique as configurações em locais como `php.ini` ou o pool do PHP-FPM.\n6. Verifique se é necessário preservar evidências e depois reinicie os processos PHP.\n\nNã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)\n\n### O que verificar no comunicado adicional de 23 de outubro\n\nNo 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.\n\nAs 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)\n\n## Como verificar os logs e trocar as credenciais\n\nA 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.\n\n| Alvo da verificação | Indícios a procurar |\n| --- | --- |\n| Logs do servidor web | Erros HTTP 500 repetidos |\n| Registros de execução do PHP | Encerramentos anormais e segfault |\n| Pastas web, de upload e temporárias | Arquivos PHP novos ou alterados |\n| Registros de execução de processos | Execução de sh, bash ou ferramentas de download pelo servidor web |\n| Conexões de rede | Indícios de novas conexões com endereços externos desconhecidos |\n| Site e páginas de administração | Scripts externos adicionados sem autorização |\n\nA 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:\n\n\u003e 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\n\u003e\n\u003e KISA, “Diretrizes de resposta de segurança para empresas sobre as vulnerabilidades de segurança do PHP (PHP2Shell)”\n\nRecomenda-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.\n\nNos 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\u0026mCode=C010010000\u0026nttId=12588)\n\n## Ordem de resposta em caso de suspeita de comprometimento\n\nSe 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.\n\n1. Bloqueie o acesso externo do servidor na rede.\n2. Empresas na Coreia devem notificar o incidente pelo menu de notificação de incidentes de segurança do 보호나라.\n3. Preserve os logs e a lista de programas em execução.\n4. Preserve também as informações das conexões de rede atuais.\n5. Após coletar as evidências, atualize e reinicie.\n6. Remova os web shells e troque as credenciais.\n\nO canal de atendimento na Coreia é o KISA 118. O caminho do menu é 보호나라 \u003e Notificação de incidente de segurança \u003e Enviar notificação. Se a operação estiver no exterior, verifique o canal de notificação da região.\n\n## Comparação de erros comuns\n\nPara 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.\n\n| Conclusão comum | O que deve ser verificado |\n| --- | --- |\n| Se `php -v` mudou, está concluído | Verificar o PHP efetivamente usado pelo serviço web |\n| Basta instalar o pacote para concluir | Confirmar o reinício dos serviços que executam o PHP |\n| 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 |\n| Com um firewall de aplicações web, é possível dispensar a correção | Verificar as regras mais recentes e atualizar o PHP em conjunto |\n| Se os logs estão limpos, não houve vazamento | Avaliar também a possibilidade de exposição das credenciais |\n| A empresa terceirizada cuida dos sites por conta própria | Solicitar comprovação da aplicação por serviço |\n\nNã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.\n\n## Lista de verificação da conclusão das medidas em ambientes terceirizados e de hospedagem\n\nÉ 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.\n\n| Item de verificação | O que solicitar à empresa ou ao responsável |\n| --- | --- |\n| Possíveis ambientes não verificados | Lista de verificação dos sites, páginas de administração e servidores de testes |\n| Correção das vulnerabilidades | Versão aplicada ou histórico de alterações do pacote que mencione os dois CVEs |\n| Estado de execução | Registro de reinício do serviço ou de nova implantação do contêiner |\n| Aplicação efetiva | Ambiente de execução do PHP verificado no serviço web |\n| Verificação de comprometimento | Período dos logs analisados e resultados encontrados |\n| Credenciais | Credenciais a trocar e confirmação da conclusão |\n| Tarefas pendentes | Servidores com apenas medidas temporárias e plano de correção posterior |\n\nPor 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.","content_html":"\u003cp\u003eA 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.\u003c/p\u003e\n\u003cp\u003eAs 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#que-tipo-de-vulnerabilidade-%C3%A9-o-php2shell\" class=\"anchor\" id=\"que-tipo-de-vulnerabilidade-é-o-php2shell\"\u003e\u003c/a\u003eQue tipo de vulnerabilidade é o PHP2Shell?\u003c/h2\u003e\n\u003cp\u003ePHP2Shell é 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCategoria\u003c/th\u003e\n\u003cth\u003eIdentificador\u003c/th\u003e\n\u003cth\u003eNatureza do problema\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Categoria\"\u003eProblema no tratamento de falta de memória\u003c/td\u003e\n\u003ctd data-label=\"Identificador\"\u003eCVE-2026-109618\u003c/td\u003e\n\u003ctd data-label=\"Natureza do problema\"\u003eProcessamento de dados internos incompletos em situações de falta de memória\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Categoria\"\u003eProblema de estado remanescente entre requisições\u003c/td\u003e\n\u003ctd data-label=\"Identificador\"\u003eCVE-2026-109619\u003c/td\u003e\n\u003ctd data-label=\"Natureza do problema\"\u003eUso, em requisições posteriores, de um estado que aponta para memória já liberada\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003cp\u003eA 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. \u003ca href=\"https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133\u0026amp;menuNo=205020\u0026amp;nttId=72230\"\u003eDiretrizes de resposta da KISA para empresas\u003c/a\u003e, \u003ca href=\"https://www.php2shell.com/\"\u003eExplicação dos pesquisadores sobre o PHP2Shell\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#ordem-de-resposta-conforme-a-situa%C3%A7%C3%A3o\" class=\"anchor\" id=\"ordem-de-resposta-conforme-a-situação\"\u003e\u003c/a\u003eOrdem de resposta conforme a situação\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eSituação atual\u003c/th\u003e\n\u003cth\u003ePrimeira ação\u003c/th\u003e\n\u003cth\u003ePróxima ação\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situação atual\"\u003eServidor exposto à internet sem sinais de comprometimento\u003c/td\u003e\n\u003ctd data-label=\"Primeira ação\"\u003eAvaliar a compatibilidade e aplicar a versão corrigida\u003c/td\u003e\n\u003ctd data-label=\"Próxima ação\"\u003eReiniciar, verificar a versão efetivamente em uso e analisar os logs\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situação atual\"\u003eDescoberta de web shell ou conexão suspeita\u003c/td\u003e\n\u003ctd data-label=\"Primeira ação\"\u003eIsolar da rede e notificar o incidente\u003c/td\u003e\n\u003ctd data-label=\"Próxima ação\"\u003ePreservar as evidências e depois executar as medidas de recuperação\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situação atual\"\u003eServidor que não pode ser atualizado imediatamente\u003c/td\u003e\n\u003ctd data-label=\"Primeira ação\"\u003eAplicar as configurações temporárias oficiais e limitar requisições na camada de entrada\u003c/td\u003e\n\u003ctd data-label=\"Próxima ação\"\u003eDefinir um cronograma de correção e aplicá-la\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situação atual\"\u003eServidor em que nem medidas temporárias são viáveis\u003c/td\u003e\n\u003ctd data-label=\"Primeira ação\"\u003eAvaliar o bloqueio do acesso externo ou a suspensão temporária\u003c/td\u003e\n\u003ctd data-label=\"Próxima ação\"\u003eDecidir sobre a retomada após a correção\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situação atual\"\u003eAmbiente gerenciado por uma empresa de hospedagem ou pelo fabricante\u003c/td\u003e\n\u003ctd data-label=\"Primeira ação\"\u003eConfirmar com a empresa responsável se a correção foi aplicada\u003c/td\u003e\n\u003ctd data-label=\"Próxima ação\"\u003eObter comprovação de que a correção está ativa no ambiente de execução\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eReiniciar 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#como-identificar-os-ambientes-que-usam-php\" class=\"anchor\" id=\"como-identificar-os-ambientes-que-usam-php\"\u003e\u003c/a\u003eComo identificar os ambientes que usam PHP\u003c/h2\u003e\n\u003cp\u003eConfira 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.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eListe os sites e sistemas expostos à internet.\u003c/li\u003e\n\u003cli\u003eVerifique os sites desenvolvidos por terceiros e os sites antigos.\u003c/li\u003e\n\u003cli\u003eVerifique os servidores de eventos e testes e as páginas de administração.\u003c/li\u003e\n\u003cli\u003eVerifique se as interfaces de administração de equipamentos e as soluções incluem PHP.\u003c/li\u003e\n\u003cli\u003eVerifique as imagens de contêiner e os contêineres em execução.\u003c/li\u003e\n\u003cli\u003eRegistre a versão do PHP e o responsável pela administração de cada ambiente.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eSe 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#vers%C3%B5es-corrigidas-do-php-e-crit%C3%A9rios-de-fim-de-suporte\" class=\"anchor\" id=\"versões-corrigidas-do-php-e-critérios-de-fim-de-suporte\"\u003e\u003c/a\u003eVersões corrigidas do PHP e critérios de fim de suporte\u003c/h2\u003e\n\u003cp\u003eA versão corrigida da série 8.5 no comunicado oficial do PHP é a \u003cstrong\u003e8.5.12\u003c/strong\u003e. 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eSérie em uso\u003c/th\u003e\n\u003cth\u003eVersão com correção das duas vulnerabilidades\u003c/th\u003e\n\u003cth\u003eCritério de resposta\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Série em uso\"\u003ePHP 8.5\u003c/td\u003e\n\u003ctd data-label=\"Versão com correção das duas vulnerabilidades\"\u003e8.5.13 ou superior\u003c/td\u003e\n\u003ctd data-label=\"Critério de resposta\"\u003eVerificar a versão de segurança mais recente da série\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Série em uso\"\u003ePHP 8.4\u003c/td\u003e\n\u003ctd data-label=\"Versão com correção das duas vulnerabilidades\"\u003e8.4.27 ou superior\u003c/td\u003e\n\u003ctd data-label=\"Critério de resposta\"\u003eVerificar a versão de segurança mais recente da série\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Série em uso\"\u003ePHP 8.3\u003c/td\u003e\n\u003ctd data-label=\"Versão com correção das duas vulnerabilidades\"\u003e8.3.36 ou superior\u003c/td\u003e\n\u003ctd data-label=\"Critério de resposta\"\u003eVerificar a versão de segurança mais recente da série\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Série em uso\"\u003ePHP 8.2\u003c/td\u003e\n\u003ctd data-label=\"Versão com correção das duas vulnerabilidades\"\u003e8.2.35 ou superior\u003c/td\u003e\n\u003ctd data-label=\"Critério de resposta\"\u003eAplicar a correção e preparar a migração para uma série mais recente\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Série em uso\"\u003ePHP 8.1 ou anterior\u003c/td\u003e\n\u003ctd data-label=\"Versão com correção das duas vulnerabilidades\"\u003eSuporte regular de segurança encerrado\u003c/td\u003e\n\u003ctd data-label=\"Critério de resposta\"\u003eMigrar para uma série com suporte ou verificar as correções do fornecedor\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eA 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. \u003ca href=\"https://www.php.net/archive/2026.php\"\u003eComunicado de versões de segurança do PHP\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eO 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. \u003ca href=\"https://www.php.net/supported-versions.php\"\u003eCronograma de suporte do PHP\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eO 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#como-atualizar-e-reiniciar\" class=\"anchor\" id=\"como-atualizar-e-reiniciar\"\u003e\u003c/a\u003eComo atualizar e reiniciar\u003c/h2\u003e\n\u003cp\u003eApó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.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eAvalie o impacto da correção nas funcionalidades existentes.\u003c/li\u003e\n\u003cli\u003eVerifique a compatibilidade do serviço em um ambiente de testes.\u003c/li\u003e\n\u003cli\u003eAplique os pacotes corrigidos, começando pelos servidores expostos à internet.\u003c/li\u003e\n\u003cli\u003eReinicie todos os serviços que executam o PHP.\u003c/li\u003e\n\u003cli\u003eEm ambientes de contêineres, faça uma nova implantação com a imagem corrigida.\u003c/li\u003e\n\u003cli\u003eConfirme se a atualização está ativa no PHP que efetivamente processa as requisições web.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eOs 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.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ephp -v\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#crit%C3%A9rios-para-configura%C3%A7%C3%B5es-tempor%C3%A1rias-antes-da-atualiza%C3%A7%C3%A3o\" class=\"anchor\" id=\"critérios-para-configurações-temporárias-antes-da-atualização\"\u003e\u003c/a\u003eCritérios para configurações temporárias antes da atualização\u003c/h2\u003e\n\u003cp\u003eAs 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#como-aplicar-a-configura%C3%A7%C3%A3o-memory_limit\" class=\"anchor\" id=\"como-aplicar-a-configuração-memory_limit\"\u003e\u003c/a\u003eComo aplicar a configuração memory_limit?\u003c/h3\u003e\n\u003cp\u003eA recomendação temporária oficial para esta vulnerabilidade é \u003ccode\u003ememory_limit=-1\u003c/code\u003e. 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.\u003c/p\u003e\n\u003cp\u003eA 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. \u003ca href=\"https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w\"\u003eAviso sobre a vulnerabilidade de falta de memória do PHP\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eItem\u003c/th\u003e\n\u003cth\u003eMedida temporária oficial\u003c/th\u003e\n\u003cth\u003eO que verificar ao aplicar\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003e\u003ccode\u003ememory_limit\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Medida temporária oficial\"\u003eDefinir como \u003ccode\u003e-1\u003c/code\u003e\n\u003c/td\u003e\n\u003ctd data-label=\"O que verificar ao aplicar\"\u003eAplicar uma configuração administrativa para impedir alterações pela aplicação\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003e\u003ccode\u003esession.upload_progress.enabled\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Medida temporária oficial\"\u003eDefinir como \u003ccode\u003e0\u003c/code\u003e\n\u003c/td\u003e\n\u003ctd data-label=\"O que verificar ao aplicar\"\u003eUsar um local de configuração aplicado antes do processamento das requisições\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003e\u003ccode\u003epost_max_size\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Medida temporária oficial\"\u003eExemplo de \u003ccode\u003e8M\u003c/code\u003e quando uploads não são necessários\u003c/td\u003e\n\u003ctd data-label=\"O que verificar ao aplicar\"\u003eAvaliar os requisitos reais do serviço junto com os limites da camada de entrada\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003e\u003ccode\u003eupload_max_filesize\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Medida temporária oficial\"\u003eDefinir um valor menor que \u003ccode\u003epost_max_size\u003c/code\u003e\n\u003c/td\u003e\n\u003ctd data-label=\"O que verificar ao aplicar\"\u003eVerificar o impacto na funcionalidade de upload de arquivos\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003e\u003ccode\u003efatal_error_backtraces\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Medida temporária oficial\"\u003eDefinir como \u003ccode\u003e0\u003c/code\u003e no PHP 8.5\u003c/td\u003e\n\u003ctd data-label=\"O que verificar ao aplicar\"\u003eNão aplicar indiscriminadamente às outras séries\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eOs valores da tabela seguem os comunicados oficiais de resposta de outubro de 2026. \u003ccode\u003e8M\u003c/code\u003e é 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.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eLimite o tamanho das requisições no firewall de aplicações web, no servidor web e no proxy.\u003c/li\u003e\n\u003cli\u003eVerifique se os limites também se aplicam a requisições sem informação de tamanho.\u003c/li\u003e\n\u003cli\u003eSe uploads não forem necessários, bloqueie requisições multipart na camada de entrada.\u003c/li\u003e\n\u003cli\u003eVerifique as regras de bloqueio mais recentes do firewall de aplicações web.\u003c/li\u003e\n\u003cli\u003eAplique as configurações em locais como \u003ccode\u003ephp.ini\u003c/code\u003e ou o pool do PHP-FPM.\u003c/li\u003e\n\u003cli\u003eVerifique se é necessário preservar evidências e depois reinicie os processos PHP.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eNão aplique as configurações temporárias apenas com \u003ccode\u003eini_set()\u003c/code\u003e. Configurações necessárias antes do processamento das requisições podem ser aplicadas tarde demais. Também não espere que o \u003ccode\u003e.user.ini\u003c/code\u003e do PHP-FPM cumpra esse papel. \u003ca href=\"https://www.php.net/archive/2026.php\"\u003eMedidas temporárias oficiais do PHP\u003c/a\u003e\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#o-que-verificar-no-comunicado-adicional-de-23-de-outubro\" class=\"anchor\" id=\"o-que-verificar-no-comunicado-adicional-de-23-de-outubro\"\u003e\u003c/a\u003eO que verificar no comunicado adicional de 23 de outubro\u003c/h3\u003e\n\u003cp\u003eNo 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.\u003c/p\u003e\n\u003cp\u003eAs 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) \u003ca href=\"https://www.php.net/archive/2026.php\"\u003eComunicado adicional sobre PHP Session upload progress\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#como-verificar-os-logs-e-trocar-as-credenciais\" class=\"anchor\" id=\"como-verificar-os-logs-e-trocar-as-credenciais\"\u003e\u003c/a\u003eComo verificar os logs e trocar as credenciais\u003c/h2\u003e\n\u003cp\u003eA KISA recomenda verificar, no mínimo, os registros \u003cstrong\u003ea partir de 20 de outubro de 2026\u003c/strong\u003e. Se possível, verifique também os registros anteriores. A correção não reverte comprometimentos ou vazamentos de informações que já ocorreram.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eAlvo da verificação\u003c/th\u003e\n\u003cth\u003eIndícios a procurar\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Alvo da verificação\"\u003eLogs do servidor web\u003c/td\u003e\n\u003ctd data-label=\"Indícios a procurar\"\u003eErros HTTP 500 repetidos\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Alvo da verificação\"\u003eRegistros de execução do PHP\u003c/td\u003e\n\u003ctd data-label=\"Indícios a procurar\"\u003eEncerramentos anormais e segfault\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Alvo da verificação\"\u003ePastas web, de upload e temporárias\u003c/td\u003e\n\u003ctd data-label=\"Indícios a procurar\"\u003eArquivos PHP novos ou alterados\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Alvo da verificação\"\u003eRegistros de execução de processos\u003c/td\u003e\n\u003ctd data-label=\"Indícios a procurar\"\u003eExecução de sh, bash ou ferramentas de download pelo servidor web\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Alvo da verificação\"\u003eConexões de rede\u003c/td\u003e\n\u003ctd data-label=\"Indícios a procurar\"\u003eIndícios de novas conexões com endereços externos desconhecidos\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Alvo da verificação\"\u003eSite e páginas de administração\u003c/td\u003e\n\u003ctd data-label=\"Indícios a procurar\"\u003eScripts externos adicionados sem autorização\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eA 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:\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eMesmo sem anormalidades nos registros, a segurança não está garantida; por isso, realizar a atualização e a troca de credenciais em conjunto\u003c/p\u003e\n\u003cp\u003eKISA, “Diretrizes de resposta de segurança para empresas sobre as vulnerabilidades de segurança do PHP (PHP2Shell)”\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eRecomenda-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.\u003c/p\u003e\n\u003cp\u003eNos 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. \u003ca href=\"https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074\u0026amp;mCode=C010010000\u0026amp;nttId=12588\"\u003eOrientações de medidas preventivas da 개인정보보호위원회\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#ordem-de-resposta-em-caso-de-suspeita-de-comprometimento\" class=\"anchor\" id=\"ordem-de-resposta-em-caso-de-suspeita-de-comprometimento\"\u003e\u003c/a\u003eOrdem de resposta em caso de suspeita de comprometimento\u003c/h2\u003e\n\u003cp\u003eSe 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.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eBloqueie o acesso externo do servidor na rede.\u003c/li\u003e\n\u003cli\u003eEmpresas na Coreia devem notificar o incidente pelo menu de notificação de incidentes de segurança do 보호나라.\u003c/li\u003e\n\u003cli\u003ePreserve os logs e a lista de programas em execução.\u003c/li\u003e\n\u003cli\u003ePreserve também as informações das conexões de rede atuais.\u003c/li\u003e\n\u003cli\u003eApós coletar as evidências, atualize e reinicie.\u003c/li\u003e\n\u003cli\u003eRemova os web shells e troque as credenciais.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eO canal de atendimento na Coreia é o KISA 118. O caminho do menu é 보호나라 \u0026gt; Notificação de incidente de segurança \u0026gt; Enviar notificação. Se a operação estiver no exterior, verifique o canal de notificação da região.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#compara%C3%A7%C3%A3o-de-erros-comuns\" class=\"anchor\" id=\"comparação-de-erros-comuns\"\u003e\u003c/a\u003eComparação de erros comuns\u003c/h2\u003e\n\u003cp\u003ePara 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eConclusão comum\u003c/th\u003e\n\u003cth\u003eO que deve ser verificado\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Conclusão comum\"\u003eSe \u003ccode\u003ephp -v\u003c/code\u003e mudou, está concluído\u003c/td\u003e\n\u003ctd data-label=\"O que deve ser verificado\"\u003eVerificar o PHP efetivamente usado pelo serviço web\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Conclusão comum\"\u003eBasta instalar o pacote para concluir\u003c/td\u003e\n\u003ctd data-label=\"O que deve ser verificado\"\u003eConfirmar o reinício dos serviços que executam o PHP\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Conclusão comum\"\u003eSe o número da versão não mudou, nenhuma medida foi tomada\u003c/td\u003e\n\u003ctd data-label=\"O que deve ser verificado\"\u003eVerificar a correção dos CVEs no histórico de alterações da distribuição\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Conclusão comum\"\u003eCom um firewall de aplicações web, é possível dispensar a correção\u003c/td\u003e\n\u003ctd data-label=\"O que deve ser verificado\"\u003eVerificar as regras mais recentes e atualizar o PHP em conjunto\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Conclusão comum\"\u003eSe os logs estão limpos, não houve vazamento\u003c/td\u003e\n\u003ctd data-label=\"O que deve ser verificado\"\u003eAvaliar também a possibilidade de exposição das credenciais\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Conclusão comum\"\u003eA empresa terceirizada cuida dos sites por conta própria\u003c/td\u003e\n\u003ctd data-label=\"O que deve ser verificado\"\u003eSolicitar comprovação da aplicação por serviço\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eNã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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#lista-de-verifica%C3%A7%C3%A3o-da-conclus%C3%A3o-das-medidas-em-ambientes-terceirizados-e-de-hospedagem\" class=\"anchor\" id=\"lista-de-verificação-da-conclusão-das-medidas-em-ambientes-terceirizados-e-de-hospedagem\"\u003e\u003c/a\u003eLista de verificação da conclusão das medidas em ambientes terceirizados e de hospedagem\u003c/h2\u003e\n\u003cp\u003eÉ 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eItem de verificação\u003c/th\u003e\n\u003cth\u003eO que solicitar à empresa ou ao responsável\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item de verificação\"\u003ePossíveis ambientes não verificados\u003c/td\u003e\n\u003ctd data-label=\"O que solicitar à empresa ou ao responsável\"\u003eLista de verificação dos sites, páginas de administração e servidores de testes\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item de verificação\"\u003eCorreção das vulnerabilidades\u003c/td\u003e\n\u003ctd data-label=\"O que solicitar à empresa ou ao responsável\"\u003eVersão aplicada ou histórico de alterações do pacote que mencione os dois CVEs\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item de verificação\"\u003eEstado de execução\u003c/td\u003e\n\u003ctd data-label=\"O que solicitar à empresa ou ao responsável\"\u003eRegistro de reinício do serviço ou de nova implantação do contêiner\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item de verificação\"\u003eAplicação efetiva\u003c/td\u003e\n\u003ctd data-label=\"O que solicitar à empresa ou ao responsável\"\u003eAmbiente de execução do PHP verificado no serviço web\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item de verificação\"\u003eVerificação de comprometimento\u003c/td\u003e\n\u003ctd data-label=\"O que solicitar à empresa ou ao responsável\"\u003ePeríodo dos logs analisados e resultados encontrados\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item de verificação\"\u003eCredenciais\u003c/td\u003e\n\u003ctd data-label=\"O que solicitar à empresa ou ao responsável\"\u003eCredenciais a trocar e confirmação da conclusão\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item de verificação\"\u003eTarefas pendentes\u003c/td\u003e\n\u003ctd data-label=\"O que solicitar à empresa ou ao responsável\"\u003eServidores com apenas medidas temporárias e plano de correção posterior\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003ePor 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.\u003c/p\u003e\n","tags":["Proteção de dados","PHP","Atualizações de segurança"],"faqs":[{"question":"É possível bloquear PHP2Shell alterando a senha de login?","answer":"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."},{"question":"No PHP 8.5, é preciso esperar pela versão 8.5.13?","answer":"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."},{"question":"Se eu uso PHP-FPM, não preciso fazer a verificação?","answer":"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."},{"question":"Se o resultado de php -v mostrar uma versão corrigida, as medidas necessárias estão concluídas?","answer":"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."},{"question":"Se o número da versão continuar igual após a aplicação do patch, isso significa que houve uma falha?","answer":"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."},{"question":"A configuração memory_limit=-1 é proibida nas medidas de resposta a esta vulnerabilidade?","answer":"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."},{"question":"Sites sem upload de arquivos também são afetados?","answer":"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."},{"question":"Posso continuar usando PHP 8.1 ou anterior se houver um patch do fornecedor?","answer":"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."},{"question":"Se não houver anomalias nos logs, posso manter as credenciais?","answer":"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."},{"question":"Há suspeita de comprometimento. Devo atualizar primeiro?","answer":"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."},{"question":"O que os usuários de serviços de hospedagem devem verificar?","answer":"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."},{"question":"Posso reativar a configuração de progresso de upload após aplicar o patch?","answer":"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":[{"url":"https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133\u0026menuNo=205020\u0026nttId=72230","title":"KISA 보호나라: diretrizes de resposta de segurança para empresas em relação à vulnerabilidade de segurança do PHP (PHP2Shell), 22 de outubro de 2026","type":"source"},{"url":"https://www.php.net/archive/2026.php","title":"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","type":"source"},{"url":"https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w","title":"Aviso de segurança do PHP: RCE por corrupção causada por OOM","type":"source"},{"url":"https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp","title":"Aviso de segurança do PHP: RCE por estado global obsoleto","type":"source"},{"url":"https://www.php.net/supported-versions.php","title":"Versões do PHP com suporte: período de suporte oficial","type":"data_point"},{"url":"https://www.php2shell.com/","title":"PHP2Shell: explicação da vulnerabilidade pelos pesquisadores e abrangência do impacto","type":"source"},{"url":"https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074\u0026mCode=C010010000\u0026nttId=12588","title":"개인정보보호위원회: solicitação de medidas para prevenir vazamentos de dados pessoais relacionados à vulnerabilidade de segurança do PHP, 22 de outubro de 2026","type":"source"}],"images":[{"id":2106,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODIsInB1ciI6ImJsb2JfaWQifX0=--756ccdbcf3c83be470043fadc3bfdf6d3eeeef02/ai-6de3df23.webp","is_representative":true,"generation_method":"ai_photo","license":"ai_generated","mime_type":"image/webp","width":1536,"height":1024,"translations":{"ko":{"alt":"서버실에서 여성이 랙 서버의 네트워크 포트 앞에 파란 랜 케이블 커넥터를 들고 있다.","caption":"침해가 의심되면 서버를 격리하고 재시작 전에 증거를 보존해야 합니다.","description":null},"en":{"alt":"A woman holds a blue Ethernet cable connector near a rack server’s network port in a server room.","caption":"If a compromise is suspected, isolate the server and preserve evidence before restarting.","description":null},"ja":{"alt":"サーバールームで、女性がラックサーバーのネットワークポートの前に青いLANケーブルのコネクターを持っている。","caption":"侵害が疑われる場合は、サーバーを隔離し、再起動前に証拠を保全する必要があります。","description":null},"es":{"alt":"Una mujer sostiene el conector de un cable Ethernet azul junto al puerto de un servidor en una sala de servidores.","caption":"Si se sospecha una intrusión, hay que aislar el servidor y preservar las pruebas antes de reiniciarlo.","description":null},"id":{"alt":"Seorang perempuan memegang konektor kabel Ethernet biru di dekat port jaringan server rak di ruang server.","caption":"Jika dicurigai terjadi penyusupan, isolasi server dan amankan bukti sebelum memulai ulang.","description":null},"pt":{"alt":"Uma mulher segura o conector de um cabo Ethernet azul perto da porta de um servidor em uma sala de servidores.","caption":"Se houver suspeita de invasão, isole o servidor e preserve as evidências antes de reiniciá-lo.","description":null},"zh-hant":{"alt":"一名女子在伺服器機房內，手持藍色網路線接頭，靠近機架式伺服器的網路埠。","caption":"若懷疑遭到入侵，應先隔離伺服器，並在重新啟動前保全證據。","description":null},"de":{"alt":"Eine Frau hält den Stecker eines blauen Netzwerkkabels vor den Netzwerkanschluss eines Rackservers.","caption":"Bei Verdacht auf einen Angriff muss der Server isoliert und müssen vor dem Neustart Beweise gesichert werden.","description":null}}},{"id":2107,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODgsInB1ciI6ImJsb2JfaWQifX0=--ab8091216d8ebf858c1dfbe779a6e6a5d3535ae7/ai-61ada64c.webp","is_representative":false,"generation_method":"ai_semi","license":"ai_generated","mime_type":"image/webp","width":1536,"height":1024,"translations":{"ko":{"alt":"공장에서 중년 기술자가 열린 네트워크 장비함 옆 태블릿의 상태 화면을 확인하는 모습","caption":"PHP 실행 서비스를 재시작한 뒤 실제 웹 서비스에 패치가 반영됐는지 확인해야 합니다.","description":null},"en":{"alt":"An older technician checks a tablet status screen beside an open network equipment cabinet in a factory.","caption":"After restarting PHP services, verify that the patch has taken effect on the live web service.","description":null},"ja":{"alt":"工場で、開いたネットワーク機器盤の横にあるタブレットの状態画面を確認する年配の技術者","caption":"PHP実行サービスの再起動後、実際のWebサービスにパッチが反映されていることを確認してください。","description":null},"es":{"alt":"Un técnico mayor revisa una tableta junto a un armario abierto con equipos de red en una fábrica.","caption":"Tras reiniciar los servicios de PHP, compruebe que el parche se haya aplicado al servicio web en producción.","description":null},"id":{"alt":"Teknisi senior memeriksa layar status tablet di samping kabinet perangkat jaringan yang terbuka di pabrik.","caption":"Setelah memulai ulang layanan PHP, pastikan patch telah diterapkan pada layanan web yang beroperasi.","description":null},"pt":{"alt":"Um técnico mais velho verifica um tablet ao lado de um armário aberto com equipamentos de rede numa fábrica.","caption":"Após reiniciar os serviços PHP, confirme que a correção foi aplicada ao serviço web em produção.","description":null},"zh-hant":{"alt":"一名年長技術人員在工廠內，查看開啟的網路設備櫃旁平板電腦上的狀態畫面","caption":"重新啟動 PHP 執行服務後，應確認實際運作的網頁服務已套用修補程式。","description":null},"de":{"alt":"Ein älterer Techniker prüft ein Tablet neben einem offenen Netzwerkschrank in einer Fabrik.","caption":"Prüfen Sie nach dem Neustart der PHP-Dienste, ob der Patch im laufenden Webdienst wirksam ist.","description":null}}}],"published_at":"2026-10-24T16:09:48+09:00","updated_at":"2026-10-24T16:09:48+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/en/articles/php2shell-enterprise-security-patch-response-guide"}