Informe uma URL sua ou que tenha autorização para testar. Confira indícios de PHP, versões e respostas de formulários para avaliar a exposição ao PHP2Shell e orientar a correção.
2
Vulnerabilidades do núcleo do PHP
9.2
Pontuação CVSS v4.0 (crítica)
4
Ramos oficiais corrigidos de 8.2 a 8.5
Visão geral das vulnerabilidades
PHP2Shell reúne duas vulnerabilidades de segurança de memória do núcleo do PHP, CVE-2026-109618 e CVE-2026-109619, ambas com CVSS v4.0 de 9.2. Elas podem permitir execução remota de código sem autenticação; o impacto depende da versão, da implantação e do caminho de ataque.
A corrupção de memória ao tratar seu esgotamento pode permitir execução remota de código sem autenticação. Atualize o PHP ou aplique as correções do fornecedor.
Ler os detalhesUm estado global obsoleto pertencente a uma requisição pode ser reutilizado por outra no mesmo processo de trabalho, causando problemas de segurança de memória e execução remota de código.
Ler os detalhesConfira o ambiente PHP web real, a versão completa do pacote e o comunicado do fornecedor; reinicie os processos envolvidos após atualizar. Mitigações temporárias não substituem patches.
Ler os detalhesInclua PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed e outros ambientes PHP que atendam requisições web. O PHP aponta mod_php como o cenário de maior risco, com exploração demonstrada antes do código da aplicação. Páginas simples e código seguro não eliminam a exposição.
Atualizar WordPress, Drupal, um framework ou plugin não significa atualizar o PHP subjacente. Confira a versão de cada site, pools FPM, imagens de contêiner, nós e o PHP integrado em painéis ou equipamentos. As versões oficiais corrigidas foram publicadas em 21 de outubro de 2026.
O que o verificador analisa
Confira indícios de PHP nas respostas públicas.
Os cabeçalhos são indícios, não provas de correção.
Interprete as diferenças de status em relação às requisições de controle.
Confira as versões completas dos pacotes e os comunicados do fornecedor.
Confirme que todos os processos web foram atualizados e reiniciados.
Comece com um GET de referência e envie um formulário URL-encoded e outro multipart para cada um dos três métodos. Analise cada resposta antes de continuar. São requisições comuns para comparar comportamentos, sem cargas de execução de código ou esgotamento de memória.
| Ordem | Método | Conteúdo da requisição | O que observar |
|---|---|---|---|
| 01 | GET | Sem corpo de requisição | Acessibilidade, redirecionamentos, versões PHP públicas e cabeçalhos de resposta. |
| 02 | POST | application/x-www-form-urlencoded | Um campo de texto comum como controle de POST. |
| 03 | POST | multipart/form-data | Um campo de texto comparado com o POST de controle, sem arquivos ou campos de progresso de upload. |
| 04 | PUT | application/x-www-form-urlencoded | Um campo de texto comum para observar como o caminho trata PUT. |
| 05 | PUT | multipart/form-data | Compare com o PUT URL-encoded para identificar diferenças por tipo de conteúdo. |
| 06 | PATCH | application/x-www-form-urlencoded | Um campo de texto comum como controle de PATCH. |
| 07 | PATCH | multipart/form-data | Compare com o PATCH de controle, sem deduzir o comportamento de todos os métodos apenas pelo POST. |
Identificadores PHP em X-Powered-By ou Server e cookies como PHPSESSID são apenas indícios do ambiente. Podem estar ocultos, alterados ou personalizados. Um cookie também não prova que o PHP analisou o corpo da requisição.
As verificações abrangem apenas a URL e o caminho informados. Outras rotas, regras de CDN e origens acessíveis diretamente podem se comportar de modo diferente. Não generalize o resultado da página inicial para todo o site. Use apenas caminhos autorizados adequados para formulários.
Como interpretar os resultados
As respostas públicas fornecem apenas parte das evidências. As versões podem estar ocultas ou alteradas e versões antigas podem ter patches retroportados. Confira o ambiente real e não confunda falta de evidência com segurança.
Veja erros comuns de avaliaçãoUma versão pública igual ou superior ao limite de sua ramificação é um indício útil, mas proxies podem alterá-la. Confirme no servidor que todas as instâncias carregaram o código corrigido.
Priorize versões abaixo do limite oficial e verifique os backports da distribuição ou do fornecedor LTS. Se o status for desconhecido, registre a necessidade de confirmação, sem afirmar execução remota de código comprovada.
Um controle bem-sucedido e um multipart com 4xx podem indicar restrições de tipo de conteúdo. Dois retornos 405 podem apenas indicar um método não aceito. O status sozinho não distingue rejeição por CDN, servidor web ou aplicação.
Versões ocultas, caches de proxy, cookies personalizados, falhas de conexão e tempos esgotados limitam a análise. Registre evidências insuficientes ou avaliação indisponível, em vez de um resultado verde de segurança.
Processo de verificação
Informe o endereço de um site seu ou autorizado, incluindo o caminho que deseja verificar.
Veja o GET de referência e compare as respostas URL-encoded e multipart de POST, PUT e PATCH, uma requisição por vez.
Interprete os códigos de status e as versões, depois confirme os patches no ambiente PHP real e nos comunicados do fornecedor.
Verificação no servidor
Verificações externas revelam indícios, mas os patches devem ser confirmados no servidor, nos contêineres ou no painel de hospedagem. Registre o ambiente, a origem do pacote, a versão corrigida e o estado dos processos após atualizar.
Confira o PHP atribuído ao site, o módulo web ou o pool FPM. Faça um inventário das versões coexistentes, sites, contêineres e nós balanceados. php -v mostra apenas a versão CLI atual, não necessariamente a web. Não exponha uma página phpinfo pública para esta verificação.
php -vConsulte o pacote instalado e compare sua versão completa com o comunicado da distribuição. O pacote 8.3.6-0ubuntu0.24.04.13 do Ubuntu 24.04 já inclui a correção; apenas PHP 8.3.6 omite esse backport. Escolha o exemplo adequado e ajuste o nome do pacote.
dpkg-query -W php8.3-fpm
rpm -q php-fpmUse uma versão oficial corrigida, uma versão de segurança posterior do mesmo ramo ou um backport confirmado. Atualize o PHP de painéis, equipamentos e contêineres conforme o fornecedor. PHP 8.1 e anteriores estão fora do suporte regular: confirme correções LTS ou migre. O PHP também forneceu backports mínimos de código-fonte para 7.4, 8.0 e 8.1.
Confirme o reinício de PHP-FPM, Apache ou outros processos e substitua contêineres e nós quando necessário. Arquivos atualizados em disco não garantem a troca dos processos antigos. Requisições incomuns, falta de memória e falhas de processos ajudam na investigação, mas a ausência desses registros não prova ausência de impacto.
O script envia um GET e formulários URL-encoded e multipart com POST, PUT e PATCH, um por vez. Usa apenas campos de texto, sem arquivos nem campos de progresso de upload. Execute somente em caminhos autorizados adequados para testes; requisições comuns ainda podem acionar operações da aplicação.
#!/usr/bin/env bash
# PHP2Shell HTTP observations: 7 sequential requests, no exploit payload.
set -u
URL="${1:-https://example.com/}"
case "$URL" in
http://*|https://*) ;;
*) printf 'ERROR=HTTP(S)_URL_REQUIRED\n' >&2; exit 2 ;;
esac
if ! command -v curl >/dev/null 2>&1 || ! command -v awk >/dev/null 2>&1; then
printf 'ERROR=CURL_AND_AWK_REQUIRED\n' >&2
exit 127
fi
probe() {
printf '\n[%s/7] %s %s\n' "$1" "$2" "$3"
local method="$2"
shift 3
curl -q --globoff --proto '=http,https' --silent --show-error \
--connect-timeout 5 --max-time 15 --request "$method" \
--dump-header - --output /dev/null \
--write-out '\nHTTP_CODE=%{http_code} TOTAL_SECONDS=%{time_total}\n' \
"$@" --url "$URL" |
awk '{
sub(/\r$/, "")
line = tolower($0)
if ($0 ~ /^HTTP\// || line ~ /^(server|x-powered-by|content-type):/ || $0 ~ /^HTTP_CODE=/) {
print
} else if (line ~ /^set-cookie:[ \t]*phpsessid[ \t]*=/) {
print "PHPSESSID=present; value hidden"
}
}'
local curl_status="${PIPESTATUS[0]}"
if [ "$curl_status" -ne 0 ]; then
printf 'CURL_EXIT=%s\n' "$curl_status"
FAILED=1
fi
}
FAILED=0
probe 1 GET baseline
probe 2 POST urlencoded --data-raw 'php2shell_check=1'
probe 3 POST multipart --form-string 'php2shell_check=1'
probe 4 PUT urlencoded --data-raw 'php2shell_check=1'
probe 5 PUT multipart --form-string 'php2shell_check=1'
probe 6 PATCH urlencoded --data-raw 'php2shell_check=1'
probe 7 PATCH multipart --form-string 'php2shell_check=1'
exit "$FAILED"Use Bash no Linux/macOS, ou WSL ou Git Bash no Windows. Salve como php2shell-self-check.sh e execute o comando abaixo com uma URL de teste autorizada. Não cole o script Bash diretamente no PowerShell.
bash php2shell-self-check.sh https://example.com/test.phpA conexão tem limite de 5 segundos e cada solicitação de 15 segundos. O script ignora a configuração pessoal do curl, verifica TLS e não segue redirecionamentos nem repete solicitações. Ao receber 3xx, confirme a autorização da URL final antes de executar nela. PHPSESSID aparece apenas como indicador, sem valores de cookies nem corpos de resposta.
HTTP_CODE indica o status da resposta e TOTAL_SECONDS o tempo total. CURL_EXIT diferente de zero indica falha de transferência; as outras verificações continuam. Uma saída não zero indica problema de entrada, dependências ou transferência. Respostas HTTP 4xx/5xx são registradas normalmente; o código de saída não avalia vulnerabilidades nem patches.
Server ou X-Powered-By podem estar ocultos ou desatualizados. Verifique o PHP que realmente atende o site: as versões oficiais mínimas corrigidas dos respectivos ramos são 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Confirme os backports do fornecedor pela versão completa do pacote e pelo comunicado de segurança.
Se, no mesmo método, urlencoded retorna 2xx ou 3xx e multipart retorna 403 ou 406, isso indica apenas respostas diferentes. Não confirma bloqueio pelo WAF nem rejeição antes de a requisição chegar ao PHP.
Uma resposta multipart 2xx ou 3xx significa apenas que houve uma resposta de sucesso ou redirecionamento. Não comprova que o corpo chegou ao PHP e foi analisado, nem determina se a vulnerabilidade existe.
Todas as respostas serem 405 não comprova correção. A ausência de indicadores PHP não prova que o PHP não seja usado. Um cookie PHPSESSID também não confirma a análise de multipart nem a camada que gerou a resposta.
O PHP afirma que só a atualização corrige o problema completamente. As configurações abaixo reduzem a exposição a caminhos conhecidos, mas não tornam seguro um ambiente sem patches. Avalie os requisitos da aplicação e as orientações oficiais antes de alterar.
Versões oficiais corrigidas
Compare dentro de cada ramo: o limite do 8.3 não determina o status do 8.4. Não considere versões preliminares ou ramos desconhecidos corrigidos automaticamente. Confira backports e compilações próprias com a versão completa do pacote, registros de compilação e comunicados do fornecedor.
Segundo o comunicado do BaoTa de 2026-10-21, algumas versões de segurança do PHP já estão disponíveis no painel. Confira na loja de software do seu painel quais versões são oferecidas.
Ler o comunicado de atualização do BaoTaAntes de atualizar, faça backup do site, dos bancos de dados e das configurações relevantes e escolha um período adequado de manutenção.
Entre no BaoTa Panel, acesse Loja de software → Instalados, localize a versão do PHP usada pelo site e abra a página de gerenciamento.
Verifique as atualizações na página de gerenciamento do PHP e siga as instruções para instalar a versão corrigida do mesmo ramo listada acima ou uma versão de segurança posterior desse ramo.
Após atualizar, reinicie o serviço PHP correspondente e confirme que todos os processos foram recarregados. Confira a versão usada pelo site e teste acesso, uploads, conexões com bancos de dados e outras funções.
Se houver várias versões do PHP instaladas, confira todas as que ainda estão em uso. Ao instalar outra versão, confirme também que o site passou a usar o ambiente PHP corrigido.
Perguntas frequentes
Entenda a diferença entre indícios de versão, códigos de status e backports para evitar conclusões excessivas.
PHP2Shell designa duas vulnerabilidades do núcleo do PHP, CVE-2026-109618 e CVE-2026-109619, que podem permitir execução remota de código sem autenticação. Analise todos os ambientes PHP sem correção que atendam requisições web, mesmo com código de aplicação seguro.
Não. Autenticação, métodos não aceitos, limites de tamanho ou proxies podem gerar esses códigos. Rejeitar multipart só descreve o caminho atual; não comprova que o PHP foi corrigido nem que todas as vias de ataque foram bloqueadas.
Não necessariamente. A versão pode estar oculta, e uma CDN, proxy reverso ou página inicial estática pode esconder o backend. A ausência de indícios significa informação insuficiente: confira o ambiente real do servidor.
As correções oficiais estão no PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Use uma versão corrigida ou posterior de segurança no ramo adequado. Versões antigas podem conter backports: confira a versão completa do pacote e o comunicado do fornecedor. PHP 8.1 e anteriores não têm suporte regular. Reinicie os processos após atualizar.
Os métodos podem seguir rotas e filtros diferentes. Desde o PHP 8.4, aplicações podem usar request_parse_body() para analisar multipart em métodos diferentes de POST. Isso não significa que todas analisem PUT ou PATCH automaticamente. O comportamento do POST não comprova proteção dos demais métodos ou caminhos.
Registre o ambiente PHP e os patches como não confirmados. POST 200 só indica resposta; 405, rejeição do método em alguma camada. Páginas estáticas, outros ambientes e PHP com sinais ocultos podem gerar esse padrão. Confira o ambiente no servidor, sem declarar segurança ou vulnerabilidade comprovada.
As referências de vulnerabilidades e correções foram verificadas em 2026-10-22. Observações externas têm limites; siga os comunicados atuais do PHP e do fornecedor para tomar decisões.
Analise as respostas públicas uma a uma, interprete as evidências e confira os patches no ambiente real do servidor.