As technology folks, we are often under a lot of pressure to fix some deployed code, update an infrastructure component, or patch some code. Often it’s with little notice and needs to be done 5 minutes ago. The gamble with any “zero turnaround” is the rush to fix now vs. taking the time to test and check. 

Recently, a critical patch was released for Magento Ecommerce, Magento Open Source, and Adobe Commerce versions of Magento, after a critical issue was discovered by security researchers in the platform’s widely adopted ecommerce platform. CVE-2022-24086 identified a vulnerability that provided a way to utilize an SQL injection or PHP object injection at the time of checkout for an unauthenticated user. 

This led to an initial patch being rolled out by Adobe security, who moved fast to get a fix into play. A few days later, researchers discovered that the patch wasn’t enough to mitigate the code, which led to a new CVE-2022-24087 being raised and a second patch going into production. 

There is a patch available for the newly identified vulnerability in the latest security alert from Adobe. The new patch needs to be applied on top of the original CVE-2022-24086 patch. 

One thing I always love doing in the AppSec space is due diligence on deployments, libraries, and anything that can affect platform end users. So let’s dig into the latest patch and see what changed.

Perusing the CVE-20220-24087 patching patch

Before I get too far into the new patch, MDVA-43443, let’s revisit the original MDVA-43395 patch to understand what it did. 

It’s important to note that both vulnerabilities only affect Magento Open Source and Adobe Commerce versions greater than or equal to 2.3.4 and less than 2.4.5-p1 or 2.3.7-p2.

The original patch (MDVA-43395) added new secure user input sanitization during the checkout flow for the Magento shop application logic. /Email/Model/Template/transDirective and VarDirective.php both got preg_replace() and preg_match() patterns to help sanitize unwanted user input character types.

What security researchers found after the patch was deployed is that it wasn’t enough to stop the attack vector from being mitigated, and it actually opened up the possibility of even deeper vulnerabilities appearing in the framework. 

The new patch (MDVA-43443) adds a reusable framework function called sanitizeValue(), added as an extension of \Magento\Framework\Filter\Template and doing a preg_replace sanitization check and match. 

sanitizeValue() is then used to replace the preg_match() and preg_replace() sanitization code that was added by the original MDVA-43395 patch. 

The sanitizeValue() function is then used in a number of locations throughout the codebase, including loading of sanitized configure and custom value types. 

blockDirective() is where more sanitization magic happens, adding to the character matches and sanitization as part of the \Magento\Framework\FilterTemplate core.

resolveBlockDirective is transformed from a public to a private function, and layoutDirective is migrated into resolveLayoutDirective. 

The switch from public to private function here is important in PHP application security, because the private function declaration means this function can only be used from within this parent class. A public function could be accessed anywhere within the whole application.

Both patches are available from the APSB22-12 Adobe Security Bulletin, for either PHP Composer installation or by merging into a forked codebase. 

Remember to run secure backups before applying both patches, and to test the code before deployment. 

Sign up for Snyk to get new vulnerability alerts

Something I always do with big open source projects like Magento is monitor the public repository from my Snyk Dashboard. 

Click Add Project and Monitor public GitHub repos. 

This is particularly useful on development branches of a project, because you can be alerted to potential issues while they are in development. This also helps in contributing back to the project, because you can identify possible issues to remediate while it’s still in development. 

For platform projects like Magento, the monitor process will look for package manifests, code, container, and IAC configurations to scan and highlight any potential issues. The best part is that it will also suggest possible fixes and help you step through what it has detected. 

Log4Shell resource center

We’ve created an extensive library of Log4Shell resources to help you understand, find and fix this Log4j vulnerability.