Common Weakness Enumeration

CWE-639

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.

4620 vulnerabilities reference this CWE, most recent first.

GHSA-2XGC-784M-6J64

Vulnerability from github – Published: 2026-06-15 21:30 – Updated: 2026-06-15 21:30
VLAI
Details

Unauthenticated Insecure Direct Object References (IDOR) in VikRentCar <= 1.4.5 versions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-52699"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-15T21:17:24Z",
    "severity": "HIGH"
  },
  "details": "Unauthenticated Insecure Direct Object References (IDOR) in VikRentCar \u003c= 1.4.5 versions.",
  "id": "GHSA-2xgc-784m-6j64",
  "modified": "2026-06-15T21:30:50Z",
  "published": "2026-06-15T21:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52699"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/vikrentcar/vulnerability/wordpress-vikrentcar-plugin-1-4-5-insecure-direct-object-references-idor-vulnerability?_s_id=cve"
    }
  ],
  "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-2XGG-2X8H-8XW4

Vulnerability from github – Published: 2026-07-14 00:09 – Updated: 2026-07-14 00:09
VLAI
Summary
Kimai: Improper Authorization in Project, Customer, and Activity Rate Edit Endpoints Allows Cross-Scope Rate Manipulation
Details

Summary

Kimai 2.56.0 contains an authenticated improper authorization vulnerability in the Web rate editing flows for projects, customers, and activities. A user who can edit one authorized parent object can combine that authorized parent ID with the rate ID of a different, unauthorized parent object and thereby modify the unauthorized rate record.

This affects ProjectRate, CustomerRate, and ActivityRate editing. The issue is caused by missing parent-child consistency validation and allows cross-project, cross-customer, or cross-activity tampering of billing-related configuration.

Details

The issue affects the following Web routes:

  • GET/POST /en/admin/project/{id}/rate/{rate}
  • GET/POST /en/admin/customer/{id}/rate/{rate}
  • GET/POST /en/admin/activity/{id}/rate/{rate}

In both cases, the parent object and the rate object are resolved independently from user-controlled route parameters. The controller only checks whether the current user may edit the parent object referenced by {id}, but it does not verify that the child rate object referenced by {rate} actually belongs to that same parent.

In these controllers, there is no validation such as:

  • $rate->getProject() === $project
  • $rate->getCustomer() === $customer
  • $rate->getActivity() === $activity

This missing binding check is especially notable because the API delete endpoints already enforce the expected parent-child relationship.

This shows that parent-child consistency is already a recognized invariant in the application design, but the Web edit endpoints fail to enforce it for projects, customers, and activities.

A PoC was provided, but removed for security reasons.

Impact

This vulnerability allows authenticated users to tamper with billing-related rate configuration outside their authorized project, customer, or activity scope. An attacker can modify rate values belonging to other teams or business domains, which can affect time-based settlement, inherited pricing, cost calculations, budget reporting, revenue reporting, and downstream invoice generation.

Because the issue directly persists changes into kimai2_projects_rates, kimai2_customers_rates, and kimai2_activities_rates, it is a real cross-scope integrity vulnerability rather than a UI-only flaw. The attack breaks team-based isolation boundaries for high-value financial configuration.

Solution

The rate edit forms for customers, projects and activities now verify that the rate belongs to the parent referenced in the URL and reject the request otherwise.

See https://www.kimai.org/en/security/ghsa-2xgg-2x8h-8xw4 for more information.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.56.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "kimai/kimai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.57.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52826"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-14T00:09:35Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nKimai 2.56.0 contains an authenticated improper authorization vulnerability in the Web rate editing flows for projects, customers, and activities. A user who can edit one authorized parent object can combine that authorized parent ID with the rate ID of a different, unauthorized parent object and thereby modify the unauthorized rate record.\n\nThis affects `ProjectRate`, `CustomerRate`, and `ActivityRate` editing. The issue is caused by missing parent-child consistency validation and allows cross-project, cross-customer, or cross-activity tampering of billing-related configuration.\n\n### Details\n\nThe issue affects the following Web routes:\n\n- `GET/POST /en/admin/project/{id}/rate/{rate}`\n- `GET/POST /en/admin/customer/{id}/rate/{rate}`\n- `GET/POST /en/admin/activity/{id}/rate/{rate}`\n\nIn both cases, the parent object and the rate object are resolved independently from user-controlled route parameters. The controller only checks whether the current user may edit the parent object referenced by `{id}`, but it does not verify that the child rate object referenced by `{rate}` actually belongs to that same parent.\n\nIn these controllers, there is no validation such as:\n\n- `$rate-\u003egetProject() === $project`\n- `$rate-\u003egetCustomer() === $customer`\n- `$rate-\u003egetActivity() === $activity`\n\nThis missing binding check is especially notable because the API delete endpoints already enforce the expected parent-child relationship.\n\nThis shows that parent-child consistency is already a recognized invariant in the application design, but the Web edit endpoints fail to enforce it for projects, customers, and activities.\n\n*A PoC was provided, but removed for security reasons.*\n\n### Impact\n\nThis vulnerability allows authenticated users to tamper with billing-related rate configuration outside their authorized project, customer, or activity scope. An attacker can modify rate values belonging to other teams or business domains, which can affect time-based settlement, inherited pricing, cost calculations, budget reporting, revenue reporting, and downstream invoice generation.\n\nBecause the issue directly persists changes into `kimai2_projects_rates`, `kimai2_customers_rates`, and `kimai2_activities_rates`, it is a real cross-scope integrity vulnerability rather than a UI-only flaw. The attack breaks team-based isolation boundaries for high-value financial configuration.\n\n# Solution\n\nThe rate edit forms for `customers`, `projects` and `activities` now verify that the rate belongs to the parent referenced in the URL and reject the request otherwise.\n\nSee [https://www.kimai.org/en/security/ghsa-2xgg-2x8h-8xw4](https://www.kimai.org/en/security/ghsa-2xgg-2x8h-8xw4) for more information.",
  "id": "GHSA-2xgg-2x8h-8xw4",
  "modified": "2026-07-14T00:09:35Z",
  "published": "2026-07-14T00:09:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kimai/kimai/security/advisories/GHSA-2xgg-2x8h-8xw4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kimai/kimai"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Kimai: Improper Authorization in Project, Customer, and Activity Rate Edit Endpoints Allows Cross-Scope Rate Manipulation"
}

GHSA-2XGM-WC4G-5JVG

Vulnerability from github – Published: 2026-07-22 22:24 – Updated: 2026-07-22 22:24
VLAI
Summary
n8n: Improper Authorization Allows Authenticated Users to Assign Workflows to Folders in Other Projects
Details

Impact

An authenticated user with permission to create workflows in one project could bypass project/folder authorization boundaries during workflow creation. By supplying a crafted request payload, the user could associate a newly created workflow with a folder belonging to a different project they do not have access to.

The workflow itself remains in the attacker's project and is not visible to the target project's members. The target project's folder ownership is not changed, and no data from the target project is exposed. The impact is limited to a logical integrity violation of the target project's folder structure at the database level.

This issue affects instances with multi-project and folder support enabled.

Patches

The issue has been fixed in n8n version 2.28.0. Users should upgrade to this version or later to remediate the vulnerability.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Restrict project membership and workflow creation permissions to fully trusted users only.

This workaround does not fully remediate the risk and should only be used as a short-term mitigation measure.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.28.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59253"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-22T22:24:43Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Impact\nAn authenticated user with permission to create workflows in one project could bypass project/folder authorization boundaries during workflow creation. By supplying a crafted request payload, the user could associate a newly created workflow with a folder belonging to a different project they do not have access to.\n\nThe workflow itself remains in the attacker\u0027s project and is not visible to the target project\u0027s members. The target project\u0027s folder ownership is not changed, and no data from the target project is exposed. The impact is limited to a logical integrity violation of the target project\u0027s folder structure at the database level.\n\nThis issue affects instances with multi-project and folder support enabled.\n\n## Patches\nThe issue has been fixed in n8n version 2.28.0. Users should upgrade to this version or later to remediate the vulnerability.\n\n## Workarounds\nIf upgrading is not immediately possible, administrators should consider the following temporary mitigations:\n- Restrict project membership and workflow creation permissions to fully trusted users only.\n\nThis workaround does not fully remediate the risk and should only be used as a short-term mitigation measure.",
  "id": "GHSA-2xgm-wc4g-5jvg",
  "modified": "2026-07-22T22:24:43Z",
  "published": "2026-07-22T22:24:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-2xgm-wc4g-5jvg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59253"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/n8n-io/n8n"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/releases/tag/n8n@2.28.0"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/n8n-improper-authorization-in-workflow-assignment-to-folders"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "n8n: Improper Authorization Allows Authenticated Users to Assign Workflows to Folders in Other Projects"
}

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