Common Weakness Enumeration

CWE-639

Allowed

Authorization Bypass Through User-Controlled Key

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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.

4780 vulnerabilities reference this CWE, most recent first.

GHSA-J5JQ-5W3C-XC48

Vulnerability from github – Published: 2026-08-13 00:31 – Updated: 2026-08-13 18:31
VLAI
Details

vinny/views.py: (ModifyEmailNotifications) IDOR: view fetches VinceCommEmail by raw pk from URL and toggles email_function/name without checking the record's contact belongs to the requesting group-admin. Lets a vendor admin flip notification routing (or read email/name) for another vendor's contact.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-18750"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-12T22:17:15Z",
    "severity": "MODERATE"
  },
  "details": "vinny/views.py: (ModifyEmailNotifications)\tIDOR: view fetches VinceCommEmail by raw pk from URL and toggles email_function/name without checking the record\u0027s contact belongs to the requesting group-admin. Lets a vendor admin flip notification routing (or read email/name) for another vendor\u0027s contact.",
  "id": "GHSA-j5jq-5w3c-xc48",
  "modified": "2026-08-13T18:31:26Z",
  "published": "2026-08-13T00:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18750"
    },
    {
      "type": "WEB",
      "url": "https://github.com/CERTCC/VINCE/pull/235"
    },
    {
      "type": "WEB",
      "url": "https://certcc.github.com/CERTCC/VINCE"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J5JQ-CR68-V2XX

Vulnerability from github – Published: 2026-08-12 15:15 – Updated: 2026-08-12 15:15
VLAI
Summary
Winter: Authenticated backend users can bypass Users controller permission checks
Details

Impact

Affected versions of Winter CMS did not validate the handler name submitted through the form postback mechanism (_handler POST field) in the same way as AJAX requests (X_WINTER_REQUEST_HANDLER header). The AJAX path validates that handler names match the on[A-Z][\w+]* pattern, but the postback path passed the handler name directly to the handler dispatcher with no validation.

This allowed an authenticated backend user to call any method on a controller — including action-prefixed, protected, and private methods — by submitting a crafted POST request with a _handler field, as long as the controller either:

  • Contains a publicly available action via the $publicActions property, or
  • Degrades or removes the $requiredPermissions check in its constructor based on a condition

The backend's own Users controller was affected by the second scenario: it set $requiredPermissions to null for the myaccount action, allowing any authenticated backend user to access the controller without the backend.manage_users permission. Combined with the postback bypass, this allowed calling controller methods such as update_onDelete, update_onRestore, update_onUnsuspendUser, and update_onManualPasswordReset with attacker-controlled parameters.

Note that CSRF tokens are still verified on all POST requests, so the attacker must be logged into the backend with a valid session.

To actively exploit this security issue, an attacker would need access to the Backend with a user account with any level of access.

The Winter CMS maintainers strongly recommend that all Winter CMS sites that have any reliance on the roles & permissions system to update immediately. Security fixes have been backported to all major versions of Winter (1.0, 1.1, and 1.2).

Patches

The postback handler path now validates handler names using the same rules as the AJAX path. The My Account functionality has been moved to a dedicated controller that does not expose user management methods. Defence in depth has been applied at the model level to prevent unauthorized user record modifications regardless of the entry point.

This security issue has been fixed as of v1.2.13.

Workarounds

If users cannot upgrade, they may apply the following changes to their Winter CMS installation manually to resolve this issue:

  1. In modules/backend/classes/Controller.php, validate the _handler POST field against the on[A-Z][\w+]* pattern before passing it to runAjaxHandler().
  2. In modules/backend/controllers/Users.php, remove the conditional that sets $requiredPermissions to null for the myaccount action.
Severity
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N
Show details on source website
To clipboard 

{
  "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-35445"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-12T15:15:17Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nAffected versions of Winter CMS did not validate the handler name submitted through the form postback mechanism (`_handler` POST field) in the same way as AJAX requests (`X_WINTER_REQUEST_HANDLER` header). The AJAX path validates that handler names match the `on[A-Z][\\w+]*` pattern, but the postback path passed the handler name directly to the handler dispatcher with no validation.\n\nThis allowed an authenticated backend user to call any method on a controller \u2014 including action-prefixed, protected, and private methods \u2014 by submitting a crafted POST request with a `_handler` field, as long as the controller either:\n\n- Contains a publicly available action via the `$publicActions` property, or\n- Degrades or removes the `$requiredPermissions` check in its constructor based on a condition\n\nThe backend\u0027s own Users controller was affected by the second scenario: it set `$requiredPermissions` to `null` for the `myaccount` action, allowing any authenticated backend user to access the controller without the `backend.manage_users` permission. Combined with the postback bypass, this allowed calling controller methods such as `update_onDelete`, `update_onRestore`, `update_onUnsuspendUser`, and `update_onManualPasswordReset` with attacker-controlled parameters.\n\nNote that CSRF tokens are still verified on all POST requests, so the attacker must be logged into the backend with a valid session.\n\nTo actively exploit this security issue, an attacker would need access to the Backend with a user account with any level of access.\n\nThe Winter CMS maintainers strongly recommend that all Winter CMS sites that have any reliance on the roles \u0026 permissions system to update immediately. Security fixes have been backported to all major versions of Winter (1.0, 1.1, and 1.2).\n\n### Patches\n\nThe postback handler path now validates handler names using the same rules as the AJAX path. The My Account functionality has been moved to a dedicated controller that does not expose user management methods. Defence in depth has been applied at the model level to prevent unauthorized user record modifications regardless of the entry point.\n\nThis security issue has been fixed as of v1.2.13.\n\n### Workarounds\n\nIf users cannot upgrade, they may apply the following changes to their Winter CMS installation manually to resolve this issue:\n\n1. In `modules/backend/classes/Controller.php`, validate the `_handler` POST field against the `on[A-Z][\\w+]*` pattern before passing it to `runAjaxHandler()`.\n2. In `modules/backend/controllers/Users.php`, remove the conditional that sets `$requiredPermissions` to `null` for the `myaccount` action.",
  "id": "GHSA-j5jq-cr68-v2xx",
  "modified": "2026-08-12T15:15:17Z",
  "published": "2026-08-12T15:15:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/wintercms/winter/security/advisories/GHSA-j5jq-cr68-v2xx"
    },
    {
      "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:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Winter: Authenticated backend users can bypass Users controller permission checks"
}

GHSA-J5MC-P8QG-39J7

Vulnerability from github – Published: 2026-07-02 20:44 – Updated: 2026-07-02 20:44
VLAI
Summary
Kimai Favorite Timesheet Add and Remove Endpoints Allows Cross-User Bookmark Manipulation
Details

Summary

Kimai 2.56.0 contains an authenticated improper authorization / IDOR vulnerability in the favorite timesheet add and remove endpoints. A low-privileged user who knows another user's timesheet.id can add that record to, or remove it from, the victim's favorite/recent bookmark list. This allows cross-user manipulation of per-user favorite state without administrative privileges.

Details

The issue affects the following routes:

  • GET /en/favorite/timesheet/add/{id}
  • GET /en/favorite/timesheet/remove/{id}

Both endpoints accept a user-controlled timesheet identifier and only require the caller to hold the generic start_own_timesheet permission. They do not verify that the referenced Timesheet object belongs to the currently authenticated user.

  • In src/Controller/FavoriteController.php, the controller methods accept a Timesheet object directly and forward it to the favorite service.
  • The root cause becomes more obvious in src/Timesheet/FavoriteRecordService.php. The bookmark owner is derived from $timesheet->getUser() instead of the current session user.
  • Because of this design, any authenticated user who can reference another user's timesheet ID can modify the victim's favorite/recent bookmark data.

A PoC was provided, but removed for security reasons.

Impact

This vulnerability allows any authenticated low-privileged user to manipulate another user's favorite bookmark state across accounts. An attacker can inject arbitrary victim-owned timesheet entries into the victim's quick-entry workflow, remove existing favorites, and repeatedly disturb the victim's normal timesheet usage without needing administrative privileges.

The issue does not directly disclose sensitive data, but it is a real cross-user business-state tampering vulnerability with clear integrity impact. Because the add and remove endpoints can be combined, an attacker can reliably insert, remove, and reorder entries in another user's favorite/recent list.

Severity
1.3 (Low)
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/E:U
Show details on source website
To clipboard 

{
  "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": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T20:44:05Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\n\nKimai 2.56.0 contains an authenticated improper authorization / IDOR vulnerability in the favorite timesheet add and remove endpoints. A low-privileged user who knows another user\u0027s `timesheet.id` can add that record to, or remove it from, the victim\u0027s `favorite/recent` bookmark list. This allows cross-user manipulation of per-user favorite state without administrative privileges.\n\n### Details\n\nThe issue affects the following routes:\n\n- `GET /en/favorite/timesheet/add/{id}`\n- `GET /en/favorite/timesheet/remove/{id}`\n\nBoth endpoints accept a user-controlled timesheet identifier and only require the caller to hold the generic `start_own_timesheet` permission. They do not verify that the referenced `Timesheet` object belongs to the currently authenticated user.\n\n- In `src/Controller/FavoriteController.php`, the controller methods accept a `Timesheet` object directly and forward it to the favorite service. \n- The root cause becomes more obvious in `src/Timesheet/FavoriteRecordService.php`. The bookmark owner is derived from `$timesheet-\u003egetUser()` instead of the current session user.\n- Because of this design, any authenticated user who can reference another user\u0027s timesheet ID can modify the victim\u0027s `favorite/recent` bookmark data.\n\n*A PoC was provided, but removed for security reasons.*\n\n### Impact\n\nThis vulnerability allows any authenticated low-privileged user to manipulate another user\u0027s favorite bookmark state across accounts. An attacker can inject arbitrary victim-owned timesheet entries into the victim\u0027s quick-entry workflow, remove existing favorites, and repeatedly disturb the victim\u0027s normal timesheet usage without needing administrative privileges.\n\nThe issue does not directly disclose sensitive data, but it is a real cross-user business-state tampering vulnerability with clear integrity impact. Because the add and remove endpoints can be combined, an attacker can reliably insert, remove, and reorder entries in another user\u0027s `favorite/recent` list.",
  "id": "GHSA-j5mc-p8qg-39j7",
  "modified": "2026-07-02T20:44:05Z",
  "published": "2026-07-02T20:44:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kimai/kimai/security/advisories/GHSA-j5mc-p8qg-39j7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kimai/kimai"
    },
    {
      "type": "WEB",
      "url": "https://www.kimai.org/en/security/ghsa-j5mc-p8qg-39j7"
    }
  ],
  "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/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Kimai Favorite Timesheet Add and Remove Endpoints Allows Cross-User Bookmark Manipulation"
}

GHSA-J5VG-8WFX-78VQ

Vulnerability from github – Published: 2025-09-30 12:30 – Updated: 2025-10-08 18:30
VLAI
Details

Insecure Direct Object Reference (IDOR) vulnerability in BOLD Workplanner in versions prior to 2.5.25 (4935b438f9b), consisting of a lack of adequate validation of user input, allowing an authenticated user to access to functional contract details using unauthorised internal identifiers.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-41094"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-30T11:37:40Z",
    "severity": "HIGH"
  },
  "details": "Insecure Direct Object Reference (IDOR) vulnerability in BOLD Workplanner in versions prior to 2.5.25 (4935b438f9b), consisting of a lack of adequate validation of user input, allowing an authenticated user to\u00a0access to functional\u00a0contract details using unauthorised internal identifiers.",
  "id": "GHSA-j5vg-8wfx-78vq",
  "modified": "2025-10-08T18:30:15Z",
  "published": "2025-09-30T12:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41094"
    },
    {
      "type": "WEB",
      "url": "https://www.incibe.es/en/incibe-cert/notices/aviso/insecure-direct-object-reference-gps-bold-workplanner"
    }
  ],
  "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:H/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-J5XF-GV89-G422

Vulnerability from github – Published: 2023-11-09 21:30 – Updated: 2023-11-15 18:23
VLAI
Summary
Moodle Cross-site Scripting vulnerability
Details

Wiki comments required additional sanitizing and access restrictions to prevent a stored XSS risk and potential IDOR risk.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.3.0-rc2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-5544"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-11-10T00:41:02Z",
    "nvd_published_at": "2023-11-09T20:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Wiki comments required additional sanitizing and access restrictions to prevent a stored XSS risk and potential IDOR risk.",
  "id": "GHSA-j5xf-gv89-g422",
  "modified": "2023-11-15T18:23:21Z",
  "published": "2023-11-09T21:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5544"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moodle/moodle/commit/5fec728be9df3c9fc282cd0897c73ca5cfcfea5f"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2243443"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moodle/moodle"
    },
    {
      "type": "WEB",
      "url": "https://moodle.org/mod/forum/discuss.php?d=451585"
    },
    {
      "type": "WEB",
      "url": "http://git.moodle.org/gw?p=moodle.git\u0026a=search\u0026h=HEAD\u0026st=commit\u0026s=MDL-79509"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Moodle Cross-site Scripting vulnerability"
}

GHSA-J634-Q9PR-JG3J

Vulnerability from github – Published: 2025-02-01 09:30 – Updated: 2025-02-01 09:30
VLAI
Details

The WP Job Portal – A Complete Recruitment System for Company or Job Board website plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 2.2.6 via the 'jobenforcedelete' due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with employer-level access and above, to delete arbitrary

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-13429"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-01T08:15:10Z",
    "severity": "MODERATE"
  },
  "details": "The WP Job Portal \u2013 A Complete Recruitment System for Company or Job Board website plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 2.2.6 via the \u0027jobenforcedelete\u0027 due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with employer-level access and above, to delete arbitrary",
  "id": "GHSA-j634-q9pr-jg3j",
  "modified": "2025-02-01T09:30:28Z",
  "published": "2025-02-01T09:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13429"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3229608/wp-job-portal/tags/2.2.7/modules/job/controller.php?old=3216415\u0026old_path=wp-job-portal%2Ftags%2F2.2.6%2Fmodules%2Fjob%2Fcontroller.php"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/9cbce69a-53d0-4b83-9b7a-893a6b9c39c4?source=cve"
    }
  ],
  "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"
    }
  ]
}

GHSA-J6FQ-W4R3-5Q3G

Vulnerability from github – Published: 2026-09-29 18:31 – Updated: 2026-10-06 18:31
VLAI
Details

Joomla! Core - [20260902] - Core - Unauthorized user account creation via profile.save controller in Joomla 1.5.0-5.4.8, 6.0.0-6.1.3 - The profile.save controller did not check the login state of a user, allowing the creation of guest-level users on sites without active user registration.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-90907"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-29T17:17:13Z",
    "severity": "MODERATE"
  },
  "details": "Joomla! Core - [20260902] - Core - Unauthorized user account creation via profile.save controller in Joomla 1.5.0-5.4.8, 6.0.0-6.1.3 - The profile.save controller did not check the login state of a user, allowing the creation of guest-level users on sites without active user registration.",
  "id": "GHSA-j6fq-w4r3-5q3g",
  "modified": "2026-10-06T18:31:21Z",
  "published": "2026-09-29T18:31:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90907"
    },
    {
      "type": "WEB",
      "url": "https://developer.joomla.org/security-centre/1082-20260902-core-unauthorized-user-account-creation-via-profile-save-controller.html"
    },
    {
      "type": "WEB",
      "url": "https://www.joomla.org"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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-J6R6-VG97-R68X

Vulnerability from github – Published: 2022-02-08 00:00 – Updated: 2022-02-11 00:01
VLAI
Details

The IP2Location Country Blocker WordPress plugin before 2.26.5 bans can be bypassed by using a specific parameter in the URL

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-25096"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-07T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The IP2Location Country Blocker WordPress plugin before 2.26.5 bans can be bypassed by using a specific parameter in the URL",
  "id": "GHSA-j6r6-vg97-r68x",
  "modified": "2022-02-11T00:01:06Z",
  "published": "2022-02-08T00:00:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25096"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/2652469"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/e6dd140e-0c9d-41dc-821e-4910a13122c1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-J6R7-6FHX-77WX

Vulnerability from github – Published: 2026-07-14 19:07 – Updated: 2026-07-14 19:07
VLAI
Summary
n8n-MCP: Cross-tenant access to workflow version backups in multi-tenant HTTP deployments
Details

Impact

In multi-tenant HTTP deployments — where a single n8n-mcp server serves several tenants — the locally stored workflow version history (the automatic backups taken before workflow updates) was not isolated per tenant. An authenticated tenant could read workflow version snapshots belonging to other tenants, and could delete or destroy other tenants' stored backups.

A stored snapshot includes full node definitions, so the exposed data can contain credential references and authorization headers configured on nodes. This is therefore a confidentiality issue in addition to an integrity/availability one.

Affected configurations

  • HTTP mode with multi-tenancy enabled (ENABLE_MULTI_TENANT=true), where multiple tenants are served by a single shared instance and database.

Not affected:

  • stdio / single-user deployments (e.g. Claude Desktop).
  • Single-tenant HTTP deployments (one tenant per instance and database).

Affected versions

<= 2.56.0

Patched version

2.56.1. The stored version history is now isolated per instance, so a tenant can only access its own backups. Upgrading runs a one-time migration that isolates existing history and clears previously stored, un-scoped backups (these are auto-created, short-retention backups).

Workarounds

If users cannot upgrade immediately:

  • Disable the workflow version tool by setting DISABLED_TOOLS=n8n_workflow_versions in the server environment (for example, in your Docker .env). This removes the affected tool from the deployment for all tenants; automatic backups are unaffected, but the cross-tenant access path is closed.
  • Alternatively, do not run in multi-tenant mode — serve each tenant from a separate instance with its own database, so no local store is shared between tenants.
  • Restrict network access to the HTTP endpoint to trusted operators.

stdio and single-tenant HTTP deployments are not affected.

Credit

Reported by Francisco Rosales (@0xmagic0) and coordinated by Ax Sharma (@axsharma) of Manifold Security.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.56.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "n8n-mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.56.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54052"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-14T19:07:14Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Impact\n\nIn multi-tenant HTTP deployments \u2014 where a single n8n-mcp server serves several tenants \u2014 the locally stored workflow version history (the automatic backups taken before workflow updates) was not isolated per tenant. An authenticated tenant could read workflow version snapshots belonging to other tenants, and could delete or destroy other tenants\u0027 stored backups.\n\nA stored snapshot includes full node definitions, so the exposed data can contain credential references and authorization headers configured on nodes. This is therefore a confidentiality issue in addition to an integrity/availability one.\n\n## Affected configurations\n\n- HTTP mode with multi-tenancy enabled (`ENABLE_MULTI_TENANT=true`), where multiple tenants are served by a single shared instance and database.\n\nNot affected:\n\n- stdio / single-user deployments (e.g. Claude Desktop).\n- Single-tenant HTTP deployments (one tenant per instance and database).\n\n## Affected versions\n\n`\u003c= 2.56.0`\n\n## Patched version\n\n`2.56.1`. The stored version history is now isolated per instance, so a tenant can only access its own backups. Upgrading runs a one-time migration that isolates existing history and clears previously stored, un-scoped backups (these are auto-created, short-retention backups).\n\n## Workarounds\n\nIf users cannot upgrade immediately:\n\n- Disable the workflow version tool by setting `DISABLED_TOOLS=n8n_workflow_versions` in the server environment (for example, in your Docker `.env`). This removes the affected tool from the deployment for all tenants; automatic backups are unaffected, but the cross-tenant access path is closed.\n- Alternatively, do not run in multi-tenant mode \u2014 serve each tenant from a separate instance with its own database, so no local store is shared between tenants.\n- Restrict network access to the HTTP endpoint to trusted operators.\n\nstdio and single-tenant HTTP deployments are not affected.\n\n## Credit\n\nReported by Francisco Rosales (@0xmagic0) and coordinated by Ax Sharma (@axsharma) of Manifold Security.",
  "id": "GHSA-j6r7-6fhx-77wx",
  "modified": "2026-07-14T19:07:14Z",
  "published": "2026-07-14T19:07:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/czlonkowski/n8n-mcp/security/advisories/GHSA-j6r7-6fhx-77wx"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/czlonkowski/n8n-mcp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/czlonkowski/n8n-mcp/releases/tag/v2.56.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "n8n-MCP: Cross-tenant access to workflow version backups in multi-tenant HTTP deployments"
}

GHSA-J6X3-F5CF-2PG4

Vulnerability from github – Published: 2026-07-22 18:32 – Updated: 2026-07-22 18:32
VLAI
Details

Onlook through 0.2.32, fixed in commit 423e2e9, contains a broken object level authorization vulnerability that allows authenticated attackers to access and manipulate other users' resources by supplying arbitrary UUID values to tRPC API procedures including project.get, member.remove, and chat.conversation.delete. Attackers can provide arbitrary projectId or conversationId values without authorization validation to read, modify, and delete other users' project data, members, and conversation history.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-65013"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-22T17:16:59Z",
    "severity": "HIGH"
  },
  "details": "Onlook through 0.2.32, fixed in commit 423e2e9, contains a broken object level authorization vulnerability that allows authenticated attackers to access and manipulate other users\u0027 resources by supplying arbitrary UUID values to tRPC API procedures including project.get, member.remove, and chat.conversation.delete. Attackers can provide arbitrary projectId or conversationId values without authorization validation to read, modify, and delete other users\u0027 project data, members, and conversation history.",
  "id": "GHSA-j6x3-f5cf-2pg4",
  "modified": "2026-07-22T18:32:39Z",
  "published": "2026-07-22T18:32:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65013"
    },
    {
      "type": "WEB",
      "url": "https://github.com/onlook-dev/onlook/issues/3122"
    },
    {
      "type": "WEB",
      "url": "https://github.com/onlook-dev/onlook/pull/3129"
    },
    {
      "type": "WEB",
      "url": "https://github.com/onlook-dev/onlook/commit/423e2e924366419e418ee049093872d535eea41a"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/onlook-trpc-insecure-direct-object-reference-via-multiple-procedures"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/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"
    }
  ]
}
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.

← Back to the CWE list