Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect 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:30
VLAI
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.

Show details on source website

{
  "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:33
VLAI
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.

Show details on source website

{
  "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:42
VLAI
Summary
OpenClaw DM pairing-store identities could satisfy group allowlist authorization
Details

Summary

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@8bdda7a651c21e98faccdbbd73081e79cffe8be0
  • openclaw/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.

Show details on source website

{
  "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:34
VLAI
Summary
OpenClaw: QQBot streaming command could mutate config without explicit allowFrom
Details

Summary

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.

Show details on source website

{
  "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:30
VLAI
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.

Show details on source website

{
  "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:09
VLAI
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.

Show details on source website

{
  "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:31
VLAI
Details

Incorrect 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.

Show details on source website

{
  "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:06
VLAI
Summary
October CMS: Editor Sub-Permission Bypass for Asset and Blueprint File Operations
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.

Impact

  • Only exploitable by authenticated backend users with editor access who have been specifically denied the editor.cms_assets or editor.tailor_blueprints sub-permissions
  • Does not affect default permission configurations where editor users typically have all sub-permissions granted
  • Users without editor.cms_assets could manipulate theme asset files (delete, rename, move, upload, create directories)
  • Users without editor.tailor_blueprints could manipulate blueprint files (delete, rename, move, upload, create directories)
  • Users without editor.tailor_blueprints could 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 editor permission to fully trusted administrators only
  • Remove the editor permission from any user who should not have asset or blueprint management access
Show details on source website

{
  "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:54
VLAI
Summary
Froxlor has a Reseller Domain Quota Bypass via Unvalidated adminid Parameter in Domains.add()
Details

Summary

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:

  1. The domain INSERT at line 757: 'adminid' => $adminid
  2. 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

  1. Quota bypass: A reseller can create unlimited domains beyond their allocated quota, since their own domains_used counter is never incremented.
  2. Quota exhaustion DoS: The target admin's domains_used counter is incremented instead, potentially exhausting their quota and preventing legitimate domain creation.
  3. 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.
  4. 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'));
}
Show details on source website

{
  "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:01
VLAI
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.

Show details on source website

{
  "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
Architecture and Design
  • 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
Architecture and Design

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
Architecture and Design

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
Architecture and Design
  • 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
System Configuration Installation

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.