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-JV3H-VGC4-3286
Vulnerability from github – Published: 2023-03-29 21:30 – Updated: 2023-04-06 18:30This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of NETGEAR R6700v3 1.0.4.120_10.0.91 routers. Authentication is not required to exploit this vulnerability. The specific flaw exists within readycloud_control.cgi. The issue results from incorrect string matching logic when accessing protected pages. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-15762.
{
"affected": [],
"aliases": [
"CVE-2022-27645"
],
"database_specific": {
"cwe_ids": [
"CWE-306",
"CWE-697",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-29T19:15:00Z",
"severity": "HIGH"
},
"details": "This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of NETGEAR R6700v3 1.0.4.120_10.0.91 routers. Authentication is not required to exploit this vulnerability. The specific flaw exists within readycloud_control.cgi. The issue results from incorrect string matching logic when accessing protected pages. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-15762.",
"id": "GHSA-jv3h-vgc4-3286",
"modified": "2023-04-06T18:30:18Z",
"published": "2023-03-29T21:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27645"
},
{
"type": "WEB",
"url": "https://kb.netgear.com/000064722/Security-Advisory-for-Sensitive-Information-Disclosure-on-Some-Routers-and-Fixed-Wireless-Products-PSV-2021-0325"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-22-522"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JV46-GR4P-7XP9
Vulnerability from github – Published: 2025-02-18 18:33 – Updated: 2025-02-18 18:33Insecure Permissions in Atos Eviden IDRA and IDCA before 2.7.0. A highly trusted role (Config Admin) could exceed their configuration privileges in a multi-partition environment and access some confidential data. Data integrity and availability is not at risk.
{
"affected": [],
"aliases": [
"CVE-2024-39328"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-18T18:15:20Z",
"severity": "MODERATE"
},
"details": "Insecure Permissions in Atos Eviden IDRA and IDCA before 2.7.0. A highly trusted role (Config Admin) could exceed their configuration privileges in a multi-partition environment and access some confidential data. Data integrity and availability is not at risk.",
"id": "GHSA-jv46-gr4p-7xp9",
"modified": "2025-02-18T18:33:21Z",
"published": "2025-02-18T18:33:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39328"
},
{
"type": "WEB",
"url": "https://eviden.com/solutions/digital-security/digital-identity"
},
{
"type": "WEB",
"url": "https://support.bull.com/ols/product/security/psirt/security-bulletins/potential-privilege-escalation-in-idpki-psirt-1335-tlp-clear-version-2-10-cve-2024-39327-cve-2024-39328-cve-2024-51505/view"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-JV6R-27WW-4GW4
Vulnerability from github – Published: 2026-03-03 19:17 – Updated: 2026-03-25 18:42Summary
DM pairing-store identities were incorrectly eligible for group allowlist authorization checks, enabling cross-context authorization in group message paths.
Details
In affected versions, group allowlist evaluation could inherit identities from the DM pairing store. A sender approved via DM pairing could satisfy group sender allowlist checks without being explicitly present in groupAllowFrom.
This is an authorization-policy boundary issue between DM pairing and group allowlists.
Affected Packages / Versions
openclaw(npm): affected<= 2026.2.25(latest published npm version at triage time)openclaw(npm): patched>= 2026.2.26(planned next release)
Fix Commit(s)
openclaw/openclaw@8bdda7a651c21e98faccdbbd73081e79cffe8be0openclaw/openclaw@051fdcc428129446e7c084260f837b7284279ce9
Release Process Note
patched_versions is pre-set to the planned next release (2026.2.26) so once npm release is published, maintainers can publish the advisory without additional metadata edits.
Maintainer Timeline Note
Maintainers landed the initial fix before this report was filed; this report still provided useful independent confirmation of the issue class and exploit path.
OpenClaw thanks @tdjackey for reporting.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2026.2.25"
},
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.2.26"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32027"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-285",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-03T19:17:22Z",
"nvd_published_at": "2026-03-19T22:16:37Z",
"severity": "HIGH"
},
"details": "## Summary\nDM pairing-store identities were incorrectly eligible for group allowlist authorization checks, enabling cross-context authorization in group message paths.\n\n## Details\nIn affected versions, group allowlist evaluation could inherit identities from the DM pairing store. A sender approved via DM pairing could satisfy group sender allowlist checks without being explicitly present in `groupAllowFrom`.\n\nThis is an authorization-policy boundary issue between DM pairing and group allowlists.\n\n## Affected Packages / Versions\n- `openclaw` (npm): affected `\u003c= 2026.2.25` (latest published npm version at triage time)\n- `openclaw` (npm): patched `\u003e= 2026.2.26` (planned next release)\n\n## Fix Commit(s)\n- `openclaw/openclaw@8bdda7a651c21e98faccdbbd73081e79cffe8be0`\n- `openclaw/openclaw@051fdcc428129446e7c084260f837b7284279ce9`\n\n## Release Process Note\n`patched_versions` is pre-set to the planned next release (`2026.2.26`) so once npm release is published, maintainers can publish the advisory without additional metadata edits.\n\n## Maintainer Timeline Note\nMaintainers landed the initial fix before this report was filed; this report still provided useful independent confirmation of the issue class and exploit path.\n\nOpenClaw thanks @tdjackey for reporting.",
"id": "GHSA-jv6r-27ww-4gw4",
"modified": "2026-03-25T18:42:22Z",
"published": "2026-03-03T19:17:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jv6r-27ww-4gw4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32027"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/051fdcc428129446e7c084260f837b7284279ce9"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/8bdda7a651c21e98faccdbbd73081e79cffe8be0"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-improper-authorization-via-dm-pairing-store-identity-inheritance-in-group-allowlist"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw DM pairing-store identities could satisfy group allowlist authorization"
}
GHSA-JVM4-4J77-39P6
Vulnerability from github – Published: 2026-07-02 16:34 – Updated: 2026-07-02 16:34Summary
QQBot streaming command could mutate config without explicit allowFrom. In affected versions, a QQBot sender reaching the affected command could change configuration without requiring an explicit non-wildcard allowlist entry.
This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.
Impact
When the affected feature is enabled and reachable, this could modify QQBot streaming configuration outside the intended admin policy. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path.
Patched Versions
The first stable patched version is 2026.4.29.
Mitigations
disable the command or restrict it to explicit trusted QQBot senders until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2026.4.27"
},
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.4.29"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-02T16:34:39Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nQQBot streaming command could mutate config without explicit allowFrom. In affected versions, a QQBot sender reaching the affected command could change configuration without requiring an explicit non-wildcard allowlist entry.\n\nThis advisory is scoped to the named feature and configuration. It does not change OpenClaw\u0027s trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.\n\n### Impact\n\nWhen the affected feature is enabled and reachable, this could modify QQBot streaming configuration outside the intended admin policy. Practical impact depends on the operator\u0027s configuration and whether lower-trust input can reach that path.\n\n### Patched Versions\n\nThe first stable patched version is `2026.4.29`.\n\n### Mitigations\n\ndisable the command or restrict it to explicit trusted QQBot senders until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.",
"id": "GHSA-jvm4-4j77-39p6",
"modified": "2026-07-02T16:34:39Z",
"published": "2026-07-02T16:34:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jvm4-4j77-39p6"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw: QQBot streaming command could mutate config without explicit allowFrom"
}
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"
}
]
}
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.