# Vulnerabilidade Shopware 6 PHP2Shell: como proteger a sua loja

> Shopware 6 e PHP2Shell: porque uma atualização da loja não basta, onde se esconde código malicioso (.env, custom/plugins, public) e como verificar integrações.

Fonte: https://phpsos.de/pt/plattformen/shopware-6/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Em resumo:** a vulnerabilidade do Shopware 6 que muitos comerciantes procuram neste momento é, na verdade, uma vulnerabilidade do PHP. As atualizações do Shopware não a corrigem. Precisa de um PHP com patch e do reinício de todos os processos e, depois, deve verificar `.env`, `custom/plugins`, a pasta `public` e as integrações de API.

## O que o PHP2Shell significa para o Shopware 6

O Shopware 6 assenta na framework PHP Symfony e corre geralmente com PHP-FPM por trás do Nginx ou do Apache. As vulnerabilidades CVE-2026-109618 e CVE-2026-109619 afetam precisamente este modo de operação. Segundo a equipa do PHP, permitem executar código malicioso remotamente, sem autenticação na loja.

Um atacante com execução de código no servidor alcança tudo a que a própria loja acede: dados de clientes, encomendas, documentos de faturação, credenciais da gestão de mercadorias e de prestadores de pagamento. Explicamos o contexto técnico em [O que é o PHP2Shell?](https://phpsos.de/pt/php2shell/was-ist-php2shell/).

## Verificar a vulnerabilidade do Shopware 6: que PHP está realmente a correr?

O Shopware 6 é muito mantido pela linha de comandos, por exemplo com `bin/console`. Daí resulta um erro fácil: `php -v` mostra a versão do PHP da linha de comandos, não necessariamente a do PHP-FPM, que processa os pedidos da loja. Em muitos servidores estão instaladas várias versões do PHP em paralelo.

Fiáveis são a indicação no painel de alojamento para o domínio concreto e a confirmação do fornecedor sobre o estado do pacote. As versões upstream corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35; os backports podem ter números mais antigos. Quais as versões do PHP que a sua versão do Shopware suporta, verifique-o nos requisitos de sistema da documentação em shopware.com. Como verificar por si próprio, está em [Verificar corretamente a versão e o estado do patch do PHP](https://phpsos.de/pt/php2shell/php-version-pruefen/).

Um ponto é muitas vezes ignorado no Shopware 6: muitas lojas processam a fila de mensagens e as tarefas agendadas através de processos em segundo plano permanentes, por exemplo `bin/console messenger:consume` sob um gestor de processos. Estes processos carregam o PHP uma só vez, no arranque. Após a atualização, é por isso necessário reiniciar não só o PHP-FPM, mas também estes workers. Caso contrário, parte da loja continua a trabalhar com o PHP antigo e vulnerável em memória.

## Pastas e ficheiros que deve conhecer

| Local | Conteúdo | Porque é relevante |
|---|---|---|
| `.env`, `.env.local` | Acesso à base de dados, `APP_SECRET`, outras chaves | Renovar em caso de suspeita |
| `public/` | Raiz de documentos com `index.php`, multimédia, ficheiros do tema | Ficheiros PHP adicionais são suspeitos |
| `public/theme/` | Ficheiros JavaScript e CSS compilados da storefront | Local para skimmers introduzidos |
| `custom/plugins/`, `custom/apps/` | Extensões | Código de plugin alterado |
| `files/` | Ficheiros privados, como faturas e guias de remessa | Dados pessoais |
| `var/log/` | Registos da loja | Guardar os vestígios |

Primeiras verificações inofensivas:

```bash
# Mostrar os plugins instalados com versão e estado
bin/console plugin:list
# Listar os ficheiros PHP na pasta pública
find public -type f -name "*.php"
# Mostrar vulnerabilidades conhecidas nas dependências do Composer
composer audit
```

Na pasta `public/` devem existir apenas poucos ficheiros PHP conhecidos. Tudo o que for desconhecido deve ser guardado e analisado, não apagado de imediato.

> **Dica:**
> Na administração, em Definições > Sistema, verifique as áreas «Utilizadores e permissões» e «Integrações». Utilizadores desconhecidos ou integrações de API desconhecidas são uma backdoor que qualquer análise de ficheiros deixa passar.

## Acesso de administração, plugins e apps como risco

A administração fica por predefinição em `/admin`. Proteja-a com contas pessoais, autenticação forte e, se possível, com uma restrição de acesso a redes conhecidas. As integrações para gestão de mercadorias, marketplaces ou prestadores de expedição devem ter apenas os direitos de que realmente precisam.

Os plugins da loja de extensões e os desenvolvimentos próprios trazem código PHP próprio; as apps trazem ainda webhooks para servidores externos. Quantas mais extensões, maior a superfície de ataque e mais trabalhosa cada atualização do PHP. Remova por completo os plugins que já não são usados.

## O que uma atualização do Shopware consegue e o que não consegue

Uma atualização do Shopware ou de um plugin corrige falhas conhecidas nesse código. Não consegue:

- aplicar o patch ao PHP no servidor,
- reiniciar processos PHP-FPM antigos,
- remover de forma segura ficheiros alheios em `public/` ou ficheiros de tema manipulados,
- eliminar utilizadores ou integrações alheios,
- provar que nada aconteceu antes do patch.

Após uma atualização do PHP para uma nova versão principal, deve regenerar a cache e o tema e testar a loja num ambiente de teste. A mudança do PHP com comprovativo é assegurada, a pedido, pelo nosso [serviço de patch PHP](https://phpsos.de/pt/leistungen/php-patch-service/).

O Shopware 6 corre, em retalhistas maiores, muitas vezes em vários servidores de aplicação. Nesse caso, todos os servidores têm de ter o patch aplicado e estar reiniciados, também os que só executam tarefas em segundo plano. Se um prestador de serviços operar a loja como plataforma gerida, deve confirmar-lhe o estado de todos os nós.

## Como ajuda concretamente a PHP SOS?

- Apuramos que PHP a sua loja usa realmente via FPM e esclarecemos o patch e o reinício com o fornecedor de alojamento ou a agência.
- Guardamos registos a partir de 20/10/2026, a base de dados e os ficheiros.
- Verificamos `public/`, ficheiros de tema compilados, plugins, utilizadores e integrações quanto a anomalias.
- Em caso de descoberta, limpamos a loja em conjunto com a sua agência e renovamos chaves e acessos de forma ordenada.


## Perguntas frequentes

**O próprio Shopware 6 é afetado pelo PHP2Shell?**  
As vulnerabilidades estão no PHP, não no código do Shopware. Qualquer loja Shopware 6 num PHP sem patch é, por isso, potencialmente vulnerável, independentemente da versão do Shopware. Uma atualização do Shopware não altera isso.

**Que ficheiro do Shopware 6 é particularmente crítico após um ataque?**  
O ficheiro .env ou .env.local, com o acesso à base de dados e o APP_SECRET. Quem o conseguiu ler conhece as suas credenciais. Perante uma suspeita, estes valores devem ser renovados, em articulação com a sua agência.

**O que são integrações no Shopware 6 e porque verificá-las?**  
As integrações são acessos de API para sistemas externos, como a gestão de mercadorias ou marketplaces. Uma integração alheia com direitos de administrador permite acesso total à loja através da API, sem que exista qualquer ficheiro no servidor.

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [Shopware](https://www.shopware.com/)
- [Versões do PHP suportadas](https://www.php.net/supported-versions.php)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)