CWE-302
AllowedAuthentication Bypass by Assumed-Immutable Data
Abstraction: Base · Status: Incomplete
The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.
73 vulnerabilities reference this CWE, most recent first.
GHSA-6MQ3-XMGP-PJM5
Vulnerability from github – Published: 2026-02-27 21:22 – Updated: 2026-02-27 21:22Summary
Opaque OIDC access tokens in v2 format, truncated to 80 characters are still considered valid.
ZITADEL uses a symmetric AES encryption for opaque tokens. The cleartext payload is a concatenation of a couple of identifiers, such as a token ID and user ID. Internally Zitadel has 2 different versions of token payloads. v1 tokens are no longer created, but are still verified as to not invalidate existing session after upgrade.
The cleartext payload has a format of <token_id>:<user_id>. v2 tokens distinguished further where the token_id is of the format v2_<oidc_session_id>-at_<access_token_id>. This is an example of such a cleartext: V2_354201447279099906-at_354201447279165442:354201364702363650
Impact
V1 token authZ/N session data is retrieved from the database using the (simple) token_id value and user_id value. The user_id (called subject in some parts of our code) was used as being the trusted user ID.
V2 token authZ/N session data is retrieved from the database using the oidc_session_id and access_token_id and in this case the user_id from the token is ignored and taken from the session data in the database.
By truncating the token to 80 chars, the user_id is now missing from the cleartext of the v2 token: V2_354201447279099906-at_354201447279165442: The back-end still accepts this for above reasons.
This issue is not considered exploitable, but may look awkward when reproduced.
Affected Versions
All versions within the following ranges, including release candidates (RCs), are affected:
- v4.x: 4.0.0 through 4.10.1
- 3.x: 3.0.0 through 3.4.6
- 2.x: 2.31.0 through 2.71.19
Patches
The vulnerability has been addressed in the latest releases. The patch resolves the issue by verifying the user_id from the token against the session data from the database
4.x: Upgrade to >=4.11.0 3.x: Update to >=3.4.7 2.x: Update to >=3.4.7
Workarounds
The recommended solution is to update ZITADEL to a patched version.
Questions
If there any questions or comments about this advisory, please send an email to security@zitadel.com
Credits
ZITADEL thanks Olivier Becker and Lucas Dodgson for reporting this vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/zitadel/zitadel"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.11.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/zitadel/zitadel"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.4.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/zitadel/zitadel"
},
"ranges": [
{
"events": [
{
"introduced": "2.31.0"
},
{
"last_affected": "2.71.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/zitadel/zitadel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.80.0-v2.20.0.20260216092519-feab8e1fa371"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27840"
],
"database_specific": {
"cwe_ids": [
"CWE-302"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-27T21:22:00Z",
"nvd_published_at": "2026-02-26T01:16:25Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nOpaque OIDC access tokens in v2 format, truncated to 80 characters are still considered valid. \n\nZITADEL uses a symmetric AES encryption for opaque tokens. The cleartext payload is a concatenation of a couple of identifiers, such as a token ID and user ID. Internally Zitadel has 2 different versions of token payloads. v1 tokens are no longer created, but are still verified as to not invalidate existing session after upgrade.\n\nThe cleartext payload has a format of `\u003ctoken_id\u003e:\u003cuser_id\u003e`. v2 tokens distinguished further where the `token_id` is of the format `v2_\u003coidc_session_id\u003e-at_\u003caccess_token_id\u003e`. This is an example of such a cleartext: `V2_354201447279099906-at_354201447279165442:354201364702363650`\n\n### Impact\n\nV1 token authZ/N session data is retrieved from the database using the (simple) `token_id` value and `user_id` value. The `user_id` (called `subject` in some parts of our code) was used as being the trusted user ID.\n\nV2 token authZ/N session data is retrieved from the database using the `oidc_session_id` and `access_token_id` and in this case the `user_id` from the token is ignored and taken from the session data in the database.\n\nBy truncating the token to 80 chars, the user_id is now missing from the cleartext of the v2 token: `V2_354201447279099906-at_354201447279165442:` The back-end still accepts this for above reasons.\n\nThis issue is not considered exploitable, but may look awkward when reproduced.\n\n### Affected Versions\n\nAll versions within the following ranges, including release candidates (RCs), are affected:\n- **v4.x**: `4.0.0` through `4.10.1`\n- **3.x**: `3.0.0` through `3.4.6`\n- **2.x**: `2.31.0` through `2.71.19`\n\n### Patches\n\nThe vulnerability has been addressed in the latest releases. The patch resolves the issue by verifying the `user_id` from the token against the session data from the database\n\n4.x: Upgrade to \u003e=[4.11.0](https://github.com/zitadel/zitadel/releases/tag/v4.11.0)\n3.x: Update to \u003e=[3.4.7](https://github.com/zitadel/zitadel/releases/tag/v3.4.7)\n2.x: Update to \u003e=[3.4.7](https://github.com/zitadel/zitadel/releases/tag/v3.4.7)\n\n### Workarounds\n\nThe recommended solution is to update ZITADEL to a patched version.\n\n### Questions\n\nIf there any questions or comments about this advisory, please send an email to [security@zitadel.com](mailto:security@zitadel.com)\n\n### Credits\n\nZITADEL thanks Olivier Becker and Lucas Dodgson for reporting this vulnerability.",
"id": "GHSA-6mq3-xmgp-pjm5",
"modified": "2026-02-27T21:22:00Z",
"published": "2026-02-27T21:22:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/zitadel/zitadel/security/advisories/GHSA-6mq3-xmgp-pjm5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27840"
},
{
"type": "WEB",
"url": "https://github.com/zitadel/zitadel/commit/feab8e1fa371f3ad654640fc869b2c14f2fdb602"
},
{
"type": "PACKAGE",
"url": "https://github.com/zitadel/zitadel"
},
{
"type": "WEB",
"url": "https://github.com/zitadel/zitadel/releases/tag/v2.71.19"
},
{
"type": "WEB",
"url": "https://github.com/zitadel/zitadel/releases/tag/v3.4.7"
},
{
"type": "WEB",
"url": "https://github.com/zitadel/zitadel/releases/tag/v4.11.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "ZITADEL\u0027s truncated opaque tokens are still valid"
}
GHSA-75JM-237J-RV22
Vulnerability from github – Published: 2024-12-17 12:31 – Updated: 2026-06-02 09:36Authentication Bypass by Assumed-Immutable Data vulnerability in Digital Operation Services WiFiBurada allows Manipulating User-Controlled Variables.This issue affects WiFiBurada: before 1.0.5.
{
"affected": [],
"aliases": [
"CVE-2024-8475"
],
"database_specific": {
"cwe_ids": [
"CWE-302"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-17T12:15:21Z",
"severity": "MODERATE"
},
"details": "Authentication Bypass by Assumed-Immutable Data vulnerability in Digital Operation Services WiFiBurada allows Manipulating User-Controlled Variables.This issue affects WiFiBurada: before 1.0.5.",
"id": "GHSA-75jm-237j-rv22",
"modified": "2026-06-02T09:36:14Z",
"published": "2024-12-17T12:31:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8475"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-24-1888"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-24-1888"
}
],
"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"
}
]
}
GHSA-C8W2-FGVX-VHV4
Vulnerability from github – Published: 2026-09-18 17:15 – Updated: 2026-09-18 17:15Summary
The kcp front-proxy fails to strip client-supplied identity headers before forwarding requests to shards. Any authenticated tenant can inject their own X-Remote-Group and X-Remote-Extra-* headers, which the shard trusts as a verified identity assertion — allowing a low-privilege user to escalate to cluster administrator (system:masters) and read, write, or delete resources in any workspace on the shard. This is a complete multi-tenant isolation and authorization bypass.
Impact
In a sharded kcp deployment, external clients reach shards through the front-proxy, which authenticates the client and then forwards the resulting identity to the shard using Kubernetes request-header authentication (X-Remote-User / X-Remote-Group / X-Remote-Extra-*). The shard trusts these headers because they arrive over the front-proxy's mutually-authenticated connection.
Because the front-proxy appended its identity headers instead of replacing them — and never removed any copies the client sent — an authenticated attacker could smuggle forged identity headers through to the shard. With this, an attacker holding any ordinary credential (client certificate, OIDC token, or service-account token) and no special privileges could:
- assert
X-Remote-Group: system:mastersand act as cluster super-user, bypassing the entire kcp authorizer chain in every workspace on the shard; - forge
authorization.kcp.io/warrantto assume an arbitrary user/group identity via kcp's delegated-identity mechanism; - forge
authentication.kcp.io/scopesto escape the cluster-scoping that confines service-account and impersonated identities to their origin workspace; - satisfy per-workspace required-group gating by injecting the required group.
The result is arbitrary read/write/delete access to any tenant's resources, secrets, RBAC, APIExports/APIBindings, and LogicalClusters — a cross-workspace access break and authorizer bypass across the proxy's trust boundary.
Patches
Fixed in v0.31.4, 0.32.2. The front-proxy and the shard's in-process local-proxy now unconditionally remove any inbound X-Remote-* identity headers before stamping the authenticated identity, so no client-supplied value can be forwarded to a shard.
Operators should upgrade to a patched release. No configuration changes are required after upgrading.
Workarounds
There is no complete workaround other than upgrading. Deployments that terminate client connections at an external proxy capable of stripping X-Remote-User, X-Remote-Group, and all X-Remote-Extra-* headers from inbound requests before they reach the kcp front-proxy can mitigate exposure in the interim.
Credit to 5ud0er / Tarmo Technologies.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/kcp-dev/kcp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.31.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/kcp-dev/kcp"
},
"ranges": [
{
"events": [
{
"introduced": "0.32.0"
},
{
"fixed": "0.32.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-61682"
],
"database_specific": {
"cwe_ids": [
"CWE-290",
"CWE-302",
"CWE-348"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-18T17:15:49Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "# Summary\n\nThe kcp front-proxy fails to strip client-supplied identity headers before forwarding requests to shards. Any authenticated tenant can inject their own `X-Remote-Group` and `X-Remote-Extra-*` headers, which the shard trusts as a verified identity assertion \u2014 allowing a low-privilege user to escalate to cluster administrator (`system:masters`) and read, write, or delete resources in any workspace on the shard. This is a complete multi-tenant isolation and authorization bypass.\n\n## Impact \n\nIn a sharded kcp deployment, external clients reach shards through the front-proxy, which authenticates the client and then forwards the resulting identity to the shard using Kubernetes request-header authentication (`X-Remote-User` / `X-Remote-Group` / `X-Remote-Extra-*`). The shard trusts these headers because they arrive over the front-proxy\u0027s mutually-authenticated connection.\n\nBecause the front-proxy appended its identity headers instead of replacing them \u2014 and never removed any copies the client sent \u2014 an authenticated attacker could smuggle forged identity headers through to the shard. With this, an attacker holding any ordinary credential (client certificate, OIDC token, or service-account token) and no special privileges could:\n\n- assert `X-Remote-Group: system:masters` and act as cluster super-user, bypassing the entire kcp authorizer chain in every workspace on the shard;\n- forge `authorization.kcp.io/warrant` to assume an arbitrary user/group identity via kcp\u0027s delegated-identity mechanism;\n- forge `authentication.kcp.io/scopes` to escape the cluster-scoping that confines service-account and impersonated identities to their origin workspace;\n- satisfy per-workspace required-group gating by injecting the required group.\n\nThe result is arbitrary read/write/delete access to any tenant\u0027s resources, secrets, RBAC, APIExports/APIBindings, and LogicalClusters \u2014 a cross-workspace access break and authorizer bypass across the proxy\u0027s trust boundary.\n\n\n# Patches\nFixed in v0.31.4, 0.32.2. The front-proxy and the shard\u0027s in-process local-proxy now unconditionally remove any inbound `X-Remote-*` identity headers before stamping the authenticated identity, so no client-supplied value can be forwarded to a shard.\n\nOperators should upgrade to a patched release. No configuration changes are required after upgrading.\n\n# Workarounds\n\nThere is no complete workaround other than upgrading. Deployments that terminate client connections at an external proxy capable of stripping `X-Remote-User`, `X-Remote-Group`, and all `X-Remote-Extra-*` headers from inbound requests before they reach the kcp front-proxy can mitigate exposure in the interim.\n\nCredit to [5ud0er](https://github.com/5ud0er) / Tarmo Technologies.",
"id": "GHSA-c8w2-fgvx-vhv4",
"modified": "2026-09-18T17:15:49Z",
"published": "2026-09-18T17:15:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kcp-dev/kcp/security/advisories/GHSA-c8w2-fgvx-vhv4"
},
{
"type": "WEB",
"url": "https://github.com/kcp-dev/kcp/commit/7437cdcfec8f927d1a9bf1b2dd1e075d038e27ca"
},
{
"type": "PACKAGE",
"url": "https://github.com/kcp-dev/kcp"
},
{
"type": "WEB",
"url": "https://github.com/kcp-dev/kcp/releases/tag/v0.31.4"
},
{
"type": "WEB",
"url": "https://github.com/kcp-dev/kcp/releases/tag/v0.32.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kcp front-proxy does not strip inbound X-Remote-* identity headers, allowing any authenticated client to inject groups/warrants and impersonate system:masters in any workspace"
}
GHSA-CGPV-QFW8-FG8X
Vulnerability from github – Published: 2026-08-12 21:31 – Updated: 2026-08-12 21:31IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 and IBM Verify Identity Access Container 11.0 through 11.0.3 could allow an authenticated user to gain privileges of another user via a specially crafted request.
{
"affected": [],
"aliases": [
"CVE-2026-13267"
],
"database_specific": {
"cwe_ids": [
"CWE-302"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-12T20:17:34Z",
"severity": "HIGH"
},
"details": "IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 and IBM Verify Identity Access Container 11.0 through 11.0.3 could allow an authenticated user to gain privileges of another user via a specially crafted request.",
"id": "GHSA-cgpv-qfw8-fg8x",
"modified": "2026-08-12T21:31:40Z",
"published": "2026-08-12T21:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13267"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7283079"
}
],
"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"
}
]
}
GHSA-F5QR-822F-J6GV
Vulnerability from github – Published: 2025-07-18 18:30 – Updated: 2025-07-18 18:30Authentication bypass by assumed-immutable data in Azure DevOps allows an unauthorized attacker to elevate privileges over a network.
{
"affected": [],
"aliases": [
"CVE-2025-47158"
],
"database_specific": {
"cwe_ids": [
"CWE-302"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-18T17:15:31Z",
"severity": "CRITICAL"
},
"details": "Authentication bypass by assumed-immutable data in Azure DevOps allows an unauthorized attacker to elevate privileges over a network.",
"id": "GHSA-f5qr-822f-j6gv",
"modified": "2025-07-18T18:30:29Z",
"published": "2025-07-18T18:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47158"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-47158"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F697-GM3H-XRF9
Vulnerability from github – Published: 2024-12-24 12:30 – Updated: 2025-01-02 16:09Authentication Bypass by Assumed-Immutable Data vulnerability in Apache HugeGraph-Server.
This issue affects Apache HugeGraph-Server: from 1.0.0 before 1.5.0.
Users are recommended to upgrade to version 1.5.0, which fixes the issue.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.hugegraph:hugegraph-server"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-43441"
],
"database_specific": {
"cwe_ids": [
"CWE-302"
],
"github_reviewed": true,
"github_reviewed_at": "2024-12-26T20:23:58Z",
"nvd_published_at": "2024-12-24T12:15:21Z",
"severity": "CRITICAL"
},
"details": "Authentication Bypass by Assumed-Immutable Data vulnerability in Apache HugeGraph-Server.\n\nThis issue affects Apache HugeGraph-Server: from 1.0.0 before 1.5.0.\n\nUsers are recommended to upgrade to version 1.5.0, which fixes the issue.",
"id": "GHSA-f697-gm3h-xrf9",
"modified": "2025-01-02T16:09:32Z",
"published": "2024-12-24T12:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43441"
},
{
"type": "WEB",
"url": "https://github.com/apache/incubator-hugegraph/commit/03b40a52446218c83e98cb43020e0593a744a246"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/incubator-hugegraph"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/h2607yv32wgcrywov960jpxhvsmmlf12"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/12/24/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Apache HugeGraph-Server: Fixed JWT Token (Secret)"
}
GHSA-FR4J-QWJ2-GRQW
Vulnerability from github – Published: 2025-11-14 15:30 – Updated: 2026-06-05 12:31Authorization Bypass Through User-Controlled Key, Weak Password Recovery Mechanism for Forgotten Password, Authentication Bypass by Assumed-Immutable Data vulnerability in Optimus Software Brokerage Automation allows Exploiting Trust in Client, Authentication Bypass, Manipulate Registry Information.This issue affects Brokerage Automation: before 1.1.71.
{
"affected": [],
"aliases": [
"CVE-2025-8855"
],
"database_specific": {
"cwe_ids": [
"CWE-302"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-14T13:15:45Z",
"severity": "HIGH"
},
"details": "Authorization Bypass Through User-Controlled Key, Weak Password Recovery Mechanism for Forgotten Password, Authentication Bypass by Assumed-Immutable Data vulnerability in Optimus Software Brokerage Automation allows Exploiting Trust in Client, Authentication Bypass, Manipulate Registry Information.This issue affects Brokerage Automation: before 1.1.71.",
"id": "GHSA-fr4j-qwj2-grqw",
"modified": "2026-06-05T12:31:43Z",
"published": "2025-11-14T15:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8855"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-25-0396"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-25-0396"
}
],
"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"
}
]
}
GHSA-FX87-2QCR-264F
Vulnerability from github – Published: 2023-09-14 21:30 – Updated: 2026-05-21 12:31** UNSUPPPORTED WHEN ASSIGNED ** Authentication Bypass by Assumed-Immutable Data vulnerability in Exagate SYSGuard 3001 allows Authentication Bypass.This issue affects SYSGuard 3001: before 3.2.20.0.
{
"affected": [],
"aliases": [
"CVE-2023-4669"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-302"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-09-14T19:16:51Z",
"severity": "CRITICAL"
},
"details": "** UNSUPPPORTED WHEN ASSIGNED ** Authentication Bypass by Assumed-Immutable Data vulnerability in Exagate SYSGuard 3001 allows Authentication Bypass.This issue affects SYSGuard 3001: before 3.2.20.0.",
"id": "GHSA-fx87-2qcr-264f",
"modified": "2026-05-21T12:31:43Z",
"published": "2023-09-14T21:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4669"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-23-0525"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-23-0525"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FXGJ-CFM7-W8HW
Vulnerability from github – Published: 2023-11-09 15:30 – Updated: 2025-02-27 00:30Improper Authentication vulnerability in Apereo CAS in jakarta.servlet.http.HttpServletRequest.getRemoteAddr method allows Multi-Factor Authentication bypass.This issue affects CAS: through 7.0.0-RC7. It is unknown whether in new versions the issue will be fixed. For the date of publication there is no patch, and the vendor does not treat it as a vulnerability.
{
"affected": [],
"aliases": [
"CVE-2023-4612"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-302"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-09T14:15:08Z",
"severity": "CRITICAL"
},
"details": "Improper Authentication vulnerability in Apereo CAS in\u00a0jakarta.servlet.http.HttpServletRequest.getRemoteAddr method allows Multi-Factor Authentication bypass.This issue affects CAS: through 7.0.0-RC7. It is unknown whether in new versions the issue will be fixed. For the date of publication there is no patch, and the vendor does not treat it as a vulnerability.",
"id": "GHSA-fxgj-cfm7-w8hw",
"modified": "2025-02-27T00:30:26Z",
"published": "2023-11-09T15:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4612"
},
{
"type": "WEB",
"url": "https://cert.pl/en/posts/2023/11/CVE-2023-4612"
},
{
"type": "WEB",
"url": "https://cert.pl/posts/2023/11/CVE-2023-4612"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G6XR-2P64-FH4G
Vulnerability from github – Published: 2026-05-11 12:32 – Updated: 2026-05-11 12:32Dell ECS versions 3.8.1.0 through 3.8.1.7 and Dell ObjectScale versions prior to 4.3.0.0, contains an authentication bypass by assumed-immutable data vulnerability in Geo replication. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to unauthorized access to data in transit.
{
"affected": [],
"aliases": [
"CVE-2025-43992"
],
"database_specific": {
"cwe_ids": [
"CWE-302"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-11T10:16:12Z",
"severity": "MODERATE"
},
"details": "Dell ECS versions 3.8.1.0 through 3.8.1.7 and Dell ObjectScale versions prior to 4.3.0.0, contains an authentication bypass by assumed-immutable data vulnerability in Geo replication. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to unauthorized access to data in transit.",
"id": "GHSA-g6xr-2p64-fh4g",
"modified": "2026-05-11T12:32:31Z",
"published": "2026-05-11T12:32:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43992"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000462117/dsa-2026-047-security-update-for-dell-ecs-and-objectscale-multiple-vulnerabilities-1"
}
],
"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"
}
]
}
Mitigation
Implement proper protection for immutable data (e.g. environment variable, hidden form fields, etc.)
CAPEC-10: Buffer Overflow via Environment Variables
This attack pattern involves causing a buffer overflow through manipulation of environment variables. Once the adversary finds that they can modify an environment variable, they may try to overflow associated buffers. This attack leverages implicit trust often placed in environment variables.
CAPEC-13: Subverting Environment Variable Values
The adversary directly or indirectly modifies environment variables used by or controlling the target software. The adversary's goal is to cause the target software to deviate from its expected operation in a manner that benefits the adversary.
CAPEC-21: Exploitation of Trusted Identifiers
An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.
CAPEC-274: HTTP Verb Tampering
An attacker modifies the HTTP Verb (e.g. GET, PUT, TRACE, etc.) in order to bypass access restrictions. Some web environments allow administrators to restrict access based on the HTTP Verb used with requests. However, attackers can often provide a different HTTP Verb, or even provide a random string as a verb in order to bypass these protections. This allows the attacker to access data that should otherwise be protected.
CAPEC-31: Accessing/Intercepting/Modifying HTTP Cookies
This attack relies on the use of HTTP Cookies to store credentials, state information and other critical data on client systems. There are several different forms of this attack. The first form of this attack involves accessing HTTP Cookies to mine for potentially sensitive data contained therein. The second form involves intercepting this data as it is transmitted from client to server. This intercepted information is then used by the adversary to impersonate the remote user/session. The third form is when the cookie's content is modified by the adversary before it is sent back to the server. Here the adversary seeks to convince the target server to operate on this falsified information.
CAPEC-39: Manipulating Opaque Client-based Data Tokens
In circumstances where an application holds important data client-side in tokens (cookies, URLs, data files, and so forth) that data can be manipulated. If client or server-side application components reinterpret that data as authentication tokens or data (such as store item pricing or wallet information) then even opaquely manipulating that data may bear fruit for an Attacker. In this pattern an attacker undermines the assumption that client side tokens have been adequately protected from tampering through use of encryption or obfuscation.
CAPEC-45: Buffer Overflow via Symbolic Links
This type of attack leverages the use of symbolic links to cause buffer overflows. An adversary can try to create or manipulate a symbolic link file such that its contents result in out of bounds data. When the target software processes the symbolic link file, it could potentially overflow internal buffers with insufficient bounds checking.
CAPEC-77: Manipulating User-Controlled Variables
This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.