A new security patch is out for Magento 1, addressing 16 APPSEC issues: https://magento.com/security/patches/supee-9767

Seven of the vulnerabilities score 8.0 or higher for CVSSv3 Severity, and they are being exploited in the wild, so this is a critical patch. Sites can apply SUPEE-9767, or update to the new release CE 1.9.3.3 / EE 1.14.3.3.

What are common issues or pitfalls to watch out for when applying SUPEE-9767?


UPDATE 2017-07-12:

Magento has released SUPEE-9767 V2 and CE 1.9.3.4 to address many of the issues from the initial patch. If you applied V1, you should revert and then apply V2. If you haven't patched yet, just apply V2, and most of the issues brought up here will not be relevant.

  • "Seven of the vulnerabilities score 8.0 or higher for CVSSv3 Severity, and they are being exploited in the wild, so this is a critical patch." I just wanted to check, the "attacker" needs to get into admin to do any of these exploits? – PaddyD Jun 1 '17 at 10:08
  • 3
    yes, you must have admin access to exploit... – MagenX Jun 1 '17 at 10:57
  • The patch doesn't seem to stop the common brute-force endpoint though, (i.e. /rss/order/new) which seems to be the most common way botters are attempting to gain access to admin areas? – Ricky Odin Matthews Jun 26 '17 at 10:59
  • 1
    I use this for RSS @RickyOdinMatthews in .htaccess RewriteRule ^/?(index.phprss|index.php/rss/catalog|index.php/rss/order|rss/catalog|rss/order).*$ /no-route [R=301,L,NC] – Richard Feraro Jul 13 '17 at 2:16
  • @RichardFeraro I use nginx, but already use a similar solution. I've noticed bots typically scan for, and brute force these endpoints though. – Ricky Odin Matthews Jul 14 '17 at 10:06

23 Answers 23

up vote 95 down vote accepted

Here's my overview of the patch after digging into it

TIME SAVER : Experius provides a patch helper that helps you finding the files in custom themes, custom modules or local overwrites that also might need to be patched manually, you can find it here: https://github.com/experius/Magento-1-Experius-Patch-Helper#magento

Checkout form keys

As said in the other post, this patch adds form keys to the following forms:

Shipping cart form:

app/design/frontend/<package>/<theme>/template/checkout/cart/shipping.phtml

Multishipping billing checkout form:

app/design/frontend/<package>/<theme>/template/checkout/multishipping/billing.phtml

Multishipping shipping checkout form:

app/design/frontend/<package>/<theme>/template/checkout/multishipping/shipping.phtml

Multishipping addresses checkout form:

app/design/frontend/<package>/<theme>/template/checkout/multishipping/addresses.phtml

Billing checkout form:

app/design/frontend/<package>/<theme>/template/checkout/onepage/billing.phtml

Shipping checkout form:

app/design/frontend/<package>/<theme>/template/checkout/onepage/shipping.phtml

Payment checkout form:

app/design/frontend/<package>/<theme>/template/checkout/onepage/payment.phtml

Shipping method checkout form:

app/design/frontend/<package>/<theme>/template/checkout/onepage/shipping_method.phtml

Persistent Billing checkout form:

app/design/frontend/<package>/<theme>/template/persistent/checkout/onepage/billing.phtml

On top of that the following JS files have been updated to be compatible with that change:

  • js/varien/payment.js
  • skin/frontend/base/default/js/opcheckout.js

What to do:

If you're using with custom versions of those templates you'll have to update them by adding the following code into them:

<?php echo $this->getBlockHtml('formkey') ?>

If you're using a 3rd party checkout module, you'll have to get in touch with them so they can provide an updated version of their module.

Also if you have custom versions of the previously listed JS files, you'll have to update them too.

SAVE YOUR TIME:

Fabian Schmengler wrote a nice little script to update all those things for you, you can find it here:

https://gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b

IMPORTANT NOTE : the checkout formkey validation can be changed in the backend via a new config field under System > Configuration > Admin > Security > Enable Form Key Validation On Checkout . THIS IS NOT ENABLED BY DEFAULT so you'll have to enable it to benefit from this security feature!!! Note that you'll get a notice in the backend if it's not enabled.

Image Upload callback

The image gallery controller has been updated to add a validation callback.

What to do

If you're using a custom module that does image upload with code that looks like this:

        $uploader = new Mage_Core_Model_File_Uploader('image');
        $uploader->setAllowedExtensions(array('jpg','jpeg','gif','png'));
        $uploader->addValidateCallback('catalog_product_image',
            Mage::helper('catalog/image'), 'validateUploadFile');
        $uploader->setAllowRenameFiles(true);
        $uploader->setFilesDispersion(true);

I strongly suggest you update that code by adding the following piece after it:

        $uploader->addValidateCallback(
            Mage_Core_Model_File_Validator_Image::NAME,
            Mage::getModel('core/file_validator_image'),
            'validate'
        );

Symlinks

This patch removes the system configuration field that allows you to allow template symlinks in the backend. It used to be under System > Configuration > Developer > Template > Allow Symlinks . Now the entire Template section is gone.

On top of that, that field is now disabled by default via the app/etc/config.xml

The funny thing here is that you'll get a notice in the backend if you have that configuration field enabled prior to the patch but you won't be able to disable it as the field is gone.

Only way of doing it is by running the following SQL query

UPDATE core_config_data SET value = 0 WHERE path = "dev/template/allow_symlink";

Clarification

First I strongly suggest you check those two posts that will help you understand the purpose of that Symlink modification:

This modification is really about calling uploadable content (like images) via template directives.

The issue related to symlinks is exploitable only with admin access and Magento added some more protection around image uploads as well.

Please note that they are some protections against known way to exploit it in addition to the setting itself.

What to do: if like me, you're using modman or composer with template symlinks, you're gonna face some issues. I'm still trying to find out what's the best thing to do here apart from dealing with SQL queries.

Main post regarding this issue: SUPEE-9767, modman and symlinks

List of possible issues

V2 was released since that original post. Don't forget to upgrade

Bugs

The word 'confirmed' is used for confirmed bugs. If it's not there, that means it could be a bug but hasn't been confirmed yet.

Hunk Failed Issues

Note that all those issues could be simply because you modified the original file, to double check that this is not the case:

  • Backup the file where you get the Hunk Failed error
  • Download the original file from your Magento version
  • Compare both files

If files are different you'll have to apply the patch with the original file then reapply your custom changes the clean way such as:

  • custom template in a custom theme folder
  • local.xml
  • app/code/local file

If files are not different then this is either a permission issue or a "bug" in the patch.

Issue1: form_key invalid at checkout onepage

Magento add form_key at most of the forms.

if you have using default onepage and using custom theme, then you will start getting **form_key issue at checkout each step **;

you should add form key at <?php echo $this->getBlockHtml('formkey') ?>

to form of each checkout step files if below files exits,

  • app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/billing.phtml
  • app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/payment.phtml
  • app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/shipping.phtml

  • app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/shipping_method.phtml

if the template files are calling from base theme then it does not create problem.Because patch will automatically update those files.

Also note: <?php echo $this->getBlockHtml('formkey') ?> should always inside of form tag

 <form action="" .....>
     <fieldset>
      .......
       <?php echo $this->getBlockHtml('formkey') ?>
     </fieldset>
 </form>

** If you using Magento multi-shipping checkout then need to done at

below files:

Issue2: form_key issue to Shipping estimation form at cart page:

Add form_key at estimates shipping form at cart page

Then must add form key <?php echo $this->getBlockHtml('formkey') ?>

at app/design/frontend/{Your_Package}/{YOUR_THEME]/template/checkout/cart/shipping.phtml

Issue3: Magento onepage checkout opcheckout.js error

If you using default onepage checkout and have opcheckout.js then should check

if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {is available at opcheckout.js

If not exits then replace

if (elements[i].name=='payment[method]') {

with

if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {

For case of issue1,issue2, issue3, Issue can fix easily by using @FabianSchmengler 's script add-checkout-form-key.sh. It will fix the issue on your receptive theme files

Issue4: Invalid form key after customer login when Mage_Customer_Model_Session rewrite

If Mage_Customer_Model_Session class rewrite or have called from

app/code/local/Mage/Customer/Model/Session.php then you may be get form_key issue when we set a customer for the session using setCustomerAsLoggedIn() /or after a customer set at session .

In this case, you must be add

Mage::getSingleton('core/session')->renewFormKey();

at setCustomerAsLoggedIn() before call of

Mage::dispatchEvent('customer_login', array('customer'=>$customer));

  public function setCustomerAsLoggedIn($customer)
    {
        $this->setCustomer($customer);
        $this->renewSession();
        // add this  for patch -9767
        Mage::getSingleton('core/session')->renewFormKey();
       // end this for patch 9767
        Mage::dispatchEvent('customer_login', array('customer'=>$customer));
        return $this;
    }

Issue5: Form_key issue after logout

After logout customer from session, you may be start session issue if If Mage_Customer_Model_Session class rewrite or have called from

app/code/local/Mage/Customer/Model/Session.php

In those same need for this case:

   protected function _logout()
    {
        $this->setId(null);
        $this->setCustomerGroupId(Mage_Customer_Model_Group::NOT_LOGGED_IN_ID);
        $this->getCookie()->delete($this->getSessionName());
// add this  for patch -9767
Mage::getSingleton('core/session')->renewFormKey();
        return $this;
    }

Recommendation:

Recommendation1: For fixed the issue of supee-9767, you can use the patch https://github.com/experius/Magento-1-Experius-Patch-Helper

This is one best solution for now.

Note, before do that I am strongly recommended to take files and database backup or full system backup.


Recommendation2: Use patch feature on your ONESTEP CHECKOUT

We know that patch supee-9767 release for security purpose, the if you using ONESTEP CHECKOUT then you should add form_key validation to SAVE action of your onestep checkout controller.

Suppose for save shipping method details, your onestep checkout have using saveShippingmethod() Then on this you should add

if ($this->isFormkeyValidationOnCheckoutEnabled() && !$this->_validateFormKey()) {
           return;
      }

Also on youmust add form key <?php echo $this->getBlockHtml('formkey') ?> at your onestep checkout phtml files respective section

Some related link

https://peterocallaghan.co.uk/2017/06/appsec-1281-dangerous-symlinks/

  • 1
    Nice and quick one-liner to find your custom template files for the form key in checkout; find app/design/frontend | grep -E "checkout/onepage/(billing|payment|shipping|shipping_method).phtml" | grep -v "base/default" | grep -v "rwd/default" – Peter Jaap Blaakmeer Jun 1 '17 at 8:49
  • 6
    or update them immediately with a slightly longer one liner: gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b – Fabian Schmengler Jun 1 '17 at 8:53
  • that is @FabianSchmengler magic !!! :) – Amit Bera Jun 1 '17 at 8:54
  • @FabianSchmengler awesome, that worked! – Peter Jaap Blaakmeer Jun 1 '17 at 9:08
  • 1
    @AmitBera FYI: some checkout plugins use AJAX to submit billing / shipping /etc. I just had to patch one. Easy way of doing it is putting <script> var formKey = "<?php echo Mage::getSingleton('core/session')->getFormKey(); ?>"; </script> into head of theme. Then you can add form_key: formKey as a parameter to AJAX submission. Of course test the forms after to confirm submission of the new parameter and edit Controller to handle it like you mentioned in your post. – Kalvin Klien Jun 2 '17 at 22:28

Based on my first pass at review of the patch file...

  • A new setting admin/security/validate_formkey_checkout has been added. When turned on, checkout forms are checked for presence of a form key. If the template files are overriden in the theme they'll need to be updated there. This setting seems to be off by default
  • Symlinks seem to be disallowed by default (in app/etc/config.xml). Also, the ability to allow them seems to have been removed from the admin configuration. However, if your site previously explicitly enabled symlinks, the setting would be saved in the database, overriding this change.
  • You need to clear both the cache AND the full page cache when applying this patch. The design exceptions are saved in a format the is incompatible with decoding. You'll see an error like this "Decoding failed: Syntax error" if you don't flush page cache.
  • 1
    You could also just go in with a hex editor and add it to the database yourself, but that may be a little much for most people – cat May 31 '17 at 20:20
  • 1
    If some of you are using CDN, like cloudflare, make sure to purge cache. I tried going throigh checkout with CDN being active and it would no go past Payments page. The moment I purged cache and enabled Development mode, all went good. – Icon May 31 '17 at 23:08

Below base/default file affected with this patch, if this files were in your theme then please make changes accordingly

app/design/frontend/base/default/template/checkout/cart/shipping.phtml

app/design/frontend/base/default/template/checkout/multishipping/billing.phtml

app/design/frontend/base/default/template/checkout/multishipping/shipping.phtml

app/design/frontend/base/default/template/checkout/onepage/billing.phtml

app/design/frontend/base/default/template/checkout/onepage/payment.phtml

app/design/frontend/base/default/template/checkout/onepage/shipping.phtml

app/design/frontend/base/default/template/checkout/onepage/shipping_method.phtml

app/design/frontend/base/default/template/persistent/checkout/onepage/billing.phtml

in all above phtml files below form key line is added so please add this line in your respective phtml file.

 <?php echo $this->getBlockHtml('formkey') ?>

For above issue @fabian created a script which will add form key even in your theme file

https://gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b

after applying security patch if you get error for form key you can apply this patch , for applying this patch process is same as security patch just

  sh filename.sh

and one base/default change in Js file

  skin/frontend/base/default/js/opcheckout.js

so if this js file is loading from your theme then do below steps

remove blow line

 if (elements[i].name=='payment[method]') {

and add below line instead of above

 if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {

EDIT

And if you are using any checkout extension which overrides below files then add form key line in checkout extension's phtml file.

EDIT2 -- Issues

1) Error at saveBillingAction() or getting form key null Or Form Key issue : Patch 9767 getting invalid Form Key

2) Hunk #1 FAILED at 225. 1 out of 1 hunk FAILED -- saving rejects to file app/design/frontend/enterprise/default/template/persistent/checkout/onepage/billing.phtml : SUPEE-9767 - Hunk #1 FAILED at 225. 1 out of 1 hunk FAILED

3) saving rejects to file app/code/core/Enterprise/PageCache/Model/Observer.php.rej : SUPEE-9767 ERROR: Patch can't be applied/reverted successfully

4) SUPEE-9767, modman and symlinks : SUPEE-9767, modman and symlinks

5) app/design/frontend/rwd/default/layout/page.xml Hunk #1 FAILED at 36. Hunk #2 FAILED at 54. 2 out of 2 hunks FAILED : SUPEE-9767 Error

6) 1 out of 1 hunk FAILED -- saving rejects to file app/code/core/Mage/Sales/Model/Quote/Item.php : Magento 1.9.2.2 SUPEE-9767 Patch ERROR

7) onestep checkout error (again this is the form key issue) : SUPEE-9767 Magento CE 1.9.3.3 Onestep Checkout not working with Form Key Validation On Checkout enabled

8) one step checkout customer registration issue : SUPEE-9767 Patch/CE 1.9.3.3 - One Page Checkout - Customer Registration issue

9) app/code/core/Mage/Core/Model/File/Validator/Image.php : Magento SUPEE 9697 1.9.2.2 fails at Image.php

  • 1
    Version 2 of the patch should be available soon. Bugs should be fixed. – Icon Jun 2 '17 at 4:07
  • 1
    @icon waiting for the v2 – Murtuza Zabuawala Jun 2 '17 at 4:08

Note that Symlinks have always been disabled by default on new Magento installations admin YES/NO config values default to 'NO'. The update now explicitly disables symlinks in config.xml and as an extra precaution also removes the template section from admin->developer which contained the configuration option.

This will not affect your current symlink settings, if you manually enabled symlinks prior to 1.9.3.2 they will stay enabled, although you cannot see the setting anymore in admin.

Users using modman to manage Magento 1.x modules should ensure that they do not disable symlinks as this will disable the modman modules.

Responsible admins can enable the symlink admin section again by looking for the diff changes to the template section in app/code/core/Mage/Core/etc/system.xml and adding the section to your system.xml at around line 600. Or double check symlinks are still enabled with

n98-magerun.phar config:dump | grep symlink

Here is the diff file for magento1933 and magento1932 to assist with identifying changes in the default theme which may affect your custom/extended themes.

diff -r magento1933 magento1932 > https://pastebin.com/ADzMBLhr

Issue: Using php7 sometimes throws the following error:

Decoding failed: Syntax error

#0 /______/app/code/core/Enterprise/PageCache/Model/Observer.php(179): Zend_Json::decode('')
#1 /______/app/code/core/Enterprise/PageCache/Model/Observer.php(215): Enterprise_PageCache_Model_Observer->_loadDesignExceptions()
#2 /______/app/code/core/Enterprise/PageCache/Model/Observer.php(125): Enterprise_PageCache_Model_Observer->_saveDesignException()
#3 /______/app/code/core/Mage/Core/Model/App.php(1358): Enterprise_PageCache_Model_Observer->cacheResponse(Object(Varien_Event_Observer))
#4 /______/app/code/core/Mage/Core/Model/App.php(1337): Mage_Core_Model_App->_callObserverMethod(Object({custom extensio}_Model_Rewrite_PageCache_Observer), 'cacheResponse', Object(Varien_Event_Observer))
#5 /______/app/Mage.php(456): Mage_Core_Model_App->dispatchEvent('controller_fron...', Array)
#6 /______/app/code/core/Mage/Core/Controller/Varien/Front.php(182): Mage::dispatchEvent('controller_fron...', Array)
#7 /______/app/code/core/Mage/Core/Model/App.php(365): Mage_Core_Controller_Varien_Front->dispatch()
#8 /______/app/Mage.php(691): Mage_Core_Model_App->run(Array)
#9 /______/index.php(105): Mage::run('brandfield_nl', 'store')
#10 {main}

Its pretty sure that Zend version has to do something with it. A fast fix is this but is for sure not correct:

-> app/code/core/Enterprise/PageCache/Model/Observer.php:244 replace it with:

    if ($cachedSslOffloaderHeader !== false) {
        $cachedSslOffloaderHeader = trim(@Zend_Json::decode($cachedSslOffloaderHeader));
    }

-> and app/code/core/Enterprise/PageCache/Model/Observer.php:177 with:

    if ($exceptions !== false) {
        $exceptions = Zend_Json::decode($exceptions);
    }

Of course create an addon to rewrite this. But I am sure there is something better to be done here.

UPDATE (Better solution)

-> Go to: lib/Zend/Json.php and after the line 76 add this:

    if ((float)phpversion() >= 7.0
        && empty($encodedValue)
    ) {
        return null;
    }

Create your extension to override it and dont edit the core file.

  • Cache was cleared completely. This is not the same issue. – folektoras133 Jun 1 '17 at 15:12
  • 2
    We hit this same issue - reverting app/code/core/Enterprise/PageCache/Model/Observer.php removed the problem, but obviously that is not the correct fix, just prevention a:5:{i:0;s:29:"Decoding failed: Syntax error";i:1;s:1376:"#0 app/code/core/Enterprise/PageCache/Model/Observer.php(177): Zend_Json::decode('a:0:{}') – Judder Jun 1 '17 at 15:50

Issue: Dynamic code or css disables form key input element at checkout

An issue I have seen is where dynamic code (paypal plus) in the one page checkout process overwrites the fieldset element in the one step payment method form html - deleting or disabling (with css) the hidden form_key element.

The fix is to ensure the formkey element is not being disabled by any dynamic code or css. Moving the formkey code outside of the fieldset element may also help

<form>
    <?php echo $this->getBlockHtml('formkey') ?>
    <fieldset>
        <?php echo $this->getChildHtml('methods') ?>
    </fieldset>
</form>

You can easily confirm if the form_key is being detected and sent to the one page controller by inspecting the ajax network requests in your browser as you move through the checkout methods, each method should include the form key in the ajax form data, if the form key is not there but the Magento source code has been patched check for external code affecting the form key element, i.e. css or dynamic client side changes.

enter image description here

  • 2
    This bit of fix didn't seem to work for me with EE. I found that the file app/design/frontend/[package]/[theme]/template/giftcardaccount/onepage/payment/scripts.phtml needed to be updated as well: Lines 35-38 need to be updated to include || elements[i].name == 'form_key' along with the other selectors to keep the form_key form field being disabled. – g-man1066 Jul 20 '17 at 16:47
  • Thanks g-man1066! That was exactly the problem I was having. – grafikchaos Sep 6 '17 at 19:15

Issue: Missing fixes in head-simple.phtml

app/design/adminhtml/default/default/template/oauth/authorize/head-simple.phtml

need the same fixes as

app/design/adminhtml/default/default/template/page/head.phtml

ISSUE: Customer Registration Fails when using generic Magento 5-step checkout.

This issue is only presented when we ENABLE form key authentication. Version used: 1.7.0.2, but looks like someone has posted that same issue occurs on 1.9.3 version too. SUPEE-9767 Patch/CE 1.9.3.3 - One Page Checkout - Customer Registration issue

When Go to checkout, we are presented with 2 options: CHECKOUT AS A GUEST OR REGISTER Once click "Register", and fill-out the form along with password, you proceed throguh all steps and complete the order. Order gets placed, BUT customer never gets registered in magento. It looks like Guest placed order.

When I went back and Disabled form key authentication, and tried placing order while registering as a customer, it got placed without any problems and the customer got registered in the backend.

UPDATE 13/07/2017 [ THE ISSUE IS FIXED ]

Magento team has released SUPEE-9767 V2 in this version of the patch the problem with transparent gif's and png's is fixed.

You should revert all changes to the file that was discussed in this thread. Then revert the applied V1 patch and finally apply the new version V2.


PRE - SUPEE-9767 V2

Please don't use the code discussed bellow instead apply V2 of the patch the problem discussed bellow is already fixed in this version

If somebody experience problem with transparent png's that when uploaded from the admin panel the background becomes black. (On the products) is in relation to the Image Upload callback introduced in:

app/code/core/Mage/Adminhtml/controllers/Catalog/Product/GalleryController.php

In the moment I am not sure what exactly is causing this behaviour but I am trying to figure it out I can confirm that when the callback is removed the strange behaviour is going away.

enter image description here

UPDATE

Ok, I found the function that is also updated from SUPEE-9767 this is actually breaking the transparency in the png's a copy of the original image is created without transparency.

+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
@@ -87,10 +87,33 @@ public function setAllowedImageTypes(array $imageFileExtensions = array())
      */
     public function validate($filePath)
     {
-        $fileInfo = getimagesize($filePath);
-        if (is_array($fileInfo) and isset($fileInfo[2])) {
-            if ($this->isImageType($fileInfo[2])) {
-                return null;
+        list($imageWidth, $imageHeight, $fileType) = getimagesize($filePath);
+        if ($fileType) {
+            if ($this->isImageType($fileType)) {
+                //replace tmp image with re-sampled copy to exclude images with malicious data
+                $image = imagecreatefromstring(file_get_contents($filePath));
+                if ($image !== false) {
+                    $img = imagecreatetruecolor($imageWidth, $imageHeight);
+                    imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
+                    switch ($fileType) {
+                        case IMAGETYPE_GIF:
+                            imagegif($img, $filePath);
+                            break;
+                        case IMAGETYPE_JPEG:
+                            imagejpeg($img, $filePath, 100);
+                            break;
+                        case IMAGETYPE_PNG:
+                            imagepng($img, $filePath);
+                            break;
+                        default:
+                            return;
+                    }
+                    imagedestroy($img);
+                    imagedestroy($image);
+                    return null;
+                } else {
+                    throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid image.'));
+                }
             }
         }
         throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid MIME type.'));

UPDATE

Here is updated version of the function to preserve the png transparency

  imagealphablending($img, false);
  imagesavealpha($img, true);

these two lines need to be added to the patch. Update the function in app/code/core/Mage/Core/Model/File/Validator/Image.php

/**
 * Validation callback for checking is file is image
 *
 * @param  string $filePath Path to temporary uploaded file
 * @return null
 * @throws Mage_Core_Exception
 */
public function validate($filePath)
{
    list($imageWidth, $imageHeight, $fileType) = getimagesize($filePath);
    if ($fileType) {
        if ($this->isImageType($fileType)) {
            //replace tmp image with re-sampled copy to exclude images with malicious data
            $image = imagecreatefromstring(file_get_contents($filePath));
            if ($image !== false) {
                $img = imagecreatetruecolor($imageWidth, $imageHeight);
                imagealphablending($img, false);
                imagesavealpha($img, true);  
                imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                switch ($fileType) {
                    case IMAGETYPE_GIF:
                        imagegif($img, $filePath);
                        break;
                    case IMAGETYPE_JPEG:
                        imagejpeg($img, $filePath, 100);
                        break;
                    case IMAGETYPE_PNG:
                        imagepng($img, $filePath);
                        break;
                    default:
                        return;
                }
                imagedestroy($img);
                imagedestroy($image);
                return null;
            } else {
                throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid image.'));
            }
        }
    }
    throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid MIME type.'));
}

UPDATE 23/06/17

This updated version of the function fixes the PNG and the GIF transparency.

    /**
 * Validation callback for checking is file is image
 *
 * @param  string $filePath Path to temporary uploaded file
 * @return null
 * @throws Mage_Core_Exception
 */
public function validate($filePath)
{
    list($imageWidth, $imageHeight, $fileType) = getimagesize($filePath);
    if ($fileType) {
        if ($this->isImageType($fileType)) {
            //replace tmp image with re-sampled copy to exclude images with malicious data
            $image = imagecreatefromstring(file_get_contents($filePath));
            if ($image !== false) {
                $img = imagecreatetruecolor($imageWidth, $imageHeight);
                switch ($fileType) {
                    case IMAGETYPE_GIF:
                        imagecolortransparent($img, imagecolorallocatealpha($img, 0, 0, 0, 127));
                        imagealphablending($img, false);
                        imagesavealpha($img, true);
                        imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                        imagegif($img, $filePath);
                        break;
                    case IMAGETYPE_JPEG:
                        imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                        imagejpeg($img, $filePath, 100);
                        break;
                    case IMAGETYPE_PNG:
                        imagealphablending($img, false);
                        imagesavealpha($img, true);  
                        imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                        imagepng($img, $filePath);
                        break;
                    default:
                        return;
                }
                imagedestroy($img);
                imagedestroy($image);
                return null;
            } else {
                throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid image.'));
            }
        }
    }
    throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid MIME type.'));
}
  • 1
    This solved my problem in a Magento 1.7 installation. Thanks! – Tjitse Jun 9 '17 at 12:15
  • No problem Tjitse just make a note of this change in case the Magento team don't fix the patch you will have to revert it when you doing the next patch. I have submitted the problem to the community at bugcrowd.com hope they will introduce patch fix soon. – Daniel Yovchev Jun 9 '17 at 12:52
  • this does fix it for pngs, but not for transparent gif files. gif files need slightly different handling using imagecolortransparent – alternize Jun 15 '17 at 18:04
  • Thanks for pointing this out alternize see the updated function that fixes the gif transparency also. – Daniel Yovchev Jun 23 '17 at 9:52

Issue: Allow symlink notification not shown to admins

The symlink notification will not be shown in the admin notification area as it is not included in the <block type="core/text_list" name="notifications" as="notifications">

The patch for both CE and EE below:

--- app/design/adminhtml/default/default/layout/main.xml
+++ app/design/adminhtml/default/default/layout/main.xml
@@ -119,7 +119,8 @@ Default layout, loads most of the pages
<block type="adminhtml/cache_notifications" name="cache_notifications" template="system/cache/notifications.phtml"></block>
<block type="adminhtml/notification_survey" name="notification_survey" template="notification/survey.phtml"/>
<block type="adminhtml/notification_security" name="notification_security" as="notification_security" template="notification/security.phtml"></block>
-            </block>
+                <block type="adminhtml/checkout_formkey" name="checkout_formkey" as="checkout_formkey" template="notification/formkey.phtml"/></block>
+                <block type="adminhtml/notification_symlink" name="notification_symlink" template="notification/symlink.phtml"/>
<block type="adminhtml/widget_breadcrumbs" name="breadcrumbs" as="breadcrumbs"></block>
<!--<update handle="formkey"/> this won't work, see the try/catch and a jammed exception in Mage_Core_Model_Layout::createBlock() -->

The issue is </block> is at the end of checkout_formkey (which is self-terminating) and therefore closes the parent notifications. This causes the notification_symlink to not be included in the core/text_list and not be rendered.

  • This is not really an issue, the notification has been removed because symlinks have been explicitly disabled and the symlink config section removed. It's not possible to manually change the symlink value in admin in v1933 so therefore showing an admin notification is rather pointless. The issue will be for new 1933 installations where users who require symlinks i.e. for modman can no longer manually enable it. One could infer that Magento doesn't expect any new 1.x installations... – paj Jun 1 '17 at 8:57
  • I disagree, this patch does not explicitly disable the config if it is already set - it only disables it if it is not already set. Therefore if an instance has dev/template/allow_symlink set to yes in the DB/local.xml prior to this patch and they apply the patch they SHOULD receive the warning that symlinks are allowed as they are potentially vulnerable. – mwylde Jun 1 '17 at 11:00
  • I see your point, and you are correct. But for a normal user what would they then do - it's impossible to manually disable it from admin as the config option has been removed. It's a bit of a catch 22 situation... – paj Jun 1 '17 at 11:04

Little tip for #patchday; after copying 1.9.3.3 over your install, run git diff -w --stat | grep -v " 2 +" | grep -v " 0" to quickly see bigger changes in files.

Issue: EE shipping template not patched

I patched an EE 1.13.1.0 install, and the enterprise shipping template (app/design/frontend/enterprise/default/template/checkout/onepage/shipping.phtml) did not have the formkey added, but the billing and payment templates did.

app/design/frontend/base/default/template/checkout/onepage/shipping.phtml was patched.

  • I also needed (for EE 1.14.2) to add the form_key to /app/design/frontend/enterprise/default/template... .../checkout/cart/coupon.phtml, .../giftcardaccount/cart/block.phtml .../giftcardaccount/cart/check.phtml – g-man1066 Jul 20 '17 at 17:07

There is an issue with Magento EE versions that are patched with SUPEE-9767 (so not with upgrades to 1.14.3.3). The form key on that page will be cached. So when I flush my cache and then go to a product page and make sure the page is completely cached (refresh a couple of times), I should be able to add that product to my cart.

Now, when I open a different browser (or incognito mode), open the same page and try to add the product to the cart again. The product will not be added to cart, because of the form key. Now when you flush the cache again, the product can be added to the cart again.

Thanks to Jasper Zeinstra

For developers using Magento Composer Intaller, you can change the deployment strategy to Copy instead of Symlink. You can also configure to append the module files to your .gitignore, so your repository will stay clean.

https://github.com/Cotya/magento-composer-installer/blob/master/doc/Deploy.md#deploy-per-copy-instead-of-symlink

{ "extra":{ "magento-root-dir": "htdocs/", "magento-deploystrategy": "copy", "auto-append-gitignore": true } }

  • We found out that with copy "magento-force": true, becomes important – Jeroen Jun 2 '17 at 10:19

I had an issue on EE 1.14.2.2 with FPC enabled and this patch applied.

Intermittently users could not add to cart.

Explanation and fix here: SUPEE-9767 issue : Add to cart issue, Enterprise Full Page Cache

Issue: Patch was working on vanilla Magento 1.7.0.0 [edited]

During the testing of our patch script we discovered a problem in the patch for Magento 1.7.0.0. Don't know if anybody still uses it, but anyhow it is a problem in SUPEE-9767. We used a vanilla install and we installed all previous patches first.

Patch file used: PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh The patch file does work for Magento 1.7.0.1 and 1.7.0.2

Summary of problems:

ERROR: Patch can't be applied/reverted successfully.
...
can't find file to patch at input line 377
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git app/code/core/Mage/Core/Model/File/Validator/Image.php app/code/core/Mage/Core/Model/File/Validator/Image.php
|index 7f7b9d0..cbbcbb1 100644
|--- app/code/core/Mage/Core/Model/File/Validator/Image.php
|+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
2 out of 2 hunks ignored
...
checking file app/code/core/Mage/Sales/Model/Quote/Item.php
Hunk #1 FAILED at 502.
1 out of 1 hunk FAILED
...

For the record, this on on the 1.7.0.0 we tried the patch on:

$ grep SUPEE app/etc/applied.patches.list
2017-06-01 12:59:49 UTC | SUPEE-2677 | EE_1.13.0.2 | v2 | d20e6763cd0df70c4ac6e418c9775a1ff0f2618f | Tue Jan 14 17:49:25 2014 +0200 | v1.13.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-2629 | EE_1.12.0.0 | v1 | 5de775cf535e137b0b099d8066bd5b3a81f7ec4c | Wed Dec 11 16:50:40 2013 +0200 | v1.12.0.0..HEAD
-e 2017-06-01 12:59:49 UTC | SUPEE-1049 | EE-1.12.0.2 | v1 | 6d06f286f461562fa6d6573349f1491f7bf89859 | Wed Feb 13 17:46:13 2013 -0800 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-1868-1-12-0-2 | EE_1.12.0.2 | v1 | 2148b1b6be28a9bad0bec9a4aecc63ed318dd201 | Fri Jul 26 13:20:27 2013 -0700 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-4334-v1.11.1.0 | EE_1.11.1.0 | v1 | 40f5a2e4db9ca53dc6a8e62eb0c728fd63b1157e | Wed Sep 10 10:42:31 2014 -0700 | ef80f7bff749c941b4d1736cc2b502888e7540c9
2017-06-01 12:59:49 UTC | SUPEE-5345 | EE_1.12.0.2 | v1 | 2d36f61cf684ed26286b6d10307fcb99dd47ff02 | Thu Feb 5 19:39:01 2015 +0200 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-5994 | CE_1.6.0.0 | v1 | _ | n/a | SUPEE-5994_CE_1.6.0.0_v1.patch
2017-06-01 12:59:49 UTC | SUPEE-6237 | EE_1.14.2.0 | v1 | 8b216c42e2e5d2cb5d8e500fcb6690abede9df52 | Fri Jun 12 13:39:59 2015 +0300 | v1.14.2.0..HEAD
2017-06-01 12:59:49 UTC | SUPEE-6285 | CE_1.7.0.2 | v1 | 84749c91e14543e1f96af30e86efdf29f4562c98 | Tue Jun 23 09:48:07 2015 +0300 | c6e6cee8eb..84749c91e1
2017-06-01 12:59:49 UTC | SUPEE-6482 | CE_1.8.0.0 | v1 |  | Tue Jul 14 14:17:04 2015 +0300 |
2017-06-01 12:59:49 UTC | SUPEE-6788 | CE_1.7.0.1 | v1 | 04d237d56b116989e46839c41691585d927f99db | Fri Oct 23 13:52:50 2015 +0300 | f69136a
2017-06-01 12:59:49 UTC | SUPEE-7616 | CE_1.7.0.2-CE_1.4.2.0 | v1 | a16c51e3679c3f19de6c3207b7a42daa7f9227fc | Fri Dec 18 12:42:03 2015 +0200 | 3617437b6da11be812fcca85f4e6ecbd8b8dc94c..a16c51e3679c3f19de6c3207b7a42daa7f9227fc
2017-06-01 12:59:50 UTC | SUPEE-8788 | CE_1.7.0.0 | v2 | 6b5ef4fc5b09af74d0fd401440948d0a54dd203d | Fri Oct 14 19:27:22 2016 +0300 | 84fa3dd598466fa5c482965a3f8e5395af33bf9d
2017-06-01 12:59:50 UTC | SUPEE-8967 | EE_1.13.1.0 | v1 | 1fa53e9533f6f3a16f24d9b64dabef0ab7f965d7 | Thu Aug 18 16:32:48 2016 +0300 | 97d160644..1fa53e9533
2017-06-01 12:59:50 UTC | SUPEE-9652 | EE_1.14.3.1 | v1 | 4038f0785d828794083f53f10c01aaa6af403523 | Tue Jan 24 15:03:12 2017 +0200 | 9586981e6ca8b255014b242d50b68b88525b0754..4038f0785d828794083f53f10c01aaa6af403523
  • 4
    If you are missing that file, you most likely have not applied security patch SUPEE-7405. – Ryan Hoerr Jun 1 '17 at 13:28
  • @RyanHoerr you are right, SUPEE-7405 was skipped because the official file PATCH_SUPEE-7405_CE_1.7.0.2_v1-2016-01-20-04-58-44.sh does not work for 1.7.0.0. I created a fixed version of the file. If anyone needs it, send me a message. – Jeroen Vermeulen - MageHost Jun 1 '17 at 19:38

I just had to revert this patch due to some strange behavior. For whatever reason, certain users could not add certain items to their cart.

I'm assuming it has something to do with old quotes colliding with the current quote for that customer. I verified this issue by logging in as the user to make sure it wasn't just a 1D10T.

It's been an issue since I took that patch life last Friday. We are using 1.14.2.4. We are heavily modified so it might work fine for other users. Just a warning!

  • That is correct, patch does break add to cart action for EE version of the Magento. Basically, the issue occurs due to PageCache module having one version of form_key generation logic, while the session has its own. When FPC has the cached version of the requested page, but needs to regenerate minicart, session is triggered which regenerates form_key at the same time FPC save is called which generates its own form_key. At that point session value of form_key differs from one stored in customer cookie (used in FPC processor) so you are getting invalid key on add to cart controller. – Stjepan Jun 7 '17 at 12:52
  • I'm also encountering this issue. I'll let you know if I find a fix. – cmtickle Jun 7 '17 at 18:42
  • I resolved this issue, explanation here: magento.stackexchange.com/questions/177942/… – cmtickle Jun 7 '17 at 21:35
  • Does anyone know if this is resolved in SUPEE-9767 v2? – Disciple of One Aug 22 '17 at 14:58

Issue: Infinite redirect loop on 1.6.0.0

Quick Fix

Find the below lines inside the method protected function _checkBaseUrl($request) in the file app/code/core/Mage/Core/Controller/Varien/Front.php

 if (isset($uri['scheme']) && $uri['scheme'] != $request->getScheme()
        || isset($uri['host']) && $uri['host'] != $request->getHttpHost()
        || isset($uri['path']) && strpos($requestUri, $uri['path']) === false
 ) {  

Change these lines to

 if (isset($uri['host']) && $uri['host'] != $request->getHttpHost()
            || isset($uri['path']) && strpos($requestUri, $uri['path']) === false
 ) { 

After that save the file (commit to your REPO), clear the cache (remove everything inside var/cache folder) and reload your store front. You should find the site loads without anymore 302 redirect issues after applying the SUPEE 9767 Patch.

Root Cause

The difference in SCHEME value between the actual Request and the URI after redirection. Eg: The actual request returns the scheme HTTP but the scheme in the URI can be HTTPS.

Possible Underlying Reasons

  1. You may most likely have a redirect rule in .htaccess file to redirect all the http requests to https. The user requests http://yourdomain.com and you may have changed the scheme and redirected him to https://yourdomain instead of http://yourdomain.com which he had actually requested.

  2. Both the base secure and unsecure URLs begin with https

The CONFIRMED BUG "Customer registration fails at checkout" occurred a bit different on my side.

If the customer choose register in checkout then its password is not correctly stored. The customer is created correctly just that the password is not stored. I detected this by the fact that the password was not shown in welcome email. People can't login because of this too.

Bugfix linked in SUPEE-9767 Patch/CE 1.9.3.3 - One Page Checkout - Customer Registration issue has done the job for me too.

Can anyone tell me what the f... is this s... for in supee-9767?

enter image description here

  • 1
    The jQuery 1.10.2 version is considered vulnerable, and flagged by some PCI scanners. The 1.12 version is not. – Ryan Hoerr Jun 17 '17 at 17:42
  • @Detzler StackExchange isn't a forum. If you want to ask a question, you should post one, not an answer to a question. – toon81 Jun 26 '17 at 11:57
  • 1
    Ryan Hoerr asked about any issues brought by the patch. So I told him a possible breaking change as you see at the screenshot. I can not explain the reason for this change. So I sub asked. So what's your problem? – Detzler Jun 26 '17 at 15:05

The patch doesn't work even for a vanilla Magento 1.7.0.2.

martins@martinsmac.local:/var/www/magento1702-original$ ./PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh
Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.

patching file app/code/core/Mage/Admin/Model/Session.php
Hunk #1 succeeded at 109 (offset -29 lines).
patching file app/code/core/Mage/Adminhtml/Block/Checkout/Formkey.php
patching file app/code/core/Mage/Adminhtml/Block/Notification/Symlink.php
patching file app/code/core/Mage/Adminhtml/Block/Widget/Grid/Column/Filter/Date.php
patching file app/code/core/Mage/Adminhtml/Model/Config/Data.php
patching file app/code/core/Mage/Adminhtml/controllers/Catalog/Product/GalleryController.php
patching file app/code/core/Mage/Checkout/controllers/MultishippingController.php
patching file app/code/core/Mage/Checkout/controllers/OnepageController.php
Hunk #1 succeeded at 293 (offset -34 lines).
Hunk #2 succeeded at 313 (offset -34 lines).
Hunk #3 succeeded at 363 (offset -34 lines).
Hunk #4 succeeded at 392 (offset -34 lines).
Hunk #5 succeeded at 431 (offset -34 lines).
patching file app/code/core/Mage/Checkout/etc/system.xml
patching file app/code/core/Mage/Cms/Model/Wysiwyg/Images/Storage.php
patching file app/code/core/Mage/Core/Controller/Front/Action.php
patching file app/code/core/Mage/Core/Controller/Request/Http.php
Hunk #1 succeeded at 141 (offset -7 lines).
can't find file to patch at input line 377
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git app/code/core/Mage/Core/Model/File/Validator/Image.php app/code/core/Mage/Core/Model/File/Validator/Image.php
|index 7f7b9d0..cbbcbb1 100644
|--- app/code/core/Mage/Core/Model/File/Validator/Image.php
|+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
2 out of 2 hunks ignored
patching file app/code/core/Mage/Core/etc/config.xml
patching file app/code/core/Mage/Core/etc/system.xml
patching file app/code/core/Mage/Customer/Model/Session.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Adapter/Zend/Cache.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Container/Abstract.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Parser/Csv.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Parser/Xml/Excel.php
patching file app/code/core/Mage/ImportExport/Model/Import/Uploader.php
patching file app/code/core/Mage/Sales/Model/Quote/Item.php
Hunk #1 FAILED at 502.
1 out of 1 hunk FAILED -- saving rejects to file app/code/core/Mage/Sales/Model/Quote/Item.php.rej
patching file app/code/core/Mage/Widget/Model/Widget/Instance.php
patching file app/code/core/Mage/XmlConnect/Helper/Image.php
patching file app/design/adminhtml/default/default/layout/main.xml
patching file app/design/adminhtml/default/default/template/notification/formkey.phtml
patching file app/design/adminhtml/default/default/template/notification/symlink.phtml
patching file app/design/adminhtml/default/default/template/page/head.phtml
patching file app/design/frontend/base/default/template/checkout/cart/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/multishipping/billing.phtml
patching file app/design/frontend/base/default/template/checkout/multishipping/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/billing.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/payment.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/shipping_method.phtml
patching file app/design/frontend/base/default/template/persistent/checkout/onepage/billing.phtml
patching file app/etc/config.xml
patching file app/locale/en_US/Mage_Adminhtml.csv
patching file app/locale/en_US/Mage_Core.csv
patching file app/locale/en_US/Mage_Dataflow.csv
patching file downloader/Maged/Connect.php
patching file downloader/Maged/Controller.php
Hunk #1 succeeded at 400 (offset -5 lines).
Hunk #2 succeeded at 923 (offset -5 lines).
patching file downloader/Maged/Model/Session.php
Hunk #2 succeeded at 235 with fuzz 2 (offset -13 lines).
patching file js/varien/payment.js
patching file skin/frontend/base/default/js/opcheckout.js

even after applying older patches manually.

$ grep '|' app/etc/applied.patches.list
2017-06-19 04:01:42 UTC | SUPEE-2677 | EE_1.13.0.2 | v2 | d20e6763cd0df70c4ac6e418c9775a1ff0f2618f | Tue Jan 14 17:49:25 2014 +0200 | v1.13.0.2..HEAD
2017-06-19 04:03:26 UTC | SUPEE-2629 | EE_1.12.0.0 | v1 | 5de775cf535e137b0b099d8066bd5b3a81f7ec4c | Wed Dec 11 16:50:40 2013 +0200 | v1.12.0.0..HEAD
2017-06-19 04:04:12 UTC | SUPEE-1049 | EE_1.12.0.2 | v1 | 5cd884653325315804056d4c591572385b3c1d03 | Thu Mar 20 16:33:19 2014 +0200 | v1.12.0.2..HEAD
2017-06-19 04:05:01 UTC | SUPEE-1868-1-12-0-2 | EE_1.12.0.2 | v1 | 2148b1b6be28a9bad0bec9a4aecc63ed318dd201 | Fri Jul 26 13:20:27 2013 -0700 | v1.12.0.2..HEAD
2017-06-19 04:06:38 UTC | SUPEE-4334-v1.11.1.0 | EE_1.11.1.0 | v1 | 40f5a2e4db9ca53dc6a8e62eb0c728fd63b1157e | Wed Sep 10 10:42:31 2014 -0700 | ef80f7bff749c941b4d1736cc2b502888e7540c9
2017-06-19 04:07:10 UTC | SUPEE-1533 | EE_1.12 | v1 | _ | n/a | SUPEE-1533_EE_1.12_v1.patch
2017-06-19 04:08:41 UTC | SUPEE-5345 | EE_1.12.0.2 | v1 | 2d36f61cf684ed26286b6d10307fcb99dd47ff02 | Thu Feb 5 19:39:01 2015 +0200 | v1.12.0.2..HEAD
2017-06-19 04:09:29 UTC | SUPEE-5994 | CE_1.6.0.0 | v1 | _ | n/a | SUPEE-5994_CE_1.6.0.0_v1.patch
2017-06-19 04:10:00 UTC | SUPEE-6237 | EE_1.14.2.0 | v1 | 8b216c42e2e5d2cb5d8e500fcb6690abede9df52 | Fri Jun 12 13:39:59 2015 +0300 | v1.14.2.0..HEAD
2017-06-19 04:11:22 UTC | SUPEE-6285 | CE_1.7.0.2 | v1 | 84749c91e14543e1f96af30e86efdf29f4562c98 | Tue Jun 23 09:48:07 2015 +0300 | c6e6cee8eb..84749c91e1
2017-06-19 04:11:50 UTC | SUPEE-6482 | CE_1.8.0.0 | v1 |  | Tue Jul 14 14:17:04 2015 +0300 |
2017-06-19 04:12:12 UTC | SUPEE-7616 | CE_1.7.0.2-CE_1.4.2.0 | v1 | a16c51e3679c3f19de6c3207b7a42daa7f9227fc | Fri Dec 18 12:42:03 2015 +0200 | 3617437b6da11be812fcca85f4e6ecbd8b8dc94c..a16c51e3679c3f19de6c3207b7a42daa7f9227fc
2017-06-19 04:14:30 UTC | SUPEE-8167 | EE_1.12.0.2 | v1 | b1be28f9cd8c2ecba2aa403e59ad9e3d2855eb95 | Thu May 4 13:52:13 2017 +0300 | 8d12ea6fe564b6dc9ed1affb6de990f81aca3796..HEAD
2017-06-19 04:16:21 UTC | SUPEE-8967 | EE_1.13.1.0 | v1 | 1fa53e9533f6f3a16f24d9b64dabef0ab7f965d7 | Thu Aug 18 16:32:48 2016 +0300 | 97d160644..1fa53e9533
2017-06-19 04:16:44 UTC | SUPEE-9652 | EE_1.14.3.1 | v1 | 4038f0785d828794083f53f10c01aaa6af403523 | Tue Jan 24 15:03:12 2017 +0200 | 9586981e6ca8b255014b242d50b68b88525b0754..4038f0785d828794083f53f10c01aaa6af403523
2017-06-19 04:19:35 UTC | SUPEE-6788 | CE_1.7.0.2 | v1 | 0398c4b951d9a0f64495e7b8b3b8ca480952dd70 | Fri Oct 23 13:50:23 2015 +0300 | cfc252b

The solution/problem I found is that some of the changes in the patch for 1.7.0.2 is for files that doesn't exist before 1.9.2.3. So I copied the following files from a brand new 1.9.2.3 installation before running the patch script:

  • app/code/core/Mage/Core/Model/File/Validator/Image.php
  • app/code/core/Mage/Sales/Model/Quote/Item.php
  • The patch assumes all other security patches have already been applied. The files you are talking about were added/changed by previous patches. You're missing at least SUPEE-7405. – Ryan Hoerr Jun 19 '17 at 13:25
  • Hi Ryan, In fact I tried to apply 7405 as well, but didn't work either... $ ./PATCH_SUPEE-7405_CE_1.7.0.2_v1.1-2016-02-23-07-22-52\ (1).sh Checking if patch can be applied/reverted successfully... ERROR: Patch can't be applied/reverted successfully. (..)Adminhtml/Helper/Sales.php Hunk #1 FAILED at 121. 1 out of 1 hunk FAILED -- saving rejects to file (..)Adminhtml/Helper/Sales.php.rej patching file (..)/Core/Model/Config.php Hunk #1 FAILED at 1642. 1 out of 1 hunk FAILED -- saving rejects to file (..) Config.php.rej patching file (..)/Quote/Item.php Hunk #1 FAILED at 509.... – Ricardo Martins Jun 21 '17 at 2:11
  • @RicardoMartins how can i solve this error : patching file app/locale/en_US/Mage_Adminhtml.csv Hunk #2 FAILED at 36. 1 out of 2 hunks FAILED -- saving rejects to file app/locale/en_US/Mage_Adminhtml.csv.rej ? – zus Dec 5 '17 at 11:26

Jut an addition to https://magento.stackexchange.com/a/176930/46249

Note that Symlinks have always been disabled by default on new Magento installations admin YES/NO config values default to 'NO'. The update now explicitly disables symlinks in config.xml and as an extra precaution also removes the template section from admin->developer which contained the configuration option.

This will not affect your current symlink settings, if you manually enabled symlinks prior to 1.9.3.2 they will stay enabled, although you cannot see the setting anymore in admin.


The bold text isn't correct. If updating to 1.9.3.4 (SUPEE-9767 V2) or newer current settings will be deleted:

# app/code/core/Mage/Core/sql/core_setup/upgrade-1.6.0.6-1.6.0.7.php
$connection->delete(
    $this->getTable('core_config_data'),
    $connection->prepareSqlCondition('path', array(
        'like' => 'dev/template/allow_symlink'
    ))
);

Responsible admins can enable the symlink admin section again by looking for the diff changes to the template section in app/code/core/Mage/Core/etc/system.xml and adding the section to your system.xml at around line 600. Or double check symlinks are still enabled with

Just make config option visible again does no solve the problem. The option shows up, but you're not able to change config since newly introduced backend model prevents saving the value. See:

# app/code/core/Mage/Core/etc/system.xml
<backend_model>adminhtml/system_config_backend_symlink</backend_model>

and

# Mage_Adminhtml_Model_System_Config_Backend_Symlink
public function save()
{
    return $this;
}

So you have to remove or override this backend model, see How to enable symlinks after SUPEE-9767 V2 install?

protected by Marius Jun 6 '17 at 6:18

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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