Magento 1.9.3.7 / 1.14.3.7 / SUPEE-10415 Causing Every Page To 404

Published: January 11, 2018

Tags:

• Magento

Improve this page on GitHub

Magento 1.9.3.7 / 1.14.3.7 and SUPEE-10415 contain a potentially serious bug. Under certain conditions, every single page on your site will 404.

What’s worse, in my experience, reproduction of the issue can be dependent on site configuration. In my case, it wasn’t until the patch went to production, that the issue surfaced.

In this post, let’s review the issue.

How It Happens

The issue stems from this change to Mage::log().

diff --git app/Mage.php app/Mage.php
index 455ee23..46afbbd 100644
--- app/Mage.php
+++ app/Mage.php
@@ -805,7 +805,12 @@ final class Mage
         static $loggers = array();
 
         $level  = is_null($level) ? Zend_Log::DEBUG : $level;
-        $file = empty($file) ? 'system.log' : $file;
+        $file = empty($file) ? 'system.log' : basename($file);
+
+        // Validate file extension before save. Allowed file extensions: log, txt, html, csv
+        if (!self::helper('log')->isLogFileExtensionValid($file)) {
+            return;
+        }

The problem is that it’s not always safe to call self::helper('log') from Mage::log(). Specifically, if Mage::log() is called before store initialization (Mage_Core_Model_App::_initCurrentStore()), an exception will be thrown and a 404 response will be returned.

The chain of events plays out like this…

1. Mage_Log_Helper_Data::__construct() calls Mage::getStoreConfig(self::XML_PATH_LOG_ENABLED).
2. Mage::getStoreConfig() calls Mage_Core_Model_App::getStore().
3. Mage_Core_Model_App::getStore() throws a Mage_Core_Model_Store_Exception since the store has not yet been initialized[1].
4. Mage::run() catches that exception and returns a 404[2]

[1]

$id = $this->_currentStore;

if (!isset($id)) {
    $this->throwStoreException();
}

[2]

try {
    $_app->run();
} catch (Mage_Core_Model_Store_Exception $e) {
    require_once(self::getBaseDir() . DS . 'errors' . DS . '404.php');
    die();
}

In my case, code running prior to store initialization was causing an E_NOTICE on every request. The notice was being caught by mageCoreErrorHandler() (in app/code/core/Mage/Core/functions.php) which ultimately lead to a call to Mage::log.

if (Mage::getIsDeveloperMode()) {
    throw new Exception($errorMessage);
} else {
    Mage::log($errorMessage, Zend_Log::ERR);
}

While this notice was previously a minor annoyance, SUPEE-10415 made it catostrophic, causing every page on the site to 404.

Community / Magento Response

The issue has been documented by the community in the “Security Patch SUPEE-10415 - Possible Issues?” StackExchange question. Additionally, it’s been acknowledged by Magento as a known issue in the Magento 1.9.3.7 Release Notes.

Known Issue

Issue: Magento displays a “404: Page Not Found” error from the errors/ directory after upgrading to SUPEE-10415. This issue occurs only in Magento installations that run certain third-party extensions.

Description: Magento is not properly logging PHP warnings that occur early during page initialization. Instead, of logging the error and continuing operation, Magento generates a 404 page. (Previously, Magento logged these warnings in the system.log file, and execution would continue as usual.)

Workaround: Confirm that there are no PHP warnings generated by any of the extensions or customizations.

How To Actually Fix The Issue

The workaround documented by Magento is less than ideal. Calls to Mage::log() prior to store instantiation originate from 3rd party extensions and modifying these is against best practice.

Instead, isLogFileExtensionValid() should simply become an internal method to the Mage class. This would prevent instantiating an instance of Mage_Log_Helper_Data, which is the the the first domino eventually leading to the 404s.