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.

5504 vulnerabilities reference this CWE, most recent first.

GHSA-JHPV-5J76-M56H

Vulnerability from github – Published: 2026-04-17 22:17 – Updated: 2026-05-05 11:49
VLAI
Summary
OpenClaw: Sender policy bypass in host media attachment reads allows unauthorized local file disclosure
Details

Summary

OpenClaw's outbound host-media attachment read helper could enable host-local file reads based on global or agent-level read access without also honoring sender and group-scoped tool policy. In channel deployments that used toolsBySender or group policy to deny read for less-trusted senders, a denied sender could still trigger host-media attachment loading and cause readable local files to be returned through the outbound media path.

Affected Versions

This issue is known to affect OpenClaw 2026.4.9. Earlier versions were not confirmed during triage, so the advisory range is intentionally scoped to >= 2026.4.9 < 2026.4.10.

Impact

Affected deployments are those that both allow host read or filesystem root expansion at the global/agent level and rely on sender or group-scoped policy to deny read for some channel participants. In that configuration, the intended sender/group authorization boundary could be bypassed for outbound media reads, potentially disclosing host-local files readable by the OpenClaw process.

The issue does not require treating the model prompt as the security boundary. The vulnerable behavior was a concrete policy enforcement mismatch: sender/group policy denied read, while the host-media read helper could still be installed without that sender context.

Resolution

Fixed in OpenClaw 2026.4.10 by PR #64459, commit c949af9fabf3873b5b7c484090cb5f5ab6049a98. The fix threads sender, session, channel, and account context into outbound media access resolution and intersects host-media read capability creation with the existing group tool policy for read. When a concrete sender/group override denies read, OpenClaw no longer creates the host readFile media capability.

Additional attachment canonicalization hardening shipped in 2026.4.14, but the authorization bypass described here was fixed in 2026.4.10.

Credit

Thanks to @Telecaster2147 for reporting this issue.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2026.4.9"
            },
            {
              "fixed": "2026.4.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42438"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-17T22:17:57Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nOpenClaw\u0027s outbound host-media attachment read helper could enable host-local file reads based on global or agent-level read access without also honoring sender and group-scoped tool policy. In channel deployments that used `toolsBySender` or group policy to deny `read` for less-trusted senders, a denied sender could still trigger host-media attachment loading and cause readable local files to be returned through the outbound media path.\n\n## Affected Versions\n\nThis issue is known to affect OpenClaw 2026.4.9. Earlier versions were not confirmed during triage, so the advisory range is intentionally scoped to `\u003e= 2026.4.9 \u003c 2026.4.10`.\n\n## Impact\n\nAffected deployments are those that both allow host read or filesystem root expansion at the global/agent level and rely on sender or group-scoped policy to deny `read` for some channel participants. In that configuration, the intended sender/group authorization boundary could be bypassed for outbound media reads, potentially disclosing host-local files readable by the OpenClaw process.\n\nThe issue does not require treating the model prompt as the security boundary. The vulnerable behavior was a concrete policy enforcement mismatch: sender/group policy denied `read`, while the host-media read helper could still be installed without that sender context.\n\n## Resolution\n\nFixed in OpenClaw 2026.4.10 by PR #64459, commit `c949af9fabf3873b5b7c484090cb5f5ab6049a98`. The fix threads sender, session, channel, and account context into outbound media access resolution and intersects host-media read capability creation with the existing group tool policy for `read`. When a concrete sender/group override denies `read`, OpenClaw no longer creates the host `readFile` media capability.\n\nAdditional attachment canonicalization hardening shipped in 2026.4.14, but the authorization bypass described here was fixed in 2026.4.10.\n\n## Credit\n\nThanks to @Telecaster2147 for reporting this issue.",
  "id": "GHSA-jhpv-5j76-m56h",
  "modified": "2026-05-05T11:49:51Z",
  "published": "2026-04-17T22:17:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jhpv-5j76-m56h"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/pull/64459"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/c949af9fabf3873b5b7c484090cb5f5ab6049a98"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Sender policy bypass in host media attachment reads allows unauthorized local file disclosure"
}

GHSA-JJ4J-X5WW-CWH9

Vulnerability from github – Published: 2025-09-15 16:28 – Updated: 2026-04-06 23:15
VLAI
Summary
Before action, Ash's hooks may execute in certain scenarios despite a request being forbidden
Details

Summary

Certain bulk action calls with a before_transaction hook and no after_transaction hook, will call the before_transaction hook before authorization is checked and a Forbidden error is returned, when called as a bulk action.

The impact is that a malicious user could cause a before_transaction to run even though they are not authorized to perform the whole action. The before_action could run a sensitive/expensive operation.

Impact

A malicious user could cause a before_action to run even though they are not authorized to perform the whole action.

You are affected if you have an create, update or destroy action that:

  • has a before_transaction hook on it, and no after_transaction hook on it.
  • is being used via an Ash.bulk_* callback (which AshJsonApi and AshGraphql do for update/destroy actions)

Whether or not or how much it matters depends on the nature of those before_transaction callbacks. If those before_transaction callbacks are side-effectful, or just doing something like looking up some external data. If your API endpoints are behind authentication and what kind.

Severity

The severity for this was hard to gauge. before_transaction hooks are not that commonly used. Additionally, any attacker must know which of these things are available to them, be authenticated to make such a request (i.e you very rarely have policies preventing the running of anonymous queries), so privileges and inside knowledge are required. Additionally, the action will always return a forbidden error, so no information is revealed. We will evaluate and adjust the severity in the next few days as needed.

It is currently marked as High, given that we really don't know what logic folks are putting in their before_transaction hooks and it could theoretically be very bad.

Workarounds

You should update ASAP, but if for whatever reason you cannot update, you can add logic to those before_transaction hooks to prevent them from doing their logic before they should.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.5.38"
      },
      "package": {
        "ecosystem": "Hex",
        "name": "ash"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.5.39"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-48042"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-15T16:28:24Z",
    "nvd_published_at": "2025-09-07T16:15:51Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nCertain bulk action calls with a `before_transaction` hook and no `after_transaction` hook, will call the `before_transaction` hook before authorization is checked and a Forbidden error is returned, when called as a bulk action.\n\nThe impact is that a malicious user could cause a `before_transaction` to run even though they are not authorized to perform the whole action. The `before_action` could run a sensitive/expensive operation.\n\n### Impact\nA malicious user could cause a `before_action` to run even though they are not authorized to perform the whole action.\n\nYou are affected if you have an create, update or destroy action that:\n\n- has a before_transaction hook on it, and no after_transaction hook on it.\n- is being used via an `Ash.bulk_*` callback (which AshJsonApi and AshGraphql do for update/destroy actions)\n\nWhether or not or how much it matters depends on the nature of those before_transaction callbacks. If those before_transaction callbacks are side-effectful, or just doing something like looking up some external data. If your API endpoints are behind authentication and what kind. \n\n### Severity\n\nThe severity for this was hard to gauge. `before_transaction` hooks are not that commonly used. Additionally, any attacker must know which of these things are available to them, be authenticated to make such a request (i.e you very rarely have policies preventing the running of anonymous queries), so privileges and inside knowledge are required. Additionally, the action will always return a `forbidden` error, so no information is revealed. We will evaluate and adjust the severity in the next few days as needed.\n\nIt is currently marked as High, given that we really don\u0027t know what logic folks are putting in their before_transaction hooks and it could theoretically be very bad.\n\n### Workarounds\n\nYou should update ASAP, but if for whatever reason you cannot update, you can add logic to those before_transaction hooks to prevent them from doing their logic before they should.",
  "id": "GHSA-jj4j-x5ww-cwh9",
  "modified": "2026-04-06T23:15:03Z",
  "published": "2025-09-15T16:28:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ash-project/ash/security/advisories/GHSA-jj4j-x5ww-cwh9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48042"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ash-project/ash/commit/5d1b6a5d00771fd468a509778637527b5218be9a"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2025-48042.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ash-project/ash"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2025-48042"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Before action, Ash\u0027s hooks may execute in certain scenarios despite a request being forbidden"
}

GHSA-JJ68-CP4V-98QF

Vulnerability from github – Published: 2024-07-02 21:20 – Updated: 2024-07-05 21:27
VLAI
Summary
aimeos/ai-admin-graphql improper access control vulnerability allows editors to manage own services
Details

aimeos/ai-admin-graphql is the Aimeos GraphQL API admin interface. Starting in version 2022.04.1 and prior to versions 2022.10.10, 2023.10.6, and 2024.4.2, improper access control allows a editors to manage own services via GraphQL API which isn't allowed in the JQAdm front end. Versions 2022.10.10, 2023.10.6, and 2024.4.2 contain a patch for the issue.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "aimeos/ai-admin-graphql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2022.04.1"
            },
            {
              "fixed": "2022.10.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "aimeos/ai-admin-graphql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2023.04.1"
            },
            {
              "fixed": "2023.10.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "aimeos/ai-admin-graphql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2024.04.1"
            },
            {
              "fixed": "2024.04.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2024.04.1"
      ]
    }
  ],
  "aliases": [
    "CVE-2024-39324"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1220",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-07-02T21:20:55Z",
    "nvd_published_at": "2024-07-02T21:15:11Z",
    "severity": "LOW"
  },
  "details": "aimeos/ai-admin-graphql is the Aimeos GraphQL API admin interface. Starting in version 2022.04.1 and prior to versions 2022.10.10, 2023.10.6, and 2024.4.2, improper access control allows a editors to manage own services via GraphQL API which isn\u0027t allowed in the JQAdm front end. Versions 2022.10.10, 2023.10.6, and 2024.4.2 contain a patch for the issue.\n",
  "id": "GHSA-jj68-cp4v-98qf",
  "modified": "2024-07-05T21:27:07Z",
  "published": "2024-07-02T21:20:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/aimeos/ai-admin-graphql/security/advisories/GHSA-jj68-cp4v-98qf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39324"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aimeos/ai-admin-graphql/commit/4eabc2b973509ffa5924e7f88c8f87ee96e93b38"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aimeos/ai-admin-graphql/commit/687059d7eb2e1d55a09ed72dad3814f35edad038"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aimeos/ai-admin-graphql/commit/a839a5adf16fee4221d444b7d2f5140d8cabf0ac"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aimeos/ai-admin-graphql/commit/acbb044620f4ff8e8d78a775cd205ec47cf119b3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/aimeos/ai-admin-graphql"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "aimeos/ai-admin-graphql improper access control vulnerability allows editors to manage own services"
}

GHSA-JJ82-76V6-933R

Vulnerability from github – Published: 2026-03-03 23:13 – Updated: 2026-03-20 21:35
VLAI
Summary
OpenClaw's exec allowlist wrapper analysis did not unwrap env/shell dispatch chains
Details

Summary

system.run exec allowlist analysis treated wrapper binaries as the effective executable and did not fully unwrap env/shell-dispatch wrappers.

This allowed wrapper-smuggled payloads (for example env bash -lc ...) to satisfy an allowlist entry for the wrapper while executing non-allowlisted commands.

Impact

On affected versions, an actor who can trigger system.run requests under an allowlist policy could bypass intended allowlist restrictions by routing execution through wrapper binaries.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected: <= 2026.2.21-2
  • Patched in next release: 2026.2.22 (pre-set below so publish can happen immediately after npm release)

Fix Commit(s)

  • 2b63592be57782c8946e521bc81286933f0f99c7

Release Process Note

patched_versions is pre-set to the planned next release (>= 2026.2.22).

After npm 2026.2.22 is published, this advisory can be published directly without further metadata edits.

OpenClaw thanks @tdjackey for reporting.

Severity
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
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-27566"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-78",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T23:13:51Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n`system.run` exec allowlist analysis treated wrapper binaries as the effective executable and did not fully unwrap `env`/shell-dispatch wrappers.\n\nThis allowed wrapper-smuggled payloads (for example `env bash -lc ...`) to satisfy an allowlist entry for the wrapper while executing non-allowlisted commands.\n\n### Impact\nOn affected versions, an actor who can trigger `system.run` requests under an allowlist policy could bypass intended allowlist restrictions by routing execution through wrapper binaries.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Affected: `\u003c= 2026.2.21-2`\n- Patched in next release: `2026.2.22` (pre-set below so publish can happen immediately after npm release)\n\n### Fix Commit(s)\n- `2b63592be57782c8946e521bc81286933f0f99c7`\n\n### Release Process Note\n`patched_versions` is pre-set to the planned next release (`\u003e= 2026.2.22`).\n\nAfter npm `2026.2.22` is published, this advisory can be published directly without further metadata edits.\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-jj82-76v6-933r",
  "modified": "2026-03-20T21:35:56Z",
  "published": "2026-03-03T23:13:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jj82-76v6-933r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27566"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/2b63592be57782c8946e521bc81286933f0f99c7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-allowlist-bypass-via-wrapper-binary-unwrapping-in-system-run"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw\u0027s exec allowlist wrapper analysis did not unwrap env/shell dispatch chains"
}

GHSA-JJJJ-JWHF-8RGR

Vulnerability from github – Published: 2025-10-16 21:36 – Updated: 2025-10-24 19:28
VLAI
Summary
MinIO is Vulnerable to Privilege Escalation via Session Policy Bypass in Service Accounts and STS
Details

Summary

A privilege escalation vulnerability allows service accounts and STS (Security Token Service) accounts with restricted session policies to bypass their inline policy restrictions when performing "own" account operations, specifically when creating new service accounts for the same user.

Details

The vulnerability exists in the IAM policy validation logic in cmd/iam.go. When validating session policies for restricted accounts performing operations on their own account (such as creating service accounts), the code incorrectly relied on the DenyOnly argument.

The DenyOnly flag is used to allow accounts to perform actions related to their own account by only checking if the action is explicitly denied. However, when a session policy (sub-policy) is present, the system should validate that the action is actually allowed by the session policy, not just that it isn't denied.

Attack Scenario

  1. An administrator creates a service account or STS account with a restricted inline policy (e.g., access only to bucket1 and bucket2)
  2. The restricted account attempts to create a new service account for itself without specifying any policy restrictions
  3. Due to the bypass, the new service account is created with full parent privileges instead of being restricted by the inline policy
  4. The attacker now has escalated privileges beyond the intended restrictions

Impact

Attack Complexity: LOW - Exploitation requires only valid credentials for a restricted service/STS account

Confidentiality: HIGH - Attackers can access buckets and objects beyond their intended restrictions

Integrity: HIGH - Attackers can modify, delete, or create objects outside their authorized scope

Availability: NONE - Does not directly impact service availability

Patches

Fixed in PR https://github.com/minio/minio/pull/21642 Commit: c1a49490c78e9c3ebcad86ba0662319138ace190

Install the release

go install -v github.com/minio/minio@RELEASE.2025-10-15T17-29-55Z

Workarounds

No workarounds available. You can upgrade to the latest version immediately.

Mitigation Steps

  1. Upgrade MinIO: Update to the latest version containing the fix
  2. Audit Service Accounts: Review all service accounts created by non-admin accounts
  3. Revoke Suspicious Accounts: Delete any service accounts that may have been created through exploitation
  4. Review Access Logs: Check for unauthorized access to sensitive buckets

Resources

  • Fix PR: https://github.com/minio/minio/pull/21642
  • Affected code: cmd/iam.go (functions: isAllowedBySessionPolicyForServiceAccount, isAllowedBySessionPolicy)
Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/minio/minio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20251015170045-c1a49490c78e"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-62506"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-16T21:36:06Z",
    "nvd_published_at": "2025-10-16T22:15:31Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA privilege escalation vulnerability allows service accounts and STS (Security Token Service) accounts with restricted session policies to bypass their inline policy restrictions when performing \"own\" account operations, specifically when creating new service accounts for the same user.\n\n### Details\nThe vulnerability exists in the IAM policy validation logic in `cmd/iam.go`. When validating session policies for restricted accounts performing operations on their own account (such as creating service accounts), the code incorrectly relied on the `DenyOnly` argument.\n\nThe `DenyOnly` flag is used to allow accounts to perform actions related to their own account by only checking if the action is explicitly denied. However, when a session policy (sub-policy) is present, the system should validate that the action is actually **allowed** by the session policy, not just that it isn\u0027t denied.\n\n### Attack Scenario\n  1. An administrator creates a service account or STS account with a restricted inline policy (e.g., access only to bucket1 and bucket2)\n  2. The restricted account attempts to create a new service account for itself without specifying any policy restrictions\n  3. Due to the bypass, the new service account is created with full parent privileges instead of being restricted by the inline policy\n  4. The attacker now has escalated privileges beyond the intended restrictions\n\n### Impact\n\n  **Attack Complexity**: LOW - Exploitation requires only valid credentials for a restricted service/STS account\n\n  **Confidentiality**: HIGH - Attackers can access buckets and objects beyond their intended restrictions\n\n  **Integrity**: HIGH - Attackers can modify, delete, or create objects outside their authorized scope\n\n  **Availability**: NONE - Does not directly impact service availability\n\n### Patches\nFixed in PR https://github.com/minio/minio/pull/21642\nCommit: c1a49490c78e9c3ebcad86ba0662319138ace190\n\nInstall the release\n```\ngo install -v github.com/minio/minio@RELEASE.2025-10-15T17-29-55Z\n```\n\n### Workarounds\nNo workarounds available. You can upgrade to the latest version immediately.\n\n### Mitigation Steps\n\n1. **Upgrade MinIO**: Update to the latest version containing the fix\n2. **Audit Service Accounts**: Review all service accounts created by non-admin accounts\n3. **Revoke Suspicious Accounts**: Delete any service accounts that may have been created through exploitation\n4. **Review Access Logs**: Check for unauthorized access to sensitive buckets\n\n### Resources\n\n- Fix PR: https://github.com/minio/minio/pull/21642\n- Affected code: cmd/iam.go (functions: isAllowedBySessionPolicyForServiceAccount, isAllowedBySessionPolicy)",
  "id": "GHSA-jjjj-jwhf-8rgr",
  "modified": "2025-10-24T19:28:23Z",
  "published": "2025-10-16T21:36:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/minio/minio/security/advisories/GHSA-jjjj-jwhf-8rgr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62506"
    },
    {
      "type": "WEB",
      "url": "https://github.com/minio/minio/issues/21647"
    },
    {
      "type": "WEB",
      "url": "https://github.com/minio/minio/pull/21642"
    },
    {
      "type": "WEB",
      "url": "https://github.com/minio/minio/commit/c1a49490c78e9c3ebcad86ba0662319138ace190"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/minio/minio"
    },
    {
      "type": "WEB",
      "url": "https://github.com/minio/minio/discussions/21655"
    },
    {
      "type": "WEB",
      "url": "https://news.ycombinator.com/item?id=45684035"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "MinIO is Vulnerable to Privilege Escalation via Session Policy Bypass in Service Accounts and STS"
}

GHSA-JM2G-3F56-RVVH

Vulnerability from github – Published: 2025-04-23 12:31 – Updated: 2026-06-26 06:30
VLAI
Details

A vulnerability was found in mod_proxy_cluster. The issue is that the directive should be replaced by the directive as the former does not restrict IP/host access as Require ip IP_ADDRESS would suggest. This means that anyone with access to the host might send MCMP requests that may result in adding/removing/updating nodes for the balancing. However, this host should not be accessible to the public network as it does not serve the general traffic.

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-2024-10306"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-23T10:15:14Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in mod_proxy_cluster. The issue is that the \u003cDirectory\u003e directive should be replaced by the \u003cLocation\u003e directive as the former does not restrict IP/host access as `Require ip IP_ADDRESS` would suggest. This means that anyone with access to the host might send MCMP requests that may result in adding/removing/updating nodes for the balancing. However, this host should not be accessible to the public network as it does not serve the general traffic.",
  "id": "GHSA-jm2g-3f56-rvvh",
  "modified": "2026-06-26T06:30:30Z",
  "published": "2025-04-23T12:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10306"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modcluster/mod_proxy_cluster/pull/309"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHBA-2025:2973"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHBA-2025:5309"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:9434"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:9466"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:9997"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-10306"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2321302"
    }
  ],
  "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-JM36-4MV9-X2PW

Vulnerability from github – Published: 2022-01-19 00:00 – Updated: 2023-08-08 15:31
VLAI
Details

An issue has been discovered in GitLab CE/EE affecting all versions starting with 12.3. Under certain conditions it was possible to bypass the IP restriction for public projects through GraphQL allowing unauthorised users to read titles of issues, merge requests and milestones.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-0172"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-18T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions starting with 12.3. Under certain conditions it was possible to bypass the IP restriction for public projects through GraphQL allowing unauthorised users to read titles of issues, merge requests and milestones.",
  "id": "GHSA-jm36-4mv9-x2pw",
  "modified": "2023-08-08T15:31:37Z",
  "published": "2022-01-19T00:00:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0172"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-0172.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/348411"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JM4G-8RVQ-V87J

Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2023-12-21 13:49
VLAI
Summary
Incorrect permission check in XebiaLabs XL Deploy Plugin allows capturing credentials
Details

An incorrect permission check in Jenkins XebiaLabs XL Deploy Plugin 10.0.1 and earlier allows attackers with Generic Create permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing Username/password credentials stored in Jenkins.

The permission check was partially fixed in XebiaLabs XL Deploy Plugin 7.5.9: A permission check was added, but for the wrong permission, still allowing some non-admin users to access the form validation method.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.0.1"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.xebialabs.deployit.ci:deployit-plugin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-21664"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-14T16:18:06Z",
    "nvd_published_at": "2021-06-10T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An incorrect permission check in Jenkins XebiaLabs XL Deploy Plugin 10.0.1 and earlier allows attackers with Generic Create permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing Username/password credentials stored in Jenkins.\n\nThe permission check was partially fixed in XebiaLabs XL Deploy Plugin 7.5.9: A permission check was added, but for the wrong permission, still allowing some non-admin users to access the form validation method.\n",
  "id": "GHSA-jm4g-8rvq-v87j",
  "modified": "2023-12-21T13:49:53Z",
  "published": "2022-05-24T19:04:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21664"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/xldeploy-plugin/commit/79ae204d2ee6cd94badf4c24a150cee13a3bde44"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/xldeploy-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2021-06-10/#SECURITY-1982"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2021/06/10/14"
    }
  ],
  "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"
    }
  ],
  "summary": "Incorrect permission check in XebiaLabs XL Deploy Plugin allows capturing credentials"
}

GHSA-JM6P-WFJG-XM7X

Vulnerability from github – Published: 2021-12-01 18:26 – Updated: 2021-12-02 15:29
VLAI
Summary
bookstack is vulnerable to Improper Access Control
Details

bookstack is vulnerable to Improper Access Control.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "ssddanbrown/bookstack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "21.11.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-4026"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-12-01T15:23:39Z",
    "nvd_published_at": "2021-11-30T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "bookstack is vulnerable to Improper Access Control.",
  "id": "GHSA-jm6p-wfjg-xm7x",
  "modified": "2021-12-02T15:29:37Z",
  "published": "2021-12-01T18:26:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4026"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bookstackapp/bookstack/commit/b4fa82e3298a15443ca40bff205b7a16a1031d92"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BookStackApp/BookStack/releases/tag/v21.11.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bookstackapp/bookstack"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/c6dfa80d-43e6-4b49-95af-cc031bb66b1d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "bookstack is vulnerable to Improper Access Control"
}

GHSA-JM9M-RQR3-WFMH

Vulnerability from github – Published: 2024-08-29 17:55 – Updated: 2024-08-29 19:07
VLAI
Summary
Kirby has insufficient permission checks in the language settings
Details

TL;DR

This vulnerability affects all Kirby sites with enabled languages option that might have potential attackers in the group of authenticated Panel users.

If you have disabled the languages and/or api option and don't call any methods in your code that cause a write access to languages (language creation, update or deletion), your site is not affected.

Introduction

Kirby allows to restrict the permissions of specific user roles. Users of that role can only perform permitted actions.

Permissions for creating and deleting languages have already existed and could be configured, but were not enforced by Kirby's frontend or backend code.

A permission for updating existing languages has not existed before the patched versions. So disabling the languages.* wildcard permission for a role could not have prohibited updates to existing language definitions.

Impact

The missing permission checks allowed attackers with Panel access to manipulate the language definitions.

The language definitions are at the core of multi-language content in Kirby. Unauthorized modifications with malicious intent can cause significant damage, for example:

  • If the languages option was enabled but no language exists, creating the first language will switch Kirby to multi-language mode.
  • Deleting an existing language will lead to content loss of all translated content in that language. Deleting the last language will switch Kirby to single-language mode.
  • Updating a language allows to change the metadata including the language slug (used in page URLs) and language variables. It also allows to change the default language, which will cause Kirby to use the new default language's content as a fallback for non-existing translations.

Depending on the site code, the result of such actions can cause loss of site availability (e.g. error messages in the site frontend) or integrity (due to changed URLs or removed translations).

Patches

The problem has been patched in Kirby 3.6.6.6, Kirby 3.7.5.5, Kirby 3.8.4.4, Kirby 3.9.8.2, Kirby 3.10.1.1, and Kirby 4.3.1. Please update to one of these or a later version to fix the vulnerability.

In all of the mentioned releases, we have added checks for the languages.create and languages.delete permissions that ensure that users without those permissions cannot perform the respective actions. We have also added a new languages.update permission.

Credits

Thanks to Sebastian Eberlein of JUNO (@SebastianEberlein-JUNO) for reporting the identified issue.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
8.8 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/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= 3.6.6.5"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "getkirby/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.6.6.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.7.5.4"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "getkirby/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.7.0"
            },
            {
              "fixed": "3.7.5.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.8.4.3"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "getkirby/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.8.0"
            },
            {
              "fixed": "3.8.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.9.8.1"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "getkirby/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.9.0"
            },
            {
              "fixed": "3.9.8.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.10.1"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "getkirby/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.10.0"
            },
            {
              "fixed": "3.10.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.3.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "getkirby/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-41964"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-08-29T17:55:30Z",
    "nvd_published_at": "2024-08-29T17:15:07Z",
    "severity": "HIGH"
  },
  "details": "### TL;DR\n\nThis vulnerability affects all Kirby sites with enabled `languages` option that might have potential attackers in the group of authenticated Panel users.\n\nIf you have disabled the `languages` and/or `api` option and don\u0027t call any methods in your code that cause a write access to languages (language creation, update or deletion), your site is *not* affected.\n\n----\n\n### Introduction\n\nKirby allows to restrict the permissions of specific user roles. Users of that role can only perform permitted actions.\n\nPermissions for creating and deleting languages have already existed and could be configured, but were not enforced by Kirby\u0027s frontend or backend code.\n\nA permission for updating existing languages has not existed before the patched versions. So disabling the `languages.*` wildcard permission for a role could not have prohibited updates to existing language definitions.\n\n### Impact\n\nThe missing permission checks allowed attackers with Panel access to manipulate the language definitions.\n\nThe language definitions are at the core of multi-language content in Kirby. Unauthorized modifications with malicious intent can cause significant damage, for example:\n\n- If the `languages` option was enabled but no language exists, creating the first language will switch Kirby to multi-language mode.\n- Deleting an existing language will lead to content loss of all translated content in that language. Deleting the last language will switch Kirby to single-language mode.\n- Updating a language allows to change the metadata including the language slug (used in page URLs) and language variables. It also allows to change the default language, which will cause Kirby to use the new default language\u0027s content as a fallback for non-existing translations.\n\nDepending on the site code, the result of such actions can cause loss of site availability (e.g. error messages in the site frontend) or integrity (due to changed URLs or removed translations).\n\n### Patches\n\nThe problem has been patched in [Kirby 3.6.6.6](https://github.com/getkirby/kirby/releases/tag/3.6.6.6), [Kirby 3.7.5.5](https://github.com/getkirby/kirby/releases/tag/3.7.5.5), [Kirby 3.8.4.4](https://github.com/getkirby/kirby/releases/tag/3.8.4.4), [Kirby 3.9.8.2](https://github.com/getkirby/kirby/releases/tag/3.9.8.2), [Kirby 3.10.1.1](https://github.com/getkirby/kirby/releases/tag/3.10.1.1), and [Kirby 4.3.1](https://github.com/getkirby/kirby/releases/tag/4.3.1). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability.\n\nIn all of the mentioned releases, we have added checks for the `languages.create` and `languages.delete` permissions that ensure that users without those permissions cannot perform the respective actions. We have also added a new `languages.update` permission.\n\n### Credits\n\nThanks to Sebastian Eberlein of JUNO (@SebastianEberlein-JUNO) for reporting the identified issue.",
  "id": "GHSA-jm9m-rqr3-wfmh",
  "modified": "2024-08-29T19:07:02Z",
  "published": "2024-08-29T17:55:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/security/advisories/GHSA-jm9m-rqr3-wfmh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41964"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/commit/1dbc9215c97a5c22dc7f34a4e3a64d19e1eac151"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/commit/38636655b054e820f66c3b717c55a9d60fe6400a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/commit/83fce501759782cf843b6f1d9293a7c7167e69af"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/commit/ab95d172667c3cd529917c2bc94d3c7969706d23"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/commit/af9b0a58dea63effab85525ae217faa1f5ded423"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/commit/e647a177c75636ef4824662b2ce00d8e5c3a8406"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getkirby/kirby"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/releases/tag/3.10.1.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/releases/tag/3.6.6.6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/releases/tag/3.7.5.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/releases/tag/3.8.4.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/releases/tag/3.9.8.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/releases/tag/4.3.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Kirby has insufficient permission checks in the language settings"
}
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