Em resumo: na segurança do OXID eShop, após o PHP2Shell, trata-se primeiro do servidor: a vulnerabilidade está no PHP, não no OXID. Faça confirmar o estado do PHP e reiniciar todos os processos. Depois, verifique config.inc.php, módulos, ficheiros do tema, contas de admin e os acessos ao ERP e aos serviços de pagamento.
Porque devem as lojas OXID olhar com atenção
O OXID eShop é difundido no espaço de língua alemã sobretudo no comércio B2B, em fabricantes com venda direta e no comércio grossista. Estas lojas raramente são soluções isoladas: trocam encomendas, preços, stocks e dados de clientes com ERP, PIM e serviços de pagamento. Um atacante no servidor da loja vê, por isso, muitas vezes mais do que apenas a loja.
Segundo a equipa do PHP, as vulnerabilidades PHP CVE-2026-109618 e CVE-2026-109619 permitem executar código malicioso remotamente sem autenticação. Para isso, é irrelevante se o próprio OXID está atualizado. Os dados típicos nas lojas OXID são:
- Clientes empresariais com interlocutores, moradas, números de cliente e preços individuais
- Histórico de encomendas e pedidos de proposta
- Credenciais de acesso ao ERP e a serviços de pagamento e de expedição, na configuração e nas definições dos módulos
- Contas de colaboradores na área de administração
Segurança do OXID eShop: verificar corretamente o estado do PHP
Na área de administração, Serviço > Informação do sistema mostra os dados do PHP da loja em funcionamento. Essa é a versão web com que os clientes são atendidos. A consola do OXID, as importações e as tarefas cron correm, em contrapartida, muitas vezes com um PHP de linha de comandos, que pode ser de outra versão. Ambos têm de ter o patch aplicado.
As versões upstream corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35. As distribuições e os fornecedores de alojamento entregam por vezes as correções como backport, e o número mantém-se; o decisivo é o estado do pacote confirmado. Quais as versões do PHP que a sua versão do OXID suporta, verifique-o nos requisitos de sistema da documentação do fabricante em oxid-esales.com.
As lojas OXID mais antigas da geração 4 ou as primeiras versões da geração 6 correm muitas vezes ainda em versões antigas do PHP sem atualizações oficiais. Nesse caso, são necessárias proteção provisória e um calendário firme até à atualização.
Pastas e ficheiros no OXID
Desde o OXID 6, a loja é instalada via Composer; a raiz de documentos é, em regra, o diretório source/.
| Local | Conteúdo | Ponto de verificação |
|---|---|---|
source/config.inc.php |
Acesso à base de dados, definições básicas | Código inserido, alterar a palavra-passe em caso de suspeita |
source/modules/ (até ao OXID 6), a partir do OXID 7 vendor/ |
Módulos, em parte de pacotes Composer | Módulos desconhecidos, ficheiros alterados |
var/configuration/ |
Configuração de módulos e da loja como ficheiros | Alterações inesperadas |
source/out/ |
Temas, imagens, JavaScript | Scripts alheios, ficheiros PHP em pastas de imagens |
source/tmp/ |
Templates compilados e cache | Esvaziar após a limpeza |
source/log/ |
Registo da loja | Guardar antes de alterações |
Os templates compilados no diretório tmp passam muitas vezes despercebidos. Consistem em código PHP e são regenerados após uma limpeza; por isso, a pasta deve ser esvaziada após cada descoberta.
Primeiras verificações inofensivas:
# Ficheiros PHP em pastas de imagens e multimédia
find source/out -type f -name "*.php"
# Ficheiros de módulos alterados desde 17/10/2026 (OXID 6; a partir do OXID 7 os módulos ficam em vendor/)
find source/modules -type f -newermt "2026-10-17"
# Vulnerabilidades conhecidas nas dependências
composer audit
Um servidor de loja limpo não volta a tornar secretos os acessos de interface que já saíram. Perante uma suspeita, renove as credenciais de acesso ao ERP e aos serviços de pagamento e de expedição, em articulação com os respetivos operadores.
Área de administração e módulos
A área de administração fica, por predefinição, em /admin/. Verifique a gestão de utilizadores quanto a contas com direitos de admin que ninguém consegue atribuir e a acessos de antigos prestadores de serviços. Se possível, restrinja o acesso de admin à rede da empresa ou a uma VPN; em ambiente B2B, isso é normalmente bem exequível.
Os módulos para métodos de pagamento, ligação ao ERP e funções B2B, como preços por escalões ou processos de aprovação, são muitas vezes adaptados individualmente nas lojas OXID. Cada módulo é código PHP próprio, e os módulos adaptados travam frequentemente as atualizações do PHP. Registe que módulos estão ativos, quem os mantém e se existe uma versão para a versão do PHP pretendida.
O que uma atualização do OXID consegue e o que não consegue
Uma atualização do OXID ou de um módulo corrige falhas conhecidas nesse código e pode permitir versões mais recentes do PHP. Não aplica patch ao PHP e não reinicia nem o PHP-FPM nem os processos em segundo plano. Ficheiros alheios em source/out, módulos manipulados, templates compilados e novas contas de admin permanecem. Se há indícios de um ataque, verifique-o com Já fui comprometido?. Sobre a situação nas empresas médias, vale a pena Segurança informática para empresas médias e indústria.
Muitas lojas OXID têm, além do sistema em produção, um ambiente de staging no mesmo servidor ou num segundo. Verifique e aplique o patch também a este, pois contém muitas vezes uma cópia dos dados de clientes e é igualmente útil para os atacantes.
Como ajuda concretamente a PHP SOS?
- Apuramos o PHP web e o PHP CLI do seu servidor OXID e fazemos confirmar o patch e o reinício.
- Guardamos registos a partir de 20/10/2026, ficheiros e base de dados.
- Verificamos
config.inc.php, módulos, temas, templates compilados e contas de admin. - Perante uma suspeita, coordenamos, através da nossa resposta a incidentes, a limpeza e a renovação dos acessos das interfaces com a sua agência e os seus prestadores de ERP.
Perguntas frequentes
O OXID eShop é afetado pelo PHP2Shell?
O PHP2Shell não é uma vulnerabilidade do OXID, mas do PHP. Qualquer loja OXID num servidor PHP sem patch é, por isso, potencialmente vulnerável. Uma atualização do OXID não corrige a falha.
Onde vejo a versão do PHP no OXID?
Na área de administração, em Serviço > Informação do sistema, onde são apresentados os dados do PHP da loja em funcionamento. Não se reconhece aí se foi aplicado um backport; isso é confirmado pelo seu fornecedor de alojamento ou operador.
Que ficheiro do OXID contém as credenciais de acesso?
O ficheiro config.inc.php, no diretório source. Contém o acesso à base de dados. Perante uma suspeita, deve alterar a palavra-passe da base de dados e verificar se o ficheiro tem código inserido.
Temos de verificar a nossa interface ERP?
Sim. Se um atacante executou código no servidor da loja, pode ter lido credenciais de acesso ao ERP, PIM ou serviços de pagamento. Esses acessos devem ser renovados perante uma suspeita.