Security Patch SUPEE-8788 - Possible Problems?

Important notes

Please note that 1.9.3 is different than 1.9.2.4 + SUPEE-8788. Here's the diff between the two: https://gist.github.com/digitalpianism/14a15cd52baede0e5d600e8c653f33e9

Update October 14th: v2 of the patch has been released (see below) ~~As of October 13th, the patches for 1.5.x to 1.8.x have been taken down from the Magento website because of the incompatibility with previous patches (see below):~~

https://community.magento.com/t5/Security-Patches/SUPEE-8788-AND-SUPEE-1533-Incompatible-Hunk-error/td-p/50434/highlight/false/page/2

V3 of the patch

This new version is only for Magento EE 1.13.0.x

Apply the V3:

revert SUPEE 1533 (if installed)
install SUPEE 3941 (if not installed)
install SUPEE 8788 v3

V2 of the patch

Apply the V2:

revert SUPEE 8788 v1
revert SUPEE 1533 (if installed)
install SUPEE 3941 (if not installed)
install SUPEE 8788 v2

DemacMedia developed a useful bash script to automate the process above you can find it here: https://github.com/DemacMedia/magento-SUPEE8788-patcher

Details of the patch

After digging into the patch here are the interesting parts (patching from 1.9.2.4):

Mage_Adminhtml_Block_Media_Uploader has been replaced with Mage_Uploader_Block_Multiple so there's a full Mage_Uploader module which drops Flash support. The old block is now deprecated and extends the new block.
Still regarding the uploader, the Mage_Downloadable module has been refactored to handle the new non-flash uploader. It uses Mage_Uploader_Block_Single as the upload block instead of using templates.
Following this change, the SWF files skin/adminhtml/default/default/media/flex.swf, skin/adminhtml/default/default/media/uploader.swf and skin/adminhtml/default/default/media/uploaderSingle.swf have been deleted.
Address deletion controller is now protected with form key directly via the getDeleteUrl from Mage_Customer_Block_Address_Book
Wishlist item removal controller is now protected with form key via the getRemoveUrl from Mage_Wishlist_Helper_Data
Paypal Express payment method now ensures that the customer email used exists in Magento when checking out and registering a new user. (understand: the new user is created before the new quote is processed)
The payment methods using cURL/HTTP Client now have CURLOPT_SSL_VERIFYHOST set to 2 (was 0 before) and the CURLOPT_SSL_VERIFYPEER flag is now added to the cURL calls. The Verify Peer flag can be enable/disable via the payment method configuration via the Enable SSL Verification dropdown.
Mage_Http_Client_Curl now has CURLOPT_SSL_VERIFYPEER set to true (was false before), beware if you have any custom module using it.
Max dimensions for product pictures are now configurable in the config. NB: it can result in a funny error message if you upload too big images: Disallowed file format in Magento 1.9.2.2 after patch upload

Known SUPEE-8788 v2 issues

Magento 1.9.2.0 SUPEE-8788 v2 Hunk #1 FAILED at 91 after reverting SUPEE-1533
Patch can't be applied on PayPal Express model: Magento 1.9.2.2 SUPEE-8788 v2 Hunk #1 FAILED
Coïncidence not patch related ~~Emails stopped being sent on 1.8 : https://magento.stackexchange.com/q/141799/2380 and Security patch 8788 V2 problem~~
Backward incompatible change when calling the getConfig() method from the uploader block: Issue in Admin Panel after SUPEE Patch 8788 installation

Known SUPEE-8788 v1 issues

Update: the v2 of the patch fixes that issue (see above)Conflict between SUPEE-1533 and SUPEE-8788, possible (hacky) workaround here . A less hacky solution here
Update: v2 of the patch fixes that issue Unsupported data type N error in /lib/Unserialize/Reader/ArrValue.php in 1.9.1.0 and possibly earlier versions when patch is applied. fix here: https://gist.github.com/balloz/ceaf5feb5ac66caaa82342441d32aa88
Update: the v2 of the patch fixes that issue ~~Possible conflict with SUPEE-3941: https://magento.stackexchange.com/a/140696/2380~~
Issue with OS X: Illegal Byte Sequence : SUPEE-8788 on OSX - illegal byte sequence
Malformed patch (probably bue to the binary sequence in the patch): Magento 1.9.2.4 patch SUPEE-8788 malformed patch at line 5790
Inclusion of a test_oauth.php file with EE patch, don't push that file to prod
Possible login issue on EE related to Enterprise_Pci : https://magento.stackexchange.com/a/140577/2380
Problem if you edit the patch file as it contains binary files encapsulated, use this method if you need to edit: https://magento.stackexchange.com/a/140575/2380
In case you have an app/code/local version of Mage/Core/functions.php you'll have issue with the new hash_equals function: https://magento.stackexchange.com/a/140664/2380
Good to know that there is some templates change involved regarding form_key for Magento prior to 1.8
Possible issue on 1.5.1.0 with downloader/Maged/View.php : Security Patch SUPEE-8788 failing at downloader/Maged/View.php (M1 v1.5.1.0)
Incase you removed/renamed the downloader folder: https://magento.stackexchange.com/a/140631/2380

Known 1.9.3.0 issues

Edit: as the list is getting long and it's pretty much off-topic in this answer (as not SUPEE-8788 related) you can refer to this post for the list of known 1.9.3.0 issues: https://magento.stackexchange.com/a/140826/2380

When applying the patch this error can happen:

checking file skin/adminhtml/default/default/media/flex.swf
checking file skin/adminhtml/default/default/media/uploader.swf
checking file skin/adminhtml/default/default/media/uploaderSingle.swf
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored
checking file skin/adminhtml/default/default/xmlconnect/boxes.css

The 8788 patch contains binary content. As Magento does not provide any direct download links (I hate this policy ever since), you have to download the patch to your computer and upload it with an file-transfer application (like WinSCP on Windows) to your server. WinSCP for example will upload in TEXT-mode (WinSCP handles *.sh files as text by default).

So the workaround for this is, zip/tar the patch-file and unzip/untar again on the server. et voila.

Sorry I didn't have any way to answer this

Download the correct magento version (Eg: CE 1.9.1.0)
Replace the following files with downloaded location

skin/adminhtml/default/default/media/flex.swf skin/adminhtml/default/default/media/uploader.swf skin/adminhtml/default/default/media/uploaderSingle.swf

Run the patch

Worked for me

Here's a summary of what I (and others) encountered so far, I'm trying to keep it sorted, feel free to add or link anything that's missing, the post is a Community Wiki:

Reasons for failed patch

If you see "ERROR: Patch can't be applied/reverted successfully", look for "Hunk #1 FAILED" in the log messages to check at which file the patch failed.

Apparently v2 of the patch for Magento 1.7 expects SUPEE-3941 to present although it only exists for Magento 1.8 and 1.9. If you are on Magento 1.7 and see errors related to files in downloader, download SUPEE-3941 for 1.8 and apply it on 1.7, it should work. See comment thread here: Security Patch SUPEE 8788 problem
On Magento versions that have had SUPEE-1533 applied before, the patch fails at app/code/core/Mage/Adminhtml/controllers/DashboardController.php because the file is affected by both patches and SUPEE-8788 (incorrectly!) assumes that the unpatched version is present. This is still true with version 2 of the patch! Version 2 includes the changes from SUPEE-1533, so if you installed it before, you still have to revert it, but you don't have to manually apply it again afterwards.
If you deleted or renamed the "downloader" directory, the patch will fail because it patches a file within the downloader. The easiest workaround is to restore the original downloader directory, apply the patch, then delete the directory again. Alternatively, you could also remove the instructions for downloader/lib/Mage/HTTP/Client/Curl.php from the patch.
Other "Hunk FAILED" messages are usually due to changes in core files or missing previous patches. Make sure all previous patches for your Magento version are installed and you did not make changes in core files.

Another common problem is that the patch fails to delete .swf files because of their binary content. The error will look like this:

checking file skin/adminhtml/default/default/media/uploaderSingle.swf
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored

or like this

Patching file skin/adminhtml/default/default/media/uploader.swf using Plan A...
No such line 2 in input file, ignoring
Empty context always matches.
Hunk #1 failed at 0.
1 out of 1 hunks failed while patching skin/adminhtml/default/default/media/uploader.swf
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------

or like this:

Checking if patch can be applied/reverted successfully...
/bin/patch: **** malformed patch at line 5790: ?rM]M??????&X㔮??v??Q;r?N?qJ??Y???I0?Y??4??'?????9?.??X?Ǒ?{??ax!G???I???q?u|????թ??????|
                                               h??o?V@??|? ?g?H aꪭ??Ю???,I"?ğ????.??    yI?I\????)?X?
                     ?p???*?e?q?K8<DqD?H;|?
ERROR: Patch can't be applied/reverted successfully.

Possible solutions are given in this answer by @infabo. Downloading the patch directly to the system where I want to apply it, using curl as explained in https://gist.github.com/piotrekkaminski/9bc45ec84028611d621e always worked for me, except when I tried it on Cygwin

Advanced way to deal with failed patches: @PeterOCallaghan suggested to comment out the dry-run line and manually deal with the *.rej files. This way the patch can partially be applied and if it fails to delete the swf files, you can do that manually. Or if it fails to update files in downloader because you deleted that directory, you can just ignore that.

vi PATCH_SUPEE-8788_CE_1.8.1.0_v1-2016-10-11-06-54-44.sh (or similar file name) change _apply_revert_patch dry-run to look like #_apply_revert_patch dry-run

run the patch by issuing ./PATCH_SUPEE-8788_CE_1.8.1.0_v1-2016-10-11-06-54-44.sh

That will patch your files

Comment _apply_revert_patch to #_apply_revert_patch

run the patch again, to add the app/etc/app/etc/applied.patches.list entry

grep for all .rej files with

git status | grep *.rej

manually work in those changes

Issues after applying patch

Form keys

For Magento versions prior to 1.8 there are changes in frontend/base/default templates. Make sure that you manually apply the same changes in your theme if it overrides these files

More specifically, a form key has been added for frontend actions such as:
- Removing an item from the wishlist
- Deleting a customers address from the store view
- Updating a quote item in your basket
See this answer by @LukeRogers if you encounter problems with these actions.

Custom uploader

Unirgy_Rapidflow and other extensions with custom upload forms are not working anymore.

See this answer by @mpchadwick and comment by @lloiacono

I fixed it by replacing $this->getUploader()->getConfig() with $this->getUploader()->getUploaderConfig() in Unirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload

To find out if any of your extensions use this, you can run the following on the command line:

grep -R 'getUploader()->getConfig();' app/code/community

Reported error messages

PHP Fatal error: Call to undefined function hash_equals()

happens if you are on a PHP version prior to 5.6 and override code/core/Mage/core/functions.php in code/local/Mage/core/functions.php (which might be the case if you use Fishpig extensions). See this answer by @ClaudiuCreanga

Problems solved in v2 of the patch

If you encounter any of these issues, you probably use version 1 of the patch ("v1" in the filename). Download the patch again to get "v2" which fixes these issues:

There was a compatibility issue with SUPEE-3941 and downloader/lib/Mage/HTTP/Client/Curl.php
'Exception' with message 'Unsupported data type N' in /lib/Unserialize/Reader/ArrValue.php
The patch for EE 1.14.2.0 accidently contained a new file test_oauth.php which you should delete! See this answer by @MatthiasZeis

Security Patch SUPEE-8788 - Possible Problems?

Important notes

V3 of the patch

V2 of the patch

Details of the patch

Known SUPEE-8788 v2 issues

Known SUPEE-8788 v1 issues

Known 1.9.3.0 issues

Reasons for failed patch

Issues after applying patch

Form keys

Custom uploader

Reported error messages

Problems solved in v2 of the patch

Tags:

Security

Magento 1

Patches

Supee 8788

Related

Recent Posts