# Segurança OXID eShop após o PHP2Shell: proteger a loja e as interfaces > Proteger o OXID eShop após o PHP2Shell: verificar o PHP no admin, controlar config.inc.php e módulos e proteger contas de admin e interfaces B2B. Fonte: https://phpsos.de/pt/plattformen/oxid-eshop/ 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:** 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: ```bash # 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 ``` > **Importante:** > 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?](https://phpsos.de/pt/php2shell/bin-ich-gehackt-anzeichen/). Sobre a situação nas empresas médias, vale a pena [Segurança informática para empresas médias e indústria](https://phpsos.de/pt/branchen/mittelstand-industrie/). 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](https://phpsos.de/pt/leistungen/incident-response/), 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. ## Fontes - [php.net: avisos de segurança](https://www.php.net/) - [OXID eSales](https://www.oxid-esales.com/) - [Versões do PHP suportadas](https://www.php.net/supported-versions.php) - [BSI](https://www.bsi.bund.de/)