SUPEE-1533 installed with no problem. Then attempted to install SUPEE-5345 and three files were patched successfully but the 4th file failed:

# sh PATCH_SUPEE-5345_CE_1.7.0.2_v1-2015-02-10-08-11-22.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/Observer.php
patching file app/code/core/Mage/Core/Controller/Request/Http.php
patching file app/code/core/Mage/Oauth/controllers/Adminhtml/Oauth/AuthorizeController.php
patching file lib/Varien/Db/Adapter/Pdo/Mysql.php
Hunk #1 FAILED at 2672.
1 out of 1 hunk FAILED -- saving rejects to file lib/Varien/Db/Adapter/Pdo/Mysql.php.rej

FYI, the MySQL.php.rej file that the patch supposedly created it not there.

Is there anything I need to do to get that last file patched, or is it something I don't need to worry about?

  • 1
    The absense of a reject file would indicate the lack of writing permissions and therefore also the cause of the patch failing. I would expect to see more output (on stderr) then is shown here, but verify anyway.
    – user4351
    Commented May 11, 2015 at 16:37

3 Answers 3


If you're having trouble using the patch files you could always just manually overwrite the files with the patched ones.

You can download the zipped patch files here:



I'd be very cautious here. It's highly unlikely that you would have made modifications to the MySQL driver included in that file either accidentally or on purpose - it's such a low-level system component that it's rarely modified by anyone (of course it IS possible, just unlikely).

As the other submitters indicated, the message you received is indicating that the file can not be patched. Normally there are two reasons this happens:

  1. You (or someone on your team) modified this file so when the patch utility first compares the file to what expects to see in the original, it throws an error and says it can't patch the file. It logs the details in the lib/Varien/Db/Adapter/Pdo/Mysql.php.rej file for you to review.

  2. The file is successfully compromised by an attacker.

The problem is that this file was one of the ones called out in the recent security patches that not only needed to be updated, but that was modified by attackers to compromise Magento installations. I saw it modified on several of the sites we evaluated and remediated after being compromised.

Given that this file failed on installation of the patch, you should assume your system was compromised before you installed the patch. I know that sounds horrible, but you can work through this and restore your site back to functioning properly.

Before I go into the details below, I want to encourage you to contact a security professional who can assist you if you have not spent a lot of time developing working on security issues or with systems that have been successfully attacked. You do not want to do this alone unless you have an expert on your team since it is difficult to know if you're going to expose your customers to additional risk until you've had a thorough scan and audit by someone who has experience dealing with both the technical considerations as well as the contractual and legal issues surrounding breaches and notification requirements and any laws dictating which law enforcement agencies you may need to notify where you are located.

All that said, it's unfortunate, as I discuss below, but installing the fixes will not resolve your problem if you are already compromised. They only stop future attacks, They DO NOT DO ANYTHING TO FIX A SYSTEM THAT IS ALREADY COMPROMISED.

We've documented our research to provide a list of known attack signatures so that you can check your systems for evidence of them and respond accordingly.

We're working on a toolkit to automate the remediation of these item but it may be a week or two until it's ready for distribution. In the meantime, we're sharing the knowledge we've acquired working through these compromises with everyone in the community in an effort to make sure everyone is as safe as can be expected.

You can't know what has or hasn't been compromised until you diff the files in your system against the default source code provided by Magento or a copy you have made in your (Git / Mercurial / SVN) repository. YOU SHOULD ASSUME that your database and logins have been compromised and go change them all.

Phase 1: Identify the scope of your compromise. Each and every one of the items I list below are signatures we've discovered on compromised Magento sites specifically relating to the SUPEE-5344 and SUPEE-5994 vulnerability announcements. After you've installed the most recent patches (and any others you may need to install from Magento), you need to go through each one and check to see if you find any evidence of the signature on your system. Many of them are enough by themselves to allow an attacker to re-enter your system after you patch it, so you'll have to be diligent and make sure you don't skip anything or fail to remediate it.

You can also use the online scanner from Magento, but by and large this only will tell you if you've installed the patches and prevented future compromises. If you've already been compromised, these won't scan for other back doors or attacks that may have been installed when you were first attacked. at least none of the ones we tested found the signatures we discovered. Defense in depth is the way to go, which means multiple scans and reviews from multiple tools and perspectives if you want to be confident in the results.

Phase 2: Delete what you must, and replace what you can : use the original files from your repository or the Magento source files. If you're not running one of the latest versions, you can still use the Magento download page to grab older version sources from their site.

Phase 3: RESET Credentials: Inventory every use of a login name and password remotely related to your deployment and reset them all, including

  • Merchant Account Logins and API Keys
  • Magento Admin Logins & Passwords
  • Email account credentials
  • LDAP / AD / Primary Authentication System
  • Passwords
  • You can be reasonably sure that the preceding steps will help you purge infected fies but you can not know if passwords have been sniffed or key logged or the victim of some other attack, so resetting all related credentials is the safest option if you are going to attempt to remediate a compromised system.

The guide is too long to post in this response but the signature list can be downloaded immediately at our Magento Security Toolkit GitHub repository.


The reason that you are experiencing this problem is that your file lib/Varien/Db/Adapter/Pdo/Mysql.php has been modified since the install, either by a previous patch or through direct manipulation.

If you are unsure of the change made to Mysql.php I would suggest downloading a fresh install of Magento and do a direct file comparison. You will then need to decide if you want to keep the changes or restore the file to its original state.

If you going to keep the file at its current state you are going to have to manually run through the patch file and apply it. As the patch failed all files still need to be patched not just the file that the error occurred on. If you replace the Mysql.php file with the original you should be able to apply the patch without any issues going forward.

Please not that it is not recommended to modify the files in the /lib folder, if you want to changes override then in the similar manner as you would override the core files. But be careful cause as soon as you do this when security updates like the following are applied even though you think that since you applied the patch you are save, the truth of the matter is unless you update the overridden file you still leave yourself open to attach/venerability.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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