CVE-2026-46362: Phpmyfaq/phpmyfaq PhpMyFAQ Has An Authorization Bypass Vulnerability

MODERATE
Advisory Identifier: GHSA-hpgw-ww76-c68r
CVSS 6.5
CWE-863
Published
Advisory Summary

CVE-2026-46362 is a MODERATE (CVSS 6.5) phpmyfaq has an authorization bypass vulnerability (CWE-863: Incorrect Authorization) affecting Phpmyfaq/phpmyfaq libraries in the Packagist ecosystem. The issue involves phpmyfaq has an authorization bypass in all admin pages due to non-terminating permission check. Remediation is available by upgrading affected packages to version 4.1.2.

CVE-2026-46362 at a Glance

CVE Identifier CVE-2026-46362
GHSA Identifier GHSA-hpgw-ww76-c68r
Severity MODERATE
CVSS v3.1 Base Score 6.5
CWE Classification CWE-863: Incorrect Authorization
Affected Product Phpmyfaq/phpmyfaq
Package Ecosystem Packagist
Published Date
Last Updated

Security Impact

CVSS: 6.5

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity None (I:N)
Availability None (A:N)

How to Fix CVE-2026-46362

To remediate this vulnerability, upgrade all affected Phpmyfaq/phpmyfaq dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

phpmyfaq/phpmyfaq fixed: 4.1.2
Upgrade phpmyfaq/phpmyfaq to 4.1.2
thorsten/phpmyfaq fixed: 4.1.2
Upgrade thorsten/phpmyfaq to 4.1.2
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for phpmyfaq/phpmyfaq

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-46362, inspect your project dependencies for Phpmyfaq/phpmyfaq:

inspect dependencies for phpmyfaq/phpmyfaq

Analyze the terminal output to locate any version of Phpmyfaq/phpmyfaq in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 4.1.2), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-863: Incorrect Authorization, where the product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. In Phpmyfaq/phpmyfaq, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## 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: ```php #[\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`): ```php 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: ```bash # 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 'loggingData\|ad_adminlog_ip' response.html # matches — admin log data also present # Access system information (requires CONFIGURATION_EDIT permission) curl -b cookies.txt -s 'https://TARGET/admin/system-information' | tee sysinfo.html # Contains PHP version, extensions, database info, server configuration ``` 3. The HTTP response body contains the forbidden page HTML followed by the full protected page HTML, including all sensitive data. ## Impact Any authenticated admin user — even one with zero administrative permissions beyond basic login — can access **every** permission-protected admin page by simply requesting its URL. The permission check sends a forbidden page but does not stop execution, so the protected content is always appended to the response. Exposed data includes: - **Admin logs**: All admin users' IP addresses, actions, and timestamps - **User management**: User accounts, email addresses, permissions - **System information**: PHP configuration, database details, server paths - **Configuration**: All application settings including security-sensitive values - **Backups**: Database export functionality This effectively renders the entire admin permission system non-functional for the 58 page controllers using `AbstractAdministrationController`. ## Recommended Fix Add `return` after sending the forbidden response, and re-throw for the generic Exception case: ```php #[\Override] protected function userHasPermission(PermissionType $permissionType): void { try { parent::userHasPermission($permissionType); } catch (ForbiddenException $exception) { $response = $this->getForbiddenPage($exception->getMessage()); $response->send(); exit; // Terminate execution to prevent controller from continuing } catch (Exception $exception) { $this->configuration->getLogger()->error($exception->getMessage()); throw $exception; // Re-throw to prevent controller from continuing } } ``` A cleaner architectural fix would be to not swallow the exception at all, and instead let it propagate to the Symfony HttpKernel exception handler (which already handles `ForbiddenException` via `WebExceptionListener`): ```php #[\Override] protected function userHasPermission(PermissionType $permissionType): void { // Simply delegate to parent — let ForbiddenException propagate // to the WebExceptionListener which renders the appropriate error page parent::userHasPermission($permissionType); } ``` Or remove the override entirely, since the `WebExceptionListener` registered in the Kernel already handles exception-to-response conversion.

CVE-2026-46362 Affected Phpmyfaq/phpmyfaq Versions

2 component(s)
Fixed Versions:
4.1.2
Product / Package Ecosystem Affected Versions Fixed Version
phpmyfaq/phpmyfaq
Packagist
< 4.1.2
4.1.2
thorsten/phpmyfaq
Packagist
< 4.1.2
4.1.2

References

Frequently Asked Questions

What is CVE-2026-46362?
CVE-2026-46362 is a security vulnerability in Phpmyfaq/phpmyfaq involving phpMyFAQ has an Authorization Bypass in All Admin Pages Due to Non-Terminating Permission Check under CWE-863: Incorrect Authorization.
Which Phpmyfaq/phpmyfaq versions are affected?
Affected versions include releases prior to 4.1.2 across affected packages: phpmyfaq/phpmyfaq, thorsten/phpmyfaq.
What version fixes CVE-2026-46362?
Upgrading to 4.1.2 (or the latest patched release for your respective branch) resolves the vulnerability.
Is phpmyfaq/phpmyfaq affected?
Yes, phpmyfaq/phpmyfaq is affected in releases prior to 4.1.2. Upgrade your dependency to 4.1.2 or later.
Is thorsten/phpmyfaq affected?
Yes, thorsten/phpmyfaq is affected in releases prior to 4.1.2. Upgrade your dependency to 4.1.2 or later.
What is the CVSS score of CVE-2026-46362?
CVE-2026-46362 has a CVSS v3.1 base score of 6.5 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N.
What CWE is associated with CVE-2026-46362?
CVE-2026-46362 is classified under CWE-863: Incorrect Authorization (The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.).
How can I check Packagist dependencies for CVE-2026-46362?
Run the dependency tree command: 'inspect dependencies for phpmyfaq/phpmyfaq'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-hpgw-ww76-c68r",
  "modified" : "2026-06-09T00:01:28Z",
  "published" : "2026-05-06T20:11:52Z",
  "aliases" : [ "CVE-2026-46362" ],
  "summary" : "phpMyFAQ has an Authorization Bypass in All Admin Pages Due to Non-Terminating Permission Check",
  "details" : "## Summary\n\n`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.\n\n## Details\n\nThe 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.\n\nHowever, `AbstractAdministrationController` overrides this method at line 390-399:\n\n```php\n#[\\Override]\nprotected function userHasPermission(PermissionType $permissionType): void\n{\n    try {\n        parent::userHasPermission($permissionType);\n    } catch (ForbiddenException $exception) {\n        $response = $this->getForbiddenPage($exception->getMessage());\n        $response->send();  // Outputs HTML but does NOT terminate execution\n    } catch (Exception $exception) {\n        $this->configuration->getLogger()->error($exception->getMessage());\n        // Only logs, no response, no termination\n    }\n}\n```\n\nThe 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.\n\nFor example, in `AdminLogController::index()` (`phpmyfaq/src/phpMyFAQ/Controller/Administration/AdminLogController.php:45-83`):\n\n```php\npublic function index(Request $request): Response\n{\n    $this->userHasPermission(PermissionType::STATISTICS_ADMINLOG);\n    // ^^^ If user lacks permission: forbidden page is echoed, but execution continues\n\n    // ... all of this still executes:\n    $loggingData = $this->adminLog->getAll();  // Fetches ALL admin log entries\n    // ...\n    return $this->render('@admin/statistics/admin-log.twig', [\n        // ... full admin log data including IPs, usernames, actions\n        'loggingData' => $currentItems,\n    ]);\n}\n```\n\nThe 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.\n\nThe 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.\n\n**58 admin controllers** extend `AbstractAdministrationController` and call `userHasPermission()`, meaning every permission-protected admin page is affected. This includes:\n- Admin logs (user IPs, actions, usernames)\n- User management (user data, permissions)\n- System information (server configuration, PHP info)\n- Configuration pages (all application settings)\n- Backup pages\n- All other admin functionality\n\n## PoC\n\n1. Create a test admin user with minimal permissions (e.g., only FAQ editing, no statistics access):\n\n2. Authenticate as the limited admin user and request a permission-protected page:\n\n```bash\n# Get admin session cookies by logging in\ncurl -c cookies.txt -d 'faqusername=limited_admin&faqpassword=password&pmf-csrf-token=TOKEN' \\\n  'https://TARGET/admin/?action=login'\n\n# Access admin log page (requires STATISTICS_ADMINLOG permission)\ncurl -b cookies.txt -s 'https://TARGET/admin/statistics/admin-log' | tee response.html\n\n# The response contains BOTH the forbidden page HTML AND the full admin log:\ngrep -c 'You are not allowed' response.html    # 1 — forbidden page was sent\ngrep -c 'loggingData\\|ad_adminlog_ip' response.html  # matches — admin log data also present\n\n# Access system information (requires CONFIGURATION_EDIT permission)  \ncurl -b cookies.txt -s 'https://TARGET/admin/system-information' | tee sysinfo.html\n# Contains PHP version, extensions, database info, server configuration\n```\n\n3. The HTTP response body contains the forbidden page HTML followed by the full protected page HTML, including all sensitive data.\n\n## Impact\n\nAny authenticated admin user — even one with zero administrative permissions beyond basic login — can access **every** permission-protected admin page by simply requesting its URL. The permission check sends a forbidden page but does not stop execution, so the protected content is always appended to the response.\n\nExposed data includes:\n- **Admin logs**: All admin users' IP addresses, actions, and timestamps\n- **User management**: User accounts, email addresses, permissions\n- **System information**: PHP configuration, database details, server paths\n- **Configuration**: All application settings including security-sensitive values\n- **Backups**: Database export functionality\n\nThis effectively renders the entire admin permission system non-functional for the 58 page controllers using `AbstractAdministrationController`.\n\n## Recommended Fix\n\nAdd `return` after sending the forbidden response, and re-throw for the generic Exception case:\n\n```php\n#[\\Override]\nprotected function userHasPermission(PermissionType $permissionType): void\n{\n    try {\n        parent::userHasPermission($permissionType);\n    } catch (ForbiddenException $exception) {\n        $response = $this->getForbiddenPage($exception->getMessage());\n        $response->send();\n        exit;  // Terminate execution to prevent controller from continuing\n    } catch (Exception $exception) {\n        $this->configuration->getLogger()->error($exception->getMessage());\n        throw $exception;  // Re-throw to prevent controller from continuing\n    }\n}\n```\n\nA cleaner architectural fix would be to not swallow the exception at all, and instead let it propagate to the Symfony HttpKernel exception handler (which already handles `ForbiddenException` via `WebExceptionListener`):\n\n```php\n#[\\Override]\nprotected function userHasPermission(PermissionType $permissionType): void\n{\n    // Simply delegate to parent — let ForbiddenException propagate\n    // to the WebExceptionListener which renders the appropriate error page\n    parent::userHasPermission($permissionType);\n}\n```\n\nOr remove the override entirely, since the `WebExceptionListener` registered in the Kernel already handles exception-to-response conversion.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "phpmyfaq/phpmyfaq"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "4.1.2"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 4.1.1"
    }
  }, {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "thorsten/phpmyfaq"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "4.1.2"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 4.1.1"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-hpgw-ww76-c68r"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-46362"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/thorsten/phpMyFAQ"
  }, {
    "type" : "WEB",
    "url" : "https://www.vulncheck.com/advisories/phpmyfaq-authorization-bypass-in-admin-pages-via-non-terminating-permission-check"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-863" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-06T20:11:52Z",
    "nvd_published_at" : null
  }
}