Applying Magento CE SUPEE-5994 Security Patch Bundle (May 2015)

Geoff Jackson

Geoff Jackson (more commonly known by his online pseudonym zigojacko) is the founder of Design Haven and The Clubnet Group which hosts numerous agencies including the most widely recognised of them, Clubnet Digital, a full service digital marketing and creative design/development agency. He also has a personal blog but it doesn't get updated as much as he'd like.

You may also like...

Sponsored Links...

Subscribe to Design Haven UK

Enter your email address to subscribe and receive our new posts by email.

14 Responses

  1. Olivier says:


    I try to apply this patch on my dev environment and I got an issue with the get.php patching action :

    Hunk #1 FAILED at 37.
    1 out of 1 hunk FAILED — saving rejects to file get.php.rej

    I’m running on Magento 1.12 EE

    Can’t figure out whats going on


    • Thanks for stopping by and leaving a comment Olivier.

      This patch is only needed for Magento CE versions. You don’t need to worry about it on EE. I should perhaps make that clearer in the post so sorry about that.

  2. Olivier says:

    Thanks for your quick reply. Sorry I did not notice the title of your article (CE). But they release a patch also for EE today. Thats why 🙂


    • The original post title didn’t contain ‘CE’, I amended it since your comment to make it clearer (as well as adding the notice about it in the post body).

      Where is the release for EE? I checked the patch releases for EE and there was no equivalent released for this security patch bundle that I could see.

  3. MrArtist says:

    Thanks for your useful articles.

    I’m already on and I just went to apply patch 5994 and all I seem to get are messages that imply it’s already done?

    I get things like:
    patching file app/code/core/Mage/Authorizenet/controllers/Directpost/PaymentController.php
    Reversed (or previously applied) patch detected!  Assume -R? [n]
    Apply anyway? [n]
    Skipping patch.
    2 out of 2 hunks ignored — saving rejects to file app/code/core/Mage/Authorizenet/controllers/Directpost/PaymentController.php.rej


    The next patch would create the file lib/PEAR/PEAR/PEAR5.php,
    which already exists!  Assume -R? [n]
    Apply anyway? [n]
    Skipping patch.
    1 out of 1 hunk ignored

    and 15 other similar messages in the SSH window. All implying everything done or existing.

    What I can’t figure out is why, if the updates are done, how to check? There seems to be no clear way to know what has been done historically at all!

    For what it’s worth, the whole Magento update and patch thing seems to be a real mess with no proper explanations and poorly implemented with lacking and out of date instructions via the Magento help pages. So much simpler in other platforms/frameworks.

    Any suggestions as to what these messages imply?

    • Hey MrArtist,

      Thanks for stopping by to comment with details to your experience.

      The closest method Magento provides to find a history of applied patches can be found in /app/etc/applied.patches.list. From here, you can see which patches have been applied/reverted and which files they affected. This may help you but if you want to know specifically what has changed in each file, you would need to run a diffcheck against your patched files and the same files from the Magento core (either manually or directly on the command line).

      The messages do seem to imply that the patch has already been applied. How that would have happen, I’m not sure. Perhaps your web host patches their hosted Magento stores on behalf of their customers?

      As with most things Magento, the process isn’t overly clear to many which is why it is always worth working with specialist Magento developers to handle maintenance and support such as this.

      To be sure that the patches are definitely applied though (in addition to checking the applied.patches.list file), you can just grab the modified files for this patch and upload them manually. You can download a zip of these files here for Magento CE – (courtesy of Magentary).

      Hope that helps!

      • MrArtist says:

        Hi Geoff
        Thanks for the very useful response. I’ll check through those things you suggest later.

        It is odd about the seemingly already applied patches. My hosting provider has something called Installatron which did do the patch automatically, but then my hosting company then sent out an email the other day advising me to apply the patches. Maybe I have some setting “on” in Installatron which also does the patches? I’ll have to check exactly what is going on.

        Once again, thanks for your reply. I only found your site the other day and it’s looking very useful already and I shall give it a definite bookmark to come back to.

        I wonder if Magento 2 will be any better at being a bit more rational, automated updates and easier to follow?

        • My guess would be that something in your hosting set up, probably Installatron has already applied said patch then yeah.

          Glad you’re finding this site useful 🙂 We only just recently kick-started it back into life and have quite a lot of articles to write up on various web platforms so hopefully, it will prove much more useful still yet.

          Magento 2 does improve many areas with it being a major release. You can actually get Magento 2 up and running already from github and view the changelog to see what is being worked on.

          We’ve yet to really get stuck in to Magento 2 so this is on the ‘to-do’ list and will no doubt lead to some more blog posts on here.

          Thanks for the kind words.

  4. Cindy Martin says:

    I am using CE 1.8.1 and applying patch 5994. I get the error Hunk 1 failed at 37. Can you help?

    • Sure Cindy, please can you supply the full log of your patch or contact us via our contact form to provide more details of the issue. Thanks.

      • Cindy Martin says:

        [~/public_html]# sh
        Checking if patch can be applied/reverted successfully…
        ERROR: Patch can’t be applied/reverted successfully.

        patching file app/code/core/Mage/Authorizenet/controllers/Directpost/PaymentController.php
        patching file app/code/core/Mage/Core/Controller/Varien/Router/Admin.php
        patching file app/code/core/Mage/Core/Controller/Varien/Router/Standard.php
        patching file app/code/core/Mage/Customer/Model/Customer.php
        patching file app/code/core/Mage/Dataflow/Model/Convert/Parser/Csv.php
        patching file app/code/core/Mage/ImportExport/Model/Export/Adapter/Csv.php
        patching file app/code/core/Mage/Install/Controller/Router/Install.php
        patching file app/code/core/Mage/Install/etc/config.xml
        patching file app/code/core/Mage/Sales/controllers/Recurring/ProfileController.php
        patching file downloader/Maged/Model/Connect.php
        patching file downloader/Maged/View.php
        patching file downloader/template/connect/packages_prepare.phtml
        patching file downloader/template/messages.phtml
        patching file get.php
        Hunk #1 FAILED at 37.
        1 out of 1 hunk FAILED — saving rejects to file get.php.rej
        patching file lib/PEAR/PEAR/PEAR.php
        patching file lib/PEAR/PEAR/PEAR5.php
        patching file lib/Varien/Io/File.php

        I compared my get.php file to the original that was distributed with magento 1.8.1 and they are completely different. I was afraid to replace it. What I have now is actually the php code for InboX Mass Mailer. Any help would be appreciated. Thanks!

        • Thanks for including the log details of the patch Cindy.

          Please could you paste the contents of your get.php file at and send over the link to it for us to see?

          • I have bad news I am afraid Cindy, your Magento store has been hacked and your get.php file is one of the files infected.

            None of the files contents are what it should contain and it contains encrypted base64 code which will be carrying out malicious actions without your knowledge.

            Whilst you’d be safe to replace the get.php with the original from Magento 1.8.1, it will unlikely resolve the problem as the exploitation will have already created a backdoor into your site/server for them to use over and over.

            You’ll need your website patched up to the latest version and a malware scan run to ensure that all infected files are cleansed and restored back to the originals.

            We do provide a service to get rid of any infections and patching in Magento should it be of interest to you. Sorry to be the bearer of bad news.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: