--- title: "PHP2Shell: de versões vulneráveis do PHP a um pull request revisável com o Harbyn | Harbyn" description: "Acompanhe uma varredura pública do Harbyn, dos achados do PHP2Shell até um PR de atualização real, com pins exatos, tags flutuantes e as decisões que ficam para revisão." canonical: "https://harbyn.com/br/blog/php2shell-production-runtime" last-updated: 2026-10-22 --- # PHP2Shell: de versões vulneráveis do PHP a um pull request revisável com o Harbyn Publicado em 22 de outubro de 2026 pela Harbyn. Tags: php, security, php2shell, developer-tools. Quando sai uma atualização crítica do PHP, o anúncio é só o começo. A próxima pergunta é do seu projeto: onde a versão afetada está declarada, e o que precisa mudar? O PHP2Shell trouxe um exemplo concreto. Rodamos o Harbyn num repositório público de demonstração com várias formas de declarar a versão do PHP. A varredura apontou seis achados em onze arquivos, e o Harbyn abriu um pull request atualizando dois pins de versão exata. Você pode conferir a [execução da varredura](https://github.com/harbyn/php2shell-demo/actions/runs/39718957930) e o [pull request de verdade](https://github.com/harbyn/php2shell-demo/pull/1). Veja o que aconteceu e como testar o mesmo fluxo no seu repositório. ## O que aconteceu com o PHP2Shell Em 21 de outubro de 2026, o PHP lançou correções para duas vulnerabilidades críticas, CVE-2026-109618 e CVE-2026-109619, que podem permitir execução remota de código sem autenticação. As versões corrigidas são **8.2.35, 8.3.36, 8.4.27 e 8.5.12**. Veja o [anúncio oficial de segurança do PHP](https://www.php.net/archive/2026.php#2026-10-21-5). Para um time de desenvolvimento, agir sobre esse anúncio significa achar as declarações do PHP espalhadas pelo repositório. O runtime pode estar fixado num Dockerfile, referenciado no Compose, configurado num workflow ou representado nas configurações do Composer. Essas declarações não significam a mesma coisa, então não devem receber a mesma edição. ## A demonstração: seis achados, um PR revisável O nosso [repositório de demonstração](https://github.com/harbyn/php2shell-demo) é uma pequena aplicação PHP fictícia criada para esta demonstração. Ele tem pins de versão exata, versões flutuantes, um requisito do Composer e uma imagem PHP 8.1. Usando o Harbyn, a GitHub Action varreu onze arquivos e apontou seis linhas que pedem atenção. Depois o Harbyn abriu um PR com as atualizações suportadas. Isso dá um caminho rastreável do anúncio de segurança até as declarações no repositório e as mudanças propostas. A evidência está no log da execução e no diff, e não num print ilustrativo de terminal. ## Por que os achados levaram a ações diferentes Os seis achados não eram seis correções iguais: | Declaração na demo | O que fazer | | --- | --- | | Dois pins de versão exata do PHP | Atualizar para a versão corrigida do mesmo branch do PHP. | | Duas versões flutuantes | Reconstruir ou atualizar o ambiente e conferir o runtime que está de fato em uso. | | Um requisito de PHP no Composer | Revisar os requisitos de compatibilidade separado do interpretador instalado. | | Uma imagem PHP 8.1 | Avaliar a mudança para um branch suportado, incluindo a compatibilidade da aplicação. | Uma tag flutuante como `php:8.3-fpm` pode continuar igual enquanto uma imagem antiga segue em produção. Pode não haver nenhuma versão para trocar no Dockerfile; o trabalho está em obter e publicar uma imagem corrigida. Branches mais antigos do PHP também pedem outra decisão. Levar uma aplicação do PHP 8.1 para um branch suportado pode afetar a compatibilidade. Pacotes de distribuições ou de suporte estendido podem ter recebido as correções por backport, então confira o aviso de segurança dos pacotes que você realmente usa. O [anúncio do PHP](https://www.php.net/archive/2026.php#2026-10-21-5) fala dessas opções. ## Dentro do pull request O [PR gerado](https://github.com/harbyn/php2shell-demo/pull/1) tem duas mudanças pontuais. No `Dockerfile`, ele atualiza a imagem base do PHP: ```diff -FROM php:8.3.35-fpm +FROM php:8.3.36-fpm ``` No `composer.json`, ele atualiza `config.platform.php`: ```diff - "php": "8.3.35" + "php": "8.3.36" ``` A segunda mudança merece uma explicação. A configuração de plataforma do Composer diz à resolução de dependências qual versão do PHP assumir. Ela não instala nem atualiza o PHP. Atualizá-la junto com o Dockerfile alinha essa suposição com o runtime pretendido. Veja a [documentação do Composer sobre dependências de plataforma](https://getcomposer.org/doc/articles/composer-platform-dependencies.md). O PR reúne as edições propostas para revisão. Depois de revisar, o time ainda constrói e publica a imagem atualizada, substitui as instâncias antigas e confere o runtime que está atendendo as requisições. É assim que a mudança no repositório chega à aplicação. ## Teste o Harbyn no seu repositório Na pasta do seu repositório, rode: ```sh npx harbyn scan ``` O scanner roda localmente, baixa o feed de mudanças assinado do Harbyn e confere as declarações suportadas sem enviar o seu código-fonte. Revise os arquivos, as linhas e as fontes apontados. Para configurar o fluxo de PR, siga a [documentação do Harbyn](https://harbyn.com/docs). O PHP2Shell é um exemplo do problema que o Harbyn ajuda desenvolvedores a resolver: uma mudança externa passa a importar para uma linha específica de um repositório. O Harbyn liga essa mudança ao código e, quando existe uma correção suportada, prepara a atualização para revisão. [Rode uma varredura no seu projeto](https://harbyn.com), ou veja antes o [PR público do PHP2Shell](https://github.com/harbyn/php2shell-demo/pull/1).