List of Magento 1 integrations with known security issues. Looking for Magento 2?
Objective: easily identify insecure 3rd party software in your Magento code base.
The list contains these columns:
- Vendor_Name of the module (as reported by
n98-magerun dev:module:listorMage::getConfig()->getNode()->modules) - The earliest safe version to use. Older entries are considered insecure.
- Part of the URL that attackers use to exploit this module. Can be used to search logfiles for malicious activity. (optional)
- Reference URL describing the problem. If no public statement is available, then the name of the researcher who discovered it.
- URL with upgrade instructions (optional)
Magento is an attractive target for payment skimmers and the number of attacks has increased steadily since 2015. In 2018, attackers shifted from Magento core exploits (eg, Shoplift, brute force attacks on admin passwords) to 3rd party software components. This poses a practical problem: there is no central place where one can (programmatically) find out whether a particular module version has known security issues. This repository solves that!
You can quickly scan your site against this blacklist using a Magerun module or a single-line command. Both require command line or SSH access to the server. Magerun is recommended as it can be easily scheduled or used on an ongoing basis, and provides better output. Both approaches load the latest vulnerability data on every run.
- Install n98-magerun
- Install the Magento1 Module Blacklist plugin:
mkdir -p ~/.n98-magerun/modules
cd ~/.n98-magerun/modules
git clone https://github.com/gwillem/magento-module-blacklist.git
- Scan your Magento install:
n98-magerun.phar dev:module:security
You can also use the -q flag to limit output to findings only.
n98-magerun.phar dev:module:security -q
To quickly check a Magento installation for vulnerable modules, run this command in SSH at your Magento site root:
php -r "require_once('app/Mage.php');Mage::app();$config=Mage::getConfig()->getNode()->modules;$found=array();$list=fopen('https://raw.githubusercontent.com/gwillem/magento1-module-blacklist/master/magento1-vulnerable-extensions.csv','r');while($list&&list($name,$version)=list($row['module'],$row['fixed_in'],,$row['reference'],$row['update'])=fgetcsv($list)){if(isset($name,$version,$config->{$name},$config->{$name}->version)&&(empty($version)||version_compare($config->{$name}->version,$version,'<'))){$found[]=$row;}}if($found){echo 'Found possible vulnerable modules: '.print_r($found,1);}else{echo 'No known vulnerable modules detected.';}"
Contributions welcome. Requirements:
- Either "name" or "uri" (in case of exploitation in the wild) is required.
- A reputable, verifiable source is required.
Only security issues that have verified proof or are being actively exploited in the wild should be considered.
There are many good initiatives already, however they either lack a simple web GUI, are too complicated to maintain or do not cover all extensions out there. For Magento 2, there is already excellent support via composer, please refer to Roave's SecurityAdvisories for automated composer integration.
We register the newest only and advice everybody to upgrade to the latest version. If people want to stick to an older (possible insecure) version, they should study the relevant changelogs.
The name as registered in the code (and output by n98-magerun dev:module:list) is leading. If a module is known under several (code) names, then we should create duplicate entries, so that automated tools will not ignore such an entry.
If the vendor has issued a security statement, that should be leading. Otherwise, a statement by a security researcher (Blog/Twitter) can be used. If a vendor has issued a statement that is false or misleading, an independent statement should take precedence.
Indeed, but the main advantage of a simple CSV with few columns is that it's easy to browse, maintain and extend. Other projects have stalled because there is too much overhead in vulnerability administration. The primary objective of this repository is to support a n98-magerun command. If people want more information, they can look it up via the referenced source.
This can be used by tools to filter "suspicious" web traffic from the logs. Ie, check if malicious activity has already taken place.
Seperate them with a ";"
Use the date of the fix in YYYY-MM-DD notation.
These Magento/security professionals have contributed valuable research and code:
- Ryan Hoerr - ParadoxLabs
- Peter O'Callaghan
- Max Chadwick - Something Digital
- Jeroen Vermeulen - MageHost.pro
- Roland Walraven - MageHost.pro
- Martin Pachol - MageMojo
The information and code of this repository is provided free of charge, without warranty or assumed liability of any kind. Merchants and development agencies are free to use this data to assess their own stores. It is not allowed to use or include this data in commercial products or offerings.