Zero-Day Magento EE Cache Poisoning Attack


Magento Enterprise Edition is vulnerable to poisoning of its page cache under some configurations due to inappropriate trust of HTTP Host header values.


Users shopping at online stores driven by Magento EE can be redirected to arbitrary third party sites, allowing malicious entities to entice users to hand over their credit card information inappropriately.


Major – Exploit allows for content injection, and hijacking of users. Exploits have been observed in the wild.

Fix/Workaround Status

At this time, the vendor (Magento Inc) has only stated an intent to fix the problem (as a “product enhancement”) but has not provided any patch despite being given considerable lead time by us and being first made aware of the problem in 2008 (see note below for more details). The issue can be worked around using one of several configuration-related changes, including one which the vendor introduced in 2008. Affected Versions:

All versions of Magento EE, up to and including (the latest as of this writing) when page caching is enabled. It is unclear if the block-level caching in Magento Community/Professional Edition is similarly impacted, however both are likely vulnerable to the misinterpretation of data.


Magento uses a hierarchical configuration mechanism, allowing values such as site URLs to be set at a global level and at a more specific per-storefront level. Magento EE adds a mechanism for caching whole pages. With default URL values, Magento EE can be tricked into generating page cache entries with arbitrary URL values by simply sending an artificial HTTP Host header. Unfortunately, setting the URL value at the storefront level is insufficient to prevent this behavior. In order to prevent this issue, one of the following must be true:

Web-server level

The key is to have the web server send only trustworthy/cleansed values to PHP. The following are example approaches for Apache: Your web server is configured in a way that results in untrusted Host values never being sent to PHP. An example of this would be the use of name-based vhosts that do not point the “_default_” vhost to a Magento instance. Using one or more ServerAlias masks with IP-based vhosting to constrain the range of valid host values.

Magento level

Provide Base Unsecure URL and Base Secure URL values in the “Default Config” (top-level) configuration. The precise values do not appear to matter, just so long as some value is present. Reproducing the problem simply requires requesting any URL with a forged Host header at a time when the page cache is considered invalid.

Nota Bene

The vendor’s solution to the problem when confronted with it in 2008 was to introduce a vaguely worded warning in the admin UI when the base URL value is not defined at the top level of the configuration hierarchy.

Given that:

  • It is not made clear that the configuration status presents a severe security hole.
  • A non-default base URL value in the top-level configuration level is never actually used in page-cache generation. Its presence apparently serves only to trigger use of the per-storefront configuration value.

We therefore hold that the provided warning does not suffice as a ‘fix’. The vendor has indicated that they believe otherwise both through their actions and their communications with us.



2: The exact wording of the message is: “{{base_url}} is not recommended to use in a production environment to declare the Base Unsecure URL / Base Secure URL. It is highly recommended to change this value in your Magento configuration.”

magento, security 581 words, est. time: 116 seconds.

« Pathfinding in Unity Careful Cutting To Get Faster RSpec Runs with Rails »


Copyright © 2022 - Jon Frisby - Powered by Octopress