Magento has released a new security patch for M1, and updates for M1 and M2.

What issues should I look out for when upgrading or applying this patch?


SUPEE-10570, Magento Commerce and Open Source contain multiple security enhancements that help close remote code execution (RCE), cross-site scripting (XSS, and other issues. These releases also include small functional fixes listed in the release notes.

MAGENTO 2.2.3, 2.1.12 AND 2.0.18 SECURITY UPDATE

Magento Commerce and Open Source 2.2.3, 2.1.12 and 2.0.18 contain multiple security enhancements that help close Cross-Site Scripting (XSS), authenticated Admin user remote code execution (RCE) and other vulnerabilities. The releases include additional functional fixes. To find out more about the functional fixes please check Release Notes for Magento Commerce 2.0.18, 2.1.12, 2.2.3 and Magento Open Source 2.0.18, 2.1.12, 2.2.3.

  • 1
    For Open Source / Community Edition 1.x no frontend template changes seem to be included, so this at least should not create too many troubles. However - a database backup is highly recommended as there are two install (upgrade) scripts included in this patch. More details may follow after I've patched the first environments. – Christoph Farnleitner Feb 27 '18 at 17:15
  • 1
    If you have stores using a customized adminhtml grid that includes the store name, the patch now escapes it presumably to fix some potential exploits based on changing the store name and rendering. – Andrew Quackenbos Feb 27 '18 at 19:34
  • I have so far patched 2 sites on without issue. – asdfasdfasf Feb 27 '18 at 19:42
  • 1
    I've applied the patch on, and so far no issues – David Feb 28 '18 at 15:08
  • 2
    This is from the security blog: magento.com/security/patches/supee-10570 NOTE: Some customers are experiencing issue in checkout when trying to create an account while checking out. An update patch or a workaround to fix this issue will be available shortly. If you are experiencing this issue right now, consider reverting the portion of the code causing this issue by applying the following patch: invalid_sesssion_fix.patch from the Release Archives, SUPEE-10570 section – The Tankgirl Mar 15 '18 at 9:55

16 Answers 16


Here is the list of modified files by the SUPEE-10570 patch:



Finally after deploying on my prod website (CE, i noticed a critical blocking issue (checkout process blocked).

The context: after step 1 address, i directly create AND log the customer, he should see only the next checkout step.

The problem: after supee-10570, the checkout process is broken after step 1 (in case account creation) and the customer is redirected to homepage (with shopping cart empty + logged out) = impossible to achieve his checkout.

The emergency fix: In case you encounter similar problem with your checkout / customer session, comment the lines 414-430 from app/code/core/Mage/Core/Model/Session/Abstract/Varien.php (the ones added by the patch, see below).

//         if ($this->useValidateSessionPasswordTimestamp()
//             && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
//             && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
//             && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
//             > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
//         ) {
//             return false;
//         }

//         if ($this->useValidateSessionExpire()
//             && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
//             && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {
//             return false;
//         } else {
//             $this->_data[self::VALIDATOR_KEY][self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]
//                 = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP];
//         }

EDIT (2)

I think the following condition will always return false (Mage_Core_Model_Session_Abstract_Varien at lines 414-419, especially lines 417+418).

if ($this->useValidateSessionPasswordTimestamp()
            && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
            && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
            && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
            > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
        ) {
        return false;

VALIDATOR_PASSWORD_CREATE_TIMESTAMP will be always greater than VALIDATOR_SESSION_EXPIRE_TIMESTAMP. The session "expiration" timestamp is redefined at account creation, so inevitably older than session init.

So for instance if you create the customer during checkout, this will return false and the customer will be just kickedout (= end checkout, redirect to homepage & cart empty). Pretty bad.

I've reported this issue to magento team. I'll give feedback here asap.

EDIT (3)

A new patch is wip (on the magento patch download page it's write "SUPEE-10570 for CE - UPDATED PATCH EXPECTED, DO NOT USE (0.06 MB)").

EDIT (4) ~1 month after initial blocking issue reported

Hi! Hope you're all goods (and hope you didn't keep the initial patch state until now, unless your business income had probably seriously decreased^^).

I've noticed the following sentence from official page: "Magento is now providing an updated patch (SUPEE-10570v2) that no longer causes this issue. Note, however, that this new patch no longer protects against two low risk session handling-related security issues that patch SUPEE-10570 protected against." from official supee-10570 page.

On the release page we can finally find the v2 file (PATCH_SUPEE-10570_CE_v1.7.0.2_v2-2018-03-29-08-52-37.sh).

I've investigated the modifications in details. Finally it seems magento team just decided to drop a security part of the patch. Hope this security hole won't cause serious damages (it's low critical according official note).

After revert v1 + apply v2, please take care the following files are reverted as their initial state (before v1 was applied):


PS: obviously some other files are also modified, please check accordingly.

  • 1
    @Icon: i've just reported this bug to magento. I'll publish the answer as soon i receive an official feedback. – DarkCowboy Mar 2 '18 at 13:02
  • 4
    @Icon / Soleil: Unfortunately still no official answer or fix regarding my bugfix request. – DarkCowboy Mar 9 '18 at 15:36
  • 1
    @DarkCowboy I just noticed that once you go to patch download page, you can see Magento team added a note in the and patch. Looks like new patch is coming. – Icon Mar 12 '18 at 16:49
  • 3
    Hi everyone. I saw a new patch has been added ("PATCH_SUPEE-10570_CE_v1.7.0.2_v1-2018-02-28-04-54-53.sh"). You can see the difference here (left pane is 1st patch "PATCH_SUPEE-10570_CE_v1.7.0.2_v1-2018-02-23-06-28-18.sh"): diffchecker.com/uGON91aR . So no fix on the new patch?! In addition the "... UPDATED PATCH EXPECTED, DO NOT USE" notice has gone. So I'm a bit confusing what magento core team is doing with this problem. – DarkCowboy Mar 16 '18 at 6:44
  • 1
    FYI, V2 of the patch still lists "SUPEE-10570_CE_v1.9.2.4 | CE_1.9.2.4 | v1" in app/etc/applied.patches.list – Moose Apr 9 '18 at 14:25

(not sure if this was in release notes from beginning)

Known issues

These two known issues are associated with the use of HTML tags within a product’s SKU attribute:

  • If you try to import products that contain HTML tags in the SKU attribute, Magento displays this error at the data validation stage (that is, when you click Check data):
 Invalid value in SKU column. HTML tags are not allowed.
  • If you try to create or edit a product in the Admin panel and the product’s SKU attribute value contains HTML tags, Magento throws this error when you try to save the product: HTML tags are not allowed in SKU attribute.

From patch notes:

If the patch fails to apply while patching lib/Zend/Mail/Transport/Sendmail.php, it might mean your Magento installation was previously patched with SUPEE-9652v1 instead of SUPEE-9652v2. The recommended solution is to revert patch SUPEE-9652v1 and apply SUPEE-9652v2 prior to applying SUPEE-10570.


I had the same issue as @DarkCowboy after applying the patch to Magento CE

After choosing to register as a new customer during the checkout, placing the order creates both the order and the customer, but instead of displaying the order success page I'm redirected to the homepage and logged out.

The solution I have found is to reverse the order of the code blocks in the changes to app/code/core/Mage/Core/Model/Session/Abstract/Varien.php.

Comparing the patched version with the same file in Magento CE, I found the new blocks to validate the session expiration and password timestamp are in a different order.

Magento CE - Lines 476-491:

    if ($this->useValidateSessionExpire()
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {
        return false;
    } else {
            = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP];
    if ($this->useValidateSessionPasswordTimestamp()
        && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
        > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
    ) {
        return false;

Magento CE - Lines 414-430:

    if ($this->useValidateSessionPasswordTimestamp()
        && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
        > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
    ) {
        return false;

    if ($this->useValidateSessionExpire()
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {
        return false;
    } else {
            = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP];

This results in the value of $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP] being greater than $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime(), meaning the method always returns false and the validation fails.

Changing the code in Magento CE to match the version in Magento CE fixes the issue.

The resulting code for Magento CE - Lines 414-430:

    if ($this->useValidateSessionExpire()
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {
        return false;
    } else {
            = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP];
    if ($this->useValidateSessionPasswordTimestamp()
        && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
        > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
    ) {
        return false;

I'd suggest creating your own patch file and applying directly to the core file (this is how I normally approach fixing bugs in the core). This would make it easy to revert if Magento issues a version 2 of the patch.

  • Hi Dave. Seems you encountered the same issue than me. Regarding your fix, with your inversion the second condition won't be tested at all... I'll investigate these session data. – DarkCowboy Mar 2 '18 at 6:33
  • 4
    Update for expected mid March. (v2 of the patch), issue is confirmed. – Piotr Kaminski Mar 6 '18 at 14:54
  • Has anyone tested if this solution actually keeps the password change timestamp check working, or if it reopens the security hole they were trying to patch? Note: If you don't care about the security benefit, you can simply disable password change timestamp checking alltogether by having useValidateSessionPasswordTimestamp() return false. (one line change in the same file) – Eric Seastrand Mar 8 '18 at 22:13
  • Hi. We have evaluated, that the "redirect with empty cart" problem still exists with the changed validation order. We turned off the "useValidateSessionPasswordTimestamp" check until, magento create an update. – Steven Fritzsche Mar 14 '18 at 13:45

We saw a blank page at /checkout/cart after applying SUPEE-10570 and compiling. Just to clarify: With deactivated compiler all things went well, with activated compiler we only could see a blank cart page when logged in without any log entries (even after activating all possible logs and developer mode).

The solution was to alter the function getPasswordTimestamp() in app/code/core/Mage/Customer/Helper/Data.php (of course means: app/code/local/Mage/Customer/Helper/Data.php!) and to use Mage::getSingleton('core/resource') instead of Mage::getModel('customer/customer') or Mage::getSingleton('customer/session'). So replace whole function e.g. with these lines of code:

    $resource = Mage::getSingleton('core/resource');
    $readConnection = $resource->getConnection('core_read');
    $query = 'SELECT * FROM ' . $resource->getTableName('customer_entity').' WHERE `entity_id` = '.$customerId;
    $results = $readConnection->fetchAll($query);
    $date_created = Varien_Date::toTimestamp($result['created_at']);
    return $date_created;

After recompiling problem was gone. Anyone else with this problem?

Explanation in German here.

  • This is in many different ways some of the worst advice and code ever seen here. Please don't do any of this at home. – pong Mar 10 '18 at 9:58
  • Exactly same with me. This patch is not working with compiler enabled. – Rafael Patro Mar 19 '18 at 19:50
  • In it works fine for me. – TonkBerlin Aug 25 '18 at 1:39

Patch: PATCH_SUPEE-10570_CE_v1.7.0.0_v1-2018-02-23-06-37-58.sh

This error happens if you've not previously applied SUPEE-9652 or SUPEE-9767

patching file lib/Zend/Mail/Transport/Sendmail.php
Hunk #1 FAILED at 119.
Hunk #2 FAILED at 130.

Apply those patches to correct the issue.

  • 2
    Make sure you got 9652 and 9767 installed – Icon Feb 27 '18 at 23:27
  • Indeed, we tested SUPEE-10570 on all vanilla Magento versions since and it all works. But only if you applied all previous patches. Here you can look up which patches are required: docs.google.com/spreadsheets/d/… – Jeroen Vermeulen - MageHost Feb 28 '18 at 12:48

Patch PATCH_SUPEE-10570_CE_v1.7.0.0_v1-2018-02-23-06-37-58.sh File app/code/core/Mage/Core/Model/Session/Abstract/Varien.php

The patch for only adds one constant:

+    const VALIDATOR_PASSWORD_CREATE_TIMESTAMP   = 'password_create_timestamp';

However, it adds the use of two new constants, notably this one:

+        if ($this->useValidateSessionPasswordTimestamp()
+            && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
+            && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
+            && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
+            > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
+        ) {
+            return false;
+        }

This results in the error:

PHP Fatal error:  Uncaught Error: Undefined class constant 'VALIDATOR_SESSION_EXPIRE_TIMESTAMP' in 
Stack trace:
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php(358): Mage_Core_Model_Session_Abstract_Varien->_validate()
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php(176): Mage_Core_Model_Session_Abstract_Varien->validate()
app/code/core/Mage/Core/Model/Session/Abstract.php(84): Mage_Core_Model_Session_Abstract_Varien->init('core', 'frontend')
app/code/core/Mage/Core/Model/Session.php(42): Mage_Core_Model_Session_Abstract->init('core', 'frontend')
app/code/core/Mage/Core/Model/Config.php(1354): Mage_Core_Model_Session->__construct(Array)

The fix:

Add a definition for this second constant above or below the first constant added by this patch.

const VALIDATOR_SESSION_EXPIRE_TIMESTAMP = 'session_expire_timestamp';

So far I haven't seen this issue in any of the 1.9. or 1.14.x patches, because they define the constant correctly.

  • This was patched by adding const VALIDATOR_SESSION_EXPIRE_TIMESTAMP = 'session_expire_timestamp'; to the top of the file, like is done in most other versions of this patch. – Tyler V. Mar 1 '18 at 22:22
  • Yep seems to be specific to patch – danmentzer Mar 5 '18 at 16:37
  • Tyler can you add the fix to your actual answer rather than the comments section. – danmentzer Mar 5 '18 at 16:40
  • 1
    Also I would just note that this also effects patches for the EE version of the patch as well EE – danmentzer Mar 5 '18 at 16:46

First thing you should check, if you are previously applied the correct version of SUPEE-6788 or SUPEE-7405, if not revert the wrong version and then apply the correct version of SUPEE-6788/SUPEE-7405.

Then try again to apply SUPEE-10570.


The below files are updated/added after applied patch SUPEE - 10570 in EE

@DarkCowboy provided a lists of files other than that EE files are:


Some important notes

password_created_at created in customer attributes table.


These above are files are used for creation and validation. session issue occurs at checkout or user login check, the above any one of files are overwritten in your local pool or Any password_created_at attribute is created in your customer attribute table and the proper value stored in that table.

  • I could not find password_created_at in CE database where the problem is also given. – TonkBerlin Apr 2 '18 at 10:09
  • check this file app/code/core/Mage/Customer/sql/customer_setup/upgrade- – Rama Chandran M Apr 2 '18 at 13:35

My magento version is ver.

We saw a blank page at /checkout/cart after applying SUPEE-10570 and compiling. Just to clarify: With deactivated compiler all things went well, with activated compiler we only could see a blank cart page when logged in without any log entries (even after activating all possible logs and developer mode).


  1. the function getPasswordTimestamp will invoke two times when logged in and visit /checkout/cart.

  2. disabled compiler both invocation work.

  3. enable compiler only the first invocation work, second invocation failed.

can anyone explain and give the good solution?


An issues with I have noticed is as follows:

  1. Add Product to Cart and go to Checkout

  2. Click "Register"

  3. Fill all necessary order information including, payment details, etc.
  4. Click Complete Order.


5. Automatically get redirected to HOME PAGE. You don't get to see order number confirmation. But in reality, order is placed and customer account created.

  • have you find any solution for this? I am facing the same issue. – Parth Thummar Apr 6 '18 at 14:11
  • 1
    V2 of patch is out, problem solved – Icon Apr 6 '18 at 20:23

This patch has broken some of the CMS hierarchy manager for EE users.

This is because of the following patch line which is responsible for escaping stores/website names and fixing APPSEC-1873/1979/1980.

diff --git app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml
index e45298c..8bee617 100644
--- app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml
+++ app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml
@@ -36,7 +36,7 @@
             <div class="cms-popup-description"></div>
             <div class="fieldset">
                 <div class="cms-hierarchy manage-form">
-                    <?php echo $this->getFormHtml() ?>
+                    <?php echo $this->escapeHtml($this->getFormHtml()); ?>

It should show the store selector on the left but it instead shows the html on the right. If you really need this functionality you need to make a call of security vs functionality which isn't great.

show broken hierarchy


I met the same issue, Magento added this method into Mage_Customer_Helper_Data class

 * Get customer password creation timestamp or customer account creation timestamp
 * @param $customerId
 * @return int
public function getPasswordTimestamp($customerId)
    /** @var $customer Mage_Customer_Model_Customer */
    $customer = Mage::getModel('customer/customer')
    $passwordCreatedAt = $customer->getPasswordCreatedAt();

    return is_null($passwordCreatedAt) ? $customer->getCreatedAtTimestamp() : $passwordCreatedAt;

If you overrode this class inside Local folder (not the best practice), we may have errors generated by this class.


The patch was changed by Magento silently. Here shown with patch for Magento On first download i got file


A few days later i got following file


Diff shows that the former file contains files from Magento Enterprise Edition which contain the wrong license "Magento Enterprise Edition End User License Agreement". This has been corrected to "Open Software License (OSL 3.0)".


Same exact error as Tyler, on Magento Patch PATCH_SUPEE-10570_CE_v1.9.2.4_v1-2018-02-28-04-53-53.sh

checking file lib/Zend/Mail/Transport/Sendmail.php
Hunk #1 FAILED at 119.
Hunk #2 FAILED at 129.
2 out of 2 hunks FAILED
  • check you have installed the previous patch. particular 9767 patch – Rama Chandran M Mar 1 '18 at 7:17
  • Ran a check on www.magereport.com and it confirmed that all patches were installed.9767 as well. – Roy Toledo Mar 1 '18 at 17:04
  • I will check and provide ans – Rama Chandran M Mar 1 '18 at 17:20
  • 1
    @royToledo Make sure that you've applied patch SUPEE-9652 as well – Tyler V. Mar 1 '18 at 22:21

If you have some patch detection tool you probably need to modify the detection of SUPEE-9562 because SUPEE-10570 modifies the same file:


You may get following error

Hunk #3 FAILED at 17 after line

checking file app/code/core/Enterprise/Cms/Block/Adminhtml/Cms/Page/Edit/Tab/Hierarchy.php

It happened for me on Magento version. It happened because SUPEE-6285 patch was not applied.

Not the answer you're looking for? Browse other questions tagged or ask your own question.