Adobe has released a critical security patch early this week on https://support.magento.com/hc/en-us/articles/4426353041293-Security-updates-available-for-Adobe-Commerce-APSB22-12– and https://helpx.adobe.com/security/products/magento/apsb22-12.html.
Of course, Adobe Commerce merchants and agencies are nervous and want to apply the security patch as soon as possible. However, I believe as long as your admin passwords are strong enough and you have control about your admin accounts, you shouldn’t be worried too much.
Here is why.
Let’s have a look at the content of the security patch.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
diff --git a/vendor/magento/module-email/Model/Template/Filter.php b/vendor/magento/module-email/Model/Template/Filter.php index 1a7c3683820a..586cb485ee1f 100644 --- a/vendor/magento/module-email/Model/Template/Filter.php +++ b/vendor/magento/module-email/Model/Template/Filter.php @@ -618,6 +618,12 @@ public function transDirective($construction) } $text = __($text, $params)->render(); + + $pattern = '/{{.*?}}/'; + do { + $text = preg_replace($pattern, '', (string)$text); + } while (preg_match($pattern, $text)); + return $this->applyModifiers($text, $modifiers); } diff --git a/vendor/magento/framework/Filter/DirectiveProcessor/VarDirective.php b/vendor/magento/framework/Filter/DirectiveProcessor/VarDirective.php index f2fe398c3848..78034d70ba51 100644 --- a/vendor/magento/framework/Filter/DirectiveProcessor/VarDirective.php +++ b/vendor/magento/framework/Filter/DirectiveProcessor/VarDirective.php @@ -55,6 +55,11 @@ public function process(array $construction, Template $filter, array $templateVa $result = $this->filterApplier->applyFromRawParam($construction['filters'], $result); } + $pattern = '/{{.*?}}/'; + do { + $result = preg_replace($pattern, '', (string)$result); + } while (preg_match($pattern, $result)); + return $result; } |
The patch will update two files only that are responsible to process template variables such as email variables {{var logo_url}} or {{config path=”general/store_information/name”}} or variables within CMS pages or Static Blocks. The change is trivial and will wipe out unwanted content by using the pattern $pattern = ‘/{{.*?}}/’.
It basically means, in order to be able to exploit this issue, you must:
1. Know the admin url of a store
2. Have access to the Magento backend ( ideally admin privileges )
3. Know how to exploit the issue
So, as long as you maintain admin accounts regularly and know who is actively working in your backend, you should be fine.
However, if you have modules installed that add custom variables by injecting Magento\Email\Model\Template\Filter in combination with 3rd party services, you should probably go and install the patch with your next release.
Update: 2022/02/16
Code could possibly injected by using the customers billing or shipping address ( e.g {{trans “%name,” name=$order.getBillingAddress().getName()}} ) depending on how strong form validation is in the front-end ( My Account > Addresses or Checkout ).
Hi,
thanks for the short explainer. However I wonder why the vulnerability is rated as unauthenticated (the screenshot at https://twitter.com/ptswarm/status/1494240197915123713 indicates this as well).
Might it be possible that this is actually used in unauthenticated places? Do you have any insights?