APPSEC-1057 (part of SUPEE-6788) states

Magento now includes a whitelist of allowed blocks or directives. If a module or anyone uses variables like {{config path=”web/unsecure/base_url”}} and {{block type=rss/order_new}} in CMS pages or emails, and the directives are not on this list, you will need to add them with your database installation script.

Extensions or custom code that handles content (like blog extensions) might be affected. If your code uses some config variables or blocks, you need to create a data update script that adds variables or blocks to the white list tables:

How do you whitelist custom variables and blocks?

3 Answers 3


For the sake of completeness, you can manually add blocks and variables to the white lists under System > Permissions > Variables and System > Permissions > Blocks. The codes you add there are in the form web/unsecure/base_url (config path) or rss/order_new (block class alias).

Original answer

My upgrade script looks like this:

 * Make sure the upgrade is not performed on installations without the tables
 * (i.e. unpatched shops).
$adminVersion = Mage::getConfig()->getModuleConfig('Mage_Admin')->version;
if (version_compare($adminVersion, '', '>=')) {

    $blockNames = array(
    foreach ($blockNames as $blockName) {
        $whitelistBlock = Mage::getModel('admin/block')->load($blockName, 'block_name');
        $whitelistBlock->setData('block_name', $blockName);
        $whitelistBlock->setData('is_allowed', 1);

    $variableNames = array(

    foreach ($variableNames as $variableName) {
        $whitelistVar = Mage::getModel('admin/variable')->load($variableName, 'variable_name');
        $whitelistVar->setData('variable_name', $variableName);
        $whitelistVar->setData('is_allowed', 1);

Replace $blockNames and $variableNames with your own. The following tool helps to find used variables and blocks: https://github.com/peterjaap/magerun-addons

Loading the variables/blocks first makes sure that you don't try to insert duplicates (this would crash the script). This happened to me because the script showed me variables "trans_email/ident_general/email" and "trans_email/ident_support/email" which are already whitelisted in the final patch release.

How to use the upgrade script

Place it in a custom module as data upgrade script (data upgrade scripts are run after normal upgrade script, this ensures that the tables already exist). If you don't have a module yet that you use for config updates, create it like this:


<?xml version="1.0"?>


<?xml version="1.0"?>


(as above)

  • 1
    This worked well for my custom blocks. I don't fully understand how the variable whitelist works. Variables in my existing custom modules do not appear in the whitelist, but are working.
    – paj
    Commented Oct 29, 2015 at 9:50
  • 1
    the blocks show, but the db isn't changed. weird Commented Oct 29, 2015 at 11:42
  • just to clarify my comment above regarding variables, are we are talking about whitelisting variables called in cms or locale files i.e. email templates using {config path= and not custom module variables accessed in PHP with Mage::getStoreConfig('my_var') ? So far the tools have found blocks that are not whitelisted, but no variables.
    – paj
    Commented Oct 29, 2015 at 14:21
  • only {{config}} directives need whitelisting. The code is intended for projects, not for extensions, so I assume a patched shop, but extensions should check the Magento version (or better, check if the tables exist) Commented Oct 29, 2015 at 15:14
  • 3
    Updated again with a nicer check thanks to @mam08ixo gist.github.com/mam08ixo/3937df764da7a6816a1d Commented Oct 30, 2015 at 15:45

You can add them manually in the Magento backend under System > Permissions > Variables and System > Permissions > Blocks once Magento is installed.

Plugins that use custom variables of blocks will need to add a data upgrade script with code similar as shown below.

if (Mage::getModel('admin/block')) {

    $installer = $this;
    $connection = $installer->getConnection();

            array('block_name' => 'flexslider/view', 'is_allowed' => 1),


  • 1
    This will only work for community edition, I would add the check on CE and EE: if ((Mage::getEdition()==Mage::EDITION_COMMUNITY && version_compare(Mage::getVersion(), '', '>=')) || (Mage::getEdition()==Mage::EDITION_ENTERPRISE && version_compare(Mage::getVersion(), '', '>=')) { Commented Oct 28, 2015 at 9:39
  • 1
    as @DmitryFurs stated there better make your check if feature exist by checing the tables or existance of configuration fields but not on version
    – Anton S
    Commented Oct 28, 2015 at 9:56
  • Good point Vladimir and Anton. I tried using this if ($installer->getConnection()->isTableExists($installer->getTable('admin/permission_block'))) { ... } but it results in an error . Any idea on how to poperly check if the table exists and do nothing if it doesnt?
    – Solide
    Commented Oct 28, 2015 at 18:47
  • I have updated my answer, you can use if (Mage::getModel('admin/block')) { ... }
    – Solide
    Commented Oct 28, 2015 at 18:54

You can find there are new tables after SUPEE-6788 patch has been installed



And you can add some config variables or blocks to these whitelist tables.


Not the answer you're looking for? Browse other questions tagged or ask your own question.