CWE-863
Allowed-with-ReviewIncorrect Authorization
Abstraction: Class · Status: Incomplete
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.
5491 vulnerabilities reference this CWE, most recent first.
GHSA-HP2J-X7VV-R597
Vulnerability from github – Published: 2023-01-31 15:30 – Updated: 2023-02-08 03:30IdentityIQ 8.3 and all 8.3 patch levels prior to 8.3p2, IdentityIQ 8.2 and all 8.2 patch levels prior to 8.2p5, IdentityIQ 8.1 and all 8.1 patch levels prior to 8.1p7, IdentityIQ 8.0 and all 8.0 patch levels prior to 8.0p6, and all prior versions allow authenticated users assigned the Identity Administrator capability or any custom capability that contains the SetIdentityForwarding right to modify the work item forwarding configuration for identities other than the ones that should be allowed by Lifecycle Manager Quicklink Population configuration.
{
"affected": [],
"aliases": [
"CVE-2022-45435"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-31T15:15:00Z",
"severity": "MODERATE"
},
"details": "IdentityIQ 8.3 and all 8.3 patch levels prior to 8.3p2, IdentityIQ 8.2 and all 8.2 patch levels prior to 8.2p5, IdentityIQ 8.1 and all 8.1 patch levels prior to 8.1p7, IdentityIQ 8.0 and all 8.0 patch levels prior to 8.0p6, and all prior versions allow authenticated users assigned the Identity Administrator capability or any custom capability that contains the SetIdentityForwarding right to modify the work item forwarding configuration for identities other than the ones that should be allowed by Lifecycle Manager Quicklink Population configuration.",
"id": "GHSA-hp2j-x7vv-r597",
"modified": "2023-02-08T03:30:25Z",
"published": "2023-01-31T15:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45435"
},
{
"type": "WEB",
"url": "https://www.sailpoint.com/security-advisories/sailpoint-identityiq-identity-forwarding-vulnerability-cve-2022-45435"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HP3Q-747R-8RPP
Vulnerability from github – Published: 2023-01-14 12:30 – Updated: 2023-01-24 21:30Broken Access Control in Betheme theme <= 26.6.1 on WordPress.
{
"affected": [],
"aliases": [
"CVE-2022-45353"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-14T11:15:00Z",
"severity": "HIGH"
},
"details": "Broken Access Control in Betheme theme \u003c= 26.6.1 on WordPress.",
"id": "GHSA-hp3q-747r-8rpp",
"modified": "2023-01-24T21:30:29Z",
"published": "2023-01-14T12:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45353"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/betheme/wordpress-betheme-theme-26-6-1-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HPCC-2F3J-H5C3
Vulnerability from github – Published: 2024-02-14 21:30 – Updated: 2024-02-14 21:30An incorrect authorization vulnerability was identified in GitHub Enterprise Server that allowed an attacker to create new branches in public repositories and run arbitrary GitHub Actions workflows with permissions from the GITHUB_TOKEN. To exploit this vulnerability, an attacker would need access to the Enterprise Server. This vulnerability affected all versions of GitHub Enterprise Server after 3.8 and prior to 3.12, and was fixed in versions 3.9.10, 3.10.7, 3.11.5. This vulnerability was reported via the GitHub Bug Bounty program.
{
"affected": [],
"aliases": [
"CVE-2024-1482"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-14T20:15:45Z",
"severity": "HIGH"
},
"details": "An incorrect authorization vulnerability was identified in GitHub Enterprise Server that allowed an attacker to create new branches in public repositories and run arbitrary GitHub Actions workflows with permissions from the GITHUB_TOKEN. To exploit this vulnerability, an attacker would need access to the Enterprise Server. This vulnerability affected all versions of GitHub Enterprise Server after 3.8 and prior to 3.12, and was fixed in versions 3.9.10, 3.10.7, 3.11.5. This vulnerability was reported via the GitHub Bug Bounty program.\n",
"id": "GHSA-hpcc-2f3j-h5c3",
"modified": "2024-02-14T21:30:33Z",
"published": "2024-02-14T21:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1482"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.10/admin/release-notes#3.10.7"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.11/admin/release-notes#3.11.5"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.9/admin/release-notes#3.9.10"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HPGW-WW76-C68R
Vulnerability from github – Published: 2026-05-06 20:11 – Updated: 2026-06-09 00:01Summary
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": [
"CVE-2026-46362"
],
"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-06-09T00:01:28Z",
"published": "2026-05-06T20:11:52Z",
"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"
}
],
"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"
}
GHSA-HPQ2-JQ6G-6G73
Vulnerability from github – Published: 2024-11-09 18:30 – Updated: 2024-11-14 18:30Mattermost versions 9.10.x <= 9.10.2, 9.11.x <= 9.11.1, 9.5.x <= 9.5.9 and 10.0.x <= 10.0.0 fail to properly authorize the requests to /api/v4/channels which allows a User or System Manager, with "Read Groups" permission but with no access for channels to retrieve details about private channels that they were not a member of by sending a request to /api/v4/channels.
{
"affected": [],
"aliases": [
"CVE-2024-42000"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-09T18:15:14Z",
"severity": "LOW"
},
"details": "Mattermost versions 9.10.x \u003c= 9.10.2, 9.11.x \u003c= 9.11.1, 9.5.x \u003c= 9.5.9 and 10.0.x \u003c= 10.0.0 fail to properly authorize the requests to\u00a0/api/v4/channels \u00a0which allows\u00a0a User or System Manager, with \"Read Groups\" permission but with no access for channels to retrieve details about private channels that they were not a member of by sending a request to\u00a0/api/v4/channels.",
"id": "GHSA-hpq2-jq6g-6g73",
"modified": "2024-11-14T18:30:33Z",
"published": "2024-11-09T18:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42000"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HPW9-5GQC-MG62
Vulnerability from github – Published: 2022-05-11 00:00 – Updated: 2025-01-02 21:31Windows Hyper-V Security Feature Bypass Vulnerability.
{
"affected": [],
"aliases": [
"CVE-2022-24466"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-10T21:15:00Z",
"severity": "MODERATE"
},
"details": "Windows Hyper-V Security Feature Bypass Vulnerability.",
"id": "GHSA-hpw9-5gqc-mg62",
"modified": "2025-01-02T21:31:32Z",
"published": "2022-05-11T00:00:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24466"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-24466"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-24466"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HQ28-CRG7-95PR
Vulnerability from github – Published: 2026-05-08 22:24 – Updated: 2026-07-02 14:48Impact
An authenticated user with only users.edit permission can escalate their own privileges to admin by sending a PATCH request to /api/v1/users/{id} with permissions[admin]=1. The API controller only strips the superuser key from the permissions array, allowing admin and all other permission keys to be set by any user who can update users.
Patches
Patched in https://github.com/grokability/snipe-it/commit/ce18ff669ceb0f0349749fd5d11c1d3d40b10569, fix was released in v8.4.1
Workarounds
None.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "snipe/snipe-it"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.4.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44832"
],
"database_specific": {
"cwe_ids": [
"CWE-281",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T22:24:45Z",
"nvd_published_at": "2026-05-26T20:16:20Z",
"severity": "HIGH"
},
"details": "### Impact\nAn authenticated user with only `users.edit` permission can escalate their own privileges to `admin` by sending a PATCH request to `/api/v1/users/{id}` with `permissions[admin]=1`. The API controller only strips the `superuser` key from the permissions array, allowing `admin` and all other permission keys to be set by any user who can update users.\n\n### Patches\nPatched in https://github.com/grokability/snipe-it/commit/ce18ff669ceb0f0349749fd5d11c1d3d40b10569, fix was released in v8.4.1\n\n### Workarounds\nNone.",
"id": "GHSA-hq28-crg7-95pr",
"modified": "2026-07-02T14:48:19Z",
"published": "2026-05-08T22:24:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/grokability/snipe-it/security/advisories/GHSA-hq28-crg7-95pr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44832"
},
{
"type": "WEB",
"url": "https://github.com/grokability/snipe-it/commit/ce18ff669ceb0f0349749fd5d11c1d3d40b10569"
},
{
"type": "PACKAGE",
"url": "https://github.com/grokability/snipe-it"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Snipe-IT has Privilege Escalation via API Permissions Assignment"
}
GHSA-HQGG-Q83J-H468
Vulnerability from github – Published: 2025-08-26 12:30 – Updated: 2025-08-26 12:30An access control vulnerability was discovered in the Request Trace and Download Trace functionalities of CMC before 25.1.0 due to a specific access restriction not being properly enforced for users with limited privileges. An authenticated user with limited privileges can request and download trace files due to improper access restrictions, potentially exposing unauthorized network data.
{
"affected": [],
"aliases": [
"CVE-2025-1501"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-26T11:15:31Z",
"severity": "MODERATE"
},
"details": "An access control vulnerability was discovered in the Request Trace and Download Trace functionalities of CMC before 25.1.0 due to a specific access restriction not being properly enforced for users with limited privileges.\u00a0An authenticated user with limited privileges can request and download trace files due to improper access restrictions, potentially exposing unauthorized network data.",
"id": "GHSA-hqgg-q83j-h468",
"modified": "2025-08-26T12:30:23Z",
"published": "2025-08-26T12:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1501"
},
{
"type": "WEB",
"url": "https://security.nozominetworks.com/NN-2025:3-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-HQGR-XF2J-75R5
Vulnerability from github – Published: 2025-05-22 21:30 – Updated: 2025-05-22 21:30An incorrect authorization vulnerability exists in multiple WSO2 products due to a business logic flaw in the account recovery-related SOAP admin service. A malicious actor can exploit this vulnerability to reset the password of any user account, leading to a complete account takeover, including accounts with elevated privileges.
This vulnerability is exploitable only through the account recovery SOAP admin services exposed via the "/services" context path in affected products. The impact may be reduced if access to these endpoints has been restricted based on the "Security Guidelines for Production Deployment" by disabling exposure to untrusted networks.
{
"affected": [],
"aliases": [
"CVE-2024-6914"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-22T19:15:42Z",
"severity": "CRITICAL"
},
"details": "An incorrect authorization vulnerability exists in multiple WSO2 products due to a business logic flaw in the account recovery-related SOAP admin service. A malicious actor can exploit this vulnerability to reset the password of any user account, leading to a complete account takeover, including accounts with elevated privileges.\n\nThis vulnerability is exploitable only through the account recovery SOAP admin services exposed via the \"/services\" context path in affected products. The impact may be reduced if access to these endpoints has been restricted based on the \"Security Guidelines for Production Deployment\" by disabling exposure to untrusted networks.",
"id": "GHSA-hqgr-xf2j-75r5",
"modified": "2025-05-22T21:30:47Z",
"published": "2025-05-22T21:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6914"
},
{
"type": "WEB",
"url": "https://security.docs.wso2.com/en/latest/security-announcements/security-advisories/2024/WSO2-2024-3561"
},
{
"type": "WEB",
"url": "https://security.docs.wso2.com/en/latest/security-guidelines/security-guidelines-for-production-deployment"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HQPJ-F3JH-29VX
Vulnerability from github – Published: 2026-05-18 09:31 – Updated: 2026-06-01 15:53Mattermost versions 11.5.x <= 11.5.1, 10.11.x <= 10.11.13 fail to validate that the RefreshedToken differs from the original invite token during remote cluster invite confirmation which allows an authenticated attacker to bypass token rotation and reuse the original invite token via sending a crafted invite confirmation with a RefreshedToken matching the original token. Mattermost Advisory ID: MMSA-2026-00575
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "11.5.0"
},
{
"fixed": "11.5.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "10.11.0"
},
{
"fixed": "10.11.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.0.0-20260313190740-742e0be95074"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.3.2-0.20260313190740-742e0be95074"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-4273"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-01T15:53:25Z",
"nvd_published_at": "2026-05-18T08:16:14Z",
"severity": "LOW"
},
"details": "Mattermost versions 11.5.x \u003c= 11.5.1, 10.11.x \u003c= 10.11.13 fail to validate that the RefreshedToken differs from the original invite token during remote cluster invite confirmation which allows an authenticated attacker to bypass token rotation and reuse the original invite token via sending a crafted invite confirmation with a RefreshedToken matching the original token. Mattermost Advisory ID: MMSA-2026-00575",
"id": "GHSA-hqpj-f3jh-29vx",
"modified": "2026-06-01T15:53:25Z",
"published": "2026-05-18T09:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4273"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/742e0be9507454a7e662668e1d9ec1b94b636e9b"
},
{
"type": "PACKAGE",
"url": "https://github.com/mattermost/mattermost"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Mattermost doesn\u0027t validate that the RefreshedToken differs from the original invite token during remote cluster invite confirmation"
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
No CAPEC attack patterns related to this CWE.