Pe scurt: La securitatea OXID eShop, după PHP2Shell, este vorba mai întâi de server: vulnerabilitatea se află în PHP, nu în OXID. Puneți să fie confirmată starea PHP și reporniți toate procesele. Apoi verificați config.inc.php, modulele, fișierele de temă, conturile de admin și accesurile la ERP și la serviciile de plată.
De ce ar trebui magazinele OXID să fie examinate cu atenție
OXID eShop este răspândit în spațiul de limbă germană mai ales în comerțul B2B, la producătorii cu vânzare directă și în comerțul en-gros. Astfel de magazine sunt rareori soluții izolate: ele schimbă comenzi, prețuri, stocuri și date de clienți cu ERP, PIM și servicii de plată. Un atacator de pe serverul magazinului vede, de aceea, adesea mai mult decât doar magazinul.
Potrivit echipei PHP, vulnerabilitățile PHP CVE-2026-109618 și CVE-2026-109619 permit execuția de cod malițios la distanță, fără autentificare. Faptul că OXID însuși este actualizat nu joacă niciun rol în acest caz. Datele tipice din magazinele OXID sunt:
- Clienți companii, cu persoane de contact, adrese, numere de client și prețuri individuale
- Istoricul comenzilor și cererile de ofertă
- Date de acces la ERP, la servicii de plată și de expediere în configurație și în setările modulelor
- Conturi de angajați în zona de administrare
Securitatea OXID eShop: verificarea corectă a stării PHP
În zona de administrare, Service > Informații sistem arată datele PHP ale magazinului care rulează. Aceasta este versiunea web, cu care sunt serviți clienții. Consola OXID, importurile și cronjob-urile rulează în schimb adesea cu un PHP din linia de comandă, care poate fi o altă versiune. Ambele trebuie să aibă patchul aplicat.
Versiunile upstream remediate sunt 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Distribuțiile și furnizorii de hosting livrează uneori corecțiile ca backport, numărul rămânând atunci același; decisivă este starea confirmată a pachetului. Ce versiuni PHP sunt acceptate de versiunea dumneavoastră de OXID verificați conform cerințelor de sistem din documentația producătorului de pe oxid-esales.com.
Magazinele OXID mai vechi, din generația 4 sau din primele versiuni ale generației 6, rulează adesea încă pe versiuni PHP vechi, fără actualizări oficiale. Atunci este nevoie, până la upgrade, de protecție de tranziție și de un calendar ferm.
Directoare și fișiere în OXID
Începând cu OXID 6, magazinul se instalează prin Composer; rădăcina documentelor este, de regulă, directorul source/.
| Loc | Conținut | Punct de verificare |
|---|---|---|
source/config.inc.php |
Accesul la baza de date, setări de bază | Cod strecurat, schimbați parola în caz de suspiciune |
source/modules/ (până la OXID 6), din OXID 7 vendor/ |
Module, în parte din pachete Composer | Module necunoscute, fișiere modificate |
var/configuration/ |
Configurația modulelor și a magazinului ca fișiere | Modificări neașteptate |
source/out/ |
Teme, imagini, JavaScript | Scripturi străine, fișiere PHP în directoarele de imagini |
source/tmp/ |
Șabloane compilate și cache | Goliți după curățare |
source/log/ |
Jurnalul magazinului | Salvați înainte de modificări |
Șabloanele compilate din directorul tmp sunt adesea trecute cu vederea. Ele constau din cod PHP și sunt regenerate după o curățare; de aceea, directorul ar trebui golit după fiecare descoperire.
Primele verificări inofensive:
# Fișiere PHP în directoarele de imagini și media
find source/out -type f -name "*.php"
# Fișiere de modul modificate din 17.10.2026 (OXID 6; din OXID 7 modulele se află în vendor/)
find source/modules -type f -newermt "2026-10-17"
# Vulnerabilități cunoscute în dependențe
composer audit
Un server de magazin curățat nu face din nou secrete accesurile de interfață care s-au scurs. În caz de suspiciune, reînnoiți datele de acces la ERP, la serviciile de plată și de expediere, în acord cu operatorii acestora.
Zona de administrare și modulele
Zona de administrare se află implicit la /admin/. Verificați administrarea utilizatorilor pentru conturi cu drepturi de admin pe care nu le poate atribui nimeni și pentru accesuri ale foștilor prestatori. Restricționați, dacă este posibil, accesul admin la rețeaua firmei sau la un VPN; în mediul B2B, aceasta este de obicei bine realizabilă.
Modulele pentru metode de plată, conexiunea ERP, funcții B2B precum prețurile pe trepte sau procesele de aprobare sunt adesea adaptate individual în magazinele OXID. Fiecare modul este cod PHP propriu, iar modulele adaptate frânează adesea upgrade-urile PHP. Consemnați ce module sunt active, cine le întreține și dacă există o versiune pentru versiunea PHP vizată.
Ce poate și ce nu poate o actualizare OXID
O actualizare OXID sau a unui modul închide erori cunoscute din acel cod și poate permite versiuni PHP mai noi. Ea nu aplică patchul PHP și nu repornește nici PHP-FPM, nici procesele de fundal. Fișierele străine din source/out, modulele manipulate, șabloanele compilate și conturile noi de admin rămân. Dacă există indicii ale unui atac verificați cu Am fost deja compromis?. Pentru situația din firmele mijlocii se potrivește Securitate IT pentru firmele mijlocii și industrie.
Multe magazine OXID au, pe lângă sistemul live, un mediu de staging pe același server sau pe un al doilea. Verificați și actualizați și acest mediu, deoarece conține adesea o copie a datelor clienților și este la fel de util atacatorilor.
Cum ajută PHP SOS concret?
- Stabilim PHP-ul web și CLI al serverului dumneavoastră OXID și punem să fie confirmate patchul și repornirea.
- Salvăm jurnalele începând cu 20.10.2026, fișierele și baza de date.
- Verificăm
config.inc.php, modulele, temele, șabloanele compilate și conturile de admin. - În caz de suspiciune, coordonăm, prin răspunsul nostru la incidente, curățarea și reînnoirea accesurilor de interfață împreună cu agenția dumneavoastră și cu prestatorii dumneavoastră ERP.
Întrebări frecvente
Este OXID eShop afectat de PHP2Shell?
PHP2Shell nu este o vulnerabilitate OXID, ci o vulnerabilitate în PHP. Orice magazin OXID pe un server PHP fără patch este, de aceea, potențial vulnerabil. O actualizare OXID nu închide vulnerabilitatea.
Unde văd versiunea PHP în OXID?
În zona de administrare, la Service > Informații sistem, unde sunt afișate datele PHP ale magazinului care rulează. Dacă a fost aplicat un backport nu recunoașteți de aici; acest lucru îl confirmă furnizorul dumneavoastră de hosting sau operatorul.
Ce fișier OXID conține datele de acces?
Fișierul config.inc.php din directorul source. El conține accesul la baza de date. În caz de suspiciune, ar trebui să schimbați parola bazei de date și să verificați fișierul pentru cod strecurat.
Trebuie să verificăm interfața noastră ERP?
Da. Dacă un atacator a executat cod pe serverul magazinului, este posibil să fi citit date de acces la ERP, PIM sau servicii de plată. Aceste accesuri ar trebui reînnoite în caz de suspiciune.