By crawling specially crafted URLs (e.g. by “forced browsing”), an attacker is able to overflow the database of the shop and this way make it stop working. This is called a DoS (Denial of Service) attack. The only precondition: the shop allows rendering empty categories to the storefront by admin option.

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

  • Your OXID eShop gets slower and slower over the time. Please note that this time frame is not specified: it might be a fast or slow process.
  • The ‘oxseo’ table of your database gets unusually packed.
  • Often, web hosting providers run quotas for the database size. In case the database flows over, they will inform you.

An attacker might run a DoS (Denial of Service) against your system until it shuts down.

An attacker will not gain access to the data of your customers, passwords or any other nor access to the admin panel. Also, he will not be able to inject malicious code into your file system.

Default setting of Articles per category page is 10, in case you changed this setting in your shop, calculate with your own value here. We need to know the absolute maximum number of pages one category can have: CountOfArticlesInShop / NumberOfArticlesPerCategoryPage

NOTE: We count all entries in table oxarticles, disregarding variants, we want to see the maximum count:

select FLOOR((select count(*) from oxarticles where oxshopid = [shop_id]) / [number_of_articles_per_category_page] + 0.5) as max_single_cat_pages;


select FLOOR((select count(*) from oxarticles where oxshopid = 1)/10 + 0.5) as max_single_cat_pages;

You should not get any pagination higher than this value.

Check your shop

select oxshopid, count(*), oxtype, max(CAST(oxparams as unsigned)) from oxseo where (oxtype not in ('static', 'content', 'oxarticle')) and (oxparams != '') and (CAST(oxparams as unsigned) > [max_single_cat_pages]) group by oxshopid, oxtype;

Example (we got the estimate of 22 for max_single_cat_pages from the testdata we used):

select oxshopid, count(*), oxtype, max(CAST(oxparams as unsigned))  from oxseo where (oxtype not in ('static', 'content', 'oxarticle')) and (oxparams != '') and (CAST(oxparams as unsigned) > 22) group by oxshopid, oxtype;

In case you find a large amount of oxparam values that are a lot larger than the maximum pagination to be expected: Good chance you got hacked. In case not: no further action needed, you are safe for now.

NOTE: some few paginated pages with a page number that exceeds the maximum expected page might have been created by accident. We’re talking about lots and lots of them here in case of an attack.

Clean the database

NOTE: you will not destroy any valuable SEO information. Paginated pages will be regenerated if needed.

delete from oxseo where (oxshopid = [shop_id]) and (oxseourl REGEXP '/([0-9])*/') and (oxtype not in ('static', 'content', 'oxarticle')) and (oxparams != '');


delete from oxseo where (oxshopid = 1) and (oxseourl REGEXP '/([0-9])*/') and (oxtype not in ('static', 'content', 'oxarticle')) and (oxparams != '');
  • Apply the hotfix for your OXID eShop version offered in Security Bulletin 2017-002 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.

Yes: there’ll be a hotfix for OXID eShop series 4.7, 4.8, 4.9, 4.10, 5.0, 5.1, 5.2 and 5.3.

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. Please use them!

We expect the users of OXID eShop to update their shops regularly. However, not a lot of core application files are affected. For OXID eShop versions prior than 4.7 and 5.0, please try to use the files of the hotfix in your installation or make a diff.

Unfortunately, a server side interception is not possible in this constellation. Otherwise, we would have published mod_security rules at least to our hosting partners and to other web hosting providers as well.

No, but you should definitely use SSL certificates nevertheless to prevent other (man-in-the-middle) attacks.

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

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