PHP2Shell: corrigir a aplicação não substitui o patch do runtime
Separe a exposição do PHP dos problemas da aplicação, confirme a substituição dos workers e revise evidências de correção com a Plexicus.
Além de ASPM
AppSec orientada por provas para equipes que desenvolvem com IA
A Plexicus usa AI Swarm Pentest para explorar caminhos autorizados da aplicação, validar o que é explorável e dar às equipes evidências para priorizar a remediação.
Explorar AI Swarm PentestUm pull request pode corrigir um erro da aplicação e deixar uma vulnerabilidade do runtime aberta. São alterações com responsáveis, artefatos e evidências diferentes. Os avisos de outubro do PHP mostram essa distinção.
As versões de 21 de outubro 8.2.35, 8.3.36, 8.4.27 e 8.5.12 corrigem CVE-2026-109618 e CVE-2026-109619. Anúncio do PHP.
O aviso de falta de memória descreve um caminho do Apache mod_php anterior ao código da aplicação. Alterar middleware não protege um caminho executado antes dele. Aviso OOM.
O segundo descreve estado de uma requisição que permanece em um worker persistente e pode afetar uma requisição posterior. Aviso de estado global.
São resultados do projeto, não vulnerabilidades reproduzidas independentemente pela Plexicus. Propomos um fluxo de evidências sem afirmar que sua implantação esteja afetada.
Separe os critérios de encerramento
Imagine que a equipe de pagamentos adicione validação ao upload. O código é revisado, os testes passam e a mudança entra em produção. Isso demonstra algo sobre o manipulador, mas não identifica o pacote PHP que atende requisições nem comprova que workers antigos foram substituídos.
Abra tarefas separadas quando necessário. A tarefa da aplicação deve indicar comportamento e teste de regressão. A do runtime deve indicar aviso, pacote, serviço e evidências de implantação. Relacione ambas para que uma tarefa de código concluída não encerre uma atualização pendente.
Identifique o ambiente que atende requisições
Comece pelo serviço web. Registre modelo de integração PHP, fornecedor, arquitetura, fontes de configuração e responsável. A CLI pode ajudar no inventário, mas o serviço pode usar outro binário ou outra configuração.
| Pergunta | Evidência |
|---|---|
| Quem recebe as requisições? | Configuração do serviço e identidade do processo |
| Qual pacote contém a correção? | Aviso do fornecedor e identificador do pacote |
| O que foi implantado? | Alteração revisada, compilação ou digest imutável |
| Os workers foram substituídos? | Conclusão do rollout ou reinício e instâncias ativas |
| O que continua desconhecido? | Lacuna explícita e responsável |
Em uma distribuição mantida por fornecedor, confirme o status do patch com ele. Comparar somente a versão upstream não basta. Não publique uma página de diagnóstico expondo o ambiente para obter essas evidências.
Delimite as medidas temporárias
O aviso de 23 de outubro recomenda desativar o progresso de upload de sessão até a próxima versão regular de correções para um problema específico de configuração. Aviso informativo.
Consulte instruções atuais antes de aplicar ou remover ajustes temporários. Registre valor, escopo, responsável e condição de remoção. Mitigar um caminho não demonstra que todos os avisos foram resolvidos. Este artigo não declara que as versões de outubro corrigem vulnerabilidades posteriores.
Verifique o serviço após a alteração
Instalar o pacote é um resultado intermediário. Confirme o pacote efetivamente usado e conclua a substituição de workers necessária. Inclua instâncias secundárias, manutenção e imagens de rollback. Uma reversão pode reintroduzir o pacote antigo.
Execute regressões autorizadas com dados comuns de teste: pagamento, autenticação, uploads e sessões quando relevantes. O sucesso comprova esses fluxos, não refuta de forma independente um exploit de corrupção de memória. Preserve essa distinção no encerramento.
Como a Plexicus participa
A Plexicus Deep Code Analysis apresenta contexto do fluxo de código e do impacto. Remediation apresenta mudanças sugeridas com contexto para revisão da equipe. Essas capacidades podem organizar problemas da aplicação durante uma resposta do runtime. Não garantem atualização automática da infraestrutura PHP nem descoberta de todos os workers.
Avalie evidências operacionais junto aos resultados de código. Separe proposto, integrado, implantado e verificado. A passagem de trabalho deve explicar o que cada ação corrigiu, o que a evidência demonstra e quem ainda tem tarefas.
Quer conectar um problema a uma mudança revisada? Conheça Plexicus Remediation ou solicite Deep Code Analysis. Comece com um fluxo e seu limite com o runtime para definir critérios de aceitação claros.
