Em resumo: o composer audit compara os pacotes do seu projeto PHP com avisos de segurança conhecidos e mostra as versões afetadas. Execute o comando em cada build e, de forma regular, no estado de produção. Importante após o PHP2Shell: a verificação abrange bibliotecas, não o próprio interpretador PHP.
Porque é que as dependências precisam de atenção precisamente agora
As aplicações PHP modernas são constituídas, na sua maior parte, por código alheio. Uma loja baseada em Symfony ou um portal com Laravel traz rapidamente várias dezenas a centenas de pacotes, muitos deles de forma indireta através de outros pacotes. Cada uma destas bibliotecas pode conter uma vulnerabilidade. O OWASP Top 10 inclui por isso os componentes desatualizados e vulneráveis como categoria de risco própria.
Em outubro de 2026, o PHP2Shell mostrou com que rapidez uma vulnerabilidade crítica se espalha. As duas vulnerabilidades CVE-2026-109618 e CVE-2026-109619 afetam, é certo, o próprio PHP e não pacotes do Composer. Mas muitas equipas verificaram nesses dias toda a sua cadeia e constataram que nem sequer conheciam com exatidão o estado das suas dependências.
Esta lacuna na visão de conjunto pode ser fechada com pouco esforço. O Composer já traz a ferramenta adequada nas versões atuais.
O que o composer audit verifica e o que não verifica
O comando lê os pacotes instalados ou o ficheiro de bloqueio e consulta avisos de segurança conhecidos sobre esses pacotes. Para cada resultado, mostra o pacote, o intervalo de versões afetado, a gravidade, o identificador do aviso e uma ligação para a descrição.
| Nível | Verificado pelo composer audit? | Como verificar em alternativa |
|---|---|---|
| Pacotes Composer no projeto | sim | composer audit |
| Interpretador PHP (p. ex. PHP2Shell) | não | estado dos pacotes, confirmação do fornecedor de alojamento |
| Extensões PHP do sistema | não | gestão de pacotes da distribuição |
| Pacotes JavaScript no frontend | não | ferramenta do respetivo gestor de pacotes |
| Código próprio da aplicação | não | revisão de código, auditoria de segurança |
O comando tem também em conta as dependências indiretas, ou seja, pacotes que nunca pediu, mas que vêm com outros pacotes. É precisamente aí que as vulnerabilidades ficam muitas vezes despercebidas, porque ninguém da equipa conhece esses pacotes. As versões mais recentes do Composer assinalam ainda pacotes que os seus autores marcaram como abandonados. Esses pacotes, em regra, já não recebem correções e devem ser substituídos.
Um resultado limpo significa, portanto, apenas que, para as versões de pacotes instaladas, não existe aviso conhecido. A ferramenta não encontra vulnerabilidades desconhecidas nem erros no código próprio. Como verificar por si o estado do PHP, descreve-o o artigo Verificar corretamente a versão do PHP e o nível de patch.
Executar o composer audit e ler os resultados
No diretório do projeto basta um comando. As variantes diferem no que é verificado e na forma como o resultado é apresentado.
# Verificar os pacotes instalados
composer audit
# Verificar apenas o ficheiro de bloqueio, p. ex. no build sem pacotes instalados
composer audit --locked
# Omitir dependências de desenvolvimento (estado como no servidor)
composer audit --no-dev
# Saída legível por máquina para análise ou sistema de tickets
composer audit --format=json > audit-$(date +%F).json
Se o comando encontrar vulnerabilidades, termina com um código de erro. É intencional, pois assim um build automatizado é interrompido. Avalie cada resultado: o pacote está em uso no servidor, a função afetada é utilizada, existe uma versão corrigida?
# Que dependências diretas estão desatualizadas?
composer outdated --direct
# Porque está instalado um determinado pacote?
composer why vendor/paket
# Atualizar de forma orientada, com dependências
composer update vendor/paket --with-dependencies
Teste cada atualização num ambiente de staging. As atualizações de segurança dentro da mesma versão principal costumam ser pouco críticas; uma nova versão principal pode, em contrapartida, exigir ajustes no código.
Automatizar a verificação
Uma chamada única ajuda pouco, porque novas vulnerabilidades se tornam conhecidas continuamente. Integre por isso o composer audit em dois pontos: no pipeline de build, em cada alteração, e numa verificação regular do estado de produção, mesmo que o código não mude.
Um script simples para uma execução diária no servidor de build ou de verificação pode ser assim:
#!/bin/sh
# Auditoria diária do estado entregue (adapte o caminho)
cd /srv/build/meine-anwendung || exit 1
if ! composer audit --locked --no-dev --format=plain > /var/log/composer-audit.log 2>&1; then
logger -t composer-audit "Lücken in meine-anwendung gefunden, siehe /var/log/composer-audit.log"
fi
Encaminhe a mensagem do registo do sistema para a sua monitorização, a sua caixa de correio interna ou o seu sistema de tickets. O importante é que alguém seja responsável por avaliar as mensagens. Uma auditoria cujos avisos ninguém lê não protege.
Defina no composer.json, em config.platform.php, a versão do PHP que corre no servidor. Assim, o Composer só resolve pacotes compatíveis com esse estado, e o composer check-platform-reqs mostra os desvios.
Entregar de forma limpa: deployment sem efeitos secundários
O caminho até ao servidor também influencia a segurança. Algumas regras básicas têm-se revelado eficazes:
- Incluir o
composer.lockno repositório e executar no servidor apenascomposer install, nuncacomposer update. - Instalar com
--no-dev, para que ferramentas de teste e de depuração não acabem no servidor de produção. - Manter a pasta
vendor/fora da raiz web, para que não seja acessível diretamente por um URL. - Executar
composer validateno build, para detetar cedo indicações erradas ou contraditórias.
composer validate --strict
composer install --no-dev --prefer-dist --classmap-authoritative --no-interaction
Tenha também atenção ao suporte da própria versão do PHP. As bibliotecas exigem cada vez mais ramos atuais do PHP. Quem ainda está preso ao PHP 8.1 ou anterior já não recebe atualizações oficiais para o próprio PHP e muitas vezes já não consegue instalar versões de pacotes mais recentes com correções de segurança. O planeamento para isso é descrito no guia Fim de vida do PHP: riscos de versões desatualizadas. Indicações específicas de frameworks encontra-as em Proteger aplicações Laravel.
Como ajuda concretamente a PHP SOS?
- Registamos o estado de todas as dependências e avaliamos os resultados segundo a utilização real.
- Configuramos verificações automatizadas no build e em operação, com responsabilidade clara pelos resultados.
- Planeamos e testamos atualizações, mesmo quando novas versões principais exigem ajustes.
- Se desejar, verificamos também o código e a configuração próprios, onde nenhuma ferramenta automática chega.
Uma verificação por terceiros é descrita no serviço Auditoria de segurança e teste de intrusão.
Perguntas frequentes
O composer audit também encontra o PHP2Shell?
Não. O composer audit verifica os pacotes do seu projeto, não o interpretador PHP no servidor. O PHP2Shell está no próprio PHP e só se resolve com uma atualização do PHP e o reinício de todos os processos PHP.
O composer.lock tem de estar no repositório?
Em aplicações, sim. O ficheiro de bloqueio regista exatamente que versões estão instaladas. Só assim o composer audit verifica o estado que realmente corre no servidor, e cada deployment instala as mesmas versões.
O que fazer se não existir atualização para um pacote afetado?
Verifique se o seu projeto chega sequer a usar a função afetada e documente a avaliação. Se não houver correção, podem ser opções um pacote de substituição, um patch próprio ou uma proteção transitória ao nível do servidor.
Com que frequência devo executar o composer audit?
Em cada build e, adicionalmente, de forma regular, por exemplo diariamente, mesmo sem alterações ao código. Novas vulnerabilidades são comunicadas continuamente, e um estado que ontem estava limpo pode hoje estar afetado.