TYPO3 Core

Observed on 8.7 but should be exactly the same up to and including v10.4

Set to "must have" since this causes major inconsistency in information transmitted to 404 handlers

Consider the following code from TypoScriptFrontendController->getPageAccessFailureReasons:

$combinedRecords = array_merge(is_array($this->pageAccessFailureHistory['direct_access']) ? $this->pageAccessFailureHistory['direct_access'] : [['fe_group' => 0]], is_array($this->pageAccessFailureHistory['sub_section']) ? $this->pageAccessFailureHistory['sub_section'] : []);
if (!empty($combinedRecords)) {
    // Generate failure reason
}

If $this->pageAccessFailureHistory['direct_access'] is EMPTY, a virtual entry is generated here which 1) has no page UID as key, and 2) says that fe_group is zero.

This then makes the !empty() check return TRUE (because $combinedRecords contains this virtual entry) and enter the condition which generates an incorrect failure reason that is then transmitted to registered 404 handlers.

Handlers receive the following incorrect information:

• Failure happened because of group access (wrong, it happened because a page was not resolved)
• UID of page is zero (wrong, no such page can exist)
• UID of group that caused the failure is zero (wrong, this would always have to be a valid ID or special keyword -2)

In short, it makes the 404 error appears like a "group access denied" error.

The reason for the incorrect behavior is the falling back to a virtual "direct_access" group restriction error. Removing this part correctly identifies the 404 error as a "page not found".