Em resumo: O Composer é o gestor de pacotes do PHP. Lê no ficheiro composer.json que bibliotecas um projeto precisa, carrega-as para a pasta vendor, fixa as versões exatas no composer.lock e gera um autoloader que encontra as classes automaticamente. O Composer gere assim o código da sua aplicação, não o próprio interpretador PHP: uma atualização do Composer não fecha uma falha no PHP como o PHP2Shell.
O que é o Composer e para que serve?
Hoje, quase nenhuma aplicação PHP consiste apenas em código próprio. Frameworks, bibliotecas de correio, geração de PDF ou ligações de pagamento chegam como pacotes prontos. O Composer, o gestor de pacotes do PHP, assegura que estes pacotes se juntam em versões compatíveis e que cada dependência traz as suas próprias dependências.
Para quem decide, isto significa: uma grande parte do código que corre no seu servidor provém de terceiros. É eficiente, mas exige manutenção. Para administradores e programadores, significa: quem usa o Composer corretamente consegue, a qualquer momento, rastrear que versão de que biblioteca está em produção.
A fonte predefinida de pacotes é, segundo a documentação do Composer, o Packagist.org. Outras fontes, por exemplo repositórios internos de uma agência, podem ser registadas no composer.json em repositories.
composer.json, composer.lock e vendor: os três componentes
O Composer trabalha com três coisas que convém conhecer antes de assumir um servidor ou de contratar uma agência.
| Componente | Conteúdo | Pertence ao repositório? |
|---|---|---|
composer.json |
pacotes pretendidos com intervalos de versões (require, require-dev), regras de autoload, definições |
sim |
composer.lock |
versões exatamente resolvidas de todos os pacotes, também dos indiretos | sim, segundo a documentação do Composer, expressamente |
vendor/ |
código descarregado dos pacotes e o autoloader gerado | não, é gerado na instalação |
Em require constam os pacotes de que a aplicação precisa em funcionamento. Em require-dev constam ferramentas de desenvolvimento e testes, como frameworks de teste ou análise estática. Esta separação é importante, porque as ferramentas de desenvolvimento não têm lugar num servidor de produção.
{
"require": {
"php": ">=8.3",
"monolog/monolog": "^3.0"
},
"require-dev": {
"phpunit/phpunit": "^11.0"
},
"autoload": {
"psr-4": { "App\\": "src/" }
}
}
As indicações de versão no exemplo foram escolhidas apenas a título ilustrativo. Que versões o seu projeto precisa resulta dos seus requisitos.
install ou update: a diferença na operação
Os dois comandos soam parecido, mas têm consequências muito diferentes.
composer installlê ocomposer.locke instala exatamente as versões aí registadas. É reproduzível e pertence à entrega.composer updatevolta a resolver todas as dependências, obtém as versões mais recentes compatíveis e reescreve ocomposer.lock. Pertence ao desenvolvimento, com testes a seguir.
Segundo a documentação do Composer, o update executa, depois de gravar o ficheiro lock, uma verificação de segurança adicional (audit), a menos que seja desativada com --no-audit. O install não verifica por defeito; para isso existe a opção --audit.
Autoloading: como o Composer encontra as classes
O Composer gera o ficheiro vendor/autoload.php. Uma vez incluído, o PHP só carrega cada classe quando ela é necessária. Para o código próprio, a secção autoload define que espaço de nomes está em que pasta. Recomenda-se o PSR-4, um padrão da PHP-FIG. Como isso funciona exatamente explica-o a página Espaços de nomes e autoloading; uma visão geral de todos os padrões dá-a a página Padrões PSR.
<?php
require __DIR__ . '/../vendor/autoload.php';
$log = new Monolog\Logger('app'); // é carregado automaticamente quando necessário
Composer em produção: entregar de forma limpa
Para a entrega, consolidou-se uma ordem fixa. Corre melhor numa pipeline de build e não manualmente no servidor.
- Verificar o ficheiro lock:
composer validategarante que ocomposer.jsoné válido e ocomposer.lockestá atualizado. - Instalar sem pacotes de desenvolvimento:
composer install --no-devdeixa de fora orequire-dev. - Otimizar o autoloader:
--optimize-autoloader(abreviado-o) converte as regras numa lista de classes. Com--classmap-authoritative, o PHP carrega as classes exclusivamente a partir dessa lista. - Verificação de segurança:
composer audit --lockedverifica as versões do ficheiro lock contra comunicados de segurança conhecidos e assinala pacotes abandonados. - vendor fora da raiz web: Apenas a pasta pública com o script de entrada deve ser acessível por URL.
composer validate
composer install --no-dev --optimize-autoloader
composer audit --locked --no-dev
O composer outdated mostra adicionalmente que pacotes instalados têm versões mais recentes. É a base para atualizações planeadas em vez de ações isoladas apressadas.
Composer, segurança e PHP2Shell
O Composer e o PHP2Shell dizem respeito a dois níveis diferentes. As vulnerabilidades CVE-2026-109618 e CVE-2026-109619 estão no próprio interpretador PHP. Estão corrigidas no PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, e todos os processos PHP têm de ser reiniciados depois. Nenhum composer update e nenhum pacote em vendor altera isso.
Ainda assim, o Composer faz parte de qualquer verificação depois de um incidente. Quem coloca código malicioso num servidor também pode alterar ficheiros em vendor, e o vendor/autoload.php é carregado a cada pedido. Um composer install novo, a partir do ficheiro lock verificado, numa pasta vazia é por isso um bom método para restabelecer o conjunto de pacotes. Como verificar regularmente as dependências quanto a falhas conhecidas descreve-o o guia composer audit.
Um composer audit verde nada diz sobre o nível de patches do PHP. Verifique o ambiente de execução PHP em separado, por exemplo com o nosso serviço de patches PHP.
Como ajuda concretamente a PHP SOS?
- Registamos, para cada aplicação, a versão do PHP, os pacotes do Composer e o estado do ficheiro lock, separando de forma limpa o interpretador das bibliotecas.
- Verificamos se o
vendore o ficheiro lock são coerentes entre si e se há pacotes de desenvolvimento ou ficheiros alterados em produção. - Configuramos uma entrega reproduzível com
install --no-dev, autoloader otimizado e audit. - Depois de um incidente, restabelecemos o conjunto de pacotes a partir do ficheiro lock verificado e documentamos o resultado.
Perguntas frequentes
O composer.lock tem de ir para o repositório Git?
Sim. A documentação do Composer recomenda expressamente fazer commit do composer.lock. Só assim o desenvolvimento, a CI e a produção instalam exatamente as mesmas versões dos pacotes.
Qual é a diferença entre composer install e composer update?
O install instala as versões registadas no composer.lock. O update volta a resolver as dependências, obtém versões mais recentes compatíveis e reescreve o composer.lock. No servidor de produção só o install tem lugar.
Uma atualização do Composer fecha a vulnerabilidade do PHP2Shell?
Não. O Composer gere as bibliotecas da sua aplicação, não o interpretador PHP. O PHP2Shell só se fecha com uma atualização do ambiente de execução PHP para uma versão corrigida e o reinício de todos os processos PHP.
Onde deve estar a pasta vendor?
Idealmente fora da pasta web acessível publicamente. Muitos frameworks colocam na raiz web apenas uma pasta public, enquanto a vendor fica um nível acima.