Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

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.

5659 vulnerabilities reference this CWE, most recent first.

GHSA-7CX6-7887-9RWV

Vulnerability from github – Published: 2022-05-13 01:19 – Updated: 2022-05-13 01:19
VLAI
Details

The userfaultfd implementation in the Linux kernel before 4.19.7 mishandles access control for certain UFFDIO_ ioctl calls, as demonstrated by allowing local users to write data into holes in a tmpfs file (if the user has read-only access to that file, and that file contains holes), related to fs/userfaultfd.c and mm/userfaultfd.c.

Severity
5.5 (Medium)
CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-18397"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-12-12T10:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The userfaultfd implementation in the Linux kernel before 4.19.7 mishandles access control for certain UFFDIO_ ioctl calls, as demonstrated by allowing local users to write data into holes in a tmpfs file (if the user has read-only access to that file, and that file contains holes), related to fs/userfaultfd.c and mm/userfaultfd.c.",
  "id": "GHSA-7cx6-7887-9rwv",
  "modified": "2022-05-13T01:19:36Z",
  "published": "2022-05-13T01:19:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-18397"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torvalds/linux/commit/29ec90660d68bbdd69507c1c8b4e33aa299278b1"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHBA-2019:0327"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:0163"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:0202"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:0324"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:0831"
    },
    {
      "type": "WEB",
      "url": "https://bugs.chromium.org/p/project-zero/issues/detail?id=1700"
    },
    {
      "type": "WEB",
      "url": "https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.87"
    },
    {
      "type": "WEB",
      "url": "https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.7"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3901-1"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3901-2"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3903-1"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3903-2"
    },
    {
      "type": "WEB",
      "url": "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=29ec90660d68bbdd69507c1c8b4e33aa299278b1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7CXP-C5MG-3M9C

Vulnerability from github – Published: 2022-05-13 00:00 – Updated: 2022-05-22 00:00
VLAI
Details

Improper access control for the Intel(R) Killer(TM) Control Center software before version 2.4.3337.0 may allow an authorized user to potentially enable escalation of privilege via local access.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-26258"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-12T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Improper access control for the Intel(R) Killer(TM) Control Center software before version 2.4.3337.0 may allow an authorized user to potentially enable escalation of privilege via local access.",
  "id": "GHSA-7cxp-c5mg-3m9c",
  "modified": "2022-05-22T00:00:35Z",
  "published": "2022-05-13T00:00:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26258"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00644.html"
    }
  ],
  "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-7F4Q-9RQH-X36P

Vulnerability from github – Published: 2026-03-03 00:41 – Updated: 2026-03-30 13:46
VLAI
Summary
OpenClaw: macOS optional allowlist basename matching could bypass path-based policy
Details

Summary

On macOS node-host, optional exec-approval allowlist mode previously treated basename-only entries (for example echo) as trusted command matches. This could allow a same-name local binary (for example ./echo) to run without approval under security=allowlist + ask=on-miss.

Scope / Preconditions

  • macOS node-host path.
  • Optional exec approvals feature enabled with security=allowlist.
  • Basename-only allowlist entries configured.

Default install posture is not impacted: security=deny by default.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Latest published npm version at triage time: 2026.2.21-2
  • Vulnerable range: <=2026.2.21-2
  • Planned patched version (next release): >= 2026.2.22

Remediation

  • Enforced path-only allowlist matching on macOS node-host (basename fallback removed).
  • Added migration for legacy basename allowlist entries to last-resolved paths when available.
  • UI/store validation now rejects non-path allowlist patterns.

Fix Commit(s)

  • dd41fadcaf58fd9deb963d6e163c56161e7b35dd

Release Process Note

Patched version is pre-set for the planned next release (2026.2.22). Once that npm release is out, advisory can be published without further field edits.

OpenClaw thanks @tdjackey for reporting.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
5.1 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32016"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T00:41:20Z",
    "nvd_published_at": "2026-03-19T22:16:35Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nOn macOS node-host, optional exec-approval allowlist mode previously treated basename-only entries (for example `echo`) as trusted command matches.\nThis could allow a same-name local binary (for example `./echo`) to run without approval under `security=allowlist` + `ask=on-miss`.\n\n### Scope / Preconditions\n- macOS node-host path.\n- Optional exec approvals feature enabled with `security=allowlist`.\n- Basename-only allowlist entries configured.\n\nDefault install posture is not impacted: `security=deny` by default.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published npm version at triage time: `2026.2.21-2`\n- Vulnerable range: `\u003c=2026.2.21-2`\n- Planned patched version (next release): `\u003e= 2026.2.22`\n\n### Remediation\n- Enforced path-only allowlist matching on macOS node-host (basename fallback removed).\n- Added migration for legacy basename allowlist entries to last-resolved paths when available.\n- UI/store validation now rejects non-path allowlist patterns.\n\n### Fix Commit(s)\n- dd41fadcaf58fd9deb963d6e163c56161e7b35dd\n\n### Release Process Note\nPatched version is pre-set for the planned next release (`2026.2.22`). Once that npm release is out, advisory can be published without further field edits.\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-7f4q-9rqh-x36p",
  "modified": "2026-03-30T13:46:20Z",
  "published": "2026-03-03T00:41:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-7f4q-9rqh-x36p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32016"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/dd41fadcaf58fd9deb963d6e163c56161e7b35dd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-path-traversal-via-basename-only-allowlist-matching-on-macos"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: macOS optional allowlist basename matching could bypass path-based policy"
}

GHSA-7F5P-94W7-8F4W

Vulnerability from github – Published: 2025-01-21 21:30 – Updated: 2025-01-21 21:30
VLAI
Details

Vulnerability in the PeopleSoft Enterprise FIN eSettlements product of Oracle PeopleSoft (component: eSettlements). The supported version that is affected is 9.2. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise PeopleSoft Enterprise FIN eSettlements. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of PeopleSoft Enterprise FIN eSettlements accessible data as well as unauthorized read access to a subset of PeopleSoft Enterprise FIN eSettlements accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N).

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-21539"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-21T21:15:20Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the PeopleSoft Enterprise FIN eSettlements product of Oracle PeopleSoft (component: eSettlements).   The supported version that is affected is 9.2. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise PeopleSoft Enterprise FIN eSettlements.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of PeopleSoft Enterprise FIN eSettlements accessible data as well as  unauthorized read access to a subset of PeopleSoft Enterprise FIN eSettlements accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N).",
  "id": "GHSA-7f5p-94w7-8f4w",
  "modified": "2025-01-21T21:30:56Z",
  "published": "2025-01-21T21:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21539"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2025.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7FF8-XJH3-MGH6

Vulnerability from github – Published: 2026-03-03 22:13 – Updated: 2026-03-03 22:13
VLAI
Summary
OpenClaw's non-default autoAllowSkills setting could bypass on-miss exec prompt
Details

Summary

In openclaw versions up to and including 2026.2.22-2, a non-default exec-approval configuration could allow a skill-name collision to bypass an ask=on-miss prompt.

When autoAllowSkills=true, a path-scoped executable such as ./skill-bin could resolve to basename skill-bin, satisfy the skills allowlist segment, and run without prompting for approval.

Affected Packages / Versions

  • Package: npm openclaw
  • Affected versions: <= 2026.2.22-2
  • Patched versions: >= 2026.2.23 (released)

Configuration Scope (Not Default)

This behavior requires non-default settings and does not affect default installs.

Required conditions: - autoAllowSkills=true (default is false) - system.run with security=allowlist - ask=on-miss

Technical Details

The allowlist evaluator accepted skills satisfaction by bin-name match, so ./skill-bin could match skillBins.has("skill-bin") after resolution.

The fix hardens skill auto-allow matching by requiring: - a pathless invocation token (no / or \\), and - a trusted resolved executable path for that skill bin on the machine where skills run.

This preserves normal skill-bin ... behavior while preventing ./<skill-bin> and absolute-path basename collisions from auto-satisfying skills.

Impact

In affected non-default configurations, approval prompts could be skipped for commands that should have required operator confirmation.

Fix Commit(s)

  • ffd63b7a2c4c6d5aeb4710ef951d5794ad7ad77b (fix(security): trust resolved skill-bin paths in allowlist auto-allow)

OpenClaw thanks @tdjackey for reporting.

Severity
7.3 (High)
CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.2.22-2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-266",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T22:13:53Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nIn `openclaw` versions up to and including `2026.2.22-2`, a non-default exec-approval configuration could allow a skill-name collision to bypass an `ask=on-miss` prompt.\n\nWhen `autoAllowSkills=true`, a path-scoped executable such as `./skill-bin` could resolve to basename `skill-bin`, satisfy the `skills` allowlist segment, and run without prompting for approval.\n\n### Affected Packages / Versions\n- Package: `npm openclaw`\n- Affected versions: `\u003c= 2026.2.22-2`\n- Patched versions: `\u003e= 2026.2.23` (released)\n\n### Configuration Scope (Not Default)\nThis behavior requires non-default settings and does not affect default installs.\n\nRequired conditions:\n- `autoAllowSkills=true` (default is `false`)\n- `system.run` with `security=allowlist`\n- `ask=on-miss`\n\n### Technical Details\nThe allowlist evaluator accepted `skills` satisfaction by bin-name match, so `./skill-bin` could match `skillBins.has(\"skill-bin\")` after resolution.\n\nThe fix hardens skill auto-allow matching by requiring:\n- a pathless invocation token (no `/` or `\\\\`), and\n- a trusted resolved executable path for that skill bin on the machine where skills run.\n\nThis preserves normal `skill-bin ...` behavior while preventing `./\u003cskill-bin\u003e` and absolute-path basename collisions from auto-satisfying `skills`.\n\n### Impact\nIn affected non-default configurations, approval prompts could be skipped for commands that should have required operator confirmation.\n\n### Fix Commit(s)\n- `ffd63b7a2c4c6d5aeb4710ef951d5794ad7ad77b` (`fix(security): trust resolved skill-bin paths in allowlist auto-allow`)\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-7ff8-xjh3-mgh6",
  "modified": "2026-03-03T22:13:53Z",
  "published": "2026-03-03T22:13:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-7ff8-xjh3-mgh6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/ffd63b7a2c4c6d5aeb4710ef951d5794ad7ad77b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw\u0027s non-default autoAllowSkills setting could bypass on-miss exec prompt"
}

GHSA-7FGJ-RHF2-G7V4

Vulnerability from github – Published: 2025-09-05 18:31 – Updated: 2025-09-05 21:32
VLAI
Details

In onCreate of NotificationAccessConfirmationActivity.java, there is a possible incorrect verification of proper intent filters in NLS due to a logic error in the code. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-26442"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-04T18:15:43Z",
    "severity": "MODERATE"
  },
  "details": "In onCreate of NotificationAccessConfirmationActivity.java, there is a possible incorrect verification of proper intent filters in NLS due to a logic error in the code. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-7fgj-rhf2-g7v4",
  "modified": "2025-09-05T21:32:36Z",
  "published": "2025-09-05T18:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26442"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/packages/apps/Settings/+/63f8849244d1817be2729f522a75424c219e9ecb"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2025-05-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7FQH-MGXH-PGRJ

Vulnerability from github – Published: 2022-05-13 01:34 – Updated: 2022-05-13 01:34
VLAI
Details

An improper authorization flaw was found in the Smart Class feature of Foreman. An attacker can use it to change configuration of any host registered in Red Hat Satellite, independent of the organization the host belongs to. This flaw affects all Red Hat Satellite 6 versions.

Severity
7.2 (High)
CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-14666"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-01-22T15:29:00Z",
    "severity": "HIGH"
  },
  "details": "An improper authorization flaw was found in the Smart Class feature of Foreman. An attacker can use it to change configuration of any host registered in Red Hat Satellite, independent of the organization the host belongs to. This flaw affects all Red Hat Satellite 6 versions.",
  "id": "GHSA-7fqh-mgxh-pgrj",
  "modified": "2022-05-13T01:34:29Z",
  "published": "2022-05-13T01:34:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-14666"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-14666"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/106490"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7FW3-2WMP-J43F

Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-05-24 19:11
VLAI
Details

WP Cerber before 8.9.3 allows bypass of /wp-json access control via a trailing ? character.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-37598"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-19T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "WP Cerber before 8.9.3 allows bypass of /wp-json access control via a trailing ? character.",
  "id": "GHSA-7fw3-2wmp-j43f",
  "modified": "2022-05-24T19:11:39Z",
  "published": "2022-05-24T19:11:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37598"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fireeye/Vulnerability-Disclosures"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fireeye/Vulnerability-Disclosures/blob/master/FEYE-2021-0024/FEYE-2021-0024.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-7FW3-X4R2-G7WC

Vulnerability from github – Published: 2026-05-14 16:23 – Updated: 2026-06-09 10:25
VLAI
Summary
Portainer has a bind-mount restriction bypass via HostConfig.Mounts
Details

Summary

Portainer offers an environment-level Disable bind mounts for non-administrators security setting that blocks regular users from binding host paths into containers they create through the Portainer-mediated Docker API. The check that enforces this setting only inspected the legacy HostConfig.Binds array on the container-create proxy and never looked at the equivalent HostConfig.Mounts array. Any authenticated user with rights to create containers on a Docker environment where the restriction is enabled could submit a bind-typed entry under HostConfig.Mounts and mount any host path into their container.

The two fields are interchangeable on the Docker daemon — both produce real bind mounts at runtime — so a check that inspects only one is functionally equivalent to no check at all. The same primitive is correctly enforced on Swarm service create against TaskTemplate.ContainerSpec.Mounts; the gap was specific to the POST /containers/create proxy path.

Exploitation requires a regular user with container-create rights on an environment that has the restriction enabled. Such a user can mount any host path read-write or read-only into a container they own and use the resulting view of the host filesystem to read or write anything the Docker daemon's user can — typically root. Bind-mount restriction is the primary defence against host filesystem exposure on shared environments where regular users are otherwise permitted to deploy containers.

Severity

High

The vulnerability is exploitable over the network with low attack complexity, no attack requirement, and no user interaction. It requires a low-privilege authenticated session — any regular user with container-create rights on an environment where the bind-mount restriction is enabled. The vulnerable system (the Portainer container-create proxy) suffers a confidentiality and integrity breach by virtue of the bypass itself, but the dominant impact is on the subsequent system: the Docker host's filesystem and any container running alongside the attacker's. This is a restriction bypass rather than a cross-authority escalation — the user already had container-create rights, and the bind-mount restriction is a defence-in-depth control on top of that capability — which is the reason the rating is held at High rather than promoted to Critical despite the host-level reach.

Affected Versions

The vulnerability has existed since the AllowBindMountsForRegularUsers security setting was introduced. The HostConfig.Mounts field has never been inspected by the container-create proxy on any release line.

Fixes are included in the following releases:

Branch First vulnerable Fixed in
2.33.x (LTS) 2.33.0 2.33.8
2.39.x (LTS) 2.39.0 2.39.2
2.41.x (STS) all prior 2.41.0

Portainer releases prior to 2.33.0 are end-of-life and will not receive a fix. Users on EOL versions should upgrade to a supported LTS branch.

Workarounds

Administrators who cannot immediately upgrade can reduce exposure by:

  • Revoke container-create rights from non-administrator accounts on affected environments. If the bind-mount restriction is being relied on as a hard guarantee, audit which non-administrator accounts have container-create rights on environments where it is set, and downgrade those accounts to roles that lack container-create until the patched release is deployed. Stack and service deployment that depends on container-create will stop working for those users until the patched release is in place.
  • Audit recent container creations for HostConfig.Mounts of Type: bind from non-admin Portainer users. Inspect Docker daemon logs and docker inspect output on affected environments. Any non-admin-created container with a bind-typed Mounts entry should be treated as a potential incident.
  • Segregate tenants by environment. Where the per-environment toggle was being used to share an environment between tenants of different trust levels, splitting the workloads onto separate environments is a stronger control than the toggle and remains in place after upgrade.

None of these replace the fix.

Affected Code

The enforcement lives in decorateContainerCreationOperation in package/server-ce/api/http/proxy/factory/docker/containers.go. The PartialContainer struct used to deserialise the request body for inspection only contained HostConfig.Binds:

// package/server-ce/api/http/proxy/factory/docker/containers.go
type PartialContainer struct {
    HostConfig struct {
        Privileged bool           `json:"Privileged"`
        PidMode    string         `json:"PidMode"`
        Devices    []any          `json:"Devices"`
        Sysctls    map[string]any `json:"Sysctls"`
        CapAdd     []string       `json:"CapAdd"`
        CapDrop    []string       `json:"CapDrop"`
        Binds      []string       `json:"Binds"`
    } `json:"HostConfig"`
}

if !securitySettings.AllowBindMountsForRegularUsers && len(partialContainer.HostConfig.Binds) > 0 {
    for _, bind := range partialContainer.HostConfig.Binds {
        if strings.HasPrefix(bind, "/") {
            return forbiddenResponse, ErrBindMountsForbidden
        }
    }
}

The fix adds a Mounts field to PartialContainer and a parallel check that rejects any entry whose Type equals bind, mirroring the existing logic on the Swarm service-create proxy. The container-update path is unaffected — the Docker daemon does not accept mount changes via container update — and Swarm service create was already covered. Compose-stack deployment is not in scope of this advisory; the bind-mount restriction is a daemon-mediated container-create control, and Compose deployment runs Docker through a separate path that is not currently subject to the same restriction.

The same change applies cleanly on each LTS branch — the surrounding code shape on release/2.33 and release/2.39 is identical to develop on the points the patch touches, so the LTS backports are byte-equivalent additions of the Mounts field and the parallel check.

Impact

A regular user who has been explicitly restricted from using bind mounts can bypass the restriction and:

  • Read or write any path on the Docker host filesystem. The mount runs as the daemon user (typically root), so any path is reachable. Sensitive examples include /etc/shadow, host SSH keys under /root/.ssh and /home/*/.ssh, and TLS material under /etc/docker.
  • Compromise other containers on the same host. The host's /var/lib/docker (or equivalent) is reachable from within the bound mount, exposing the layers, volumes, and live state of every container the daemon manages.
  • Reach the Docker socket. Mounting /var/run/docker.sock into the attacker's container hands them full Docker API access on the host, regardless of any authorisation enforced by Portainer above the proxy.
  • Write persistence to the host. Without ReadOnly, the attacker can drop SSH keys into authorized_keys, install systemd units, or modify cron, achieving persistence outside of any container the daemon supervises.

The bind-mount restriction was the primary defence against this class of host exposure for non-administrator container creators; bypassing it removes the only enforcement point above the daemon for tenants who were granted container-create rights.

Timeline

  • 2026-03-04: Reported via GitHub Security Advisory by offensiveee (Assaf Alassaf).
  • 2026-03-04 – 2026-04-17: Six further independent reports of the same primitive received via GitHub Security Advisory (alexwaira, ffulbtech, Proscan-one, jeroengui, AyushParkara, marduc812) and consolidated against this advisory.
  • 2026-04-18: Fix merged to develop.
  • 2026-06-04: Backports merged to release/2.33 and release/2.39.
  • 2026-04-29: 2.41.0 released with fix.
  • 2026-05-07: 2.33.8, 2.39.2, released with fix.

Credit

  • offensiveee (Assaf Alassaf) — initial report identifying the HostConfig.Mounts bypass on container create and the divergence from the Swarm service-create check.
  • alexwaira — independently reported the same HostConfig.Mounts bypass on container create.
  • ffulbtech — independently reported the same HostConfig.Mounts bypass on container create.
  • Proscan-one — independently reported the same HostConfig.Mounts bypass on container create.
  • jeroengui — independently reported the same HostConfig.Mounts bypass on container create.
  • AyushParkara — independently reported the same HostConfig.Mounts bypass on container create.
  • marduc812 — independently reported the same HostConfig.Mounts bypass on container create.
Severity
8.5 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/portainer/portainer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.33.0"
            },
            {
              "fixed": "2.33.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/portainer/portainer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.39.0"
            },
            {
              "fixed": "2.39.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/portainer/portainer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.40.0"
            },
            {
              "fixed": "2.41.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44850"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T16:23:45Z",
    "nvd_published_at": "2026-05-28T22:16:59Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nPortainer offers an environment-level **Disable bind mounts for non-administrators** security setting that blocks regular users from binding host paths into containers they create through the Portainer-mediated Docker API. The check that enforces this setting only inspected the legacy `HostConfig.Binds` array on the container-create proxy and never looked at the equivalent `HostConfig.Mounts` array. Any authenticated user with rights to create containers on a Docker environment where the restriction is enabled could submit a `bind`-typed entry under `HostConfig.Mounts` and mount any host path into their container.\n\nThe two fields are interchangeable on the Docker daemon \u2014 both produce real bind mounts at runtime \u2014 so a check that inspects only one is functionally equivalent to no check at all. The same primitive is correctly enforced on Swarm service create against `TaskTemplate.ContainerSpec.Mounts`; the gap was specific to the `POST /containers/create` proxy path.\n\nExploitation requires a regular user with container-create rights on an environment that has the restriction enabled. Such a user can mount any host path read-write or read-only into a container they own and use the resulting view of the host filesystem to read or write anything the Docker daemon\u0027s user can \u2014 typically `root`. Bind-mount restriction is the primary defence against host filesystem exposure on shared environments where regular users are otherwise permitted to deploy containers.\n\n## Severity\n\n**High**\n\nThe vulnerability is exploitable over the network with low attack complexity, no attack requirement, and no user interaction. It requires a low-privilege authenticated session \u2014 any regular user with container-create rights on an environment where the bind-mount restriction is enabled. The vulnerable system (the Portainer container-create proxy) suffers a confidentiality and integrity breach by virtue of the bypass itself, but the dominant impact is on the subsequent system: the Docker host\u0027s filesystem and any container running alongside the attacker\u0027s. This is a restriction bypass rather than a cross-authority escalation \u2014 the user already had container-create rights, and the bind-mount restriction is a defence-in-depth control on top of that capability \u2014 which is the reason the rating is held at High rather than promoted to Critical despite the host-level reach.\n\n## Affected Versions\n\nThe vulnerability has existed since the `AllowBindMountsForRegularUsers` security setting was introduced. The `HostConfig.Mounts` field has never been inspected by the container-create proxy on any release line.\n\nFixes are included in the following releases:\n\n| Branch       | First vulnerable | Fixed in   |\n|--------------|------------------|------------|\n| 2.33.x (LTS) | 2.33.0           | **2.33.8** |\n| 2.39.x (LTS) | 2.39.0           | **2.39.2** |\n| 2.41.x (STS) | all prior        | **2.41.0** |\n\nPortainer releases prior to 2.33.0 are end-of-life and will not receive a fix. Users on EOL versions should upgrade to a supported LTS branch.\n\n## Workarounds\n\nAdministrators who cannot immediately upgrade can reduce exposure by:\n\n- **Revoke container-create rights from non-administrator accounts on affected environments.** If the bind-mount restriction is being relied on as a hard guarantee, audit which non-administrator accounts have container-create rights on environments where it is set, and downgrade those accounts to roles that lack container-create until the patched release is deployed. Stack and service deployment that depends on container-create will stop working for those users until the patched release is in place.\n- **Audit recent container creations for `HostConfig.Mounts` of `Type: bind` from non-admin Portainer users.** Inspect Docker daemon logs and `docker inspect` output on affected environments. Any non-admin-created container with a bind-typed `Mounts` entry should be treated as a potential incident.\n- **Segregate tenants by environment.** Where the per-environment toggle was being used to share an environment between tenants of different trust levels, splitting the workloads onto separate environments is a stronger control than the toggle and remains in place after upgrade.\n\nNone of these replace the fix.\n\n## Affected Code\n\nThe enforcement lives in `decorateContainerCreationOperation` in `package/server-ce/api/http/proxy/factory/docker/containers.go`. The `PartialContainer` struct used to deserialise the request body for inspection only contained `HostConfig.Binds`:\n\n```\n// package/server-ce/api/http/proxy/factory/docker/containers.go\ntype PartialContainer struct {\n    HostConfig struct {\n        Privileged bool           `json:\"Privileged\"`\n        PidMode    string         `json:\"PidMode\"`\n        Devices    []any          `json:\"Devices\"`\n        Sysctls    map[string]any `json:\"Sysctls\"`\n        CapAdd     []string       `json:\"CapAdd\"`\n        CapDrop    []string       `json:\"CapDrop\"`\n        Binds      []string       `json:\"Binds\"`\n    } `json:\"HostConfig\"`\n}\n\nif !securitySettings.AllowBindMountsForRegularUsers \u0026\u0026 len(partialContainer.HostConfig.Binds) \u003e 0 {\n    for _, bind := range partialContainer.HostConfig.Binds {\n        if strings.HasPrefix(bind, \"/\") {\n            return forbiddenResponse, ErrBindMountsForbidden\n        }\n    }\n}\n```\n\nThe fix adds a `Mounts` field to `PartialContainer` and a parallel check that rejects any entry whose `Type` equals `bind`, mirroring the existing logic on the Swarm service-create proxy. The container-update path is unaffected \u2014 the Docker daemon does not accept mount changes via container update \u2014 and Swarm service create was already covered. Compose-stack deployment is not in scope of this advisory; the bind-mount restriction is a daemon-mediated container-create control, and Compose deployment runs Docker through a separate path that is not currently subject to the same restriction.\n\nThe same change applies cleanly on each LTS branch \u2014 the surrounding code shape on `release/2.33` and `release/2.39` is identical to develop on the points the patch touches, so the LTS backports are byte-equivalent additions of the `Mounts` field and the parallel check.\n\n## Impact\n\nA regular user who has been explicitly restricted from using bind mounts can bypass the restriction and:\n\n- **Read or write any path on the Docker host filesystem.** The mount runs as the daemon user (typically `root`), so any path is reachable. Sensitive examples include `/etc/shadow`, host SSH keys under `/root/.ssh` and `/home/*/.ssh`, and TLS material under `/etc/docker`.\n- **Compromise other containers on the same host.** The host\u0027s `/var/lib/docker` (or equivalent) is reachable from within the bound mount, exposing the layers, volumes, and live state of every container the daemon manages.\n- **Reach the Docker socket.** Mounting `/var/run/docker.sock` into the attacker\u0027s container hands them full Docker API access on the host, regardless of any authorisation enforced by Portainer above the proxy.\n- **Write persistence to the host.** Without `ReadOnly`, the attacker can drop SSH keys into `authorized_keys`, install systemd units, or modify cron, achieving persistence outside of any container the daemon supervises.\n\nThe bind-mount restriction was the primary defence against this class of host exposure for non-administrator container creators; bypassing it removes the only enforcement point above the daemon for tenants who were granted container-create rights.\n\n## Timeline\n\n- 2026-03-04: Reported via GitHub Security Advisory by **offensiveee** (Assaf Alassaf).\n- 2026-03-04 \u2013 2026-04-17: Six further independent reports of the same primitive received via GitHub Security Advisory (alexwaira, ffulbtech, Proscan-one, jeroengui, AyushParkara, marduc812) and consolidated against this advisory.\n- 2026-04-18: Fix merged to `develop`.\n- 2026-06-04: Backports merged to `release/2.33` and `release/2.39`.\n- 2026-04-29: 2.41.0 released with fix.\n- 2026-05-07: 2.33.8, 2.39.2, released with fix.\n\n## Credit\n\n- **offensiveee** (Assaf Alassaf) \u2014 initial report identifying the `HostConfig.Mounts` bypass on container create and the divergence from the Swarm service-create check.\n- **alexwaira** \u2014 independently reported the same `HostConfig.Mounts` bypass on container create.\n- **ffulbtech** \u2014 independently reported the same `HostConfig.Mounts` bypass on container create.\n- **Proscan-one** \u2014 independently reported the same `HostConfig.Mounts` bypass on container create.\n- **jeroengui** \u2014 independently reported the same `HostConfig.Mounts` bypass on container create.\n- **AyushParkara** \u2014 independently reported the same `HostConfig.Mounts` bypass on container create.\n- **marduc812** \u2014 independently reported the same `HostConfig.Mounts` bypass on container create.",
  "id": "GHSA-7fw3-x4r2-g7wc",
  "modified": "2026-06-09T10:25:08Z",
  "published": "2026-05-14T16:23:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/portainer/portainer/security/advisories/GHSA-7fw3-x4r2-g7wc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44850"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/portainer/portainer"
    },
    {
      "type": "WEB",
      "url": "https://github.com/portainer/portainer/releases/tag/2.33.8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/portainer/portainer/releases/tag/2.39.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/portainer/portainer/releases/tag/2.41.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Portainer has a bind-mount restriction bypass via HostConfig.Mounts"
}

GHSA-7G2V-2FRM-RG94

Vulnerability from github – Published: 2023-05-12 09:30 – Updated: 2023-05-23 22:39
VLAI
Summary
Mattermost Incorrect Authorization vulnerability
Details

Mattermost fails to restrict a user with permissions to edit other users and to create personal access tokens from elevating their privileges to system admin

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server/v6"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server/v6"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.2.0"
            },
            {
              "fixed": "7.7.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server/v6"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.8.0"
            },
            {
              "fixed": "7.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server/v6"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.9.0"
            },
            {
              "fixed": "7.9.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-2515"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-05-12T20:17:25Z",
    "nvd_published_at": "2023-05-12T09:15:10Z",
    "severity": "HIGH"
  },
  "details": "Mattermost fails to restrict a user with permissions to edit other users and to create personal access tokens from elevating their privileges to system admin\n",
  "id": "GHSA-7g2v-2frm-rg94",
  "modified": "2023-05-23T22:39:22Z",
  "published": "2023-05-12T09:30:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2515"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost-server"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "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"
    }
  ],
  "summary": "Mattermost Incorrect Authorization vulnerability"
}
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.

← Back to the CWE list