By sending specially craftet HTTP_POST or HTTP_GET requests to the oxuser class, an attacker can gain administrative access to OXID eShop via the storefront.

There are a few symtoms which may indicate that you have been compromised:

Login and password reset stopped working

In order to administer your shop, you ususally use the admin account that was created during the setup. You cannot log in to the administration panel any longer, but you are 100 % sure your password is correct. When using the password reset function in the storefront, no email will appear in your inbox or your spam folder.

Unknown admin users in database

There is an admin user you do not know. Their name und email address is unknown to you. You can find this information by executing the following SQL query:

SELECT oxid, oxusername, oxcreate, oxtimestamp FROM oxuser WHERE oxrights='malladmin';

Example output:

example output different admin

System related time stamps differ

Usually the creation and registration date of an admin user should be the same. If this is not the case, it might be an indication for a compromised account. You can find this information by executing the following SQL query:

SELECT oxid, oxusername, oxcreate, oxregister FROM oxuser WHERE oxcreate != oxregister;

Example output:

example output timestamps differ

An attacker will gain administrative rights, and hence will get the full power of a regular shop admin. This includes changing the shop’s settings, product data, prices, discounts, but also to execute PHP code and SQL queries, inject malicious code into the storefront templates, get the customer data, including the salted password and the salt itself etc.

We strongly recommend to take all of the following initiatives:

Apply all workarounds

Apply all workarounds proposed in Security Bulletin 2016-001 in order to stop further attacks.

Backup data and files for investigation

Create local copies of your data and files for later investigation. This includes the application code including extensions, the log files (database server, web server, system, PHP logs, etc) and a database dump. Upload a clean version of OXID eShop and all the extensions you use. Check the log files for suspicious messages. Check the application and extension code for malicious code. Check the system for backdoors. Note: If you use an encrypted version of OXID eShop, code injection does not work and will immediately result in an error message.

Further reading:


Inform your customers

Urge all customers to change their passwords immediately, and also change the password if they re-used the shop’s password somewhere else.

Reset the default admin’s password

UPDATE oxuser SET oxusername='###YOUR EMAIL HERE###', oxpassword='xxx' WHERE oxid='oxdefaultadmin';
Then trigger the password reset process in the storefront.

Change SMTP password

Change the SMTP password if set in the administration backend.

Revert unauthorized changes

Clean your shop settings from any changes (discounts, vouchers, …)

  • Apply all workarounds proposed in Security Bulletin 2016-001 in order to stop further attacks
  • Update your OXID eShop installation as soon as possible

So far we are not aware of an attack. We informed our customers, partners and friends in advance about the issue, so they could take measures before the issue became public.

All OXID eShop versions are affected without any exception.

All OXID eShop editions are affected without any exception.

We take a huge effort to make regular patch releases for all our supported versions, and all patch releases are fully backwards compatible. Also we provide tools to migrate from an end-of-life version to a supported one, as well as cumulative update packages from any previous patch release to the latest patch release.

Therefore we expect the users of OXID eShop to update their shops regularly, and we will not provide a patch for unsupported versions. However, not a lot of core application files are affected. You can try to take the file application/components/oxcmp_user.php from the 5.1/4.8 patch release package, and replace it with the one on your installation. However, this is just a wild guess, with no guarantee.

Yes, and our proposed workarounds in Security Bulletin 2016-001 include an example rule set for a web application firewall such as ModSecurity.

No, but you should use SSL certificates nevertheless to prevent other attacks.

The issue was found by OXID developers, not a third party. OXID eShop has gone through many security audits in the past, but the issue wasn’t discovered there.

The security team at OXID eSales ([email protected]).

Please find more information about how we handle security issues in general on this page: