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.
5678 vulnerabilities reference this CWE, most recent first.
GHSA-JVM5-CJ73-M9QG
Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2022-12-01 00:30Canonical snapd before version 2.37.1 incorrectly performed socket owner validation, allowing an attacker to run arbitrary commands as root. This issue affects: Canonical snapd versions prior to 2.37.1.
{
"affected": [],
"aliases": [
"CVE-2019-7304"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-23T16:29:00Z",
"severity": "CRITICAL"
},
"details": "Canonical snapd before version 2.37.1 incorrectly performed socket owner validation, allowing an attacker to run arbitrary commands as root. This issue affects: Canonical snapd versions prior to 2.37.1.",
"id": "GHSA-jvm5-cj73-m9qg",
"modified": "2022-12-01T00:30:42Z",
"published": "2022-05-24T16:44:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-7304"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3887-1"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/46361"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/46362"
}
],
"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-JVQ4-XPX6-3RJC
Vulnerability from github – Published: 2022-05-24 17:09 – Updated: 2022-05-24 17:09DVR firmware in TAT-76 and TAT-77 series of products, provided by TONNET, contain misconfigured authentication mechanism. Attackers can crack the default password and gain access to the system.
{
"affected": [],
"aliases": [
"CVE-2020-3923"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-02-27T04:15:00Z",
"severity": "HIGH"
},
"details": "DVR firmware in TAT-76 and TAT-77 series of products, provided by TONNET, contain misconfigured authentication mechanism. Attackers can crack the default password and gain access to the system.",
"id": "GHSA-jvq4-xpx6-3rjc",
"modified": "2022-05-24T17:09:50Z",
"published": "2022-05-24T17:09:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3923"
},
{
"type": "WEB",
"url": "https://tvn.twcert.org.tw/taiwanvn/TVN-201910003"
},
{
"type": "WEB",
"url": "https://www.chtsecurity.com/news/4ef5eb3a-fdc3-4d78-8dd7-ec7213e2bbcf"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-JVVM-GQ28-8RGC
Vulnerability from github – Published: 2024-08-07 12:31 – Updated: 2025-03-17 09:31Incorrect User Management vulnerability in Naukowa i Akademicka Sieć Komputerowa - Państwowy Instytut Badawczy EZD RP allows logged-in user to change the password of any user, including root user, which could lead to privilege escalation. This issue affects EZD RP: from 15 before 15.84, from 16 before 16.15, from 17 before 17.2.
{
"affected": [],
"aliases": [
"CVE-2024-7265"
],
"database_specific": {
"cwe_ids": [
"CWE-286",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-07T11:15:45Z",
"severity": "HIGH"
},
"details": "Incorrect User Management vulnerability in Naukowa i Akademicka Sie\u0107 Komputerowa - Pa\u0144stwowy Instytut Badawczy EZD RP allows logged-in user to change the password of any user, including root user, which could lead to privilege escalation.\u00a0This issue affects EZD RP: from 15 before 15.84, from 16 before 16.15, from 17 before 17.2.",
"id": "GHSA-jvvm-gq28-8rgc",
"modified": "2025-03-17T09:31:01Z",
"published": "2024-08-07T12:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7265"
},
{
"type": "WEB",
"url": "https://cert.pl/en/posts/2024/08/CVE-2023-7265"
},
{
"type": "WEB",
"url": "https://cert.pl/en/posts/2024/08/CVE-2024-7265"
},
{
"type": "WEB",
"url": "https://cert.pl/posts/2024/08/CVE-2023-7265"
},
{
"type": "WEB",
"url": "https://cert.pl/posts/2024/08/CVE-2024-7265"
},
{
"type": "WEB",
"url": "https://www.gov.pl/web/ezd-rp"
}
],
"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/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:U/V:D/RE:L/U:Amber",
"type": "CVSS_V4"
}
]
}
GHSA-JVWG-PHXX-J3RP
Vulnerability from github – Published: 2026-04-21 17:15 – Updated: 2026-04-24 21:06Fine-grained sub-permission checks for asset and blueprint file operations were not enforced in the CMS and Tailor editor extensions. This only affects backend users who were explicitly granted editor access but had editor.cms_assets or editor.tailor_blueprints specifically withheld, an uncommon permission configuration. In this edge case, such users could perform file operations (create, delete, rename, move, upload) on theme assets or blueprint files despite lacking the required sub-permission. A related operator precedence error in the Tailor navigation also disclosed the theme blueprint directory tree under the same conditions.
Impact
- Only exploitable by authenticated backend users with
editoraccess who have been specifically denied theeditor.cms_assetsoreditor.tailor_blueprintssub-permissions - Does not affect default permission configurations where editor users typically have all sub-permissions granted
- Users without
editor.cms_assetscould manipulate theme asset files (delete, rename, move, upload, create directories) - Users without
editor.tailor_blueprintscould manipulate blueprint files (delete, rename, move, upload, create directories) - Users without
editor.tailor_blueprintscould view the theme blueprint navigation tree, disclosing file paths and directory structure
Patches
The vulnerability has been patched in v3.7.16 and v4.1.16. Fine-grained document type permission checks are now enforced on all asset and blueprint file operation commands, and the navigation node condition logic has been corrected. All users are encouraged to upgrade to the latest patched version.
Workarounds
- Restrict the
editorpermission to fully trusted administrators only - Remove the
editorpermission from any user who should not have asset or blueprint management access
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "october/system"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.1.16"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "october/system"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.7.16"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-29179"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-21T17:15:38Z",
"nvd_published_at": "2026-04-21T17:16:36Z",
"severity": "LOW"
},
"details": "Fine-grained sub-permission checks for asset and blueprint file operations were not enforced in the CMS and Tailor editor extensions. This only affects backend users who were explicitly granted `editor` access but had `editor.cms_assets` or `editor.tailor_blueprints` specifically withheld, an uncommon permission configuration. In this edge case, such users could perform file operations (create, delete, rename, move, upload) on theme assets or blueprint files despite lacking the required sub-permission. A related operator precedence error in the Tailor navigation also disclosed the theme blueprint directory tree under the same conditions.\n\n### Impact\n- Only exploitable by authenticated backend users with `editor` access who have been specifically denied the `editor.cms_assets` or `editor.tailor_blueprints` sub-permissions\n- Does not affect default permission configurations where editor users typically have all sub-permissions granted\n- Users without `editor.cms_assets` could manipulate theme asset files (delete, rename, move, upload, create directories)\n- Users without `editor.tailor_blueprints` could manipulate blueprint files (delete, rename, move, upload, create directories)\n- Users without `editor.tailor_blueprints` could view the theme blueprint navigation tree, disclosing file paths and directory structure\n\n### Patches\nThe vulnerability has been patched in v3.7.16 and v4.1.16. Fine-grained document type permission checks are now enforced on all asset and blueprint file operation commands, and the navigation node condition logic has been corrected. All users are encouraged to upgrade to the latest patched version.\n\n### Workarounds\n- Restrict the `editor` permission to fully trusted administrators only\n- Remove the `editor` permission from any user who should not have asset or blueprint management access",
"id": "GHSA-jvwg-phxx-j3rp",
"modified": "2026-04-24T21:06:39Z",
"published": "2026-04-21T17:15:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/octobercms/october/security/advisories/GHSA-jvwg-phxx-j3rp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29179"
},
{
"type": "PACKAGE",
"url": "https://github.com/octobercms/october"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "October CMS: Editor Sub-Permission Bypass for Asset and Blueprint File Operations"
}
GHSA-JVX4-XV3M-HRJ4
Vulnerability from github – Published: 2026-04-16 00:46 – Updated: 2026-04-24 20:54Summary
In Domains.add(), the adminid parameter is accepted from user input and used without validation when the calling reseller does not have the customers_see_all permission. This allows a reseller to attribute newly created domains to any other admin, bypassing their own domain quota (since the wrong admin's domains_used counter is incremented) and potentially exhausting another admin's quota.
Details
In lib/Froxlor/Api/Commands/Domains.php, the add() method accepts adminid as an optional parameter at line 327:
$adminid = intval($this->getParam('adminid', true, $this->getUserDetail('adminid')));
The validation for this parameter only runs when the caller has customers_see_all == '1' (lines 410-421):
if ($this->getUserDetail('customers_see_all') == '1' && $adminid != $this->getUserDetail('adminid')) {
$admin_stmt = Database::prepare("
SELECT * FROM `" . TABLE_PANEL_ADMINS . "`
WHERE `adminid` = :adminid AND (`domains_used` < `domains` OR `domains` = '-1')");
$admin = Database::pexecute_first($admin_stmt, [
'adminid' => $adminid
], true, true);
if (empty($admin)) {
Response::dynamicError("Selected admin cannot have any more domains or could not be found");
}
unset($admin);
}
When a reseller does not have customers_see_all (the common case for limited resellers), there is no else branch to force $adminid = $this->getUserDetail('adminid'). The unvalidated $adminid flows directly into:
- The domain INSERT at line 757:
'adminid' => $adminid - The quota increment at lines 862-868:
$upd_stmt = Database::prepare("
UPDATE `" . TABLE_PANEL_ADMINS . "` SET `domains_used` = `domains_used` + 1
WHERE `adminid` = :adminid
");
Database::pexecute($upd_stmt, ['adminid' => $adminid], true, true);
Compare with Domains.update() at lines 1386-1387 which correctly handles this case:
} else {
$adminid = $result['adminid'];
}
The initial quota check at line 321 checks the caller's own quota ($this->getUserDetail('domains_used')), but since the caller's domains_used is never incremented (the wrong admin's counter is incremented instead), this check passes indefinitely.
Note: The getCustomerData() call at line 407 does correctly restrict the customerid to the reseller's own customers (via Customers.get which filters by adminid). However, this does not prevent the adminid field itself from being spoofed.
PoC
# Step 1: Create a domain with the reseller's API key, specifying a different admin's ID
curl -s -u RESELLER_API_KEY:RESELLER_API_SECRET -X POST https://froxlor.example/api.php \
-d '{"command": "Domains.add", "params": {"domain": "bypass-test-1.com", "customerid": 3, "adminid": 1}}'
# Where:
# - RESELLER_API_KEY:RESELLER_API_SECRET = API credentials for a reseller WITHOUT customers_see_all
# - customerid=3 = one of the reseller's own customers
# - adminid=1 = the super-admin's ID (or any other admin's ID)
# Step 2: Verify the domain was created with adminid=1
# In the database: SELECT adminid, domain FROM panel_domains WHERE domain='bypass-test-1.com';
# Expected: adminid=1
# Step 3: Check the reseller's quota was NOT incremented
# In the database: SELECT adminid, domains_used, domains FROM panel_admins WHERE adminid=<reseller_id>;
# Expected: domains_used unchanged
# Step 4: Check the target admin's quota WAS incremented
# In the database: SELECT adminid, domains_used, domains FROM panel_admins WHERE adminid=1;
# Expected: domains_used incremented by 1
# Step 5: Repeat with different domain names to demonstrate unlimited creation
curl -s -u RESELLER_API_KEY:RESELLER_API_SECRET -X POST https://froxlor.example/api.php \
-d '{"command": "Domains.add", "params": {"domain": "bypass-test-2.com", "customerid": 3, "adminid": 1}}'
curl -s -u RESELLER_API_KEY:RESELLER_API_SECRET -X POST https://froxlor.example/api.php \
-d '{"command": "Domains.add", "params": {"domain": "bypass-test-3.com", "customerid": 3, "adminid": 1}}'
# The reseller's domains_used remains unchanged, allowing indefinite creation
Impact
- Quota bypass: A reseller can create unlimited domains beyond their allocated quota, since their own
domains_usedcounter is never incremented. - Quota exhaustion DoS: The target admin's
domains_usedcounter is incremented instead, potentially exhausting their quota and preventing legitimate domain creation. - Data integrity violation: Domains are associated with an admin who does not own the customer, breaking the ownership model. These domains become invisible to the reseller in domain listings (which filter by
adminid) but remain active on the server. - Accounting inaccuracy: Resource usage reporting and billing tied to admin quotas becomes incorrect.
Recommended Fix
Add an else branch to force $adminid to the caller's own admin ID when customers_see_all != '1', consistent with the pattern used in Domains.update():
// In lib/Froxlor/Api/Commands/Domains.php, after line 421:
if ($this->getUserDetail('customers_see_all') == '1' && $adminid != $this->getUserDetail('adminid')) {
$admin_stmt = Database::prepare("
SELECT * FROM `" . TABLE_PANEL_ADMINS . "`
WHERE `adminid` = :adminid AND (`domains_used` < `domains` OR `domains` = '-1')");
$admin = Database::pexecute_first($admin_stmt, [
'adminid' => $adminid
], true, true);
if (empty($admin)) {
Response::dynamicError("Selected admin cannot have any more domains or could not be found");
}
unset($admin);
} else {
// Force adminid to the caller's own ID when they don't have customers_see_all
$adminid = intval($this->getUserDetail('adminid'));
}
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.3.5"
},
"package": {
"ecosystem": "Packagist",
"name": "froxlor/froxlor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41233"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-16T00:46:47Z",
"nvd_published_at": "2026-04-23T05:16:05Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nIn `Domains.add()`, the `adminid` parameter is accepted from user input and used without validation when the calling reseller does not have the `customers_see_all` permission. This allows a reseller to attribute newly created domains to any other admin, bypassing their own domain quota (since the wrong admin\u0027s `domains_used` counter is incremented) and potentially exhausting another admin\u0027s quota.\n\n## Details\n\nIn `lib/Froxlor/Api/Commands/Domains.php`, the `add()` method accepts `adminid` as an optional parameter at line 327:\n\n```php\n$adminid = intval($this-\u003egetParam(\u0027adminid\u0027, true, $this-\u003egetUserDetail(\u0027adminid\u0027)));\n```\n\nThe validation for this parameter only runs when the caller has `customers_see_all == \u00271\u0027` (lines 410-421):\n\n```php\nif ($this-\u003egetUserDetail(\u0027customers_see_all\u0027) == \u00271\u0027 \u0026\u0026 $adminid != $this-\u003egetUserDetail(\u0027adminid\u0027)) {\n $admin_stmt = Database::prepare(\"\n SELECT * FROM `\" . TABLE_PANEL_ADMINS . \"`\n WHERE `adminid` = :adminid AND (`domains_used` \u003c `domains` OR `domains` = \u0027-1\u0027)\");\n $admin = Database::pexecute_first($admin_stmt, [\n \u0027adminid\u0027 =\u003e $adminid\n ], true, true);\n if (empty($admin)) {\n Response::dynamicError(\"Selected admin cannot have any more domains or could not be found\");\n }\n unset($admin);\n}\n```\n\nWhen a reseller does **not** have `customers_see_all` (the common case for limited resellers), there is no `else` branch to force `$adminid = $this-\u003egetUserDetail(\u0027adminid\u0027)`. The unvalidated `$adminid` flows directly into:\n\n1. The domain INSERT at line 757: `\u0027adminid\u0027 =\u003e $adminid`\n2. The quota increment at lines 862-868:\n```php\n$upd_stmt = Database::prepare(\"\n UPDATE `\" . TABLE_PANEL_ADMINS . \"` SET `domains_used` = `domains_used` + 1\n WHERE `adminid` = :adminid\n\");\nDatabase::pexecute($upd_stmt, [\u0027adminid\u0027 =\u003e $adminid], true, true);\n```\n\nCompare with `Domains.update()` at lines 1386-1387 which correctly handles this case:\n\n```php\n} else {\n $adminid = $result[\u0027adminid\u0027];\n}\n```\n\nThe initial quota check at line 321 checks the *caller\u0027s* own quota (`$this-\u003egetUserDetail(\u0027domains_used\u0027)`), but since the caller\u0027s `domains_used` is never incremented (the wrong admin\u0027s counter is incremented instead), this check passes indefinitely.\n\nNote: The `getCustomerData()` call at line 407 does correctly restrict the `customerid` to the reseller\u0027s own customers (via `Customers.get` which filters by `adminid`). However, this does not prevent the `adminid` field itself from being spoofed.\n\n## PoC\n\n```bash\n# Step 1: Create a domain with the reseller\u0027s API key, specifying a different admin\u0027s ID\ncurl -s -u RESELLER_API_KEY:RESELLER_API_SECRET -X POST https://froxlor.example/api.php \\\n -d \u0027{\"command\": \"Domains.add\", \"params\": {\"domain\": \"bypass-test-1.com\", \"customerid\": 3, \"adminid\": 1}}\u0027\n\n# Where:\n# - RESELLER_API_KEY:RESELLER_API_SECRET = API credentials for a reseller WITHOUT customers_see_all\n# - customerid=3 = one of the reseller\u0027s own customers\n# - adminid=1 = the super-admin\u0027s ID (or any other admin\u0027s ID)\n\n# Step 2: Verify the domain was created with adminid=1\n# In the database: SELECT adminid, domain FROM panel_domains WHERE domain=\u0027bypass-test-1.com\u0027;\n# Expected: adminid=1\n\n# Step 3: Check the reseller\u0027s quota was NOT incremented\n# In the database: SELECT adminid, domains_used, domains FROM panel_admins WHERE adminid=\u003creseller_id\u003e;\n# Expected: domains_used unchanged\n\n# Step 4: Check the target admin\u0027s quota WAS incremented\n# In the database: SELECT adminid, domains_used, domains FROM panel_admins WHERE adminid=1;\n# Expected: domains_used incremented by 1\n\n# Step 5: Repeat with different domain names to demonstrate unlimited creation\ncurl -s -u RESELLER_API_KEY:RESELLER_API_SECRET -X POST https://froxlor.example/api.php \\\n -d \u0027{\"command\": \"Domains.add\", \"params\": {\"domain\": \"bypass-test-2.com\", \"customerid\": 3, \"adminid\": 1}}\u0027\n\ncurl -s -u RESELLER_API_KEY:RESELLER_API_SECRET -X POST https://froxlor.example/api.php \\\n -d \u0027{\"command\": \"Domains.add\", \"params\": {\"domain\": \"bypass-test-3.com\", \"customerid\": 3, \"adminid\": 1}}\u0027\n\n# The reseller\u0027s domains_used remains unchanged, allowing indefinite creation\n```\n\n## Impact\n\n1. **Quota bypass**: A reseller can create unlimited domains beyond their allocated quota, since their own `domains_used` counter is never incremented.\n2. **Quota exhaustion DoS**: The target admin\u0027s `domains_used` counter is incremented instead, potentially exhausting their quota and preventing legitimate domain creation.\n3. **Data integrity violation**: Domains are associated with an admin who does not own the customer, breaking the ownership model. These domains become invisible to the reseller in domain listings (which filter by `adminid`) but remain active on the server.\n4. **Accounting inaccuracy**: Resource usage reporting and billing tied to admin quotas becomes incorrect.\n\n## Recommended Fix\n\nAdd an `else` branch to force `$adminid` to the caller\u0027s own admin ID when `customers_see_all != \u00271\u0027`, consistent with the pattern used in `Domains.update()`:\n\n```php\n// In lib/Froxlor/Api/Commands/Domains.php, after line 421:\n\nif ($this-\u003egetUserDetail(\u0027customers_see_all\u0027) == \u00271\u0027 \u0026\u0026 $adminid != $this-\u003egetUserDetail(\u0027adminid\u0027)) {\n $admin_stmt = Database::prepare(\"\n SELECT * FROM `\" . TABLE_PANEL_ADMINS . \"`\n WHERE `adminid` = :adminid AND (`domains_used` \u003c `domains` OR `domains` = \u0027-1\u0027)\");\n $admin = Database::pexecute_first($admin_stmt, [\n \u0027adminid\u0027 =\u003e $adminid\n ], true, true);\n if (empty($admin)) {\n Response::dynamicError(\"Selected admin cannot have any more domains or could not be found\");\n }\n unset($admin);\n} else {\n // Force adminid to the caller\u0027s own ID when they don\u0027t have customers_see_all\n $adminid = intval($this-\u003egetUserDetail(\u0027adminid\u0027));\n}\n```",
"id": "GHSA-jvx4-xv3m-hrj4",
"modified": "2026-04-24T20:54:37Z",
"published": "2026-04-16T00:46:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/froxlor/froxlor/security/advisories/GHSA-jvx4-xv3m-hrj4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41233"
},
{
"type": "WEB",
"url": "https://github.com/froxlor/froxlor/commit/bf47ba15329506e9f9662f9462463932aa80dff5"
},
{
"type": "PACKAGE",
"url": "https://github.com/froxlor/froxlor"
},
{
"type": "WEB",
"url": "https://github.com/froxlor/froxlor/releases/tag/2.3.6"
}
],
"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"
}
],
"summary": "Froxlor has a Reseller Domain Quota Bypass via Unvalidated adminid Parameter in Domains.add()"
}
GHSA-JW43-345W-92RC
Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2022-07-13 00:01Affected versions of Atlassian Jira Server and Data Center allow users who have watched an issue to continue receiving updates on the issue even after their Jira account is revoked, via a Broken Access Control vulnerability in the issue notification feature. The affected versions are before version 8.19.0.
{
"affected": [],
"aliases": [
"CVE-2021-39119"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-01T23:15:00Z",
"severity": "MODERATE"
},
"details": "Affected versions of Atlassian Jira Server and Data Center allow users who have watched an issue to continue receiving updates on the issue even after their Jira account is revoked, via a Broken Access Control vulnerability in the issue notification feature. The affected versions are before version 8.19.0.",
"id": "GHSA-jw43-345w-92rc",
"modified": "2022-07-13T00:01:36Z",
"published": "2022-05-24T19:12:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39119"
},
{
"type": "WEB",
"url": "https://jira.atlassian.com/browse/JRASERVER-72737"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-JW59-9V6J-FPWH
Vulnerability from github – Published: 2022-11-01 12:00 – Updated: 2022-11-02 19:00A remote unprivileged attacker can interact with the configuration interface of a Flexi-Compact FLX3-CPUC1 or FLX3-CPUC2 running an affected firmware version to potentially impact the availability of the FlexiCompact.
{
"affected": [],
"aliases": [
"CVE-2022-27583"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-31T20:15:00Z",
"severity": "CRITICAL"
},
"details": "A remote unprivileged attacker can interact with the configuration interface of a Flexi-Compact FLX3-CPUC1 or FLX3-CPUC2 running an affected firmware version to potentially impact the availability of the FlexiCompact.",
"id": "GHSA-jw59-9v6j-fpwh",
"modified": "2022-11-02T19:00:30Z",
"published": "2022-11-01T12:00:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27583"
},
{
"type": "WEB",
"url": "https://sick.com/psirt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JW62-3VW4-M49F
Vulnerability from github – Published: 2022-03-31 00:00 – Updated: 2022-04-06 00:01In PackageManager, there is a possible way to change the splash screen theme of other apps due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-12LAndroid ID: A-206474016
{
"affected": [],
"aliases": [
"CVE-2021-39750"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-30T16:15:00Z",
"severity": "HIGH"
},
"details": "In PackageManager, there is a possible way to change the splash screen theme of other apps due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-12LAndroid ID: A-206474016",
"id": "GHSA-jw62-3vw4-m49f",
"modified": "2022-04-06T00:01:54Z",
"published": "2022-03-31T00:00:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39750"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/android-12l"
}
],
"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-JW87-V85H-8H3X
Vulnerability from github – Published: 2022-01-11 00:00 – Updated: 2022-07-13 00:01An issue was discovered in dst-admin v1.3.0. The product has an unauthorized arbitrary file download vulnerability that can expose sensitive information.
{
"affected": [],
"aliases": [
"CVE-2021-44586"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-10T15:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in dst-admin v1.3.0. The product has an unauthorized arbitrary file download vulnerability that can expose sensitive information.",
"id": "GHSA-jw87-v85h-8h3x",
"modified": "2022-07-13T00:01:49Z",
"published": "2022-01-11T00:00:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44586"
},
{
"type": "WEB",
"url": "https://github.com/qinming99/dst-admin/issues/28"
}
],
"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-JW8P-XR8R-2W5H
Vulnerability from github – Published: 2025-06-09 15:31 – Updated: 2025-10-06 21:30Incorrect authorization vulnerability in TCMAN's GIM v11. This vulnerability allows an unprivileged attacker to create a user and assign it many privileges by sending a POST request to /PC/frmGestionUser.aspx/updateUser.
{
"affected": [],
"aliases": [
"CVE-2025-40670"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-09T13:15:22Z",
"severity": "HIGH"
},
"details": "Incorrect authorization vulnerability in TCMAN\u0027s GIM v11. This vulnerability allows an unprivileged attacker to create a user and assign it many privileges by sending a POST request to /PC/frmGestionUser.aspx/updateUser.",
"id": "GHSA-jw8p-xr8r-2w5h",
"modified": "2025-10-06T21:30:44Z",
"published": "2025-06-09T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40670"
},
{
"type": "WEB",
"url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-tcman-gim-1"
}
],
"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:N/VI:H/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"
}
]
}
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.