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.

5428 vulnerabilities reference this CWE, most recent first.

GHSA-9RCH-GVF7-HRFC

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

Traefik is a HTTP reverse proxy and load balancer. In versions >= v3.7.0 and <= v3.7.11, the Kubernetes ingress-nginx provider mishandles Ingresses that carry both an authentication annotation and the nginx.ingress.kubernetes.io/from-to-www-redirect annotation. For such Ingresses the provider creates an additional 'sibling' router that matches on the host alone, carries only the RedirectRegex middleware, and still points at the parent router's protected backend service. Because RedirectRegex is not a terminal handler, a request its pattern does not match is forwarded to the backend, and because the redirect pattern only accepts a numeric port while Traefik's host matcher canonicalizes the authority via net.SplitHostPort, a request with a non-numeric or empty port (for example 'Host: www.example.com:x') selects the sibling router, misses the redirect, and is proxied to the protected backend with none of the Ingress's annotation-derived middlewares applied. This discards not only authentication (e.g. BasicAuth) but every annotation-derived middleware, including source-IP allowlisting. Traefik v2 and v3 releases before v3.7.0 are not affected. The issue is fixed in v3.7.12.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
9.3 (Critical)
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
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-88877"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-10T14:17:16Z",
    "severity": "CRITICAL"
  },
  "details": "Traefik is a HTTP reverse proxy and load balancer. In versions \u003e= v3.7.0 and \u003c= v3.7.11, the Kubernetes ingress-nginx provider mishandles Ingresses that carry both an authentication annotation and the nginx.ingress.kubernetes.io/from-to-www-redirect annotation. For such Ingresses the provider creates an additional \u0027sibling\u0027 router that matches on the host alone, carries only the RedirectRegex middleware, and still points at the parent router\u0027s protected backend service. Because RedirectRegex is not a terminal handler, a request its pattern does not match is forwarded to the backend, and because the redirect pattern only accepts a numeric port while Traefik\u0027s host matcher canonicalizes the authority via net.SplitHostPort, a request with a non-numeric or empty port (for example \u0027Host: www.example.com:x\u0027) selects the sibling router, misses the redirect, and is proxied to the protected backend with none of the Ingress\u0027s annotation-derived middlewares applied. This discards not only authentication (e.g. BasicAuth) but every annotation-derived middleware, including source-IP allowlisting. Traefik v2 and v3 releases before v3.7.0 are not affected. The issue is fixed in v3.7.12.",
  "id": "GHSA-9rch-gvf7-hrfc",
  "modified": "2026-09-10T15:33:18Z",
  "published": "2026-09-10T15:33:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/security/advisories/GHSA-cjr6-pf59-jq29"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88877"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/traefik-3.7.0-authentication-bypass-via-from-to-www-redirect"
    }
  ],
  "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-9RG8-2WVR-FGJH

Vulnerability from github – Published: 2026-09-23 21:24 – Updated: 2026-09-23 21:24
VLAI
Summary
Formie: Missing authorization on sent notification resend modal exposes submission PII
Details

Impact

The control panel action formie/sent-notifications/get-resend-modal-content (SentNotificationsController::actionGetResendModalContent) performed only requireAcceptsJson() and loaded a SentNotification by request id without permission or object-level authorization checks.

Any authenticated user who could invoke the action could enumerate notification IDs and read full email content — including recipient headers and the complete HTML body containing submitted form data (PII) — without formie-accessSentNotifications or equivalent permission. Sibling actions in the same controller enforced authorization.

Patches

Fixed in 3.1.31 (Craft 5) and 2.2.23 (Craft 4).

Craft 5: canView() is enforced after loading, consistent with actionEdit.
Craft 4: formie-viewSentNotifications permission is required.

Workarounds

Restrict CP access to trusted users only until upgraded. No configuration workaround.

  • Reported by Jorge González (jorge@jmilla.es)
Severity
7.7 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "verbb/formie"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.31"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "verbb/formie"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-76089"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-639",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-23T21:24:01Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nThe control panel action `formie/sent-notifications/get-resend-modal-content` (`SentNotificationsController::actionGetResendModalContent`) performed only `requireAcceptsJson()` and loaded a `SentNotification` by request `id` without permission or object-level authorization checks.\n\nAny authenticated user who could invoke the action could enumerate notification IDs and read full email content \u2014 including recipient headers and the complete HTML body containing submitted form data (PII) \u2014 without `formie-accessSentNotifications` or equivalent permission. Sibling actions in the same controller enforced authorization.\n\n### Patches\n\nFixed in **3.1.31** (Craft 5) and **2.2.23** (Craft 4).\n\nCraft 5: `canView()` is enforced after loading, consistent with `actionEdit`.  \nCraft 4: `formie-viewSentNotifications` permission is required.\n\n### Workarounds\n\nRestrict CP access to trusted users only until upgraded. No configuration workaround.\n\n- Reported by Jorge Gonz\u00e1lez (jorge@jmilla.es)",
  "id": "GHSA-9rg8-2wvr-fgjh",
  "modified": "2026-09-23T21:24:01Z",
  "published": "2026-09-23T21:24:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/verbb/formie/security/advisories/GHSA-9rg8-2wvr-fgjh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/verbb/formie/commit/9f4e23c36b907ed7677563231eaba373fdb8b84b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/verbb/formie/commit/ff81a895fa91a2e4efb8d4714501ba2d92df0b76"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/verbb/formie"
    },
    {
      "type": "WEB",
      "url": "https://github.com/verbb/formie/releases/tag/2.2.23"
    },
    {
      "type": "WEB",
      "url": "https://github.com/verbb/formie/releases/tag/3.1.31"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Formie: Missing authorization on sent notification resend modal exposes submission PII"
}

GHSA-9RJW-3GWP-F59V

Vulnerability from github – Published: 2026-07-06 20:55 – Updated: 2026-07-06 20:55
VLAI
Summary
Coder's workspace app upsert allows cross-workspace agent rebinding via user-controlled app ID
Details

Summary

UpsertWorkspaceApp overwrites an existing app's agent_id on a primary-key conflict and insertAgentApp accepts the app ID from the provisioner's CompleteJob payload without verifying it belongs to the workspace being built. CompleteJob runs under dbauthz.AsProvisionerd so the authorization layer does not block the cross-workspace upsert.

Note: Exploitation requires elevated access as a template author or external provisioner operator.

Impact

A user with template authorship or external provisioner access can submit a CompleteJob payload with a known victim app UUID and an attacker-controlled agent ID. On completion of the attacker's build the victim's app row is rebound to the attacker's agent so later app traffic such as IDE and terminal sessions is proxied to the attacker's workspace. App UUIDs are discoverable through the public API.

Patches

The fix verifies that any existing workspace_apps row matching the supplied ID belongs to the workspace being built and rejects cross-workspace agent reassignment.

The fix was backported to all supported release lines:

Release line Patched version
2.34 v2.34.2
2.33 v2.33.8
2.32 v2.32.7
2.29 (ESR) v2.29.17

Workarounds

None. Upgrading is required.

Resources

  • Fix: #26103

Credits

Coder would like to thank Anthropic's Security Team (ANT-2026-22441) for independently disclosing this issue!

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.34.0"
            },
            {
              "fixed": "2.34.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.33.0"
            },
            {
              "fixed": "2.33.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.30.0"
            },
            {
              "fixed": "2.32.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.29.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55429"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-06T20:55:37Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`UpsertWorkspaceApp` overwrites an existing app\u0027s `agent_id` on a primary-key conflict and `insertAgentApp` accepts the app ID from the provisioner\u0027s `CompleteJob` payload without verifying it belongs to the workspace being built. `CompleteJob` runs under `dbauthz.AsProvisionerd` so the authorization layer does not block the cross-workspace upsert.\n\n\u003e **Note:** Exploitation requires elevated access as a template author or external provisioner operator.\n\n### Impact\n\nA user with template authorship or external provisioner access can submit a `CompleteJob` payload with a known victim app UUID and an attacker-controlled agent ID. On completion of the attacker\u0027s build the victim\u0027s app row is rebound to the attacker\u0027s agent so later app traffic such as IDE and terminal sessions is proxied to the attacker\u0027s workspace. App UUIDs are discoverable through the public API.\n\n### Patches\n\nThe fix verifies that any existing `workspace_apps` row matching the supplied ID belongs to the workspace being built and rejects cross-workspace agent reassignment.\n\nThe fix was backported to all supported release lines:\n\n| Release line | Patched version |\n|---|---|\n| 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) |\n| 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) |\n| 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) |\n| 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) |\n\n### Workarounds\n\nNone. Upgrading is required.\n\n### Resources\n\n- Fix: #26103\n\n### Credits\n\nCoder would like to thank Anthropic\u0027s Security Team (ANT-2026-22441) for independently disclosing this issue!",
  "id": "GHSA-9rjw-3gwp-f59v",
  "modified": "2026-07-06T20:55:37Z",
  "published": "2026-07-06T20:55:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/coder/coder/security/advisories/GHSA-9rjw-3gwp-f59v"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/coder/pull/26103"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/coder/coder"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Coder\u0027s workspace app upsert allows cross-workspace agent rebinding via user-controlled app ID"
}

GHSA-9RM8-2H7M-56CH

Vulnerability from github – Published: 2024-12-04 06:31 – Updated: 2024-12-04 06:31
VLAI
Details

The Dollie Hub – Build Your Own WordPress Cloud Platform plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 6.2.0 via the 'elementor-template' 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 password protected, private, or draft posts that they should not have access to.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-12099"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-04T04:15:04Z",
    "severity": "MODERATE"
  },
  "details": "The Dollie Hub \u2013 Build Your Own WordPress Cloud Platform plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 6.2.0 via the \u0027elementor-template\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 password protected, private, or draft posts that they should not have access to.",
  "id": "GHSA-9rm8-2h7m-56ch",
  "modified": "2024-12-04T06:31:02Z",
  "published": "2024-12-04T06:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12099"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3201770%40dollie\u0026new=3201770%40dollie\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/f29514d0-20a5-43f2-bf36-660579103220?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-9RVM-XPXJ-3CHJ

Vulnerability from github – Published: 2023-12-20 15:30 – Updated: 2026-04-28 21:33
VLAI
Details

Authorization Bypass Through User-Controlled Key vulnerability in MarketingFire Editorial Calendar.This issue affects Editorial Calendar: from n/a through 3.7.12.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-36520"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-20T15:15:08Z",
    "severity": "MODERATE"
  },
  "details": "Authorization Bypass Through User-Controlled Key vulnerability in MarketingFire Editorial Calendar.This issue affects Editorial Calendar: from n/a through 3.7.12.",
  "id": "GHSA-9rvm-xpxj-3chj",
  "modified": "2026-04-28T21:33:28Z",
  "published": "2023-12-20T15:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36520"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/editorial-calendar/wordpress-editorial-calendar-plugin-3-7-12-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:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9V52-PGW4-78WW

Vulnerability from github – Published: 2026-08-24 15:31 – Updated: 2026-08-24 15:31
VLAI
Details

Joomla Extension - miniorange.com - Arbitrary account takeover in miniOrange OAuth Client < 3.2.0 - The manipulation of a cookie value allows actors to login as arbitrary accounts, including admins.

Severity
10.0 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-77995"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-24T14:17:03Z",
    "severity": "CRITICAL"
  },
  "details": "Joomla Extension - miniorange.com - Arbitrary account takeover in miniOrange OAuth Client \u003c 3.2.0 - The manipulation of a cookie value allows actors to login as arbitrary accounts, including admins.",
  "id": "GHSA-9v52-pgw4-78ww",
  "modified": "2026-08-24T15:31:51Z",
  "published": "2026-08-24T15:31:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77995"
    },
    {
      "type": "WEB",
      "url": "https://www.miniorange.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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-9V7C-RJ74-PC33

Vulnerability from github – Published: 2022-05-24 16:57 – Updated: 2024-04-04 02:02
VLAI
Details

An issue was discovered in the Voyager package through 1.2.7 for Laravel. An attacker with admin privileges and Compass access can read or delete arbitrary files, such as the .env file. NOTE: a software maintainer has suggested a solution in which Compass is switched off in a production environment.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-17050"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-09-30T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in the Voyager package through 1.2.7 for Laravel. An attacker with admin privileges and Compass access can read or delete arbitrary files, such as the .env file. NOTE: a software maintainer has suggested a solution in which Compass is switched off in a production environment.",
  "id": "GHSA-9v7c-rj74-pc33",
  "modified": "2024-04-04T02:02:24Z",
  "published": "2022-05-24T16:57:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17050"
    },
    {
      "type": "WEB",
      "url": "https://github.com/the-control-group/voyager/issues/4322"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9V82-XRM4-MP52

Vulnerability from github – Published: 2026-03-12 14:49 – Updated: 2026-03-12 14:49
VLAI
Summary
StudioCMS: IDOR in User Notification Preferences Allows Any Authenticated User to Modify Any User's Settings
Details

Summary

The updateUserNotifications endpoint accepts a user ID from the request payload and uses it to update that user's notification preferences. It checks that the caller is logged in but never verifies that the caller owns the target account (id !== userData.user.id). Any authenticated visitor can modify notification preferences for any user, including disabling admin notifications to suppress detection of malicious activity.

Details

The vulnerable handler is in packages/studiocms/frontend/pages/studiocms_api/_handlers/dashboard/users.ts:257-311:

.handle(
    'updateUserNotifications',
    Effect.fn(function* ({ payload: { id, notifications } }) {
        // ...demo mode checks...

        const [sdk, userData] = yield* Effect.all([SDKCore, CurrentUser]);

        // Line 274: Only checks login + visitor level — any authenticated user passes
        if (!userData.isLoggedIn || !userData.userPermissionLevel.isVisitor) {
            return yield* new DashboardAPIError({ error: 'Unauthorized' });
        }

        // Line 280: Uses 'id' from payload — NOT userData.user.id
        const existingUser = yield* sdk.GET.users.byId(id);

        // Line 288: Updates target user using attacker-controlled 'id'
        const updatedData = yield* sdk.AUTH.user.update({
            userId: id,       // ← attacker controls this
            userData: {
                id,            // ← attacker controls this
                name: existingUser.name,
                username: existingUser.username,
                updatedAt: new Date().toISOString(),
                emailVerified: existingUser.emailVerified,
                createdAt: undefined,
                notifications,  // ← attacker controls this
            },
        });
    })
)

For comparison, the updateUserProfile handler in dashboard/profile.ts correctly uses userData.user.id instead of a user-supplied ID, preventing IDOR.

PoC

# 1. Log in as a visitor-role user, obtain session cookie

# 2. Disable all notifications for the admin user
curl -X POST 'http://localhost:4321/studiocms_api/dashboard/update-user-notifications' \
  -H 'Cookie: studiocms-session=<visitor-session-token>' \
  -H 'Content-Type: application/json' \
  -d '{
    "id": "<admin-user-id>",
    "notifications": ""
  }'

# Expected: 403 Forbidden
# Actual: 200 {"message":"User notifications updated successfully"}

Impact

  • Any authenticated visitor can disable notification preferences for admin/owner accounts, suppressing alerts about new user creation, account changes, and user deletions
  • Enables attack chaining — suppress admin notifications first, then perform other malicious actions with reduced detection risk
  • Can modify any user's notification preferences (enable unwanted notifications or disable critical ones)

Recommended Fix

Add an ownership check in packages/studiocms/frontend/pages/studiocms_api/_handlers/dashboard/users.ts:

// After the login check at line 274, add:
if (id !== userData.user?.id && !userData.userPermissionLevel.isAdmin) {
    return yield* new DashboardAPIError({
        error: 'Unauthorized: cannot modify another user\'s notification preferences',
    });
}
Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "studiocms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32104"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-12T14:49:41Z",
    "nvd_published_at": "2026-03-11T21:16:16Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `updateUserNotifications` endpoint accepts a user ID from the request payload and uses it to update that user\u0027s notification preferences. It checks that the caller is logged in but never verifies that the caller owns the target account (`id !== userData.user.id`). Any authenticated visitor can modify notification preferences for any user, including disabling admin notifications to suppress detection of malicious activity.\n\n## Details\n\nThe vulnerable handler is in `packages/studiocms/frontend/pages/studiocms_api/_handlers/dashboard/users.ts:257-311`:\n\n```typescript\n.handle(\n    \u0027updateUserNotifications\u0027,\n    Effect.fn(function* ({ payload: { id, notifications } }) {\n        // ...demo mode checks...\n\n        const [sdk, userData] = yield* Effect.all([SDKCore, CurrentUser]);\n\n        // Line 274: Only checks login + visitor level \u2014 any authenticated user passes\n        if (!userData.isLoggedIn || !userData.userPermissionLevel.isVisitor) {\n            return yield* new DashboardAPIError({ error: \u0027Unauthorized\u0027 });\n        }\n\n        // Line 280: Uses \u0027id\u0027 from payload \u2014 NOT userData.user.id\n        const existingUser = yield* sdk.GET.users.byId(id);\n\n        // Line 288: Updates target user using attacker-controlled \u0027id\u0027\n        const updatedData = yield* sdk.AUTH.user.update({\n            userId: id,       // \u2190 attacker controls this\n            userData: {\n                id,            // \u2190 attacker controls this\n                name: existingUser.name,\n                username: existingUser.username,\n                updatedAt: new Date().toISOString(),\n                emailVerified: existingUser.emailVerified,\n                createdAt: undefined,\n                notifications,  // \u2190 attacker controls this\n            },\n        });\n    })\n)\n```\n\nFor comparison, the `updateUserProfile` handler in `dashboard/profile.ts` correctly uses `userData.user.id` instead of a user-supplied ID, preventing IDOR.\n\n## PoC\n\n```bash\n# 1. Log in as a visitor-role user, obtain session cookie\n\n# 2. Disable all notifications for the admin user\ncurl -X POST \u0027http://localhost:4321/studiocms_api/dashboard/update-user-notifications\u0027 \\\n  -H \u0027Cookie: studiocms-session=\u003cvisitor-session-token\u003e\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\n    \"id\": \"\u003cadmin-user-id\u003e\",\n    \"notifications\": \"\"\n  }\u0027\n\n# Expected: 403 Forbidden\n# Actual: 200 {\"message\":\"User notifications updated successfully\"}\n```\n\n## Impact\n\n- Any authenticated visitor can disable notification preferences for admin/owner accounts, suppressing alerts about new user creation, account changes, and user deletions\n- Enables attack chaining \u2014 suppress admin notifications first, then perform other malicious actions with reduced detection risk\n- Can modify any user\u0027s notification preferences (enable unwanted notifications or disable critical ones)\n\n## Recommended Fix\n\nAdd an ownership check in `packages/studiocms/frontend/pages/studiocms_api/_handlers/dashboard/users.ts`:\n\n```typescript\n// After the login check at line 274, add:\nif (id !== userData.user?.id \u0026\u0026 !userData.userPermissionLevel.isAdmin) {\n    return yield* new DashboardAPIError({\n        error: \u0027Unauthorized: cannot modify another user\\\u0027s notification preferences\u0027,\n    });\n}\n```",
  "id": "GHSA-9v82-xrm4-mp52",
  "modified": "2026-03-12T14:49:41Z",
  "published": "2026-03-12T14:49:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/withstudiocms/studiocms/security/advisories/GHSA-9v82-xrm4-mp52"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32104"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/withstudiocms/studiocms"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "StudioCMS: IDOR in User Notification Preferences Allows Any Authenticated User to Modify Any User\u0027s Settings"
}

GHSA-9V85-V56P-73XM

Vulnerability from github – Published: 2026-09-01 15:31 – Updated: 2026-09-01 15:31
VLAI
Details

This vulnerability exists in the ERP system due to improper authentication and authorization controls in the API endpoint. An unauthenticated remote attacker could exploit this vulnerability by manipulating parameter which could lead to exposure of sensitive information belonging to other users on the targeted system.

Severity
9.2 (Critical)
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
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-84148"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-01T13:20:08Z",
    "severity": "CRITICAL"
  },
  "details": "This vulnerability exists in the ERP system due to improper authentication and authorization controls in the API endpoint. An unauthenticated remote attacker could exploit this vulnerability by manipulating parameter which could lead to exposure of sensitive information belonging to other users on the targeted system.",
  "id": "GHSA-9v85-v56p-73xm",
  "modified": "2026-09-01T15:31:11Z",
  "published": "2026-09-01T15:31:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84148"
    },
    {
      "type": "WEB",
      "url": "https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES01\u0026VLCODE=CIVN-2026-0430"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "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"
    }
  ]
}

GHSA-9VFR-59XG-H3VG

Vulnerability from github – Published: 2026-10-19 18:32 – Updated: 2026-10-19 18:32
VLAI
Details

Camunda 7.24.0 before 7.24.14 and 7.23.0 before 7.23.17 contains a missing authorization check vulnerability in engine-rest task sub-resources that allows authenticated attackers with no permission grants to access task comments and attachments by calling singular read and delete endpoints that lack the authorization-filtered checks enforced on their corresponding list endpoints. Attackers can exploit TaskAttachmentResourceImpl and TaskCommentResourceImpl methods such as getAttachment, getAttachmentData, deleteAttachment, and getComment using only a known object ID to read, download, or permanently delete task attachments and comments.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-109431"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-19T16:17:02Z",
    "severity": "HIGH"
  },
  "details": "Camunda 7.24.0 before 7.24.14 and 7.23.0 before 7.23.17 contains a missing authorization check vulnerability in engine-rest task sub-resources that allows authenticated attackers with no permission grants to access task comments and attachments by calling singular read and delete endpoints that lack the authorization-filtered checks enforced on their corresponding list endpoints. Attackers can exploit TaskAttachmentResourceImpl and TaskCommentResourceImpl methods such as getAttachment, getAttachmentData, deleteAttachment, and getComment using only a known object ID to read, download, or permanently delete task attachments and comments.",
  "id": "GHSA-9vfr-59xg-h3vg",
  "modified": "2026-10-19T18:32:11Z",
  "published": "2026-10-19T18:32:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-109431"
    },
    {
      "type": "WEB",
      "url": "https://codeant.ai/security-research/camunda-task-attachment-authorization-cve-2026-109431"
    },
    {
      "type": "WEB",
      "url": "https://docs.camunda.org/enterprise/download"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/camunda-missing-authorization-in-task-sub-resources"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/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"
    }
  ]
}
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