Common Weakness Enumeration

CWE-639

Weakness Allowed

Authorization Bypass Through User-Controlled Key

Abstraction: Base · Status: Incomplete

The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

It is likely that an attacker would have to be an authenticated user in the system. However, the authorization process would not properly check the data access operation to ensure that the authenticated user performing the operation has sufficient entitlements to perform the requested data access, hence bypassing any other authorization checks present in the system.

For example, attackers can look at places where user specific data is retrieved (e.g. search screens) and determine whether the key for the item being looked up is controllable externally. The key may be a hidden field in the HTML form field, might be passed as a URL parameter or as an unencrypted cookie variable, then in each of these cases it will be possible to tamper with the key value.

Mapping guidance

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Relationships and members
ChildOf: CWE-863 · View CWE-1000
ChildOf: CWE-863 · View CWE-1003
ChildOf: CWE-284 · View CWE-1340
Modes of introduction
Architecture and Design

REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Architecture and Design

Retrieval of a user record occurs in the system based on some key value that is under user control. The key would typically identify a user-related record stored in the system and would be used to lookup that record for presentation to the user.

Implementation

One manifestation of this weakness is when a system uses sequential or otherwise easily-guessable session IDs that would allow one user to easily switch to another user's session and read/modify their data.

Detection methods

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

Notes

Maintenance

As of CWE 4.20, the relationship between IDOR and BOLA needs to be investigated more closely, including research into how these terms are used in the industry. The CWE team suspects that IDOR can be a part of BOLA, but BOLA expands on the weakness inherent to IDOR in that it is not only about objects that are being directly referenced.

Content history
Submission: Evgeny Lebanidze · Cigital · 2008-01-30 · CWE Draft 8
Contribution: Mateus Godinho Pantoja · 2024-08-09 · CWE 4.20

Suggested corrections to use of IDOR versus BOLA

Modification: CWE Content Team · MITRE · 2008-09-08 · CWE 1.0

updated Common_Consequences, Relationships, Type

Modification: CWE Content Team · MITRE · 2008-10-14 · CWE 1.0.1

updated Description

Modification: CWE Content Team · MITRE · 2009-03-10 · CWE 1.3

updated Relationships

Modification: CWE Content Team · MITRE · 2009-05-27 · CWE 1.4

updated Relationships

Modification: CWE Content Team · MITRE · 2009-10-29 · CWE 1.6

updated Common_Consequences

Modification: CWE Content Team · MITRE · 2010-06-21 · CWE 1.9

updated Relationships

Modification: CWE Content Team · MITRE · 2011-03-29 · CWE 1.12

updated Alternate_Terms, Applicable_Platforms, Description, Name, Potential_Mitigations, Relationships

Modification: CWE Content Team · MITRE · 2011-06-01 · CWE 1.13

updated Common_Consequences, Relationships

Modification: CWE Content Team · MITRE · 2012-05-11 · CWE 2.2

updated Relationships

Modification: CWE Content Team · MITRE · 2013-02-21 · CWE 2.4

updated Alternate_Terms, Common_Consequences

Modification: CWE Content Team · MITRE · 2013-07-17 · CWE 2.5

updated Relationships

Modification: CWE Content Team · MITRE · 2014-07-30 · CWE 2.8

updated Relationships

Modification: CWE Content Team · MITRE · 2017-11-08 · CWE 3.0

updated Description, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Relationships

Modification: CWE Content Team · MITRE · 2018-03-27 · CWE 3.1

updated Relationships

Modification: CWE Content Team · MITRE · 2019-06-20 · CWE 3.3

updated Relationships

Modification: CWE Content Team · MITRE · 2020-02-24 · CWE 4.0

updated Relationships

Modification: CWE Content Team · MITRE · 2020-06-25 · CWE 4.1

updated Alternate_Terms

Modification: CWE Content Team · MITRE · 2020-12-10 · CWE 4.3

updated Relationships

Modification: CWE Content Team · MITRE · 2021-03-15 · CWE 4.4

updated Alternate_Terms

Modification: CWE Content Team · MITRE · 2021-10-28 · CWE 4.6

updated Relationships

Modification: CWE Content Team · MITRE · 2023-04-27 · CWE 4.11

updated Detection_Factors, Relationships

Modification: CWE Content Team · MITRE · 2023-06-29 · CWE 4.12

updated Mapping_Notes

Modification: CWE Content Team · MITRE · 2023-10-26 · CWE 4.13

updated Observed_Examples

Modification: CWE Content Team · MITRE · 2024-02-29 · CWE 4.14

updated Demonstrative_Examples

Modification: CWE Content Team · MITRE · 2025-12-11 · CWE 4.19

updated References, Relationships, Weakness_Ordinalities

Modification: CWE Content Team · MITRE · 2026-04-30 · CWE 4.20

updated Alternate_Terms, Maintenance_Notes, References

Modification: CWE Content Team · MITRE · 2026-10-28 · CWE 5.0

updated Description, Modes_of_Introduction, Time_of_Introduction

5738 vulnerabilities reference this CWE, most recent first.

GHSA-2XJ9-M79M-CHVG

Vulnerability from github – Published: 2026-10-30 21:32 – Updated: 2026-10-30 21:32
VLAI
Details

NodeBB 1.18.0 through 4.16.5 contains an authorization bypass vulnerability that allows unauthenticated visitors to act on other accounts by supplying a uid during POST /register. Attackers can submit an empty email at the /register/complete interstitial to clear a victim's email and confirmation state and revoke all their sessions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-120007"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-30T19:18:22Z",
    "severity": "MODERATE"
  },
  "details": "NodeBB 1.18.0 through 4.16.5 contains an authorization bypass vulnerability that allows unauthenticated visitors to act on other accounts by supplying a uid during POST /register. Attackers can submit an empty email at the /register/complete interstitial to clear a victim\u0027s email and confirmation state and revoke all their sessions.",
  "id": "GHSA-2xj9-m79m-chvg",
  "modified": "2026-10-30T21:32:18Z",
  "published": "2026-10-30T21:32:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-120007"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NodeBB/NodeBB/commit/376d14abb7fffd8ea14f3a2f96baa20ffee5cdb3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NodeBB/NodeBB"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NodeBB/NodeBB/blob/c3d8dc512292a376f19e06cb93512bdff2505102/src/controllers/authentication.js#L34"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NodeBB/NodeBB/blob/c3d8dc512292a376f19e06cb93512bdff2505102/src/user/interstitials.js#L124"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/nodebb-1.18.0-through-4.16.5-authorization-bypass-via-register-complete-uid"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/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-2XJF-R5X5-5XPC

Vulnerability from github – Published: 2025-08-25 15:32 – Updated: 2025-08-25 15:32
VLAI
Details

An issue in System PDV v1.0 allows a remote attacker to obtain sensitive information via the hash parameter in a URL. The application contains an Insecure Direct Object Reference (IDOR) vulnerability, which occurs due to a lack of proper authorization checks when accessing objects referenced by this parameter. This allows direct access to other users' data or internal resources without proper permission. Successful exploitation of this flaw may result in the exposure of sensitive information.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-45968"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-25T14:15:31Z",
    "severity": "CRITICAL"
  },
  "details": "An issue in System PDV v1.0 allows a remote attacker to obtain sensitive information via the hash parameter in a URL. The application contains an Insecure Direct Object Reference (IDOR) vulnerability, which occurs due to a lack of proper authorization checks when accessing objects referenced by this parameter. This allows direct access to other users\u0027 data or internal resources without proper permission. Successful exploitation of this flaw may result in the exposure of sensitive information.",
  "id": "GHSA-2xjf-r5x5-5xpc",
  "modified": "2025-08-25T15:32:00Z",
  "published": "2025-08-25T15:32:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-45968"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/@r3dd1t/pedindo-um-lanche-e-possivelemnte-descobrindo-uma-cve-9930b0114e3f"
    }
  ],
  "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-2XJR-FP46-9FHH

Vulnerability from github – Published: 2024-05-07 12:30 – Updated: 2024-05-07 12:30
VLAI
Details

IDOR vulnerability in Janto Ticketing Software affecting version 4.3r10. This vulnerability could allow a remote user to obtain the download URL of another user to obtain the purchased ticket.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-4537"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-07T12:15:09Z",
    "severity": "HIGH"
  },
  "details": "IDOR vulnerability in Janto Ticketing Software affecting version 4.3r10. This vulnerability could allow a remote user to obtain the download URL of another user to obtain the purchased ticket.",
  "id": "GHSA-2xjr-fp46-9fhh",
  "modified": "2024-05-07T12:30:50Z",
  "published": "2024-05-07T12:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4537"
    },
    {
      "type": "WEB",
      "url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-janto-ticketing-software"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2XQP-GCM9-67F8

Vulnerability from github – Published: 2026-02-12 15:32 – Updated: 2026-06-04 09:30
VLAI
Details

Authorization Bypass Through User-Controlled Key vulnerability in Farktor Software E-Commerce Services Inc. E-Commerce Package allows Manipulating User-Controlled Variables.This issue affects E-Commerce Package: through 27112025.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-13004"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-12T14:16:00Z",
    "severity": "MODERATE"
  },
  "details": "Authorization Bypass Through User-Controlled Key vulnerability in Farktor Software E-Commerce Services Inc. E-Commerce Package allows Manipulating User-Controlled Variables.This issue affects E-Commerce Package: through 27112025.",
  "id": "GHSA-2xqp-gcm9-67f8",
  "modified": "2026-06-04T09:30:34Z",
  "published": "2026-02-12T15:32:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13004"
    },
    {
      "type": "WEB",
      "url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-26-0063"
    },
    {
      "type": "WEB",
      "url": "https://www.usom.gov.tr/bildirim/tr-26-0063"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2XWH-426Q-42C5

Vulnerability from github – Published: 2026-11-09 22:43 – Updated: 2026-11-09 22:43
VLAI
Summary
Kubeflow Pipelines: Cross-tenant execution-cache poisoning / output substitution via a namespace-blind cache key in the cache webhook (multi-user)
Details

Summary

The legacy Kubeflow Pipelines V1/raw-Argo execution cache does not separate cached results by Kubernetes namespace. In multi-user deployments where tenants share the cache service, a tenant can receive another tenant's cached outputs or seed outputs that are subsequently substituted into another tenant's step.

This affects the Argo-template cache mutating webhook and its cache-server storage path. Standard KFP V2 component pods bypass this webhook cache; the separate V2 cache implementation is outside this advisory's scope.

Affected deployments and impact

The issue requires multiple tenant namespaces sharing the legacy cache service, cache-enabled V1/raw-Argo steps, and cache entries that satisfy the configured staleness policy. The standard multi-user configuration watches pods across namespaces.

A tenant able to submit a step with the same cache-relevant template fields as another tenant's step can:

  • Read cached step outputs originally produced in another namespace.
  • Populate the shared cache before another tenant's matching step runs, causing that step to report the cached outputs instead of executing its intended containers.

Matching refers to the selected template fields used by the cache key, not merely an identical container image. This is an application-level cache-key collision caused by missing tenant scope, not a cryptographic SHA-256 collision. The finding establishes cross-namespace confidentiality and integrity impact; it does not establish arbitrary code execution.

CVSS rationale

Medium — CVSS 3.1: 5.4

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

  • AV:N / PR:L / UI:N: a tenant with ordinary workload-submission privileges can exercise the shared cache through network-accessible APIs. Reading an existing cached result or poisoning a subsequent automated execution requires no additional victim interaction.
  • AC:L: known or shared templates can produce the same cache key deterministically. Cache-enabled execution and matching template fields describe the affected configuration; they do not establish an unavoidable narrow race or secret prerequisite.
  • S:U: the established impact is disclosure or substitution of output data managed by the same cache service. Crossing tenant namespaces alone does not establish a change in security authority; execution under a separate victim authority has not been established here.
  • C:L / I:L / A:N: the confirmed impact is selective cached-output disclosure and substitution. Arbitrary code execution, complete workload compromise, and a service-availability impact are not established.

Root cause

The vulnerable implementation hashes selected Argo template fields without a namespace. Cache lookups and duplicate checks use the key alone, and stored rows have no namespace ownership field. On a hit, the admission handler restores cached outputs and substitutes a dummy container for the step's containers.

The completion watcher also trusts the mutable pipelines.kubeflow.org/execution_cache_key annotation when publishing outputs. Adding a namespace to the hash alone is therefore insufficient: a tenant able to patch its own pod could supply another namespace's deterministic key. Namespace ownership must be enforced independently on cache writes and reads.

Relevant implementation files are backend/src/cache/server/mutation.go, backend/src/cache/server/watcher.go, backend/src/cache/storage/execution_cache_store.go, and backend/src/cache/model/execution_cache.go.

Fix status

The source fix merged on September 10, 2026 in PR #14359, commit 620d0cc89ae0d042a484a003f8ffe6e9a55d347e.

The merged fix:

  • Derives namespaced keys from the API server's admission request namespace and selected template fields.
  • Recomputes completed pods' keys from their observed namespace and ARGO_TEMPLATE, rejecting mismatched or malformed identities rather than trusting the annotation.
  • Stores the observed namespace separately and scopes normal reads and duplicate detection by namespace and key.
  • Adds a namespace column and composite index, leaving historical rows unowned and excluded from normal lookups.
  • Rejects structurally malformed template objects without panicking.

The first fixed release is 2.18.0. Releases through 2.17.3 remain affected; the affected-version upper bound is <= 2.17.3 and the patched version is 2.18.0.

Upgrade requirements and legacy fallback

The standard cache-server Deployment supports a normal rolling upgrade from 2.17.2. Apply the upgraded manifests without manually stopping old replicas or pausing submissions. Namespace isolation is fully enforced only after all old cache-server processes, including terminating pods, have exited and every new replica uses enforce. Custom installations sharing the cache database must upgrade every writer. Mixed-version operation does not yet provide the full isolation guarantee.

Expect reduced cache reuse and increased step execution/resource use as tasks next run; there is no startup cache rebuild. Do not infer or backfill namespace ownership for historical rows. Pre-upgrade pods carrying old-format keys do not seed the new namespaced cache. Completing the upgrade does not undo previously disclosed data or reused poisoned outputs. Do not roll back to the vulnerable implementation to recover cache hits.

PR #14427 merged into release-2.18 on October 5, 2026 and standardizes the compatibility setting as KFP_SECURITY_LEGACY_CACHE_MODE=enforce|audit on the cache-server Deployment. This supersedes the original fix's ALLOW_LEGACY_CACHE_FALLBACK interface. Unset, empty, or enforce keeps full namespace isolation; invalid values prevent startup.

Explicit audit permits a genuine namespaced cache miss to reuse a historical template-only entry whose stored namespace is empty. That entry may contain another tenant's outputs, including poisoned outputs: audit accepts residual cross-tenant confidentiality and integrity risk, and is not full remediation. Scoped entries take precedence, known foreign namespaces remain excluded, and a database error does not enable legacy fallback. Legacy hits are not promoted or backfilled into namespaced rows.

The server emits a startup warning and scoped security_audit events for legacy reuse without logging cached outputs or credentials. Keep replicas configured consistently, persist the mode in deployment configuration, and return to enforce after migration. Native V2 caching is outside this control and this advisory.

See the released cache-server guide for rollout completion checks and audit-to-enforce migration. This fix does not establish an integrity boundary between users who can modify workloads within the same namespace.

Mitigation until the fixed release is deployed

Disable legacy cache reuse for affected workloads, or ensure mutually untrusted namespaces do not share the legacy cache service and storage. Restricting the webhook's namespace selector or watcher scope alone is insufficient if mutually untrusted tenants still share cached entries.

Validation

Source review identified the shared key, unscoped storage, and mutable-annotation write path. The public fix includes regressions exercising admission and completion handling, forged foreign-namespace keys, normal same-namespace reuse, malformed templates, legacy-row exclusion, and optional fallback behavior.

During development, the cache test suite and lint passed; populated and repeatable schema migration and scoped storage behavior were verified on SQLite, MySQL 8.4, and PostgreSQL 16. Negative controls removing the watcher identity check or storage namespace filter failed their corresponding regressions. These tests use fake Kubernetes clients; they are not a claim of a live multi-tenant Kubernetes exploit reproduction.

Private patch disposition

The earlier private PR #1 is closed as superseded by public PR #14359 and the released follow-ups described above. The private branch and review history are retained; this closure does not dismiss the report or change reporter credit. The advisory remains a draft pending the publication review.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kubeflow/pipelines"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260910172610-620d0cc89ae0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-88982"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-11-09T22:43:33Z",
    "nvd_published_at": "2026-11-05T23:17:01Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe legacy Kubeflow Pipelines V1/raw-Argo execution cache does not separate cached results by Kubernetes namespace. In multi-user deployments where tenants share the cache service, a tenant can receive another tenant\u0027s cached outputs or seed outputs that are subsequently substituted into another tenant\u0027s step.\n\nThis affects the Argo-template cache mutating webhook and its cache-server storage path. Standard KFP V2 component pods bypass this webhook cache; the separate V2 cache implementation is outside this advisory\u0027s scope.\n\n## Affected deployments and impact\n\nThe issue requires multiple tenant namespaces sharing the legacy cache service, cache-enabled V1/raw-Argo steps, and cache entries that satisfy the configured staleness policy. The standard multi-user configuration watches pods across namespaces.\n\nA tenant able to submit a step with the same cache-relevant template fields as another tenant\u0027s step can:\n\n- Read cached step outputs originally produced in another namespace.\n- Populate the shared cache before another tenant\u0027s matching step runs, causing that step to report the cached outputs instead of executing its intended containers.\n\nMatching refers to the selected template fields used by the cache key, not merely an identical container image. This is an application-level cache-key collision caused by missing tenant scope, not a cryptographic SHA-256 collision. The finding establishes cross-namespace confidentiality and integrity impact; it does not establish arbitrary code execution.\n\n## CVSS rationale\n\n**Medium \u2014 CVSS 3.1: 5.4**\n\n`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N`\n\n- **AV:N / PR:L / UI:N:** a tenant with ordinary workload-submission privileges can exercise the shared cache through network-accessible APIs. Reading an existing cached result or poisoning a subsequent automated execution requires no additional victim interaction.\n- **AC:L:** known or shared templates can produce the same cache key deterministically. Cache-enabled execution and matching template fields describe the affected configuration; they do not establish an unavoidable narrow race or secret prerequisite.\n- **S:U:** the established impact is disclosure or substitution of output data managed by the same cache service. Crossing tenant namespaces alone does not establish a change in security authority; execution under a separate victim authority has not been established here.\n- **C:L / I:L / A:N:** the confirmed impact is selective cached-output disclosure and substitution. Arbitrary code execution, complete workload compromise, and a service-availability impact are not established.\n\n## Root cause\n\nThe vulnerable implementation hashes selected Argo template fields without a namespace. Cache lookups and duplicate checks use the key alone, and stored rows have no namespace ownership field. On a hit, the admission handler restores cached outputs and substitutes a dummy container for the step\u0027s containers.\n\nThe completion watcher also trusts the mutable `pipelines.kubeflow.org/execution_cache_key` annotation when publishing outputs. Adding a namespace to the hash alone is therefore insufficient: a tenant able to patch its own pod could supply another namespace\u0027s deterministic key. Namespace ownership must be enforced independently on cache writes and reads.\n\nRelevant implementation files are `backend/src/cache/server/mutation.go`, `backend/src/cache/server/watcher.go`, `backend/src/cache/storage/execution_cache_store.go`, and `backend/src/cache/model/execution_cache.go`.\n\n## Fix status\n\nThe source fix merged on September 10, 2026 in [PR #14359](https://github.com/kubeflow/pipelines/pull/14359), commit [620d0cc89ae0d042a484a003f8ffe6e9a55d347e](https://github.com/kubeflow/pipelines/commit/620d0cc89ae0d042a484a003f8ffe6e9a55d347e).\n\nThe merged fix:\n\n- Derives namespaced keys from the API server\u0027s admission request namespace and selected template fields.\n- Recomputes completed pods\u0027 keys from their observed namespace and `ARGO_TEMPLATE`, rejecting mismatched or malformed identities rather than trusting the annotation.\n- Stores the observed namespace separately and scopes normal reads and duplicate detection by namespace and key.\n- Adds a namespace column and composite index, leaving historical rows unowned and excluded from normal lookups.\n- Rejects structurally malformed template objects without panicking.\n\nThe first fixed release is **[2.18.0](https://github.com/kubeflow/pipelines/releases/tag/2.18.0)**. Releases through **2.17.3** remain affected; the affected-version upper bound is `\u003c= 2.17.3` and the patched version is `2.18.0`.\n\n## Upgrade requirements and legacy fallback\n\nThe standard cache-server Deployment supports a normal rolling upgrade from 2.17.2. Apply the upgraded manifests without manually stopping old replicas or pausing submissions. Namespace isolation is fully enforced only after all old cache-server processes, including terminating pods, have exited and every new replica uses `enforce`. Custom installations sharing the cache database must upgrade every writer. Mixed-version operation does not yet provide the full isolation guarantee.\n\nExpect reduced cache reuse and increased step execution/resource use as tasks next run; there is no startup cache rebuild. Do not infer or backfill namespace ownership for historical rows. Pre-upgrade pods carrying old-format keys do not seed the new namespaced cache. Completing the upgrade does not undo previously disclosed data or reused poisoned outputs. Do not roll back to the vulnerable implementation to recover cache hits.\n\n[PR #14427](https://github.com/kubeflow/pipelines/pull/14427) merged into `release-2.18` on October 5, 2026 and standardizes the compatibility setting as **`KFP_SECURITY_LEGACY_CACHE_MODE=enforce|audit` on the cache-server Deployment**. This supersedes the original fix\u0027s `ALLOW_LEGACY_CACHE_FALLBACK` interface. Unset, empty, or `enforce` keeps full namespace isolation; invalid values prevent startup.\n\nExplicit `audit` permits a genuine namespaced cache miss to reuse a historical template-only entry whose stored namespace is empty. That entry may contain another tenant\u0027s outputs, including poisoned outputs: audit accepts residual cross-tenant confidentiality and integrity risk, and is not full remediation. Scoped entries take precedence, known foreign namespaces remain excluded, and a database error does not enable legacy fallback. Legacy hits are not promoted or backfilled into namespaced rows.\n\nThe server emits a startup warning and scoped `security_audit` events for legacy reuse without logging cached outputs or credentials. Keep replicas configured consistently, persist the mode in deployment configuration, and return to `enforce` after migration. Native V2 caching is outside this control and this advisory.\n\nSee the [released cache-server guide](https://github.com/kubeflow/pipelines/blob/2.18.0/backend/src/cache/README.md#namespace-isolation-and-upgrades) for rollout completion checks and audit-to-enforce migration. This fix does not establish an integrity boundary between users who can modify workloads within the same namespace.\n\n## Mitigation until the fixed release is deployed\n\nDisable legacy cache reuse for affected workloads, or ensure mutually untrusted namespaces do not share the legacy cache service and storage. Restricting the webhook\u0027s namespace selector or watcher scope alone is insufficient if mutually untrusted tenants still share cached entries.\n\n## Validation\n\nSource review identified the shared key, unscoped storage, and mutable-annotation write path. The public fix includes regressions exercising admission and completion handling, forged foreign-namespace keys, normal same-namespace reuse, malformed templates, legacy-row exclusion, and optional fallback behavior.\n\nDuring development, the cache test suite and lint passed; populated and repeatable schema migration and scoped storage behavior were verified on SQLite, MySQL 8.4, and PostgreSQL 16. Negative controls removing the watcher identity check or storage namespace filter failed their corresponding regressions. These tests use fake Kubernetes clients; they are not a claim of a live multi-tenant Kubernetes exploit reproduction.\n\n### Private patch disposition\n\nThe earlier [private PR #1](https://github.com/kubeflow/pipelines-ghsa-2xwh-426q-42c5/pull/1) is closed as superseded by [public PR #14359](https://github.com/kubeflow/pipelines/pull/14359) and the released follow-ups described above. The private branch and review history are retained; this closure does not dismiss the report or change reporter credit. The advisory remains a draft pending the publication review.",
  "id": "GHSA-2xwh-426q-42c5",
  "modified": "2026-11-09T22:43:33Z",
  "published": "2026-11-09T22:43:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kubeflow/pipelines/security/advisories/GHSA-2xwh-426q-42c5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88982"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubeflow/pipelines/pull/14359"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubeflow/pipelines/commit/620d0cc89ae0d042a484a003f8ffe6e9a55d347e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kubeflow/pipelines"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubeflow/pipelines/releases/tag/2.18.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Kubeflow Pipelines: Cross-tenant execution-cache poisoning / output substitution via a namespace-blind cache key in the cache webhook (multi-user)"
}

GHSA-2XX8-J85V-J7WH

Vulnerability from github – Published: 2026-04-14 18:30 – Updated: 2026-04-16 01:32
VLAI
Summary
Webkul Krayin CRM has Broken Object-Level Authorization (BOLA) in the /Contact/Persons/PersonController.php
Details

A Broken Object-Level Authorization (BOLA) in the /Contact/Persons/PersonController.php endpoint of Webkul Krayin CRM v2.2.x allows authenticated attackers to arbitrarily read, modify, and permanently delete any contact owned by other users via supplying a crafted GET request.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "krayin/laravel-crm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-38532"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T01:32:19Z",
    "nvd_published_at": "2026-04-14T16:16:43Z",
    "severity": "HIGH"
  },
  "details": "A Broken Object-Level Authorization (BOLA) in the /Contact/Persons/PersonController.php endpoint of Webkul Krayin CRM v2.2.x allows authenticated attackers to arbitrarily read, modify, and permanently delete any contact owned by other users via supplying a crafted GET request.",
  "id": "GHSA-2xx8-j85v-j7wh",
  "modified": "2026-04-16T01:32:19Z",
  "published": "2026-04-14T18:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-38532"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TREXNEGRO/Security-Advisories/tree/main/CVE-2026-38532"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/krayin/laravel-crm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Webkul Krayin CRM has Broken Object-Level Authorization (BOLA) in the /Contact/Persons/PersonController.php"
}

GHSA-3242-HVMP-WGVM

Vulnerability from github – Published: 2023-01-30 21:30 – Updated: 2023-02-07 00:30
VLAI
Details

The AAWP WordPress plugin before 3.12.3 can be used to abuse trusted domains to load malware or other files through it (Reflected File Download) to bypass firewall rules in companies.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-4794"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-30T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "The AAWP WordPress plugin before 3.12.3 can be used to abuse trusted domains to load malware or other files through it (Reflected File Download) to bypass firewall rules in companies.",
  "id": "GHSA-3242-hvmp-wgvm",
  "modified": "2023-02-07T00:30:26Z",
  "published": "2023-01-30T21:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4794"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/feb4580d-df15-45c8-b59e-ad406e4b064c"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3277-H8G9-QJ5F

Vulnerability from github – Published: 2026-08-20 18:39 – Updated: 2026-08-20 18:39
VLAI
Summary
Winter: Authenticated IDOR in backend FileUpload widget allows cross-user access to attachment metadata
Details

Impact

The backend FileUpload form widget trusted an attacker-controlled file_id POST parameter when resolving the attachment it operates on. The lookup (FileUpload::getFileRecord()) resolved the posted id against the global system_files table without verifying that the file belonged to the widget's own relation, parent record, or deferred-binding session.

Any authenticated backend user who can reach a form containing a fileupload field — including the built-in My Account avatar field, which requires no specific backend permission — could therefore target a System\Models\File record belonging to another user or record and:

  • modify its title and description via onSaveAttachmentConfig, and
  • change its sort_order via onSortAttachments (which passed posted ids straight to setSortableOrder(), an unscoped UPDATE ... WHERE id = ?).

The same unscoped lookup is reached by onLoadAttachmentConfig, onSaveAttachmentConfig, and onRemoveAttachment. Because all attachments share the single System\Models\File model and system_files table, an attacker was not limited to other users' avatars — any attachment on any model could be referenced by id. Attachment ids are sequential integers and are easily enumerated.

The confirmed impact is unauthorized integrity modification of arbitrary attachment metadata and ordering.

CSRF tokens are still verified on all POST requests, so an attacker must be authenticated to the backend with a valid session. To exploit this issue an attacker needs a backend account with any level of access.

Patches

The FileUpload widget now scopes every file_id lookup to the widget's own relation, including any files bound through the current deferred-binding session, so a posted id can no longer reference an unrelated System\Models\File record:

  • getFileRecord() resolves the id through getRelationObject()->withDeferred($this->sessionKey)->find(...) rather than the global file model. This covers onLoadAttachmentConfig, onSaveAttachmentConfig, and onRemoveAttachment.
  • onSortAttachments() intersects the posted ids with the ids that actually belong to the relation before calling setSortableOrder().

This security issue has been fixed as of v1.2.13 (commit 9cb0ae5f9d837db141ab111c6a7de8eed9603d25).

Workarounds

There is no supported workaround other than upgrading. If you cannot upgrade immediately, you may apply the fix manually in modules/backend/formwidgets/FileUpload.php:

  1. In getFileRecord(), replace $this->getRelationModel()->find(post('file_id')) with $this->getRelationObject()->withDeferred($this->sessionKey)->find(post('file_id')).
  2. In onSortAttachments(), filter the posted sortOrder ids to those returned by $this->getRelationObject()->withDeferred($this->sessionKey)->pluck($keyName) before calling setSortableOrder().
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.2.12"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "winter/wn-backend-module"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54256"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-20T18:39:56Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nThe backend `FileUpload` form widget trusted an attacker-controlled `file_id` POST parameter when resolving the attachment it operates on. The lookup (`FileUpload::getFileRecord()`) resolved the posted id against the global `system_files` table without verifying that the file belonged to the widget\u0027s own relation, parent record, or deferred-binding session.\n\nAny authenticated backend user who can reach a form containing a `fileupload` field \u2014 including the built-in **My Account** avatar field, which requires no specific backend permission \u2014 could therefore target a `System\\Models\\File` record belonging to another user or record and:\n\n- modify its `title` and `description` via `onSaveAttachmentConfig`, and\n- change its `sort_order` via `onSortAttachments` (which passed posted ids\n  straight to `setSortableOrder()`, an unscoped `UPDATE ... WHERE id = ?`).\n\nThe same unscoped lookup is reached by `onLoadAttachmentConfig`, `onSaveAttachmentConfig`, and `onRemoveAttachment`. Because all attachments share the single `System\\Models\\File` model and `system_files` table, an attacker was not limited to other users\u0027 avatars \u2014 any attachment on any model could be referenced by id. Attachment ids are sequential integers and are easily enumerated.\n\nThe confirmed impact is unauthorized integrity modification of arbitrary attachment metadata and ordering.\n\nCSRF tokens are still verified on all POST requests, so an attacker must be authenticated to the backend with a valid session. To exploit this issue an attacker needs a backend account with any level of access.\n\n### Patches\n\nThe `FileUpload` widget now scopes every `file_id` lookup to the widget\u0027s own relation, including any files bound through the current deferred-binding session, so a posted id can no longer reference an unrelated `System\\Models\\File` record:\n\n- `getFileRecord()` resolves the id through `getRelationObject()-\u003ewithDeferred($this-\u003esessionKey)-\u003efind(...)` rather than the global file model. This covers `onLoadAttachmentConfig`, `onSaveAttachmentConfig`, and `onRemoveAttachment`.\n- `onSortAttachments()` intersects the posted ids with the ids that actually belong to the relation before calling `setSortableOrder()`.\n\nThis security issue has been fixed as of **v1.2.13** (commit [`9cb0ae5f9d837db141ab111c6a7de8eed9603d25`](https://github.com/wintercms/winter/commit/9cb0ae5f9d837db141ab111c6a7de8eed9603d25)).\n\n### Workarounds\n\nThere is no supported workaround other than upgrading. If you cannot upgrade immediately, you may apply the fix manually in `modules/backend/formwidgets/FileUpload.php`:\n\n1. In `getFileRecord()`, replace `$this-\u003egetRelationModel()-\u003efind(post(\u0027file_id\u0027))` with `$this-\u003egetRelationObject()-\u003ewithDeferred($this-\u003esessionKey)-\u003efind(post(\u0027file_id\u0027))`.\n2. In `onSortAttachments()`, filter the posted `sortOrder` ids to those returned by `$this-\u003egetRelationObject()-\u003ewithDeferred($this-\u003esessionKey)-\u003epluck($keyName)` before calling `setSortableOrder()`.",
  "id": "GHSA-3277-h8g9-qj5f",
  "modified": "2026-08-20T18:39:56Z",
  "published": "2026-08-20T18:39:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/wintercms/winter/security/advisories/GHSA-3277-h8g9-qj5f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wintercms/winter/security/advisories/GHSA-qq9m-vfv4-pj5w"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wintercms/winter/commit/9cb0ae5f9d837db141ab111c6a7de8eed9603d25"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/wintercms/winter"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wintercms/winter/releases/tag/v1.2.13"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Winter: Authenticated IDOR in backend FileUpload widget allows cross-user access to attachment metadata"
}

GHSA-32C3-9M45-XG9F

Vulnerability from github – Published: 2026-10-30 12:31 – Updated: 2026-10-30 12:31
VLAI
Details

Moodle 4.2.0 through 4.5.15, 5.0.0 through 5.0.11, 5.1.0 through 5.1.8, 5.2.0 through 5.2.4, and 5.3.0 contain an information disclosure vulnerability in the core_grades_get_feedback web service. The service lacks group-membership and enrolment checks, so non-editing teachers can iterate userid values to read other groups' grade feedback and users' names and identity fields such as email.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-119555"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-30T12:16:42Z",
    "severity": "MODERATE"
  },
  "details": "Moodle 4.2.0 through 4.5.15, 5.0.0 through 5.0.11, 5.1.0 through 5.1.8, 5.2.0 through 5.2.4, and 5.3.0 contain an information disclosure vulnerability in the core_grades_get_feedback web service. The service lacks group-membership and enrolment checks, so non-editing teachers can iterate userid values to read other groups\u0027 grade feedback and users\u0027 names and identity fields such as email.",
  "id": "GHSA-32c3-9m45-xg9f",
  "modified": "2026-10-30T12:31:21Z",
  "published": "2026-10-30T12:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-119555"
    },
    {
      "type": "WEB",
      "url": "https://abraxaslabs.tech/research/moodle-grades-feedback-idor"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moodle/moodle"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moodle/moodle/blob/v5.3.0/public/grade/classes/external/get_feedback.php#L77-L96"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/moodle-through-5.3.0-5.2.4-5.1.8-5.0.11-and-4.5.15-information-disclosure-via-core-grades-get-feedback"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/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-32CW-Q6VW-7RJ6

Vulnerability from github – Published: 2026-09-17 09:33 – Updated: 2026-09-17 09:33
VLAI
Details

The Checkout Field Manager (Checkout Manager) for WooCommerce WordPress plugin before 7.9.7 does not properly validate the ownership of an attachment before deleting it, allowing any authenticated user such as a customer to delete arbitrary media attachments belonging to other users.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-87829"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-17T08:17:02Z",
    "severity": "MODERATE"
  },
  "details": "The Checkout Field Manager (Checkout Manager) for WooCommerce WordPress plugin before 7.9.7 does not properly validate the ownership of an attachment before deleting it, allowing any authenticated user such as a customer to delete arbitrary media attachments belonging to other users.",
  "id": "GHSA-32cw-q6vw-7rj6",
  "modified": "2026-09-17T09:33:01Z",
  "published": "2026-09-17T09:33:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87829"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/8c76bf99-5d3e-4573-a909-040a7ab36d68"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design

For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.

Mitigation
Architecture and Design Implementation

Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Mitigation
Architecture and Design

Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.

No CAPEC attack patterns related to this CWE.