Magento’s most empowering feature is its open source architecture, for it allows developers to freely configure the platform and create complex custom solutions for ecommerce. Yet, open architecture has an unfortunate security vulnerability, which makes the platform subject to hacker attacks. Another reason why Magento is so prone to security attacks lies in its popularity. According to estimations, in 2018 there were more than 250,000 online stores around the world powered by Magento; you can’t but agree the criminals are given rather a wide choice.
Table of contents:
Why do you need Magento 2 security patches
In the first Magento versions the development policy was more focused on improving the platform and adding new features to it. This meant security issues were mostly disregarded, and to get rid of a certain security vulnerability, a store owner would have to simply update their Magento to the latest version.
Yet, in 2015 Magento management decided to address the issue of security with more attention, and since then Magento security patches have been released regularly. Even though this decision hasn’t entirely resolved the general issue of security, it massively improved the security situation and prevented a number of hacker attacks.
So, what are security patches in Magento 2? A security patch is a change of code that fixes a certain security vulnerability. The fixes are supplied in the form of a self-installing patch script, that locates the place where the code fix belongs to, automatically applies the update to it and saves the result. Keep in mind that security patches rely on core code files for proper installation, which means that if you alter core code, there is a chance the patches will fail to install.
But are the outcomes of ignoring security patches are that severe indeed? Here are the 4 most common consequences of a Magento store being hacked :
- Credit card information of the customers can get stolen. In fact, certain Magento integrations and extensions, especially payment ones, are from time to time discovered to be attacked and abused by fraudulent hacker groups. The recent case, less than a month ago, concerned PayPal integration Payflow Pro, hacked and utilized for stealing debit and credit card numbers.
- Ransomware can get installed into your webstore. Ransomware is the type of malicious software that encrypts your code and denies you access to it until you pay for its release.
- Webstore server can get compromised by hackers and used for illicit activities, in particular, for sending spam emails.
- Malware can get installed to your shop, further spreading and infecting your visitors. As a result, your website gets blocked by search engines until the security is restored, which results in profit loss and certain reputation damage. In severe cases, you will end up losing critical customer information.
With all that in mind, let us move to the latest Magento 2 security patches and their description.
List of Magento 2 security patches
This is the list of the most critical Magento security patches released over the last year:
|Patch Title||Description||Versions fixed in|
|APPSEC-1281: Remote Code Execution if the configuration setting allowing symlinks is enabled||AllowSymlinks option from the configuration settings allowed to upload an image containing malicious code.||CE 220.127.116.11, EE 18.104.22.168|
|APPSEC-1777: Remote Code Execution in DataFlow||DataFlow functionality utilized for uploading and executing arbitrary code.||CE 22.214.171.124, EE 126.96.36.199|
|APPSEC-1686: Remote Code Execution in the Admin panel||Access to store CMS allowed to remotely execute code.||CE 188.8.131.52, EE 184.108.40.206, Magento 2.0.14 and Magento 2.1.7|
|APPSEC-1320: SQL injection in Visual Merchandiser (Enterprise Edition)||SQL injection vulnerability in the Visual Merchandiser enabled a user with admin status to edit the database||EE 220.127.116.11|
|APPSEC-1634: XSS in data fields||Inability to filter data in certain admin tables allowed for cross-site scripting attacks.||CE 18.104.22.168, EE 22.214.171.124|
|APPSEC-1759: XSS in Admin panel configuration||A person with the admin role can enter a malicious code that affects other admin panel pages.||CE 126.96.36.199, EE 188.8.131.52|
|APPSEC-1549: CSRF after logout – form key not invalidated||Form key failed to invalidate on logout, allowing one to execute malicious commands after the admin logs out.||CE 184.108.40.206, EE 220.127.116.11|
|APPSEC-1626: RCE in video upload||Video upload functionality allowed to upload malicious PHP files.||CE and EE 2.0.14/2.1.7|
|APPSEC-1746: Zend Mail vulnerability – continued||Zend Mail vulnerability was fixed in 2.0.12/2.1.4 version, but was discovered to used to avoiding the implemented protection.||CE and EE 2.0.14/2.1.7|
|APPSEC-1559: Possible remote code execution in email reminders||Email reminder functionality enabled objects instantiation.||CE and EE 2.0.14/2.1.7|
|APPSEC-1752: Stored XSS in admin panel||User data logged into admin panel was not escaped properly, allowing lower level admins attack other administrators.||CE and EE 2.0.14/2.1.7|
|APPSEC-1699: API tokens not invalidated after disabling admin user||API tokens were not invalidated after the admin user disabling, allowing for attacks or unauthorized actions.||CE and EE 2.0.14/2.1.7|
|APPSEC-1632: Password shown in action log (EE only)||Under certain conditions, the administrator password was shown in plain text in the action log.||EE 2.0.14/2.1.7|
|APPSEC-1663: Mass actions do not follow ACL||Low-level admins were able to perform unauthorized actions.||CE and EE 2.0.14/2.1.7|
|APPSEC-1661: UI controllers do not follow ACL||Low-level admins were able to extract the data they were not authorized to access.||CE and EE 2.0.14/2.1.7|
|APPSEC-1679: APIs vulnerable to CSRF||Some customer authenticated APIs were vulnerable to CSRF and phishing attacks.||CE and EE 2.0.14/2.1.7|
|APPSEC-1610: Custom admin path disclosure||Payments module disclosed custom admin path location, allowing for password guessing or other hacks.||CE and EE 2.0.14/2.1.7|
|APPSEC-1666: Information leak||Requests returned by AJAX calls contained exposing configuration info.||CE and EE 2.0.14/2.1.7|
|APPSEC-1800: Remote Code Execution vulnerability in CMS and layouts||While creating a new CMS page, a low-level admin could introduce malicious code.||Magento Open Source 18.104.22.168, Magento Commerce 22.214.171.124, Magento 2.0.16, Magento 2.1.9|
|APPSEC-1887: Arbitrary File Disclose||Theme creation vulnerability, allowing to disclose or delete Magento installation system files.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1850: Arbitrary File Delete||The File Delete module could be used to upload and delete arbitrary files.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1851: Arbitrary file delete + Lack of input sanitization leading to Remote Code Execution||Low-level Magento admin could make use of functional test vulnerability and get full remote code execution.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1567: Order history disclosure||Generic order info enabled hackers to obtain full order information.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1769: Overwrite a Relative Path in Sitemap||Sitemap generation tool could be utilized for sensitive files overwrite.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1713: Setup pages expose sensitive data||Sensitive URL info leak, including controller location.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1852: CSRF + Stored Cross Site Scripting (customer group)||A customer group vulnerability used to create a URL for CSRF attack.||Magento Open Source 126.96.36.199, Magento Commerce 188.8.131.52, Magento 2.0.16, Magento 2.1.9|
|APPSEC-1482: Security Issue with referrer||A URL can be added to Magento site, redirecting users to malicious websites.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1502: Stored XSS – Add new group in Attribute set name||Malicious code could be injected into custom product attributes.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1494: AdminNotification Stored XSS||Network Man-in-the-middle attack could inject code on the Magento Admin RSS feed.||Magento Open Source 184.108.40.206, Magento Commerce 220.127.116.11, Magento 2.0.16, Magento 2.1.9|
|APPSEC-1793: Potential file uploads solely protected by .htaccess||The non-Apache installation contained executable scripting uploads that can be used for malicious purposes.||Magento Open Source 18.104.22.168, Magento Commerce 22.214.171.124, Magento 2.0.16, Magento 2.1.9|
|APPSEC-1819: Customer login authenticates two different sessions||Incorrect setup of an expired user session, which can be used by a hacker for access.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1802: Customer registration through frontend does not have anti-CSRF protection||CSRF protection to the customer registration process, preventing from taking over accounts.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1493: CMS Page Title Stored XSS||Executable scripts can be injected into non-executable areas, such as page title.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1755: Anti-CSRF form_key is not changed after login||Anti-CSRF tokens did not change properly after the user logged in.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1853: CSRF + Stored Cross Site Scripting in newsletter template||Vulnerability in newsletter templates allowed for URL creation that can be further exploited for a CSRF attack.||Magento Open Source 126.96.36.199, Magento Commerce 188.8.131.52, Magento 2.0.16, Magento 2.1.9|
|APPSEC-1729: XSS in admin order view using order status label in Magento||The code can be injected into sales order records, resulting in an XSS attack.||Magento Open Source 184.108.40.206, Magento Commerce 220.127.116.11, Magento 2.0.16, Magento 2.1.9|
|APPSEC-1775: Stored Cross-Site Scripting in email template bypass||Malicious code can be inserted into email templates.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1591: Stored XSS on product thumbnail||Products containing malicious code in the thumbnail can be added by Magento admin.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1896: Possible XSS in admin order view using order code label||Malicious code can be injected in the Order view.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1673: Stored xss using svg images in Favicon||SVG product images could contain malicious code.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1773: Injection on Page leading to DoS||While new page creation, the page counter can be modified, resulting in an integer overflow.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1577: Stored XSS in integration activation||Malicious code could be injected in the integration activation.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1510: Any admin user can upload Favicon Icon||Low-level admin could alter a favicon image for the entire website.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1545: Stored XSS through customer group name in admin panel||Customer fields can be injected with scriptable code, resulting in an XSS attack.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1535: Access Control Lists not validated when using quick edit mode in tables||Access Control Lists were not properly checked.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1588: Order Item Custom Option Disclosure||Information about past orders can be retrieved during checkout.||Magento Open Source 18.104.22.168, Magento Commerce 22.214.171.124, Magento 2.0.16, Magento 2.1.9|
|APPSEC-1701: API token does not correctly expire||Due to incorrect expiration of customer and admin tokens, cookies can be reused for criminal purposes.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1630: Anonymous users can view upgrade progress updates||An anonymous user could check Magento upgrade status by visiting an internal URL.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1628: Full Path Disclosure Web Root Directory||Magento installation system path was disclosed.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1599: Admin login does not handle autocomplete feature correctly||Incorrect autocomplete in the admin panel that could result in information leak.||Magento Open Source 126.96.36.199, Magento Commerce 188.8.131.52, Magento 2.0.16, Magento 2.1.9|
|APPSEC-1709: Customer email enumeration through frontend login||Contact emails were leaked by the account lockout mechanism.||Magento 2.0.16, Magento 2.1.9|
|APPSEC-1495: Any user can interact with the sales order function despite not being authorized||A logged-in user could modify order fields.||Magento Open Source 184.108.40.206, Magento Commerce 220.127.116.11, Magento 2.0.16, Magento 2.1.9|
|APPSEC-2001: Authenticated Remote Code Execution (RCE) using custom layout XML||Custom layout XML can be used to copy any file.||Magento Open Source 18.104.22.168, Magento Commerce 22.214.171.124|
|APPSEC-2015: Authenticated Remote Code Execution (RCE) through the Create New Order feature (Commerce only)||Gift card functionality can be used to inject a malicious string||Magento Open Source 126.96.36.199, Magento Commerce 188.8.131.52|
|APPSEC-2042: PHP Object Injection and RCE in the Magento admin panel (Commerce Target Rule module)||An administrator could create rule-based product relations that can trigger remote code execution.||Magento Open Source 184.108.40.206, Magento Commerce 220.127.116.11|
|APPSEC-2029: PHP Object Injection and Remote Code Execution (RCE) in the Admin panel (Commerce)||With access to Commerce Target rule module, an administrator could create rule-based product relations that can trigger remote code execution.||Magento Open Source 18.104.22.168, Magento Commerce 22.214.171.124|
|APPSEC-2007: Authenticated SQL Injection when saving a category||Through request data manipulation, a malicious string can be inserted into the database, triggering the SQL injection.||Magento Open Source 126.96.36.199, Magento Commerce 188.8.131.52|
|APPSEC-2027: CSRF is possible against Web sites, Stores, and Store Views||CSRF vulnerabilities allow to delete websites, stores or store views.||Magento Open Source 184.108.40.206, Magento Commerce 220.127.116.11, Magento 2.1.14, Magento 2.2.5|
|APPSEC-1882: The cron.php file can leak database credentials||Database credentials could be leaked if it was not possible to establish connection to the database.||Magento Open Source 18.104.22.168, Magento Commerce 22.214.171.124|
|APPSEC-2014: Authenticated Remote Code Execution (RCE) through the Magento admin panel (swatches module)||Remote control over code execution could be achieved via swatches module vulnerability.||Magento 2.1.14|
|APPSEC-2054: Remote Code Execution (RCE) via product import||A person with admin rights could add malicious code to the server.||Magento 2.1.14, Magento 2.2.5|
|APPSEC-2042: PHP Object Injection and RCE in the Magento 2 EE admin panel (Commerce Target Rule module)||PHP Object Injection and RCE in the Magento 2 EE admin panel (Commerce Target Rule module)||Magento 2.1.14, Magento Open Source 126.96.36.199, Magento Commerce 188.8.131.52|
|APPSEC-2055: PHP Object Injection and RCE in the Magento 2 Commerce admin panel (Schedule Import/Export Configuration)||An admin who had access to import/export logic could insert malicious data used for PHP object injection and Remote Code Execution.||Magento 2.1.14|
|APPSEC-2048: SQL Injection through API||An API user could, via API endpoints, perform SQL Injection||Magento 2.1.14, Magento 2.2.5|
|APPSEC-2025: Arbitrary File Delete via Product Image||Admin could send modified data to the WYSIWYG admin component and delete arbitrary files.||Magento 2.1.14, Magento 2.2.5|
|APPSEC-1838: RSS session admin cookie can be used to gain Magento administrator privileges.||Access to Magento Admin Portal could be gained via low privilege RSS session cookie.||Magento Open Source 184.108.40.206, Magento Commerce 220.127.116.11|
|APPSEC-1835: Exposure of Magento secret key from app/etc/local.xml||Admin could create content that would expose sensitive Magento installation information.||Magento Open Source 18.104.22.168, Magento Commerce 22.214.171.124|
|APPSEC-1861: PHP Object Injection in product entries leading to Remote Code Execution||Malicious code could be injected into promo fields.||Magento Open Source 126.96.36.199, Magento Commerce 188.8.131.52, Magento 2.0.17, Magento 2.1.10, Magento 2.2.1|
|APPSEC-1830: PHP Object Injection in product attributes leading to Remote Code Execution||Injectable cookie could be inserted in the product attributes.||Magento Open Source 184.108.40.206, Magento Commerce 220.127.116.11, Magento 2.0.17, Magento 2.1.10, Magento 2.2.1|
|APPSEC-1893: PHP Object Injection in product metadata leading to Remote Code Execution||The injectable code could be inserted in the swatches feature.||Magento 2.0.17, Magento 2.1.10, Magento 2.2.1|
|APPSEC-1915: Remote Code Execution in CMS Page Area||Admin could create a CMS page that would be parsed incorrectly, resulting in remote code execution.||Magento Open Source 18.104.22.168, Magento Commerce 22.214.171.124|
|APPSEC-1830: PHP Object Injection in product attributes leading to Remote Code Execution||One can create a widget block with malicious code.||Magento Open Source 126.96.36.199, Magento Commerce 188.8.131.52, Magento 2.0.17, Magento 2.1.10, Magento 2.2.1|
|APPSEC-1932: Remote Code Execution Using XML Injection||Injectable XML could be inserted into the layout table, giving an opportunity to remote code injection.||Magento Open Source 184.108.40.206, Magento Commerce 220.127.116.11|
|APPSEC-1938: Remote Code Execution – additional fix not included in SUPEE-9652||Information can be inserted into a return path leading to Remote Code Execution (RCE).||Magento Open Source 18.104.22.168, Magento Commerce 22.214.171.124|
|APPSEC-1964: Remote Code Execution by (semi-)arbitrary file deletion for admin users with access to Import||An XML file could be imported, giving an opportunity to Remote Code Execution (RCE).||Magento Open Source 126.96.36.199, Magento Commerce 188.8.131.52|
|APPSEC-1952: Remote Code Execution using media upload||Using a path traversal vulnerability, one could remotely execute code during the media upload process.||Magento 2.0.18, Magento 2.1.12, Magento 2.2.3|
|PRODSECBUG-2122: PHP Object Injection (POI) and Remote Code Execution (RCE) in the Magento 2.1.15 Admin||With access to the Braintree payment method configuration, one can trigger code execution via PHP object injection.||Magento 2.1.16, Magento 2.2.7, Magento 2.3.0|
|PRODSECBUG-2123: PHP Object Injection (POI) and Remote Code Execution (RCE) in the Admin||Via Varnish configuration settings and the design configuration, one can trigger code execution via PHP object injection.||Magento 2.1.16, Magento 2.2.7, Magento 2.3.0|
|PRODSECBUG-1589: Stops Brute Force Requests via basic RSS authentication||The attacker was able to guess the admin password via brute force requests to the RSS nodes.||Magento Open Source 184.108.40.206, Magento Commerce 220.127.116.11|
|PRODSECBUG-2198: SQL Injection vulnerability through an unauthenticated user||Via an SQL injection vulnerability, one can execute arbitrary code, causing data leakage.||Magento Open Source 18.104.22.168, Magento Commerce 22.214.171.124,Magento 2.1.17, Magento 2.2.8, Magento 2.3.1|
|PRODSECBUG-2261: Arbitrary code execution due to unsafe deserialization of a PHP archive||Malicious code can be injected via Phar deserialization vulnerability.||Magento Open Source 126.96.36.199, Magento Commerce 188.8.131.52,Magento 2.1.17, Magento 2.2.8, Magento 2.3.1|
|PRODSECBUG-2253: Arbitrary code execution due to unsafe handling of a malicious layout update||An arbitrary PHP code could be executed by one with access to dataflow importer and catalog categories.||Magento Open Source 184.108.40.206, Magento Commerce 220.127.116.11|
|PRODSECBUG-2192: Remote code execution though crafted newsletter and email templates||The arbitrary code could remotely be executed via crafted newsletter or email template code.||Magento 2.1.17, Magento 2.2.8, Magento 2.3.1|
|PRODSECBUG-2287: Remote code execution through email template||Arbitrary code can be executed via email templates.||Magento 2.1.17, Magento 2.2.8, Magento 2.3.1|
|PRODSECBUG-2236: SQL Injection and cross-site scripting vulnerability in Catalog section (XSS)||One can manipulate attribute_code in the Catalog section and embed malicious code through a stored cross-site scripting vulnerability or an SQL injection vulnerability||Magento 2.1.17, Magento 2.2.8, Magento 2.3.1|
This is obviously an incomplete list; go to https://magento.com/security you can find the full history of Magento security patches.
Since Magento company realizes how critical it is to detect a security vulnerability before hackers do it and use it for illicit purposes, there are bounties assigned for detecting and submitting a Magento vulnerability. Find the rewards policy guidelines at https://hackerone.com/magento.
How to install Magento security patches
There are three ways to install Magento patches: via GitHub, manually and with a composer. Below you will find a comprehensive instruction of how to install Magento patches in each of them.
Method 1: how to install Magento patch using GitHub
Step #1: create a directory for patches.
Go to the work directory of the webstore and create a patches directory for storing Magento patches.
Step #2: copy Magento patches to the created directory
Use SSH, FTP-client and other suitable tools for this step.
Step #3: generate a patch file.
Run the following command git diff > ./patches/patchForModule.patch.
In our case, we make changes in registration.php file of our module. The changes will look the following way:
Method 2: install Magento patch manually
To install a Magento patch via Composer, use git apply or patch commands.
Connect through SSH and run one of the following commands from the root of the website:
git apply patches/patchForModule.patch
patch -p1 < patches/patchForModule.patch
Method 3: install Magento patch with Composer
Step #1: add a new module via composer for patch application.
For this, run the following command
composer require cweagans/composer-patches ~1.0
I will demonstrate this method using JS validation issue as an example https://github.com/magento/magento2/issues/21734
We can fix the issue using commits.
Step #2: Create two new patch files in the patches directory:
Step #3: Change the paths in the patches for a root directory of the module to perform the correct update.
diff –git a/app/code/Magento/Ui/view/base/web/js/lib/validation/rules.js b/app/code/Magento/Ui/view/base/web/js/lib/validation/rules.js
diff –git a/view/base/web/js/lib/validation/rules.js b/view/base/web/js/lib/validation/rules.js
For github-issue-21734-magento-ui.diff we will get
Step #4: Change the composer.json file.
Add patches directive to the extra directive.
"Patch for issue 21734": "patches/github-issue-21734-magento-ui.diff"
"Patch for issue 21734": "patches/github-issue-21734-magento-catalog.diff"
Step #5: Apply patches and update composer.lock:
Run the following commands:
composer -v install
composer update –lock
How to check Magento store security
Apart from regularly updating Magento security patches, it is essential you kept a close look at your store security and were able to detect system vulnerability at the early stages. Magento store security check can be performed directly via the admin panel of the store; in addition to this, there are third-party tools – Mage Report and Mage Scan – that provide store security analysis without the need to log in to the admin panel.
Method 1: How to run a security scan from Magento admin panel
Magento Security Scan is a newly introduced tool that allows to monitor your store’s security, detect unauthorized access and update malware patches.
Step #1: Sign in to Magento account.
Step #2: Choose Security Scan in the panel on the left and press Go to Security Scan button. Tap Agree to continue.
Step #3: Click Add Site at the Monitored Websites field or +Add Site button.
Step #4: Verify your webstore domain ownership by entering Site URL and Site Name at the corresponding field and tap Generate Confirmation Code. Copy the code to the clipboard.
Step #5: Log in to the store admin panel. Navigate to Content tab -> Design -> Configuration.
Step #6: Expand the HTML Head section and paste the copied confirmation code to the Scripts and Style Sheets field.
Step #7: Get back to Security Scan and press Verify Confirmation Code button.
Step #8: Configure your security scan to be run either weekly or daily. Press Submit.
Method 2: How to run a security scan with Mage Report
We will run a Magento security scan on a Blaha Gartenmöbel – home & garden webstore BelVG worked with.
Step #1: Go to https://www.magereport.com/
Step #2: Enter the address of the store you wish to check and press Go.
Step #3: Analyze the report you got. It consists of the list of patched vulnerabilities (in green boxes) and patches with unknown status (in grey boxes). You can learn more about each security patch; in some cases, there is How do I verify that I am protected? link.
We will run a Magento security scan on a Karmaloop – fashion and shoe webstore BelVG worked with.
Step #1: Go to https://magescan.com/.
Step #2: Enter the address of the store you wish to check and press Scan.
Step #3: Analyze the report you got. It consists of the following fields: Magento version, hosting provider, admin panel, logs, version control, development files, configuration fields, PHP version and web server. If there are no vulnerabilities, each box will contain the “No exposed configuration files were found” message.
Wrapping it up
I hope that from my article you realized the importance of Magento security patches and learned how to install and update them.