Common Weakness Enumeration

CWE-302

Allowed

Authentication Bypass by Assumed-Immutable Data

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.

65 vulnerabilities reference this CWE, most recent first.

GHSA-3J3Q-WP9X-585P

Vulnerability from github – Published: 2026-04-08 15:04 – Updated: 2026-04-09 14:28
VLAI
Summary
kcp's cache server is accessible without authentication or authorization checks
Details

Summary

The cache server is directly exposed by the root shard and has no authentication or authorization in place. This allows anyone who can access the root shard to read and write to the cache server.

Details

The cache server is routed in the pre-mux chain in the shard code. The preHandlerChainMux is handled before any authn/authz in the cache server: https://github.com/kcp-dev/kcp/blob/aaf93d59cbcd0cefb70d94bd8959ce390547c4a2/pkg/server/config.go#L514-L518

This results in the cache server being proxied before any authn/authz in the handler chain takes place.

Attack Vectors

1. Unauthenticated Read Access (Primary)

An attacker can read all replicated resources from the cache without any credentials. This exposes:

Category Resources Severity Reason
RBAC clusterroles, clusterrolebindings (filtered by annotation) High Only subset with internal.kcp.io/replicate annotation: access rules, APIExport bind/content rules, WorkspaceType use rules. Reveals permission structure for API access and tenancy. Roles/RoleBindings NOT replicated.
Infrastructure logicalclusters, shards High Reveals full cluster topology and shard configuration
API surface apiexports, apiexportendpointslices, apiresourceschemas High Reveals all exported APIs and their network endpoints
Admission control mutatingwebhookconfigurations, validatingwebhookconfigurations, validatingadmissionpolicies High Reveals admission policies, aids bypass
Tenancy workspacetypes Medium Reveals workspace structure
Cache metadata cachedobjects, cachedresources, cachedresourceendpointslices Medium Exposes cache state and resource endpoints

2. Write Access with Race Condition (Secondary)

The cache server allows full CRUD operations. While injected objects are cleaned up by the replication controller, a race condition exists that could allow temporary privilege escalation.

The race window:

  1. Attacker POSTs a malicious ClusterRole + ClusterRoleBinding to the cache server
  2. Cache etcd watch fires and notifies two consumers in parallel: 2.1. The authorization informer (CacheKubeSharedInformerFactory) updates its in-memory store — the GlobalAuthorizer and WorkspaceContentAuthorizer now see the injected RBAC rules 2.2. The replication controller's informer enqueues a reconcile to its workqueue
  3. Replication controller worker dequeues, calls getLocalCopy() → not found, deletes the object

Between steps 2 and 3, any API request hitting the GlobalAuthorizer (global_authorizer.go:89-101) would evaluate RBAC against a store that includes the attacker's injected rules. The authorization informer and the replication controller share the same CacheKubeSharedInformerFactory (config.go:361), so the object is visible to authorization as soon as the informer cache updates — before the replication controller can process and delete it.

Practical exploitability is low — the window is sub-second, requiring the attacker to fire the privileged API request with precise timing. However, it could be automated in a tight loop. The workqueue rate limiter could also widen the window under load.

Self-healing mechanism: The replication controller acts as a self-healing mechanism. Objects injected into the cache are deleted almost instantly because:

Creating an object in cache triggers the cache informer Replication controller reconciles, calls getLocalCopy() → not found Controller calls deleteObject() on the cache copy (replication_reconcile.go:157-168)

Replicatable

Start a kcp root shard and query the cache server, e.g. with:

curl --insecure 'https://root.vespucci.genericcontrolplane.io:6443/services/cache/shards/root/clusters/root/apis/apis.kcp.io/v1alpha1'

Workarounds

Network-level access control: Restrict access to /services/cache/* paths at the load balancer, reverse proxy, or firewall level. External cache server: Deploy the cache server separately with its own kubeconfig (--cache-server-kubeconfig) and restrict network access to it.

Impact

Who is affected: Any kcp deployment where the root shard is network-reachable by untrusted clients. This applies when:

  • Helm chart deployments: Affected if the shard's Service or Ingress exposes port 6443 externally.
  • Operator deployments: Affected if the Shard resource has spec.externalURL set (or spec.baseURL — externalURL defaults to baseURL if unset). When a shard has an external URL, clients route to it directly, exposing the /services/cache/* path.
  • Any deployment method: If the root shard's --shard-external-url is set and reachable from untrusted networks, the cache server is exposed.

Not affected: Deployments where the root shard is behind a front-proxy and is not directly reachable. The front-proxy does not forward /services/cache/* requests.

Write persistence: The replication controller watches the cache informer and acts as a self-healing mechanism. Objects injected into the cache are deleted almost instantly (sub-second) because:

  • Creating an object in cache triggers the cache informer
  • Replication controller reconciles, calls getLocalCopy() → not found
  • Controller calls deleteObject() on the cache copy (replication_reconcile.go:157-168)
Severity
8.2 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kcp-dev/kcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.30.0"
            },
            {
              "fixed": "0.30.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kcp-dev/kcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.29.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39429"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-302",
      "CWE-306",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-08T15:04:22Z",
    "nvd_published_at": "2026-04-08T21:16:59Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe cache server is directly exposed by the root shard and has no authentication or authorization in place.\nThis allows anyone who can access the root shard to read and write to the cache server.\n\n### Details\n\nThe cache server is routed in the pre-mux chain in the shard code. \nThe preHandlerChainMux is handled before any authn/authz in the cache server: \nhttps://github.com/kcp-dev/kcp/blob/aaf93d59cbcd0cefb70d94bd8959ce390547c4a2/pkg/server/config.go#L514-L518\n\nThis results in the cache server being proxied before any authn/authz in the handler chain takes place.\n\n### Attack Vectors\n\n#### 1. Unauthenticated Read Access (Primary)\nAn attacker can read all replicated resources from the cache without any credentials. This exposes:\n\n| Category | Resources | Severity | Reason |\n|---|---|---|---|\n| RBAC | clusterroles, clusterrolebindings (filtered by annotation) | High | Only subset with `internal.kcp.io/replicate` annotation: access rules, APIExport bind/content rules, WorkspaceType use rules. Reveals permission structure for API access and tenancy. Roles/RoleBindings NOT replicated. |\n| Infrastructure | logicalclusters, shards | High | Reveals full cluster topology and shard configuration |\n| API surface | apiexports, apiexportendpointslices, apiresourceschemas | High | Reveals all exported APIs and their network endpoints |\n| Admission control | mutatingwebhookconfigurations, validatingwebhookconfigurations, validatingadmissionpolicies | High | Reveals admission policies, aids bypass |\n| Tenancy | workspacetypes | Medium | Reveals workspace structure |\n| Cache metadata | cachedobjects, cachedresources, cachedresourceendpointslices | Medium | Exposes cache state and resource endpoints |\n\n#### 2. Write Access with Race Condition (Secondary)\nThe cache server allows full CRUD operations. While injected objects are cleaned up by the replication controller, a race condition exists that could allow temporary privilege escalation.\n\n#### The race window:\n\n1. Attacker POSTs a malicious ClusterRole + ClusterRoleBinding to the cache server\n2. Cache etcd watch fires and notifies two consumers in parallel:\n2.1. The authorization informer (CacheKubeSharedInformerFactory) updates its in-memory store \u2014 the GlobalAuthorizer and WorkspaceContentAuthorizer now see the injected RBAC rules\n2.2. The replication controller\u0027s informer enqueues a reconcile to its workqueue\n3. Replication controller worker dequeues, calls getLocalCopy() \u2192 not found, deletes the object\n\nBetween steps 2 and 3, any API request hitting the GlobalAuthorizer ([global_authorizer.go:89-101](https://github.com/kcp-dev/kcp/blob/aaf93d59c/pkg/authorization/global_authorizer.go#L89-L101)) would evaluate RBAC against a store that includes the attacker\u0027s injected rules. The authorization informer and the replication controller share the same CacheKubeSharedInformerFactory ([config.go:361](https://github.com/kcp-dev/kcp/blob/aaf93d59c/pkg/server/config.go#L361)), so the object is visible to authorization as soon as the informer cache updates \u2014 before the replication controller can process and delete it.\n\n**Practical exploitability is low** \u2014 the window is sub-second, requiring the attacker to fire the privileged API request with precise timing. However, it could be automated in a tight loop. The workqueue rate limiter could also widen the window under load.\n\n**Self-healing mechanism:** The replication controller acts as a self-healing mechanism. Objects injected into the cache are deleted almost instantly because:\n\nCreating an object in cache triggers the cache informer\nReplication controller reconciles, calls getLocalCopy() \u2192 not found\nController calls deleteObject() on the cache copy ([replication_reconcile.go:157-168](https://github.com/kcp-dev/kcp/blob/aaf93d59c/pkg/reconciler/cache/replication/replication_reconcile.go#L157-L168))\n\n### Replicatable \n\nStart a kcp root shard and query the cache server, e.g. with:\n\n```sh\ncurl --insecure \u0027https://root.vespucci.genericcontrolplane.io:6443/services/cache/shards/root/clusters/root/apis/apis.kcp.io/v1alpha1\u0027\n```\n\n### Workarounds\n\nNetwork-level access control: Restrict access to /services/cache/* paths at the load balancer, reverse proxy, or firewall level.\nExternal cache server: Deploy the cache server separately with its own kubeconfig (--cache-server-kubeconfig) and restrict network access to it.\n\n### Impact\n\nWho is affected: Any kcp deployment where the root shard is network-reachable by untrusted clients. This applies when:\n\n- **Helm chart deployments:** Affected if the shard\u0027s Service or Ingress exposes port 6443 externally.\n- **Operator deployments:** Affected if the Shard resource has spec.externalURL set (or spec.baseURL \u2014 externalURL defaults to baseURL if unset). When a shard has an external URL, clients route to it directly, exposing the /services/cache/* path.\n- **Any deployment method:** If the root shard\u0027s --shard-external-url is set and reachable from untrusted networks, the cache server is exposed.\n\n**Not affected:** Deployments where the root shard is behind a front-proxy and is not directly reachable. The front-proxy does not forward /services/cache/* requests.\n\n**Write persistence:** The replication controller watches the cache informer and acts as a self-healing mechanism. Objects injected into the cache are deleted almost instantly (sub-second) because:\n\n- Creating an object in cache triggers the cache informer\n- Replication controller reconciles, calls getLocalCopy() \u2192 not found\n- Controller calls deleteObject() on the cache copy ([replication_reconcile.go:157-168](https://github.com/kcp-dev/kcp/blob/aaf93d59c/pkg/reconciler/cache/replication/replication_reconcile.go#L157-L168))",
  "id": "GHSA-3j3q-wp9x-585p",
  "modified": "2026-04-09T14:28:52Z",
  "published": "2026-04-08T15:04:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kcp-dev/kcp/security/advisories/GHSA-3j3q-wp9x-585p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39429"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kcp-dev/kcp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kcp-dev/kcp/releases/tag/v0.29.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kcp-dev/kcp/releases/tag/v0.30.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kcp\u0027s cache server is accessible without authentication or authorization checks"
}

GHSA-3V49-294P-4C7W

Vulnerability from github – Published: 2024-04-19 00:30 – Updated: 2024-04-19 00:30
VLAI
Details

The application is vulnerable to an unauthenticated parameter manipulation that allows an attacker to set the credentials to blank giving her access to the admin panel. Also vulnerable to account takeover and arbitrary password change.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-22179"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-302"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-18T22:15:09Z",
    "severity": "HIGH"
  },
  "details": "\nThe application is vulnerable to an unauthenticated parameter \nmanipulation that allows an attacker to set the credentials to blank \ngiving her access to the admin panel. Also vulnerable to account \ntakeover and arbitrary password change.\n\n",
  "id": "GHSA-3v49-294p-4c7w",
  "modified": "2024-04-19T00:30:54Z",
  "published": "2024-04-19T00:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22179"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-24-107-02"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3VMM-7H4J-69RM

Vulnerability from github – Published: 2023-11-14 18:30 – Updated: 2023-12-15 22:14
VLAI
Summary
TYPO3 vulnerable to Weak Authentication in Session Handling
Details

CVSS: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N/E:X/RL:O/RC:C (4.0)

Problem

Given that there are at least two different sites in the same TYPO3 installation - for instance first.example.org and second.example.com - then a session cookie generated for the first site can be reused on the second site without requiring additional authentication.

This vulnerability primarily affects the frontend of the website. It's important to note that exploiting this vulnerability requires a valid user account.

Solution

Update to TYPO3 versions 8.7.55 ELTS, 9.5.44 ELTS, 10.4.41 ELTS, 11.5.33, 12.4.8 that fix the problem described above.

Credits

Thanks to Rémy Daniel who reported this issue, and to TYPO3 core & security team member Benjamin Franzke who fixed the issue.

References

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 8.7.54"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.7.55"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.5.43"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.5.44"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.4.40"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.4.41"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 11.5.32"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.5.33"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.4.7"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.0.0"
            },
            {
              "fixed": "12.4.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-47127"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-302"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-11-14T18:30:21Z",
    "nvd_published_at": "2023-11-14T20:15:08Z",
    "severity": "MODERATE"
  },
  "details": "\u003e ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N/E:X/RL:O/RC:C` (4.0)\n\n### Problem\nGiven that there are at least two different sites in the same TYPO3 installation - for instance _first.example.org_ and _second.example.com_ - then a session cookie generated for the first site can be reused on the second site without requiring additional authentication.\n\nThis vulnerability primarily affects the frontend of the website. It\u0027s important to note that exploiting this vulnerability requires a valid user account.\n\n### Solution\nUpdate to TYPO3 versions 8.7.55 ELTS, 9.5.44 ELTS, 10.4.41 ELTS, 11.5.33, 12.4.8 that fix the problem described above.\n\n### Credits\nThanks to R\u00e9my Daniel who reported this issue, and to TYPO3 core \u0026 security team member Benjamin Franzke who fixed the issue.\n\n### References\n* [TYPO3-CORE-SA-2023-006](https://typo3.org/security/advisory/typo3-core-sa-2023-006)\n",
  "id": "GHSA-3vmm-7h4j-69rm",
  "modified": "2023-12-15T22:14:29Z",
  "published": "2023-11-14T18:30:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3/typo3/security/advisories/GHSA-3vmm-7h4j-69rm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47127"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3/typo3/commit/535dfbdc54fd5362e0bc08d911db44eac7f64019"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/typo3/cms-core/CVE-2023-47127.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/TYPO3/typo3"
    },
    {
      "type": "WEB",
      "url": "https://typo3.org/security/advisory/typo3-core-sa-2023-006"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "TYPO3 vulnerable to Weak Authentication in Session Handling"
}

GHSA-495R-5J65-5HP3

Vulnerability from github – Published: 2025-07-02 12:32 – Updated: 2025-11-05 00:31
VLAI
Details

A vulnerability of plugin openid-connect in Apache APISIX.

This vulnerability will only have an impact if all of the following conditions are met: 1. Use the openid-connect plugin with introspection mode 2. The auth service connected to openid-connect provides services to multiple issuers 3. Multiple issuers share the same private key and relies only on the issuer being different

If affected by this vulnerability, it would allow an attacker with a valid account on one of the issuers to log into the other issuer.

This issue affects Apache APISIX: until 3.12.0.

Users are recommended to upgrade to version 3.12.0 or higher.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-46647"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-302"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-02T12:15:28Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability of plugin\u00a0openid-connect in Apache APISIX.\n\nThis vulnerability will only have an impact if all of the following conditions are met:\n1. Use the openid-connect plugin with introspection mode\n2. The auth service connected to openid-connect provides services to multiple issuers\n3. Multiple issuers share the same private key and relies only on the issuer being different\n\nIf affected by this vulnerability, it would allow an attacker with a valid account on one of the issuers to log into the other issuer.\n\n\n\n\nThis issue affects Apache APISIX: until 3.12.0.\n\nUsers are recommended to upgrade to version 3.12.0 or higher.",
  "id": "GHSA-495r-5j65-5hp3",
  "modified": "2025-11-05T00:31:18Z",
  "published": "2025-07-02T12:32:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46647"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/yrpp2cd3o4qkxlrh421mq8gsrt0k4x0w"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/07/02/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-67GX-C76C-V7WC

Vulnerability from github – Published: 2025-02-14 12:31 – Updated: 2025-02-14 12:31
VLAI
Details

This vulnerability exists in RupeeWeb trading platform due to improper implementation of OTP validation mechanism in certain API endpoints. A remote attacker with valid credentials could exploit this vulnerability by manipulating API responses.

Successful exploitation of this vulnerability could allow the attacker to bypass Two-Factor Authentication (2FA) for other user accounts.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-26522"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-302"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-14T12:15:29Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability exists in RupeeWeb trading platform due to improper implementation of OTP validation mechanism in certain API endpoints. A remote attacker with valid credentials could exploit this vulnerability by manipulating API responses.  \n\nSuccessful exploitation of this vulnerability could allow the attacker to bypass Two-Factor Authentication (2FA) for other user accounts.",
  "id": "GHSA-67gx-c76c-v7wc",
  "modified": "2025-02-14T12:31:38Z",
  "published": "2025-02-14T12:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26522"
    },
    {
      "type": "WEB",
      "url": "https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES01\u0026VLCODE=CIVN-2025-0020"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-6MQ3-XMGP-PJM5

Vulnerability from github – Published: 2026-02-27 21:22 – Updated: 2026-02-27 21:22
VLAI
Summary
ZITADEL's truncated opaque tokens are still valid
Details

Summary

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.

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

{
  "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:36
VLAI
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.

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

{
  "affected": [],
  "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-F5QR-822F-J6GV

Vulnerability from github – Published: 2025-07-18 18:30 – Updated: 2025-07-18 18:30
VLAI
Details

Authentication bypass by assumed-immutable data in Azure DevOps allows an unauthorized attacker to elevate privileges over a network.

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

{
  "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:09
VLAI
Summary
Apache HugeGraph-Server: Fixed JWT Token (Secret)
Details

Authentication 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.

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

{
  "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:31
VLAI
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.

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

{
  "affected": [],
  "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"
    }
  ]
}
Mitigation
Architecture and Design Operation Implementation

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.

← Back to the CWE list