CVE-2026-46362

phpMyFAQ before 4.1.2 contains an authorization bypass vulnerability in AbstractAdministrationController::userHasPermission() that fails to terminate execution after sending a forbidden response. Attackers can access all permission-protected admin pages by requesting their URLs as authenticated users, exposing admin logs, user data, system information, and application configuration.

phpMyFAQ before 4.1.2 contains an authorization bypass vulnerability in AbstractAdministrationController::userHasPermission() that fails to terminate execution after sending a forbidden response. Attackers can access all permission-protected admin pages by requesting their URLs as authenticated users, exposing admin logs, user data, system information, and application configuration.

Summary

AbstractAdministrationController::userHasPermission() catches the ForbiddenException thrown when a user lacks a specific permission, sends a "forbidden" HTML page via $response->send(), but does not terminate execution. The calling controller method continues to execute, fetches protected data, renders the full template, and returns it as a Response. The final $response->send() in admin/index.php outputs the protected page content after the forbidden page, leaking all permission-protected admin data to any authenticated admin user regardless of their actual permissions.

Details

The parent class AbstractController::userHasPermission() (phpmyfaq/src/phpMyFAQ/Controller/AbstractController.php:317-327) correctly enforces authorization by throwing a ForbiddenException when the user lacks the required permission. This exception would normally propagate to Symfony's HttpKernel exception handler, which would return an error response and prevent the controller from continuing.

However, AbstractAdministrationController overrides this method at line 390-399:

#[\Override]
protected function userHasPermission(PermissionType $permissionType): void
{
    try {
        parent::userHasPermission($permissionType);
    } catch (ForbiddenException $exception) {
        $response = $this->getForbiddenPage($exception->getMessage());
        $response->send();  // Outputs HTML but does NOT terminate execution
    } catch (Exception $exception) {
        $this->configuration->getLogger()->error($exception->getMessage());
        // Only logs, no response, no termination
    }
}

The critical flaw: after $response->send() at line 396, there is no exit(), die(), return, or re-throw. PHP execution continues normally into the calling controller method.

For example, in AdminLogController::index() (phpmyfaq/src/phpMyFAQ/Controller/Administration/AdminLogController.php:45-83):

public function index(Request $request): Response
{
    $this->userHasPermission(PermissionType::STATISTICS_ADMINLOG);
    // ^^^ If user lacks permission: forbidden page is echoed, but execution continues

    // ... all of this still executes:
    $loggingData = $this->adminLog->getAll();  // Fetches ALL admin log entries
    // ...
    return $this->render('@admin/statistics/admin-log.twig', [
        // ... full admin log data including IPs, usernames, actions
        'loggingData' => $currentItems,
    ]);
}

The entry point admin/index.php then calls $response->send() on the returned Response, appending the full protected page to the already-sent forbidden page in the HTTP response body.

The second catch block (line 397-398) for generic Exception is even worse — it only logs the error without sending any response or terminating, so the protected page renders with no forbidden notice at all.

58 admin controllers extend AbstractAdministrationController and call userHasPermission(), meaning every permission-protected admin page is affected. This includes:

• Admin logs (user IPs, actions, usernames)
• User management (user data, permissions)
• System information (server configuration, PHP info)
• Configuration pages (all application settings)
• Backup pages
• All other admin functionality

PoC

1. Create a test admin user with minimal permissions (e.g., only FAQ editing, no statistics access):

2. Authenticate as the limited admin user and request a permission-protected page:

# Get admin session cookies by logging in
curl -c cookies.txt -d 'faqusername=limited_admin&faqpassword=password&pmf-csrf-token=TOKEN' \
  'https://TARGET/admin/?action=login'

# Access admin log page (requires STATISTICS_ADMINLOG permission)
curl -b cookies.txt -s 'https://TARGET/admin/statistics/admin-log' | tee response.html

# The response contains BOTH the forbidden page HTML AND the full admin log:
grep -c 'You are not allowed' response.html    # 1 — forbidden page was sent
grep -c…

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-hpgw-ww76-c68r. This link is maintained to preserve external references.

Original Description

phpMyFAQ before 4.1.2 contains an authorization bypass vulnerability in AbstractAdministrationController::userHasPermission() that fails to terminate execution after sending a forbidden response. Attackers can access all permission-protected admin pages by requesting their URLs as authenticated users, exposing admin logs, user data, system information, and application configuration.

phpMyFAQ before 4.1.2 contains an authorization bypass vulnerability in AbstractAdministrationController::userHasPermission() that fails to terminate execution after sending a forbidden response. Attackers can access all permission-protected admin pages by requesting their URLs as authenticated users, exposing admin logs, user data, system information, and application configuration.

phpMyFAQ before 4.1.2 contains an authorization bypass vulnerability in AbstractAdministrationController::userHasPermission() that fails to terminate execution after sending a forbidden response. Attackers can access all permission-protected admin pages by requesting their URLs as authenticated users, exposing admin logs, user data, system information, and application configuration.

Summary

AbstractAdministrationController::userHasPermission() catches the ForbiddenException thrown when a user lacks a specific permission, sends a "forbidden" HTML page via $response->send(), but does not terminate execution. The calling controller method continues to execute, fetches protected data, renders the full template, and returns it as a Response. The final $response->send() in admin/index.php outputs the protected page content after the forbidden page, leaking all permission-protected admin data to any authenticated admin user regardless of their actual permissions.

Details

The parent class AbstractController::userHasPermission() (phpmyfaq/src/phpMyFAQ/Controller/AbstractController.php:317-327) correctly enforces authorization by throwing a ForbiddenException when the user lacks the required permission. This exception would normally propagate to Symfony's HttpKernel exception handler, which would return an error response and prevent the controller from continuing.

However, AbstractAdministrationController overrides this method at line 390-399:

#[\Override]
protected function userHasPermission(PermissionType $permissionType): void
{
    try {
        parent::userHasPermission($permissionType);
    } catch (ForbiddenException $exception) {
        $response = $this->getForbiddenPage($exception->getMessage());
        $response->send();  // Outputs HTML but does NOT terminate execution
    } catch (Exception $exception) {
        $this->configuration->getLogger()->error($exception->getMessage());
        // Only logs, no response, no termination
    }
}

The critical flaw: after $response->send() at line 396, there is no exit(), die(), return, or re-throw. PHP execution continues normally into the calling controller method.

For example, in AdminLogController::index() (phpmyfaq/src/phpMyFAQ/Controller/Administration/AdminLogController.php:45-83):

public function index(Request $request): Response
{
    $this->userHasPermission(PermissionType::STATISTICS_ADMINLOG);
    // ^^^ If user lacks permission: forbidden page is echoed, but execution continues

    // ... all of this still executes:
    $loggingData = $this->adminLog->getAll();  // Fetches ALL admin log entries
    // ...
    return $this->render('@admin/statistics/admin-log.twig', [
        // ... full admin log data including IPs, usernames, actions
        'loggingData' => $currentItems,
    ]);
}

The entry point admin/index.php then calls $response->send() on the returned Response, appending the full protected page to the already-sent forbidden page in the HTTP response body.

The second catch block (line 397-398) for generic Exception is even worse — it only logs the error without sending any response or terminating, so the protected page renders with no forbidden notice at all.

58 admin controllers extend AbstractAdministrationController and call userHasPermission(), meaning every permission-protected admin page is affected. This includes:

• Admin logs (user IPs, actions, usernames)
• User management (user data, permissions)
• System information (server configuration, PHP info)
• Configuration pages (all application settings)
• Backup pages
• All other admin functionality

PoC

1. Create a test admin user with minimal permissions (e.g., only FAQ editing, no statistics access):

2. Authenticate as the limited admin user and request a permission-protected page:

# Get admin session cookies by logging in
curl -c cookies.txt -d 'faqusername=limited_admin&faqpassword=password&pmf-csrf-token=TOKEN' \
  'https://TARGET/admin/?action=login'

# Access admin log page (requires STATISTICS_ADMINLOG permission)
curl -b cookies.txt -s 'https://TARGET/admin/statistics/admin-log' | tee response.html

# The response contains BOTH the forbidden page HTML AND the full admin log:
grep -c 'You are not allowed' response.html    # 1 — forbidden page was sent
grep -c…

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-hpgw-ww76-c68r. This link is maintained to preserve external references.

Original Description

phpMyFAQ before 4.1.2 contains an authorization bypass vulnerability in AbstractAdministrationController::userHasPermission() that fails to terminate execution after sending a forbidden response. Attackers can access all permission-protected admin pages by requesting their URLs as authenticated users, exposing admin logs, user data, system information, and application configuration.