En bref : pour la sécurité d'OXID eShop, après PHP2Shell, il s'agit d'abord du serveur : la faille se trouve dans PHP, pas dans OXID. Faites confirmer l'état de PHP et redémarrer tous les processus. Contrôlez ensuite config.inc.php, les modules, les fichiers de thème, les comptes admin et les accès à l'ERP et aux services de paiement.
Pourquoi les boutiques OXID doivent regarder de près
OXID eShop est répandu dans l'espace germanophone, surtout dans le commerce B2B, chez les fabricants avec vente directe et dans le commerce de gros. De telles boutiques sont rarement des solutions isolées : elles échangent commandes, prix, stocks et données clients avec l'ERP, le PIM et les services de paiement. Un attaquant sur le serveur de la boutique voit donc souvent plus que la seule boutique.
Les failles PHP CVE-2026-109618 et CVE-2026-109619 permettent, selon l'équipe PHP, d'exécuter du code malveillant à distance sans authentification. Que OXID lui-même soit à jour n'y change rien. Les données typiques des boutiques OXID sont :
- clients professionnels avec interlocuteurs, adresses, numéros de client et prix individuels
- historique des commandes et demandes d'offres
- identifiants de l'ERP, des services de paiement et d'expédition dans la configuration et les réglages des modules
- comptes de collaborateurs dans l'espace d'administration
Sécurité d'OXID eShop : vérifier correctement l'état de PHP
Dans l'espace d'administration, Service > Infos système affiche les indications PHP de la boutique en cours. C'est la version web avec laquelle les clients sont servis. La console OXID, les imports et les tâches cron fonctionnent en revanche souvent avec un PHP en ligne de commande, qui peut être d'une autre version. Les deux doivent être corrigés.
Les versions corrigées en amont sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les distributions et les hébergeurs livrent parfois les correctifs sous forme de backport, le numéro reste alors identique ; l'état confirmé des paquets est déterminant. Les versions de PHP prises en charge par votre version d'OXID se vérifient dans la configuration requise de la documentation du fabricant sur oxid-esales.com.
Les anciennes boutiques OXID de la génération 4 ou les premières versions de la génération 6 tournent souvent encore sur d'anciennes versions de PHP sans mises à jour officielles. Il faut alors, jusqu'à la mise à niveau, une protection transitoire et un calendrier ferme.
Dossiers et fichiers dans OXID
Depuis OXID 6, la boutique s'installe via Composer ; la racine web est en général le répertoire source/.
| Emplacement | Contenu | Point de contrôle |
|---|---|---|
source/config.inc.php |
Accès à la base de données, réglages de base | code inséré, changer le mot de passe en cas de soupçon |
source/modules/ (jusqu'à OXID 6), à partir d'OXID 7 vendor/ |
Modules, en partie issus de paquets Composer | modules inconnus, fichiers modifiés |
var/configuration/ |
Configuration des modules et de la boutique sous forme de fichiers | modifications inattendues |
source/out/ |
Thèmes, images, JavaScript | scripts étrangers, fichiers PHP dans les dossiers d'images |
source/tmp/ |
templates compilés et cache | vider après nettoyage |
source/log/ |
Journal de la boutique | sauvegarder avant toute modification |
Les templates compilés dans le répertoire tmp sont souvent négligés. Ils se composent de code PHP et sont régénérés après un nettoyage ; le dossier devrait donc être vidé après chaque découverte.
Premiers contrôles sans danger :
# Fichiers PHP dans les dossiers d'images et de médias
find source/out -type f -name "*.php"
# Fichiers de modules modifiés depuis le 17/10/2026 (OXID 6 ; à partir d'OXID 7, les modules sont dans vendor/)
find source/modules -type f -newermt "2026-10-17"
# Failles connues dans les dépendances
composer audit
Un serveur de boutique nettoyé ne rend pas de nouveau secrets les accès d'interface qui ont fui. En cas de soupçon, renouvelez les identifiants de l'ERP, des services de paiement et d'expédition en concertation avec leurs exploitants.
Espace d'administration et modules
L'espace d'administration se trouve par défaut sous /admin/. Vérifiez la gestion des utilisateurs à la recherche de comptes avec droits d'admin que personne ne sait attribuer et d'accès d'anciens prestataires. Limitez si possible l'accès à l'administration au réseau de l'entreprise ou à un VPN ; dans l'environnement B2B, c'est le plus souvent bien réalisable.
Les modules pour les moyens de paiement, la connexion à l'ERP, les fonctions B2B comme les prix dégressifs ou les processus de validation sont souvent adaptés sur mesure dans les boutiques OXID. Chaque module est du code PHP propre, et les modules adaptés freinent souvent les mises à niveau de PHP. Consignez quels modules sont actifs, qui les maintient et s'il existe une version pour la version de PHP visée.
Ce qu'une mise à jour d'OXID peut faire et ne peut pas faire
Une mise à jour d'OXID ou d'un module comble des défauts connus de ce code et peut permettre d'utiliser des versions de PHP plus récentes. Elle ne corrige pas PHP et ne redémarre ni PHP-FPM ni les processus d'arrière-plan. Les fichiers étrangers dans source/out, les modules manipulés, les templates compilés et les nouveaux comptes admin subsistent. Pour savoir s'il existe des signes d'une attaque, utilisez Suis-je déjà compromis ?. Pour la situation des PME, voir Sécurité informatique pour les PME et l'industrie.
De nombreuses boutiques OXID disposent, à côté du système de production, d'un environnement de staging sur le même serveur ou sur un second. Contrôlez et corrigez-le aussi, car il contient souvent une copie des données clients et est tout aussi utile aux attaquants.
Comment PHP SOS aide-t-il concrètement ?
- Nous établissons le PHP web et le PHP CLI de votre serveur OXID et faisons confirmer le correctif et le redémarrage.
- Nous sauvegardons les journaux à partir du 20/10/2026, les fichiers et la base de données.
- Nous contrôlons
config.inc.php, les modules, les thèmes, les templates compilés et les comptes admin. - En cas de soupçon, nous coordonnons via notre réponse aux incidents le nettoyage et le renouvellement des accès d'interface avec votre agence et vos prestataires ERP.
Questions fréquentes
OXID eShop est-il concerné par PHP2Shell ?
PHP2Shell n'est pas une faille d'OXID, mais une faille de PHP. Toute boutique OXID sur un serveur PHP non corrigé est donc potentiellement vulnérable. Une mise à jour d'OXID ne comble pas la faille.
Où vois-je la version de PHP dans OXID ?
Dans l'espace d'administration, sous Service > Infos système, où s'affichent les indications PHP de la boutique en cours. Le numéro ne permet pas de savoir si un backport a été appliqué ; votre hébergeur ou exploitant le confirme.
Quel fichier OXID contient les identifiants d'accès ?
Le fichier config.inc.php dans le répertoire source. Il contient l'accès à la base de données. En cas de soupçon, changez le mot de passe de la base de données et contrôlez le fichier à la recherche de code inséré.
Devons-nous contrôler notre interface ERP ?
Oui. Si un attaquant a exécuté du code sur le serveur de la boutique, il a pu lire les identifiants de l'ERP, du PIM ou des services de paiement. Ces accès devraient être renouvelés en cas de soupçon.