Instructions for quick and dirty Magento 2 Store patch for exploit MDVA-43395

MDVA-43395-quick-instructions.md

Security updates available for Magento - APSB22-12

Adobe has released security updates for Adobe Commerce and Magento Open Source. These updates resolve a vulnerability rated critical. Successful exploitation could lead to arbitrary code execution.

Adobe is aware that CVE-2022-24086 has been exploited in the wild in very limited attacks targeting Adobe Commerce merchants.

This vulnerability has a similar severity as the Magento Shoplift vulnerability from 2015. At that time, nearly all unpatched Magento stores globally were compromised in the days after the exploit publication.

– Sansec (https://sansec.io/research/magento-2-cve-2022-24086)

Proper way to patch

If you have time to do a new deployment, use this guide for reference: https://www.integer-net.com/applying-the-magento-security-patch-via-composer/

Quickest way to patch (temporary)

Since time is of the absolute essence, run this quick method if you can't do the above today.

Whatever you do, do it TODAY!

1. Download and extract the composer patch from https://github.com/magento/knowledge-base/blob/main/src/troubleshooting/known-issues-patches-attached/assets/MDVA-43395_EE_2.4.3-p1_COMPOSER_v1.patch.zip?raw=true
2. SSH into your server and cd into the Magento root directory
3. Create and edit a new file MDVA-43395.patch, insert the contents of the MDVA-43395_EE_2.4.3-p1_COMPOSER_v1.patch file from the archive above
4. Run patch -p1 < MDVA-43395.patch, or if that fails, run patch -p2 < MDVA-43395.patch
5. Just in case, if you have OPCache running, try to flush it if you have the rights. Restarting your PHP service also takes care of this.
6. Run bin/magento cache:flush
7. Take a breath, then plan to implement a proper fix. Probably Adobe comes with a patch-release update for all Magento versions soon.

UPDATE 17 February 22

An additional patch was released in followup of the above.

Full information can be found on the Adobe Security Bulletin page: https://helpx.adobe.com/security/products/magento/apsb22-12.html

Instructions are basically the same as above, but the addtional patches are more extensive than the first one, so inevitably the patches are different per Magento versions.

If you are on 2.4.3, the new composer patch is here: https://github.com/magento/knowledge-base/blob/main/src/troubleshooting/known-issues-patches-attached/assets/MDVA-43443_EE_2.4.3-p1_v1.patch.zip?raw=true

If you are on 2.3.4-p2 till 2.4.2-p2, the new composer patch is here: https://github.com/magento/knowledge-base/blob/main/src/troubleshooting/known-issues-patches-attached/assets/MDVA-43443_EE_2.4.2-p2_COMPOSER_v1.patch.zip?raw=true

If you are on 2.3.3-p1 till 2.3.4, the new composer patch is here: https://github.com/magento/knowledge-base/blob/main/src/troubleshooting/known-issues-patches-attached/assets/MDVA-43443_EE_2.3.4_COMPOSER_v1.patch.zip?raw=true

After downloading the patch, put the file in the root of your webdirectory and run the commandline patch command again, as described above.

CSS in email template break after applying the patch

If you have manually added CSS to transactional emails through the Magento Admin, these styles break after applying the patch above. (Credits to integer_net for reporting this issue)

There is currently no fix available yet, but you should 100% rather apply the patch and have broken email styles than not patching!

You can check wheter you have custom styles enabled for your emails by checking if you have any content in the Template Styles field in the email templates in the Magento Admin, or run the following SQL command:

SELECT COUNT(*) FROM `email_template` WHERE template_styles like '%{%';

Agreed with @peterjaap

It's more powerful and no need for hacking the patches that come from magento

"patches": {
    "*": {
        "Apply MDVA-43395": {
            "source": "patches/magento/MDVA-43395_EE_2.4.3-p1_COMPOSER_v1.patch",
            "targets": [
                "magento/framework",
                "magento/module-email"
            ]
        },
        "Apply MDVA-43443": {
            "source": "patches/magento/MDVA-43443_EE_2.4.2-p2_COMPOSER_v1.patch",
            "targets": [
                "magento/framework",
                "magento/module-email"
             ],
             "after": "MDVA-43395_EE_2.4.3-p1_COMPOSER_v1.patch"
        }
    },

@convenient
Did not know vaimo had support for applying patches that way (having multiple targets in a single file and defining them the way you do). Is there also a way to define version constraints for the targets like you can do when specifying a specific target?

"MDVA-43443 email patch 2.4.3-p1": {
  "source": "patches/magento-module-email/MDVA-43443_magento-module-email-243-p1.patch",
  "version": "101.1.3"
},

Edit: checked https://github.com/vaimo/composer-patches/blob/master/docs/USAGE_ADVANCED.md doesn't really define versions in bundled patches.

vaimo/composer-patches does not seem to work with private packagist.
Because it tries to download the modules from repo.magento.com instead.
Not sure if configurable somehow, just quickly tried the code here

It might serve as a hint for others, maybe someone even has a solution to this.

@Morgy93 mine pulls everything from the LFS so doesn't download anything from anywhere

We use private packagist fine.

@convenient Do you have any other configuration applied?
I tried two separate projects and, in both cases, it tried to download magento/framework from repo.magento.com before patching 🤷

@Morgy93 i don't know what to say pal.

Does it start messing up when you require vaimo/composer-patches? Or does it start messing up when you start defining the patch configuration ?

Nothing I know of in the tool should be causing the behaviour you're saying, especially if you're using the files locally and not from a remote.

@convenient I can require "vaimo/composer-patches": "^4.22" just fine and composer update runs without any issues.
But after applying your code:

    "extra": {
        "magento-force": "override",
        "patches": {
            "*": {
                "Apply MDVA-43395": {
                    "source": "patches/magento/MDVA-43395_EE_2.4.3-p1_COMPOSER_v1.patch",
                    "targets": [
                        "magento/framework",
                        "magento/module-email"
                    ]
                },
                "Apply MDVA-43443": {
                    "source": "patches/magento/MDVA-43443_EE_2.4.2-p2_COMPOSER_v1.patch",
                    "targets": [
                        "magento/framework",
                        "magento/module-email"
                     ],
                     "after": "MDVA-43395_EE_2.4.3-p1_COMPOSER_v1.patch"
                }
            }
        }
    }

I'm only left with:

On abort it shows me that it wanted to download magento/framework from repo.magento.com:

As an aside you should only need to run composer install rather than composer update

If you run with composer patch:apply --no-interaction -vvv you'll have a better idea where this is being triggered maybe.

For info we got also some "issue" small yes related to the RCE... like we use the famous Vladimir popov form and with the MDVA-43443 patch applied, we're no longer able to have prefilled fields as it use also the {{ magic :)

@convenient I did run composer install for the patch. Just because I added the package to composer.json manually and wanted to be sure all my packages are up to date I ran composer update before.

Same progress with composer patch:apply --no-interaction -vvv. At some point it tries to download https://repo.magento.com/archives/magento/framework/magento-framework-103.0.3.0.zip because that's written in the composer.lock - maybe this is different on your end?

        {
            "name": "magento/framework",
            "version": "103.0.3",
            "dist": {
                "type": "zip",
                "url": "https://repo.magento.com/archives/magento/framework/magento-framework-103.0.3.0.zip",
                "mirrors": [
                    {
                        "url": "https://repo.packagist.com/YOUR-COMPANY/dists/%package%/%version%/r%reference%.%type%",
                        "preferred": true
                    }
                ]
            },
            ...

At some point it tries to download

Yeah, I was expecting that to be shown in a stack trace from the -vvv mode. That would be an indicator of what its trying to do.

Maybe you've got prefer-source configured somewhere or something like that configured.

@convenient Nothing that I'm aware of. Only m2 default:

    "config": {
        "preferred-install": {
            "*": "dist"
        },
        "sort-packages": true
    },

Never had issues like that before since using private packagist.

@Morgy93 sorry I can't debug your setup I've never seen anything like this happening. However by running composer patch:apply --no-interaction -vvv you should see the stack trace and following that should be apparent what part of the code is operating and trying to grab from the source.

@convenient I reproduced it just fine on a new setup. If you're still willing to help please have a look: vaimo/composer-patches#91

@Morgy93 did you actually download and save these files at the locations within your repository?

patches/magento/MDVA-43395_EE_2.4.3-p1_COMPOSER_v1.patch
patches/magento/MDVA-43443_EE_2.4.2-p2_COMPOSER_v1.patch

Maybe its trying to look them up from the remote if you do not have them in your LFS?

@convenient You don't have to. The download happens before the patch file check. This is also confirmed by vaimo/composer-patches#71

And a completely different error is thrown:

(The -vvv then says the file does not exist)

edit: I just saw you also answered the issue, let's continue there.

So how we properly add styles correctly after apply new patch ?
From my understand css styles in less for email will not affected after apply patch right ? What about the case we add styles inline directly inside template email ?