In short: After PHP2Shell, OXID eShop security is first of all about the server: the flaw is in PHP, not in OXID. Have the PHP status confirmed and all processes restarted. Then check config.inc.php, modules, theme files, admin accounts and the access to ERP and payment services.
Why OXID shops should take a close look
In the German-speaking region, OXID eShop is widespread mainly in B2B trade, among manufacturers with direct sales and in wholesale. Such shops are rarely stand-alone solutions: they exchange orders, prices, stock levels and customer data with ERP, PIM and payment services. An attacker on the shop server therefore often sees more than just the shop.
According to the PHP team, the PHP flaws CVE-2026-109618 and CVE-2026-109619 allow remote code execution without authentication. Whether OXID itself is up to date plays no role here. Typical data in OXID shops includes:
- Business customers with contact persons, addresses, customer numbers and individual prices
- Order history and quote requests
- Credentials for ERP, payment and shipping services in configuration and module settings
- Employee accounts in the admin area
OXID eShop security: checking the PHP status correctly
In the admin area, Service > System Info shows the PHP details of the running shop. This is the web version used to serve customers. The OXID console, imports and cron jobs, on the other hand, often run with a command-line PHP that can be a different version. Both must be patched.
Fixed upstream versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Distributions and hosts sometimes deliver fixes as a backport, in which case the number stays the same; the confirmed package status is what counts. Which PHP versions your OXID version supports can be found in the system requirements in the manufacturer's documentation on oxid-esales.com.
Older OXID shops of generation 4 or early versions of generation 6 often still run on old PHP versions without official updates. Until the upgrade, they then need interim protection and a firm schedule.
Directories and files in OXID
Since OXID 6, the shop is installed via Composer; the document root is usually the source/ directory.
| Location | Content | What to check |
|---|---|---|
source/config.inc.php |
Database credentials, basic settings | Inserted code, change password if you suspect an incident |
source/modules/ (up to OXID 6), from OXID 7 vendor/ |
Modules, partly from Composer packages | Unknown modules, modified files |
var/configuration/ |
Module and shop configuration as files | Unexpected changes |
source/out/ |
Themes, images, JavaScript | Foreign scripts, PHP files in image folders |
source/tmp/ |
Compiled templates and cache | Empty after a cleanup |
source/log/ |
Shop log | Secure before making changes |
Compiled templates in the tmp directory are often overlooked. They consist of PHP code and are regenerated after a cleanup; the folder should therefore be emptied after every finding.
Harmless first checks:
# PHP files in image and media folders
find source/out -type f -name "*.php"
# Module files changed since 17 October 2026 (OXID 6; from OXID 7 modules are in vendor/)
find source/modules -type f -newermt "2026-10-17"
# Known vulnerabilities in dependencies
composer audit
A cleaned shop server does not make leaked interface credentials secret again. If you suspect an incident, renew the credentials for ERP, payment and shipping services in coordination with their operators.
Admin area and modules
By default, the admin area is located at /admin/. Check the user administration for accounts with admin rights that nobody can account for, and for access by former service providers. If possible, restrict admin access to the company network or a VPN; in a B2B environment this is usually quite feasible.
Modules for payment methods, ERP connection and B2B functions such as tiered prices or approval workflows are often customised in OXID shops. Every module is its own PHP code, and customised modules often hold up PHP upgrades. Record which modules are active, who maintains them and whether a version exists for the targeted PHP version.
What an OXID update can and cannot do
An update of OXID or a module closes known flaws in that code and can enable newer PHP versions. It does not patch PHP and restarts neither PHP-FPM nor background processes. Foreign files in source/out, manipulated modules, compiled templates and new admin accounts remain. Whether there are signs of an attack can be checked with Have I already been compromised?. For the situation of mid-sized companies, see IT security for mid-sized companies and industry.
Besides the live system, many OXID shops have a staging environment on the same or a second server. Check and patch it as well, because it often contains a copy of the customer data and is just as useful to attackers.
How does PHP SOS help?
- We establish the web and CLI PHP of your OXID server and have the patch and restart confirmed.
- We secure logs from 20 October 2026 onward, files and database.
- We check
config.inc.php, modules, themes, compiled templates and admin accounts. - If you suspect an incident, we coordinate the cleanup and the renewal of interface credentials with your agency and your ERP service providers through our incident response.
Frequently asked questions
Is OXID eShop affected by PHP2Shell?
PHP2Shell is not an OXID flaw but a flaw in PHP. Every OXID shop on a server with unpatched PHP is therefore potentially vulnerable. An OXID update does not close the flaw.
Where do I see the PHP version in OXID?
In the admin area under Service > System Info, which shows the PHP details of the running shop. The number does not tell you whether a backport has been applied; your host or operator confirms that.
Which OXID file contains the access credentials?
The file config.inc.php in the source directory. It contains the database credentials. If you suspect an incident, you should change the database password and check the file for injected code.
Do we need to check our ERP interface?
Yes. If an attacker has executed code on the shop server, they may have read credentials for ERP, PIM or payment services. These credentials should be renewed if you suspect an incident.