In breve: per la sicurezza di OXID eShop dopo PHP2Shell conta anzitutto il server: la vulnerabilità è in PHP, non in OXID. Si faccia confermare lo stato di PHP e riavviare tutti i processi. Poi controlli config.inc.php, moduli, file del tema, account admin e gli accessi a ERP e servizi di pagamento.
Perché gli shop OXID dovrebbero guardare con attenzione
OXID eShop è diffuso nell'area di lingua tedesca soprattutto nel commercio B2B, presso produttori con vendita diretta e nel commercio all'ingrosso. Questi shop sono raramente soluzioni isolate: scambiano ordini, prezzi, scorte e dati dei clienti con ERP, PIM e servizi di pagamento. Un aggressore sul server dello shop vede quindi spesso più del solo shop.
Le vulnerabilità PHP CVE-2026-109618 e CVE-2026-109619 consentono, secondo il team PHP, di eseguire codice dannoso da remoto senza autenticazione. Che OXID stesso sia aggiornato è irrilevante al riguardo. Dati tipici negli shop OXID sono:
- clienti aziendali con referenti, indirizzi, numeri cliente e prezzi individuali
- storico degli ordini e richieste di offerta
- credenziali di ERP, servizi di pagamento e di spedizione nella configurazione e nelle impostazioni dei moduli
- account dei dipendenti nell'area admin
Sicurezza di OXID eShop: verificare correttamente lo stato di PHP
Nell'area admin, Servizio > Info di sistema mostra i dati PHP dello shop in esecuzione. È la versione web con cui vengono serviti i clienti. La console di OXID, le importazioni e i cronjob girano invece spesso con un PHP a riga di comando, che può essere una versione diversa. Entrambi devono essere aggiornati.
Le versioni upstream corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Distribuzioni e hoster talvolta distribuiscono le correzioni come backport, e il numero resta allora lo stesso; fa fede lo stato confermato dei pacchetti. Quali versioni di PHP supporta la Sua versione di OXID, lo verifichi nei requisiti di sistema nella documentazione del produttore su oxid-esales.com.
I vecchi shop OXID della generazione 4 o le prime versioni della generazione 6 girano spesso ancora su vecchie versioni di PHP senza aggiornamenti ufficiali. In tal caso, fino all'upgrade servono una protezione transitoria e un calendario preciso.
Directory e file in OXID
Da OXID 6 lo shop viene installato tramite Composer; la document root è di norma la directory source/.
| Posizione | Contenuto | Punto da controllare |
|---|---|---|
source/config.inc.php |
Accesso al database, impostazioni di base | codice aggiunto, cambiare la password in caso di sospetto |
source/modules/ (fino a OXID 6), da OXID 7 vendor/ |
Moduli, in parte da pacchetti Composer | moduli sconosciuti, file modificati |
var/configuration/ |
Configurazione di moduli e shop come file | modifiche inattese |
source/out/ |
Temi, immagini, JavaScript | script estranei, file PHP nelle cartelle delle immagini |
source/tmp/ |
template compilati e cache | svuotare dopo la bonifica |
source/log/ |
Log dello shop | salvare prima delle modifiche |
I template compilati nella directory tmp vengono spesso trascurati. Consistono in codice PHP e dopo una bonifica vengono rigenerati; la cartella andrebbe quindi svuotata dopo ogni riscontro.
Primi controlli non invasivi:
# File PHP nelle cartelle di immagini e media
find source/out -type f -name "*.php"
# File dei moduli modificati dal 17/10/2026 (OXID 6; da OXID 7 i moduli sono in vendor/)
find source/modules -type f -newermt "2026-10-17"
# Vulnerabilità note nelle dipendenze
composer audit
Un server dello shop bonificato non rende di nuovo segreti gli accessi alle interfacce che siano già usciti. In caso di sospetto rinnovi le credenziali di ERP, servizi di pagamento e di spedizione, in accordo con i loro gestori.
Area admin e moduli
L'area admin si trova per impostazione predefinita in /admin/. Controlli la gestione utenti alla ricerca di account con diritti admin che nessuno sa attribuire e di accessi di ex fornitori di servizi. Limiti, se possibile, l'accesso admin alla rete aziendale o a una VPN; in ambito B2B di solito è ben fattibile.
I moduli per metodi di pagamento, collegamento ERP, funzioni B2B come prezzi a scaglioni o processi di approvazione sono spesso personalizzati negli shop OXID. Ogni modulo è codice PHP proprio, e i moduli personalizzati rallentano spesso gli aggiornamenti di PHP. Annoti quali moduli sono attivi, chi li cura e se esista una versione per la versione di PHP desiderata.
Che cosa può fare un aggiornamento di OXID e che cosa no
Un aggiornamento di OXID o di un modulo chiude errori noti in quel codice e può rendere possibili versioni di PHP più recenti. Non applica patch a PHP e non riavvia né PHP-FPM né i processi in background. File estranei in source/out, moduli manipolati, template compilati e nuovi account admin restano. Se ci siano indizi di un attacco, lo verifichi con Sono già compromesso?. Alla situazione delle PMI si adatta Sicurezza IT per PMI e industria.
Molti shop OXID hanno, accanto al sistema live, un ambiente di staging sullo stesso server o su un secondo. Controlli e aggiorni anche questo, perché spesso contiene una copia dei dati dei clienti ed è utile agli aggressori altrettanto.
In che modo PHP SOS aiuta concretamente?
- Accertiamo PHP web e CLI del Suo server OXID e ci facciamo confermare patch e riavvio.
- Mettiamo al sicuro i log a partire dal 20/10/2026, i file e il database.
- Controlliamo
config.inc.php, moduli, temi, template compilati e account admin. - In caso di sospetto, tramite il nostro servizio di incident response coordiniamo la bonifica e il rinnovo degli accessi alle interfacce con la Sua agenzia e i Suoi fornitori ERP.
Domande frequenti
OXID eShop è interessato da PHP2Shell?
PHP2Shell non è una vulnerabilità di OXID, ma di PHP. Ogni shop OXID su un server con PHP non aggiornato è quindi potenzialmente attaccabile. Un aggiornamento di OXID non chiude la vulnerabilità.
Dove vedo la versione di PHP in OXID?
Nell'area admin, in Servizio > Info di sistema, dove vengono mostrati i dati PHP dello shop in esecuzione. Da essi non si capisce se sia stato applicato un backport; lo conferma il Suo hoster o gestore.
Quale file OXID contiene le credenziali?
Il file config.inc.php nella directory source. Contiene l'accesso al database. In caso di sospetto dovrebbe cambiare la password del database e verificare che nel file non sia stato inserito codice.
Dobbiamo verificare la nostra interfaccia ERP?
Sì. Se un aggressore ha eseguito codice sul server dello shop, può aver letto le credenziali di ERP, PIM o servizi di pagamento. In caso di sospetto questi accessi dovrebbero essere rinnovati.