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.
3358 vulnerabilities reference this CWE, most recent first.
GHSA-C7VR-VPM2-822G
Vulnerability from github – Published: 2025-02-19 09:33 – Updated: 2026-04-08 18:33The PeproDev Ultimate Invoice plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 2.0.8 via the invoicing viewer due to missing validation on a user controlled key. This makes it possible for unauthenticated attackers to view invoices for completed orders which can contain PII of users.
{
"affected": [],
"aliases": [
"CVE-2024-13719"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-19T08:15:20Z",
"severity": "MODERATE"
},
"details": "The PeproDev Ultimate Invoice plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 2.0.8 via the invoicing viewer due to missing validation on a user controlled key. This makes it possible for unauthenticated attackers to view invoices for completed orders which can contain PII of users.",
"id": "GHSA-c7vr-vpm2-822g",
"modified": "2026-04-08T18:33:49Z",
"published": "2025-02-19T09:33:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13719"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3244844%40pepro-ultimate-invoice\u0026new=3244844%40pepro-ultimate-invoice\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/pepro-ultimate-invoice"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/46186f8d-e50c-476a-9480-b6121412474a?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:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C827-PF9P-24MM
Vulnerability from github – Published: 2026-01-16 12:30 – Updated: 2026-01-23 18:31The Membership Plugin – Restrict Content plugin for WordPress is vulnerable to Missing Authentication in all versions up to, and including, 3.2.16 via the 'rcp_stripe_create_setup_intent_for_saved_card' function due to missing capability check. Additionally, the plugin does not check a user-controlled key, which makes it possible for unauthenticated attackers to leak Stripe SetupIntent client_secret values for any membership.
{
"affected": [],
"aliases": [
"CVE-2025-14844"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-16T10:16:04Z",
"severity": "HIGH"
},
"details": "The Membership Plugin \u2013 Restrict Content plugin for WordPress is vulnerable to Missing Authentication in all versions up to, and including, 3.2.16 via the \u0027rcp_stripe_create_setup_intent_for_saved_card\u0027 function due to missing capability check. Additionally, the plugin does not check a user-controlled key, which makes it possible for unauthenticated attackers to leak Stripe SetupIntent client_secret values for any membership.",
"id": "GHSA-c827-pf9p-24mm",
"modified": "2026-01-23T18:31:27Z",
"published": "2026-01-16T12:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14844"
},
{
"type": "WEB",
"url": "https://cwe.mitre.org/data/definitions/639.html"
},
{
"type": "WEB",
"url": "https://docs.stripe.com/api/setup_intents/object"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/restrict-content/tags/3.2.16/core/includes/gateways/stripe/functions.php#L848"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/restrict-content/tags/3.2.16/core/includes/gateways/stripe/functions.php#L987"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3438168/restrict-content/tags/3.2.17/core/includes/gateways/stripe/functions.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/0c28545d-c7cd-469f-bccf-90e8b52fd4e7?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C8G9-CM5M-77PX
Vulnerability from github – Published: 2026-06-20 03:32 – Updated: 2026-06-20 03:32Capgo before 12.128.12 allows authenticated users to modify their mutable public.users.email to arbitrary addresses, which the SSO provisioning endpoint trusts as an account-merge key. Attackers can pre-position their account with a victim's corporate SSO email, causing the provision-user endpoint to merge the victim's SSO identity into the attacker-controlled account.
{
"affected": [],
"aliases": [
"CVE-2026-56215"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-20T01:16:16Z",
"severity": "HIGH"
},
"details": "Capgo before 12.128.12 allows authenticated users to modify their mutable public.users.email to arbitrary addresses, which the SSO provisioning endpoint trusts as an account-merge key. Attackers can pre-position their account with a victim\u0027s corporate SSO email, causing the provision-user endpoint to merge the victim\u0027s SSO identity into the attacker-controlled account.",
"id": "GHSA-c8g9-cm5m-77px",
"modified": "2026-06-20T03:32:30Z",
"published": "2026-06-20T03:32:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Cap-go/capgo/security/advisories/GHSA-wqc6-fhwf-qpww"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56215"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/capgo-account-merge-via-poisoned-public-users-email-in-sso-provisioning"
}
],
"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:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-C8HW-HM2H-46FP
Vulnerability from github – Published: 2026-07-17 06:30 – Updated: 2026-07-17 06:30The Ninja Forms - Excel Export plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 3.3.6 via the 'spreadsheet_export_form_id' parameter due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with subscriber-level access and above, to enumerate any Ninja Forms form ID and download all stored submission data — including names, email addresses, phone numbers, physical addresses, and any other PII collected by site forms — as a downloadable XLSX file.
{
"affected": [],
"aliases": [
"CVE-2026-15159"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-17T04:16:50Z",
"severity": "MODERATE"
},
"details": "The Ninja Forms - Excel Export plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 3.3.6 via the \u0027spreadsheet_export_form_id\u0027 parameter due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with subscriber-level access and above, to enumerate any Ninja Forms form ID and download all stored submission data \u2014 including names, email addresses, phone numbers, physical addresses, and any other PII collected by site forms \u2014 as a downloadable XLSX file.",
"id": "GHSA-c8hw-hm2h-46fp",
"modified": "2026-07-17T06:30:59Z",
"published": "2026-07-17T06:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15159"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/ninja-forms-excel-export/trunk/ninja-forms-excel-export.php#L187"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/783ccf21-db16-4aac-9a3c-992b3aac5526?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-C8VC-7PV3-G98P
Vulnerability from github – Published: 2026-07-24 21:14 – Updated: 2026-07-24 21:14Summary
POST /api/v2/email on the account portal (account.budibase.app) starts an email-change workflow using a client-supplied accountId that is not validated against the authenticated session. A logged-in attacker supplies a victim's accountId and an email address they control; the verification code is delivered to the attacker's address, and completing the workflow changes the victim's account email. The attacker then password-resets the victim's account through the controlled address and logs in — full account takeover with no victim interaction.
Vulnerability Details
The endpoint session-checks the currentEmail field (a mismatch returns 403), but it does not enforce body.accountId === session.accountId. The account-portal frontend only ever submits the logged-in user's own accountId, so in normal use the two always match — the server simply trusts the body value. An attacker who has a victim's accountId can point the workflow at the victim's account while passing their own currentEmail to clear the session check.
This is more powerful than a direct password reset: PUT /api/v2/auth/password {email} already exists and is gated only on knowing the victim's email, but the reset link is sent to the address on the account — the victim's inbox, which the attacker does not control. This IDOR moves the victim's email to an attacker-controlled inbox first, so the attacker receives the reset link and sets a password they know.
accountId obtainability. We checked every endpoint reachable from a non-admin free-tier account — GET /api/global/users (no UUID in any user record), GET /api/global/auditlogs/search (no accountId field), GET /api/global/users/invites (code + email + name only), GET /api/v2/tenant (one tenant-internal UUID, not a user accountId), the account-portal frontend (passes the session's own accountId only), and all unauthenticated endpoints — and the victim's accountId was not present in any of them. The attacker must obtain the UUID through some channel other than the normal API surface (support channel, screenshot, a leak, prior compromise, etc.).
Steps to Reproduce
Setup: Two account-portal accounts at https://account.budibase.app — Account A (attacker) and Account B (victim). From Account B's session, GET /api/auth/self returns account.accountId — this is the value the attacker needs.
- Start the email-change workflow pointed at the victim's accountId, newEmail = attacker-controlled.
POST /api/v2/email HTTP/1.1
Host: account.budibase.app
Content-Type: application/json
Cookie: budibase:auth=<ACCOUNT_A_JWT>
{"currentEmail":"<ACCOUNT_A_EMAIL>","newEmail":"attacker-controlled@example.net","accountId":"<VICTIM_ACCOUNT_ID>"}
Response: 201 Created, sets budibase:change_email:correlationkey (HttpOnly), :instancekey, :status, :newemail cookies. The workflow started against the victim's accountId even though the caller is Account A.
- Complete the change with the code from the attacker-controlled inbox (or read directly from the
correlationkeycookie set in step 1).
POST /api/v2/email/verification HTTP/1.1
Host: account.budibase.app
Content-Type: application/json
Cookie: budibase:auth=<ACCOUNT_A_JWT>; budibase:change_email:correlationkey=<CODE>; budibase:change_email:instancekey=<KEY>
{"verificationCode":"<code>","processInstanceKey":"<key>"}
Response: 200 OK. The victim's account email is now attacker-controlled@example.net.
-
Confirm the change hit the victim, not the caller (false-positive control).
-
Account A (caller) still logs in with its own original email — 200, unchanged.
- Account B's (victim) original email is now rejected — 403, locked out.
-
attacker-controlled@example.netnow logs into the victim's account — 200. -
Take over the account.
PUT /api/v2/auth/password HTTP/1.1
Host: account.budibase.app
Content-Type: application/json
{"email":"attacker-controlled@example.net"}
Response: 202 Accepted, reset link delivered to the attacker's own inbox. Complete the reset with PUT /api/v2/auth/password/verification, then log in as the victim with the attacker-chosen password. GET /api/auth/self afterward returns the victim's real accountId and tenantId — full account takeover, confirmed via a genuinely separate account/tenant (not a same-account self-test).
Impact
An authenticated account-portal user who obtains a victim's accountId (out-of-band — it is not exposed anywhere in the normal cross-user API surface we could find) can take over that victim's account: rewrite the login email to an attacker address, set a new password, and access the victim's tenants, apps, and stored datasource credentials (REST/SQL/S3 auth). The victim is locked out of their own account. Every step from the initial IDOR write to full login-as-victim is deterministic and 100% reliable once the accountId is known — no additional vulnerability or guessing is required, since the chain uses nothing but the platform's own stock password-reset flow.
Remediation
Validate that the body's accountId equals the authenticated session's accountId before starting or completing the email-change workflow (the same check already applied to currentEmail). Do not trust a client-supplied accountId to select the workflow target.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@budibase/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "3.38.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T21:14:49Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\n`POST /api/v2/email` on the account portal (`account.budibase.app`) starts an email-change workflow using a client-supplied `accountId` that is **not validated against the authenticated session**. A logged-in attacker supplies a victim\u0027s `accountId` and an email address they control; the verification code is delivered to the attacker\u0027s address, and completing the workflow changes the **victim\u0027s** account email. The attacker then password-resets the victim\u0027s account through the controlled address and logs in \u2014 full account takeover with no victim interaction.\n\n## Vulnerability Details\n\nThe endpoint session-checks the `currentEmail` field (a mismatch returns 403), but it does not enforce `body.accountId === session.accountId`. The account-portal frontend only ever submits the logged-in user\u0027s own accountId, so in normal use the two always match \u2014 the server simply trusts the body value. An attacker who has a victim\u0027s `accountId` can point the workflow at the victim\u0027s account while passing their own `currentEmail` to clear the session check.\n\nThis is more powerful than a direct password reset: `PUT /api/v2/auth/password {email}` already exists and is gated only on knowing the victim\u0027s email, but the reset link is sent to the address on the account \u2014 the victim\u0027s inbox, which the attacker does not control. This IDOR moves the victim\u0027s email to an attacker-controlled inbox first, so the attacker receives the reset link and sets a password they know.\n\n**accountId obtainability.** We checked every endpoint reachable from a non-admin free-tier account \u2014 `GET /api/global/users` (no UUID in any user record), `GET /api/global/auditlogs/search` (no accountId field), `GET /api/global/users/invites` (code + email + name only), `GET /api/v2/tenant` (one tenant-internal UUID, not a user accountId), the account-portal frontend (passes the session\u0027s own accountId only), and all unauthenticated endpoints \u2014 and the victim\u0027s `accountId` was not present in any of them. The attacker must obtain the UUID through some channel other than the normal API surface (support channel, screenshot, a leak, prior compromise, etc.).\n\n## Steps to Reproduce\n\n**Setup:** Two account-portal accounts at `https://account.budibase.app` \u2014 Account A (attacker) and Account B (victim). From Account B\u0027s session, `GET /api/auth/self` returns `account.accountId` \u2014 this is the value the attacker needs.\n\n1. **Start the email-change workflow pointed at the victim\u0027s accountId, newEmail = attacker-controlled.**\n\n```http\nPOST /api/v2/email HTTP/1.1\nHost: account.budibase.app\nContent-Type: application/json\nCookie: budibase:auth=\u003cACCOUNT_A_JWT\u003e\n\n{\"currentEmail\":\"\u003cACCOUNT_A_EMAIL\u003e\",\"newEmail\":\"attacker-controlled@example.net\",\"accountId\":\"\u003cVICTIM_ACCOUNT_ID\u003e\"}\n```\n\nResponse: `201 Created`, sets `budibase:change_email:correlationkey` (HttpOnly), `:instancekey`, `:status`, `:newemail` cookies. The workflow started against the victim\u0027s accountId even though the caller is Account A.\n\n2. **Complete the change with the code from the attacker-controlled inbox (or read directly from the `correlationkey` cookie set in step 1).**\n\n```http\nPOST /api/v2/email/verification HTTP/1.1\nHost: account.budibase.app\nContent-Type: application/json\nCookie: budibase:auth=\u003cACCOUNT_A_JWT\u003e; budibase:change_email:correlationkey=\u003cCODE\u003e; budibase:change_email:instancekey=\u003cKEY\u003e\n\n{\"verificationCode\":\"\u003ccode\u003e\",\"processInstanceKey\":\"\u003ckey\u003e\"}\n```\n\nResponse: `200 OK`. The victim\u0027s account email is now `attacker-controlled@example.net`.\n\n3. **Confirm the change hit the victim, not the caller (false-positive control).**\n\n- Account A (caller) still logs in with its own original email \u2014 200, unchanged.\n- Account B\u0027s (victim) original email is now rejected \u2014 403, locked out.\n- `attacker-controlled@example.net` now logs into the victim\u0027s account \u2014 200.\n\n4. **Take over the account.**\n\n```http\nPUT /api/v2/auth/password HTTP/1.1\nHost: account.budibase.app\nContent-Type: application/json\n\n{\"email\":\"attacker-controlled@example.net\"}\n```\n\nResponse: `202 Accepted`, reset link delivered to the attacker\u0027s own inbox. Complete the reset with `PUT /api/v2/auth/password/verification`, then log in as the victim with the attacker-chosen password. `GET /api/auth/self` afterward returns the victim\u0027s real `accountId` and `tenantId` \u2014 full account takeover, confirmed via a genuinely separate account/tenant (not a same-account self-test).\n\n## Impact\n\nAn authenticated account-portal user who obtains a victim\u0027s `accountId` (out-of-band \u2014 it is not exposed anywhere in the normal cross-user API surface we could find) can take over that victim\u0027s account: rewrite the login email to an attacker address, set a new password, and access the victim\u0027s tenants, apps, and stored datasource credentials (REST/SQL/S3 auth). The victim is locked out of their own account. Every step from the initial IDOR write to full login-as-victim is deterministic and 100% reliable once the accountId is known \u2014 no additional vulnerability or guessing is required, since the chain uses nothing but the platform\u0027s own stock password-reset flow.\n\n## Remediation\n\nValidate that the body\u0027s `accountId` equals the authenticated session\u0027s `accountId` before starting or completing the email-change workflow (the same check already applied to `currentEmail`). Do not trust a client-supplied `accountId` to select the workflow target.",
"id": "GHSA-c8vc-7pv3-g98p",
"modified": "2026-07-24T21:14:49Z",
"published": "2026-07-24T21:14:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Budibase/budibase/security/advisories/GHSA-c8vc-7pv3-g98p"
},
{
"type": "PACKAGE",
"url": "https://github.com/Budibase/budibase"
},
{
"type": "WEB",
"url": "https://github.com/Budibase/budibase/releases/tag/3.40.0"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": " Budibase: Email Change IDOR via POST /api/v2/email allows full Account Takeover (accountId not validated against session)"
}
GHSA-C925-88RR-2HQ4
Vulnerability from github – Published: 2026-03-11 21:31 – Updated: 2026-03-12 00:31SAPIDO RB-1732 V2.0.43 contains a remote command execution vulnerability that allows unauthenticated attackers to execute arbitrary system commands by submitting malicious input to the formSysCmd endpoint. Attackers can send POST requests with the sysCmd parameter containing shell commands to execute code on the device with router privileges.
{
"affected": [],
"aliases": [
"CVE-2019-25487"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-11T19:16:03Z",
"severity": "CRITICAL"
},
"details": "SAPIDO RB-1732 V2.0.43 contains a remote command execution vulnerability that allows unauthenticated attackers to execute arbitrary system commands by submitting malicious input to the formSysCmd endpoint. Attackers can send POST requests with the sysCmd parameter containing shell commands to execute code on the device with router privileges.",
"id": "GHSA-c925-88rr-2hq4",
"modified": "2026-03-12T00:31:16Z",
"published": "2026-03-11T21:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25487"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/47031"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/sapido-rb-1732-remote-command-execution-via-formsyscmd"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/sapido-rb-remote-command-execution-via-formsyscmd"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-C92M-668G-H9MV
Vulnerability from github – Published: 2024-08-13 12:30 – Updated: 2024-08-13 12:30Authorization Bypass Through User-Controlled Key vulnerability in ThimPress LearnPress allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects LearnPress: from n/a through 4.2.6.8.2.
{
"affected": [],
"aliases": [
"CVE-2024-39642"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-13T11:15:17Z",
"severity": "MODERATE"
},
"details": "Authorization Bypass Through User-Controlled Key vulnerability in ThimPress LearnPress allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects LearnPress: from n/a through 4.2.6.8.2.",
"id": "GHSA-c92m-668g-h9mv",
"modified": "2024-08-13T12:30:52Z",
"published": "2024-08-13T12:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39642"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/learnpress/wordpress-learnpress-plugin-4-2-6-8-2-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:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C977-4M9F-FCFC
Vulnerability from github – Published: 2026-02-19 18:31 – Updated: 2026-02-19 18:31The MP3 Audio Player – Music Player, Podcast Player & Radio by Sonaar plugin for WordPress is vulnerable to Insecure Direct Object Reference in versions 4.0 to 5.10 via the 'load_track_note_ajax' due to missing validation on a user controlled key. This makes it possible for unauthenticated attackers to view the contents of private posts.
{
"affected": [],
"aliases": [
"CVE-2026-1219"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-19T10:16:11Z",
"severity": "MODERATE"
},
"details": "The MP3 Audio Player \u2013 Music Player, Podcast Player \u0026 Radio by Sonaar plugin for WordPress is vulnerable to Insecure Direct Object Reference in versions 4.0 to 5.10 via the \u0027load_track_note_ajax\u0027 due to missing validation on a user controlled key. This makes it possible for unauthenticated attackers to view the contents of private posts.",
"id": "GHSA-c977-4m9f-fcfc",
"modified": "2026-02-19T18:31:54Z",
"published": "2026-02-19T18:31:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1219"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/mp3-music-player-by-sonaar/tags/5.10/public/class-sonaar-music-public.php#L323"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/mp3-music-player-by-sonaar/tags/5.10/sonaar-music.php#L179"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3453076"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/ce8fa964-d543-4d46-a534-e403dff4f425?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:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C9HW-VRGH-HH3M
Vulnerability from github – Published: 2026-07-09 06:31 – Updated: 2026-07-09 06:31The Divi Form Builder plugin for WordPress is vulnerable to Missing Authorization in versions up to, and including, 5.1.8. This is due to the update_user() function accepting a user ID parameter from form submissions without verifying that the authenticated user has permission to edit that specific user account, and the handle_register_submission() function only checking if any user is logged in rather than validating permissions for the target user. This makes it possible for authenticated attackers, with subscriber-level access and above, to change the email address and password of any user account, including administrators, resulting in complete account takeover.
{
"affected": [],
"aliases": [
"CVE-2026-5523"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-09T06:16:21Z",
"severity": "HIGH"
},
"details": "The Divi Form Builder plugin for WordPress is vulnerable to Missing Authorization in versions up to, and including, 5.1.8. This is due to the update_user() function accepting a user ID parameter from form submissions without verifying that the authenticated user has permission to edit that specific user account, and the handle_register_submission() function only checking if any user is logged in rather than validating permissions for the target user. This makes it possible for authenticated attackers, with subscriber-level access and above, to change the email address and password of any user account, including administrators, resulting in complete account takeover.",
"id": "GHSA-c9hw-vrgh-hh3m",
"modified": "2026-07-09T06:31:59Z",
"published": "2026-07-09T06:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5523"
},
{
"type": "WEB",
"url": "https://diviengine.com/divi-form-builder-changelog"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/cb158acc-69d7-4a7d-b356-7de1f6b37019?source=cve"
}
],
"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"
}
]
}
GHSA-CC7F-7QRJ-R4V2
Vulnerability from github – Published: 2024-09-06 15:32 – Updated: 2026-06-03 18:33Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Ariva Computer Accord ORS allows Retrieve Embedded Sensitive Data.This issue affects Accord ORS: before 7.3.2.1.
{
"affected": [],
"aliases": [
"CVE-2024-1744"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-06T13:15:03Z",
"severity": "CRITICAL"
},
"details": "Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Ariva Computer Accord ORS allows Retrieve Embedded Sensitive Data.This issue affects Accord ORS: before 7.3.2.1.",
"id": "GHSA-cc7f-7qrj-r4v2",
"modified": "2026-06-03T18:33:05Z",
"published": "2024-09-06T15:32:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1744"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-24-1408"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-24-1408"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/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
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.