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.
5504 vulnerabilities reference this CWE, most recent first.
GHSA-G8MJ-5558-MWH7
Vulnerability from github – Published: 2022-04-30 00:00 – Updated: 2022-05-12 00:02USU Oracle Optimization before 5.17.5 allows attackers to discover the quantum credentials via an agent-installer download. NOTE: this is not an Oracle Corporation product.
{
"affected": [],
"aliases": [
"CVE-2022-29935"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-29T17:15:00Z",
"severity": "HIGH"
},
"details": "USU Oracle Optimization before 5.17.5 allows attackers to discover the quantum credentials via an agent-installer download. NOTE: this is not an Oracle Corporation product.",
"id": "GHSA-g8mj-5558-mwh7",
"modified": "2022-05-12T00:02:08Z",
"published": "2022-04-30T00:00:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/orangecertcc/security-research/security/advisories/GHSA-rcp9-qm7c-5mmx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29935"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-G8P8-94F2-28GR
Vulnerability from github – Published: 2026-04-29 21:44 – Updated: 2026-05-08 19:55Summary
The contacts_data.php endpoint uses a weaker permission check (isAdministratorUsers(), requiring only rol_edit_user=true) than the frontend UI (contacts.php) which correctly requires the stronger isAdministrator() (requiring rol_administrator=true) and the contacts_show_all system setting. A user manager who is not a full administrator can directly request contacts_data.php?mem_show_filter=3 to retrieve all user records across all organizations in the Admidio instance, bypassing multi-tenant organization isolation.
Details
The frontend page contacts.php and the backend data endpoint contacts_data.php have mismatched authorization checks for the "show all organizations" filter (mem_show_filter=3).
Frontend guard at modules/contacts/contacts.php:80:
if ($gCurrentUser->isAdministrator() && $gSettingsManager->getBool('contacts_show_all')) {
// Only then is filter=3 ("All Organizations") shown in the dropdown
$selectBoxValues = array(
...
'3' => array('3', $gL10n->get('SYS_ALL_CONTACTS'), $gL10n->get('SYS_ALL_ORGANIZATIONS'))
);
}
This correctly requires both isAdministrator() (rol_administrator=true) AND the contacts_show_all setting.
Backend check at modules/contacts/contacts_data.php:235:
} elseif (($getMembersShowFilter === 3) && $gCurrentUser->isAdministratorUsers()) {
$mainSql = $contactsListConfig->getSql(
array(
'showAllMembersDatabase' => true,
...
)
);
This only requires isAdministratorUsers() which checks rol_edit_user=true — a weaker permission available to non-admin "user manager" roles. The contacts_show_all setting is never checked.
The critical difference between the two methods (from src/Users/Entity/User.php):
- isAdministrator() (line 1507): checks the rol_administrator flag — full system administrator
- isAdministratorUsers() (line 1625): checks rol_edit_user right — user management module access only
When showAllMembersDatabase=true reaches ListConfiguration::getSql() (at src/Roles/Entity/ListConfiguration.php:1022-1028), the generated SQL removes ALL organization filtering:
} elseif ($optionsAll['showAllMembersDatabase']) {
$sql = 'SELECT DISTINCT ' . $sqlMemLeader . $sqlIdColumns . $sqlColumnNames . '
FROM ' . TBL_USERS . '
' . $sqlJoin . '
WHERE usr_valid = true ' .
$sqlWhere .
$sqlOrderBys;
}
Compare with the default query which includes cat_org_id = $gCurrentOrgId to restrict results to the current organization.
The cross-org indicator subqueries at line 169 do correctly check isAdministrator(), so the member_other_orga columns return 0 — but this only affects display indicators, not the actual user data returned.
PoC
Prerequisites: An Admidio instance with at least two organizations sharing the same database. A user account in Organization A assigned to a role with rol_edit_user=1 but rol_administrator=0.
Step 1: Log in as the user manager account and capture the session cookie.
Step 2: Request all users across all organizations by directly calling the data endpoint:
curl -s -b 'PHPSESSID=<user_manager_session>' \
'https://target/adm_program/modules/contacts/contacts_data.php?mem_show_filter=3&draw=1&start=0&length=100&search%5Bvalue%5D='
Expected behavior: The request should be rejected or return only current-organization users, since the user is not a full administrator and the frontend never offers filter=3 to non-administrators.
Actual behavior: The endpoint returns a JSON response containing all users from ALL organizations in the database, including:
- User UUIDs (usr_uuid)
- Login names (login_name)
- Email addresses (member_email)
- All configured profile fields (names, addresses, phone numbers, etc.)
Step 3: Verify that users from Organization B (where the attacker has no membership) appear in the results by checking the member_this_orga field — it will be 0 for cross-org users.
Impact
In multi-organization Admidio deployments (the primary use case for organization isolation), a user manager in one organization can exfiltrate the complete member directory of all other organizations sharing the same database. Exposed data includes:
- Full names and all configured profile fields
- Email addresses
- Login names (useful for credential attacks)
- User UUIDs (useful for targeting other API endpoints)
This completely bypasses the multi-tenant organization isolation boundary. The contacts_show_all admin setting (intended to control this feature) is also bypassed, meaning even instances where administrators have explicitly disabled cross-org viewing are affected.
Recommended Fix
Change line 235 in modules/contacts/contacts_data.php to match the frontend guard at contacts.php:80:
// Before (vulnerable):
} elseif (($getMembersShowFilter === 3) && $gCurrentUser->isAdministratorUsers()) {
// After (fixed):
} elseif (($getMembersShowFilter === 3) && $gCurrentUser->isAdministrator() && $gSettingsManager->getBool('contacts_show_all')) {
Additionally, as defense-in-depth, add an early rejection at the top of the file (after line 59) to block the filter value entirely for unauthorized users:
if ($getMembersShowFilter === 3 && (!$gCurrentUser->isAdministrator() || !$gSettingsManager->getBool('contacts_show_all'))) {
$getMembersShowFilter = 0; // Fall back to default
}
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.0.8"
},
"package": {
"ecosystem": "Packagist",
"name": "admidio/admidio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.0.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41657"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-29T21:44:24Z",
"nvd_published_at": "2026-05-07T04:16:28Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe `contacts_data.php` endpoint uses a weaker permission check (`isAdministratorUsers()`, requiring only `rol_edit_user=true`) than the frontend UI (`contacts.php`) which correctly requires the stronger `isAdministrator()` (requiring `rol_administrator=true`) and the `contacts_show_all` system setting. A user manager who is not a full administrator can directly request `contacts_data.php?mem_show_filter=3` to retrieve all user records across all organizations in the Admidio instance, bypassing multi-tenant organization isolation.\n\n## Details\n\nThe frontend page `contacts.php` and the backend data endpoint `contacts_data.php` have mismatched authorization checks for the \"show all organizations\" filter (`mem_show_filter=3`).\n\n**Frontend guard** at `modules/contacts/contacts.php:80`:\n```php\nif ($gCurrentUser-\u003eisAdministrator() \u0026\u0026 $gSettingsManager-\u003egetBool(\u0027contacts_show_all\u0027)) {\n // Only then is filter=3 (\"All Organizations\") shown in the dropdown\n $selectBoxValues = array(\n ...\n \u00273\u0027 =\u003e array(\u00273\u0027, $gL10n-\u003eget(\u0027SYS_ALL_CONTACTS\u0027), $gL10n-\u003eget(\u0027SYS_ALL_ORGANIZATIONS\u0027))\n );\n}\n```\nThis correctly requires both `isAdministrator()` (`rol_administrator=true`) AND the `contacts_show_all` setting.\n\n**Backend check** at `modules/contacts/contacts_data.php:235`:\n```php\n} elseif (($getMembersShowFilter === 3) \u0026\u0026 $gCurrentUser-\u003eisAdministratorUsers()) {\n $mainSql = $contactsListConfig-\u003egetSql(\n array(\n \u0027showAllMembersDatabase\u0027 =\u003e true,\n ...\n )\n );\n```\nThis only requires `isAdministratorUsers()` which checks `rol_edit_user=true` \u2014 a weaker permission available to non-admin \"user manager\" roles. The `contacts_show_all` setting is never checked.\n\n**The critical difference between the two methods** (from `src/Users/Entity/User.php`):\n- `isAdministrator()` (line 1507): checks the `rol_administrator` flag \u2014 full system administrator\n- `isAdministratorUsers()` (line 1625): checks `rol_edit_user` right \u2014 user management module access only\n\nWhen `showAllMembersDatabase=true` reaches `ListConfiguration::getSql()` (at `src/Roles/Entity/ListConfiguration.php:1022-1028`), the generated SQL removes ALL organization filtering:\n```php\n} elseif ($optionsAll[\u0027showAllMembersDatabase\u0027]) {\n $sql = \u0027SELECT DISTINCT \u0027 . $sqlMemLeader . $sqlIdColumns . $sqlColumnNames . \u0027\n FROM \u0027 . TBL_USERS . \u0027\n \u0027 . $sqlJoin . \u0027\n WHERE usr_valid = true \u0027 .\n $sqlWhere .\n $sqlOrderBys;\n}\n```\n\nCompare with the default query which includes `cat_org_id = $gCurrentOrgId` to restrict results to the current organization.\n\nThe cross-org indicator subqueries at line 169 do correctly check `isAdministrator()`, so the `member_other_orga` columns return 0 \u2014 but this only affects display indicators, not the actual user data returned.\n\n## PoC\n\n**Prerequisites:** An Admidio instance with at least two organizations sharing the same database. A user account in Organization A assigned to a role with `rol_edit_user=1` but `rol_administrator=0`.\n\n**Step 1:** Log in as the user manager account and capture the session cookie.\n\n**Step 2:** Request all users across all organizations by directly calling the data endpoint:\n```bash\ncurl -s -b \u0027PHPSESSID=\u003cuser_manager_session\u003e\u0027 \\\n \u0027https://target/adm_program/modules/contacts/contacts_data.php?mem_show_filter=3\u0026draw=1\u0026start=0\u0026length=100\u0026search%5Bvalue%5D=\u0027\n```\n\n**Expected behavior:** The request should be rejected or return only current-organization users, since the user is not a full administrator and the frontend never offers filter=3 to non-administrators.\n\n**Actual behavior:** The endpoint returns a JSON response containing all users from ALL organizations in the database, including:\n- User UUIDs (`usr_uuid`)\n- Login names (`login_name`)\n- Email addresses (`member_email`)\n- All configured profile fields (names, addresses, phone numbers, etc.)\n\n**Step 3:** Verify that users from Organization B (where the attacker has no membership) appear in the results by checking the `member_this_orga` field \u2014 it will be `0` for cross-org users.\n\n## Impact\n\nIn multi-organization Admidio deployments (the primary use case for organization isolation), a user manager in one organization can exfiltrate the complete member directory of all other organizations sharing the same database. Exposed data includes:\n\n- Full names and all configured profile fields\n- Email addresses\n- Login names (useful for credential attacks)\n- User UUIDs (useful for targeting other API endpoints)\n\nThis completely bypasses the multi-tenant organization isolation boundary. The `contacts_show_all` admin setting (intended to control this feature) is also bypassed, meaning even instances where administrators have explicitly disabled cross-org viewing are affected.\n\n## Recommended Fix\n\nChange line 235 in `modules/contacts/contacts_data.php` to match the frontend guard at `contacts.php:80`:\n\n```php\n// Before (vulnerable):\n} elseif (($getMembersShowFilter === 3) \u0026\u0026 $gCurrentUser-\u003eisAdministratorUsers()) {\n\n// After (fixed):\n} elseif (($getMembersShowFilter === 3) \u0026\u0026 $gCurrentUser-\u003eisAdministrator() \u0026\u0026 $gSettingsManager-\u003egetBool(\u0027contacts_show_all\u0027)) {\n```\n\nAdditionally, as defense-in-depth, add an early rejection at the top of the file (after line 59) to block the filter value entirely for unauthorized users:\n\n```php\nif ($getMembersShowFilter === 3 \u0026\u0026 (!$gCurrentUser-\u003eisAdministrator() || !$gSettingsManager-\u003egetBool(\u0027contacts_show_all\u0027))) {\n $getMembersShowFilter = 0; // Fall back to default\n}\n```",
"id": "GHSA-g8p8-94f2-28gr",
"modified": "2026-05-08T19:55:36Z",
"published": "2026-04-29T21:44:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Admidio/admidio/security/advisories/GHSA-g8p8-94f2-28gr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41657"
},
{
"type": "PACKAGE",
"url": "https://github.com/Admidio/admidio"
},
{
"type": "WEB",
"url": "https://github.com/Admidio/admidio/releases/tag/v5.0.9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Admidio Exposes Cross-Organization Member Data via Permission Check Mismatch in contacts_data.php"
}
GHSA-G8RG-7RPR-CWR2
Vulnerability from github – Published: 2020-09-02 18:03 – Updated: 2021-08-02 14:33A missing access check in the backend module allows an authenticated backend user to export participant data for events which the user does not have access to, resulting in Information Disclosure.
Another missing access check in the backend module allows an authenticated backend user to send emails to event participants for events which the user does not have access to, resulting in Broken Access Control.
External reference: https://typo3.org/security/advisory/typo3-ext-sa-2020-017
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "derhansen/sf_event_mgt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.3.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "derhansen/sf_event_mgt"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-25026"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2020-09-02T18:03:13Z",
"nvd_published_at": "2020-09-02T17:15:00Z",
"severity": "MODERATE"
},
"details": "A missing access check in the backend module allows an authenticated backend user to export participant data for events which the user does not have access to, resulting in Information Disclosure. \n\nAnother missing access check in the backend module allows an authenticated backend user to send emails to event participants for events which the user does not have access to, resulting in Broken Access Control.\n\nExternal reference: [https://typo3.org/security/advisory/typo3-ext-sa-2020-017](https://typo3.org/security/advisory/typo3-ext-sa-2020-017)",
"id": "GHSA-g8rg-7rpr-cwr2",
"modified": "2021-08-02T14:33:59Z",
"published": "2020-09-02T18:03:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/derhansen/sf_event_mgt/security/advisories/GHSA-g8rg-7rpr-cwr2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25026"
},
{
"type": "WEB",
"url": "https://github.com/derhansen/sf_event_mgt/commit/17edcbf608b252cc1123e1279f0735f6aa28fef4"
},
{
"type": "WEB",
"url": "https://packagist.org/packages/derhansen/sf_event_mgt"
},
{
"type": "WEB",
"url": "https://typo3.org/help/security-advisories"
},
{
"type": "WEB",
"url": "https://typo3.org/security/advisory/typo3-ext-sa-2020-017"
}
],
"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"
}
],
"summary": "Information Disclosure in TYPO3 extension sf_event_mgt"
}
GHSA-G8V6-86F6-JJ9Q
Vulnerability from github – Published: 2024-08-06 06:30 – Updated: 2024-08-06 06:30Improper access control in Calibre 6.9.0 ~ 7.14.0 allow unauthenticated attackers to achieve remote code execution.
{
"affected": [],
"aliases": [
"CVE-2024-6782"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-06T04:16:46Z",
"severity": "CRITICAL"
},
"details": "Improper access control in Calibre 6.9.0 ~ 7.14.0 allow unauthenticated attackers to achieve remote code execution.",
"id": "GHSA-g8v6-86f6-jj9q",
"modified": "2024-08-06T06:30:35Z",
"published": "2024-08-06T06:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6782"
},
{
"type": "WEB",
"url": "https://github.com/kovidgoyal/calibre/commit/38a1bf50d8cd22052ae59c513816706c6445d5e9"
},
{
"type": "WEB",
"url": "https://starlabs.sg/advisories/24/24-6782"
}
],
"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-G8WG-X53J-HVJQ
Vulnerability from github – Published: 2022-05-24 19:20 – Updated: 2022-07-13 00:01Zoho Remote Access Plus Server Windows Desktop binary fixed in version 10.1.2132 is affected by an unauthorized password reset vulnerability. Because of the designed password reset mechanism, any non-admin Windows user can reset the password of the Remote Access Plus Server Admin account.
{
"affected": [],
"aliases": [
"CVE-2021-42955"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-17T13:15:00Z",
"severity": "HIGH"
},
"details": "Zoho Remote Access Plus Server Windows Desktop binary fixed in version 10.1.2132 is affected by an unauthorized password reset vulnerability. Because of the designed password reset mechanism, any non-admin Windows user can reset the password of the Remote Access Plus Server Admin account.",
"id": "GHSA-g8wg-x53j-hvjq",
"modified": "2022-07-13T00:01:43Z",
"published": "2022-05-24T19:20:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42955"
},
{
"type": "WEB",
"url": "https://medium.com/nestedif/vulnerability-disclosure-improper-acl-unauthorized-password-reset-zoho-r-a-p-62efcdceb7a6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G8XC-6MF7-H28H
Vulnerability from github – Published: 2023-05-09 21:25 – Updated: 2023-05-09 21:25Impact
There is an issue with the implementation of fine-grained access control rules (document-level security, field-level security and field masking) where they are not correctly applied to the queries during extremely rare race conditions potentially leading to incorrect access authorization. For this issue to be triggered, two concurrent requests need to land on the same instance exactly when query cache eviction happens, once every four hours.
Affected versions
OpenSearch 1.0.0-1.3.9 and 2.0.0-2.6.0
Patched versions
OpenSearch 1.3.10 and 2.7.0
For more information
If you have any questions or comments about this advisory, please contact AWS/Amazon Security via our issue reporting page (https://aws.amazon.com/security/vulnerability-reporting/) or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.opensearch.plugin:opensearch-security"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.3.10.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.opensearch.plugin:opensearch-security"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.7.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-31141"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2023-05-09T21:25:06Z",
"nvd_published_at": "2023-05-08T21:15:11Z",
"severity": "MODERATE"
},
"details": "### Impact\nThere is an issue with the implementation of fine-grained access control rules (document-level security, field-level security and field masking) where they are not correctly applied to the queries during extremely rare race conditions potentially leading to incorrect access authorization. For this issue to be triggered, two concurrent requests need to land on the same instance exactly when query cache eviction happens, once every four hours.\n\n### Affected versions\nOpenSearch 1.0.0-1.3.9 and 2.0.0-2.6.0\n\n### Patched versions\nOpenSearch 1.3.10 and 2.7.0\n\n### For more information\nIf you have any questions or comments about this advisory, please contact AWS/Amazon Security via our issue reporting page (https://aws.amazon.com/security/vulnerability-reporting/) or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.",
"id": "GHSA-g8xc-6mf7-h28h",
"modified": "2023-05-09T21:25:06Z",
"published": "2023-05-09T21:25:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/opensearch-project/security/security/advisories/GHSA-g8xc-6mf7-h28h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31141"
},
{
"type": "PACKAGE",
"url": "https://github.com/opensearch-project/security"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "OpenSearch issue with fine-grained access control during extremely rare race conditions"
}
GHSA-G929-VM5V-86GQ
Vulnerability from github – Published: 2022-05-24 17:37 – Updated: 2022-05-24 17:37An issue was discovered in Zammad before 3.4.1. Admin Users without a ticket.* permission can access Tickets.
{
"affected": [],
"aliases": [
"CVE-2020-26028"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-28T08:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Zammad before 3.4.1. Admin Users without a ticket.* permission can access Tickets.",
"id": "GHSA-g929-vm5v-86gq",
"modified": "2022-05-24T17:37:23Z",
"published": "2022-05-24T17:37:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26028"
},
{
"type": "WEB",
"url": "https://zammad.com/news/security-advisory-zaa-2020-19"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-G934-4C2X-9PCQ
Vulnerability from github – Published: 2022-05-05 00:00 – Updated: 2022-05-12 00:01Konga v0.14.9 is affected by an incorrect access control vulnerability where a specially crafted request can lead to privilege escalation.
{
"affected": [],
"aliases": [
"CVE-2021-42192"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-04T11:15:00Z",
"severity": "HIGH"
},
"details": "Konga v0.14.9 is affected by an incorrect access control vulnerability where a specially crafted request can lead to privilege escalation.",
"id": "GHSA-g934-4c2x-9pcq",
"modified": "2022-05-12T00:01:23Z",
"published": "2022-05-05T00:00:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42192"
},
{
"type": "WEB",
"url": "https://github.com/pantsel/konga/commit/d61535277aced18b5be0313ab2d124f60f649978"
},
{
"type": "WEB",
"url": "https://docs.google.com/document/d/1-YU9zWiDVUps3Mb6zos3996yvZ48vW_vfOvaJLLHc4I/edit?usp=sharing"
},
{
"type": "WEB",
"url": "https://github.com/pantsel/konga"
},
{
"type": "WEB",
"url": "https://github.com/whokilleddb/Konga-Privilege-Escalation-Exploit"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/50521"
}
],
"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"
}
]
}
GHSA-G94R-MVHR-PC74
Vulnerability from github – Published: 2026-03-04 15:30 – Updated: 2026-03-05 21:30A logic error in the remove_password() function in Checkmk GmbH's Checkmk versions <2.4.0p23, <2.3.0p43, and 2.2.0 (EOL) allows a low-privileged user to cause data loss.
{
"affected": [],
"aliases": [
"CVE-2026-3103"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-04T14:16:14Z",
"severity": "MODERATE"
},
"details": "A logic error in the remove_password() function in Checkmk GmbH\u0027s Checkmk versions \u003c2.4.0p23, \u003c2.3.0p43, and 2.2.0 (EOL) allows a low-privileged user to cause data loss.",
"id": "GHSA-g94r-mvhr-pc74",
"modified": "2026-03-05T21:30:33Z",
"published": "2026-03-04T15:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3103"
},
{
"type": "WEB",
"url": "https://checkmk.com/werk/19041"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/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-G97G-7JJM-WPHR
Vulnerability from github – Published: 2022-09-07 00:01 – Updated: 2022-09-10 00:00Broken Access Control vulnerability in Alessio Caiazza's About Me plugin <= 1.0.12 at WordPress.
{
"affected": [],
"aliases": [
"CVE-2022-36387"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-06T23:15:00Z",
"severity": "CRITICAL"
},
"details": "Broken Access Control vulnerability in Alessio Caiazza\u0027s About Me plugin \u003c= 1.0.12 at WordPress.",
"id": "GHSA-g97g-7jjm-wphr",
"modified": "2022-09-10T00:00:35Z",
"published": "2022-09-07T00:01:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36387"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/about-me/wordpress-about-me-plugin-1-0-12-broken-access-control-vulnerability/_s_id=cve"
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/about-me"
}
],
"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"
}
]
}
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.