# Sicurezza OXID eShop dopo PHP2Shell: proteggere shop e interfacce > Proteggere OXID eShop dopo PHP2Shell: verificare PHP nell'admin, controllare config.inc.php e moduli, mettere in sicurezza account admin e interfacce B2B. Fonte: https://phpsos.de/it/plattformen/oxid-eshop/ Stato: 25/10/2026 Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6 **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: ```bash # 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 ``` > **Importante:** > 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?](https://phpsos.de/it/php2shell/bin-ich-gehackt-anzeichen/). Alla situazione delle PMI si adatta [Sicurezza IT per PMI e industria](https://phpsos.de/it/branchen/mittelstand-industrie/). 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](https://phpsos.de/it/leistungen/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. ## Fonti - [php.net: bollettini di sicurezza](https://www.php.net/) - [OXID eSales](https://www.oxid-esales.com/) - [Versioni di PHP supportate](https://www.php.net/supported-versions.php) - [BSI (Ufficio federale tedesco per la sicurezza informatica)](https://www.bsi.bund.de/)