Common Weakness Enumeration

CWE-639

Allowed

Authorization Bypass Through User-Controlled Key

Abstraction: Base · Status: Incomplete

The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

3257 vulnerabilities reference this CWE, most recent first.

GHSA-JP3M-M8R2-V4X3

Vulnerability from github – Published: 2026-03-11 03:31 – Updated: 2026-03-11 03:31
VLAI
Details

The ProfilePress plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 4.16.11. This is due to missing ownership validation on the change_plan_sub_id parameter in the process_checkout() function. The ppress_process_checkout AJAX handler accepts a user-controlled subscription ID intended for plan upgrades, loads the subscription record, and cancels/expires it without verifying the subscription belongs to the requesting user. This makes it possible for authenticated attackers, with Subscriber-level access and above, to cancel and expire any other user's active subscription via the change_plan_sub_id parameter during checkout, causing immediate loss of paid access for victims.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-3453"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-11T03:15:56Z",
    "severity": "HIGH"
  },
  "details": "The ProfilePress plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 4.16.11. This is due to missing ownership validation on the change_plan_sub_id parameter in the process_checkout() function. The ppress_process_checkout AJAX handler accepts a user-controlled subscription ID intended for plan upgrades, loads the subscription record, and cancels/expires it without verifying the subscription belongs to the requesting user. This makes it possible for authenticated attackers, with Subscriber-level access and above, to cancel and expire any other user\u0027s active subscription via the change_plan_sub_id parameter during checkout, causing immediate loss of paid access for victims.",
  "id": "GHSA-jp3m-m8r2-v4x3",
  "modified": "2026-03-11T03:31:28Z",
  "published": "2026-03-11T03:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3453"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wp-user-avatar/tags/4.16.9/src/Membership/Controllers/CheckoutController.php#L237"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wp-user-avatar/tags/4.16.9/src/Membership/Controllers/CheckoutController.php#L334"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wp-user-avatar/tags/4.16.9/src/Membership/Controllers/CheckoutController.php#L342"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3474509/wp-user-avatar/trunk/src/Membership/Controllers/CheckoutController.php"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/74e4808f-bd6f-4e62-91cb-31c86a427498?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:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JPW9-PFVF-9F58

Vulnerability from github – Published: 2026-07-16 19:58 – Updated: 2026-07-16 19:58
VLAI
Summary
MCP Python SDK: HTTP transports serve session requests without verifying the authenticated principal
Details

Summary

In affected versions, the SSE and Streamable HTTP server transports routed incoming requests to an existing session based only on the session identifier, without verifying that the request was authenticated as the same principal that created the session. Anyone who learned or guessed a session ID could send JSON-RPC messages on that session, regardless of which bearer token the request carried.

Am I affected?

Only if a developer's application server uses an HTTP transport (SSE, or Streamable HTTP in stateful mode) and authenticates requests. Servers on stdio, stateless Streamable HTTP, or with no authentication configured are not affected.

Details

Both transports look up the target session by its identifier alone — the session_id query parameter for SSE (mcp.server.sse.SseServerTransport) and the Mcp-Session-Id header for Streamable HTTP (mcp.server.streamable_http_manager.StreamableHTTPSessionManager). Once the lookup succeeded, the request was handled on that session without comparing its authentication context to the credentials presented when the session was created, so a request authenticated as a different OAuth client could inject messages into the session. On the SSE transport the response is delivered to the original client's event stream; on the Streamable HTTP transport it is returned on the injecting request, so the injecting client can also read the result. The SSE transport has been affected since the first release; the Streamable HTTP transport since version 1.8.0.

Impact

Servers using either HTTP transport together with the SDK's built-in bearer-token authentication are affected: the per-client isolation that authentication provides can be bypassed for any session whose ID is known. Session IDs are randomly generated UUIDs, so exploitation requires obtaining one out of band (logs, network observation). Servers that do not enable bearer-token authentication have no per-client isolation to bypass and are not addressed by this advisory, and stateless Streamable HTTP deployments do not maintain sessions and are unaffected.

Mitigation

Upgrade to version 1.27.2 or later, which records the authenticated principal that created each session — the OAuth client ID together with the token's issuer and subject when the token verifier supplies them — and answers requests presenting a different principal with the same 404 response as for an unknown session.

Deployments where many end users share a single OAuth client (hosted MCP clients, gateways) should ensure their token verifier populates AccessToken.subject (e.g. from the token's sub claim) so sessions are isolated per user rather than per client. Deployments using a custom authentication backend other than the built-in BearerAuthBackend should enforce an equivalent check themselves.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.27.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52869"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-16T19:58:53Z",
    "nvd_published_at": "2026-07-15T20:17:38Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nIn affected versions, the SSE and Streamable HTTP server transports routed incoming requests to an existing session based only on the session identifier, without verifying that the request was authenticated as the same principal that created the session. Anyone who learned or guessed a session ID could send JSON-RPC messages on that session, regardless of which bearer token the request carried.\n\n### Am I affected?\nOnly if a developer\u0027s application server uses an HTTP transport (SSE, or Streamable HTTP in stateful mode) **and** authenticates requests. Servers on stdio, stateless Streamable HTTP, or with no authentication configured are not affected.\n\n### Details\nBoth transports look up the target session by its identifier alone \u2014 the `session_id` query parameter for SSE (`mcp.server.sse.SseServerTransport`) and the `Mcp-Session-Id` header for Streamable HTTP (`mcp.server.streamable_http_manager.StreamableHTTPSessionManager`). Once the lookup succeeded, the request was handled on that session without comparing its authentication context to the credentials presented when the session was created, so a request authenticated as a different OAuth client could inject messages into the session. On the SSE transport the response is delivered to the original client\u0027s event stream; on the Streamable HTTP transport it is returned on the injecting request, so the injecting client can also read the result. The SSE transport has been affected since the first release; the Streamable HTTP transport since version 1.8.0.\n\n### Impact\nServers using either HTTP transport together with the SDK\u0027s built-in bearer-token authentication are affected: the per-client isolation that authentication provides can be bypassed for any session whose ID is known. Session IDs are randomly generated UUIDs, so exploitation requires obtaining one out of band (logs, network observation). Servers that do not enable bearer-token authentication have no per-client isolation to bypass and are not addressed by this advisory, and stateless Streamable HTTP deployments do not maintain sessions and are unaffected.\n\n### Mitigation\nUpgrade to version 1.27.2 or later, which records the authenticated principal that created each session \u2014 the OAuth client ID together with the token\u0027s issuer and subject when the token verifier supplies them \u2014 and answers requests presenting a different principal with the same 404 response as for an unknown session.\n\nDeployments where many end users share a single OAuth client (hosted MCP clients, gateways) should ensure their token verifier populates `AccessToken.subject` (e.g. from the token\u0027s `sub` claim) so sessions are isolated per user rather than per client. Deployments using a custom authentication backend other than the built-in `BearerAuthBackend` should enforce an equivalent check themselves.",
  "id": "GHSA-jpw9-pfvf-9f58",
  "modified": "2026-07-16T19:58:53Z",
  "published": "2026-07-16T19:58:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-jpw9-pfvf-9f58"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52869"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/pull/2690"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/pull/2719"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/commit/1abcca2408a6b50e10ec601181f63f9978705c00"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/commit/ce267b6fc515dc4efc1dc70b6975b16ff0feef0a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/python-sdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.27.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "MCP Python SDK: HTTP transports serve session requests without verifying the authenticated principal"
}

GHSA-JQ29-R496-R955

Vulnerability from github – Published: 2026-02-05 21:02 – Updated: 2026-02-07 00:31
VLAI
Summary
payload-preferences has Cross-Collection IDOR in Access Control (Multi-Auth Environments)
Details

Impact

A cross-collection Insecure Direct Object Reference (IDOR) vulnerability exists in the payload-preferences internal collection. In multi-auth collection environments using Postgres or SQLite with default serial/auto-increment IDs, authenticated users from one auth collection can read and delete preferences belonging to users in different auth collections when their numeric IDs collide.

Users are affected if ALL of these are true:

  • Multiple auth collections configured (e.g., admins + customers)
  • Postgres or SQLite database adapter with serial/auto-increment IDs
  • Users in different auth collections with the same numeric ID

Not affected:

  • @payloadcms/db-mongodb adapter
  • Single auth collection environments
  • Postgres/SQLite with idType: 'uuid'

Patches

This vulnerability has been patched in v3.74.0. Users should upgrade to v3.74.0 or later.

Workarounds

There is no workaround other than upgrading. Users with multiple auth collections using Postgres or SQLite with serial IDs should upgrade immediately.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "payload"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.74.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-25574"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-05T21:02:20Z",
    "nvd_published_at": "2026-02-06T22:16:11Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nA cross-collection Insecure Direct Object Reference (IDOR) vulnerability exists in the `payload-preferences` internal collection. In multi-auth collection environments using Postgres or SQLite with default serial/auto-increment IDs, authenticated users from one auth collection can read and delete preferences belonging to users in different auth collections when their numeric IDs collide.\n\n**Users are affected if ALL of these are true:**\n\n- Multiple auth collections configured (e.g., `admins` + `customers`)\n- Postgres or SQLite database adapter with serial/auto-increment IDs\n- Users in different auth collections with the same numeric ID\n\n**Not affected:**\n\n- `@payloadcms/db-mongodb` adapter\n- Single auth collection environments\n- Postgres/SQLite with `idType: \u0027uuid\u0027`\n\n### Patches\n\nThis vulnerability has been patched in **v3.74.0**. Users should upgrade to v3.74.0 or later.\n\n### Workarounds\n\nThere is no workaround other than upgrading. Users with multiple auth collections using Postgres or SQLite with serial IDs should upgrade immediately.",
  "id": "GHSA-jq29-r496-r955",
  "modified": "2026-02-07T00:31:54Z",
  "published": "2026-02-05T21:02:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/payloadcms/payload/security/advisories/GHSA-jq29-r496-r955"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25574"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/payloadcms/payload"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "payload-preferences has Cross-Collection IDOR in Access Control (Multi-Auth Environments)"
}

GHSA-JQ9G-RPJW-RHW9

Vulnerability from github – Published: 2025-05-06 09:31 – Updated: 2025-05-06 09:31
VLAI
Details

The User Registration & Membership – Custom Registration Form, Login Form, and User Profile plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 4.2.1 via the create_stripe_subscription() function, due to missing validation on the 'member_id' user controlled key. This makes it possible for unauthenticated attackers to delete arbitrary user accounts that have registered through the plugin.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-3281"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-06T08:15:16Z",
    "severity": "MODERATE"
  },
  "details": "The User Registration \u0026 Membership \u2013 Custom Registration Form, Login Form, and User Profile plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 4.2.1 via the create_stripe_subscription() function, due to missing validation on the \u0027member_id\u0027 user controlled key. This makes it possible for unauthenticated attackers to delete arbitrary user accounts that have registered through the plugin.",
  "id": "GHSA-jq9g-rpjw-rhw9",
  "modified": "2025-05-06T09:31:31Z",
  "published": "2025-05-06T09:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3281"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/user-registration/tags/4.1.3/modules/membership/includes/AJAX.php#L619"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3287698/user-registration/trunk/modules/membership/includes/AJAX.php"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/30339ff6-b6bf-4c56-b6cd-db0b8a6ce8b6?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JQCQ-Q999-P2H6

Vulnerability from github – Published: 2022-05-13 01:43 – Updated: 2022-05-13 01:43
VLAI
Details

In Kanboard before 1.0.47, by altering form data, an authenticated user can edit columns of a private project of another user.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-15202"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-10-11T01:32:00Z",
    "severity": "MODERATE"
  },
  "details": "In Kanboard before 1.0.47, by altering form data, an authenticated user can edit columns of a private project of another user.",
  "id": "GHSA-jqcq-q999-p2h6",
  "modified": "2022-05-13T01:43:40Z",
  "published": "2022-05-13T01:43:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-15202"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kanboard/kanboard/commit/074f6c104f3e49401ef0065540338fc2d4be79f0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kanboard/kanboard/commit/3e0f14ae2b0b5a44bd038a472f17eac75f538524"
    },
    {
      "type": "WEB",
      "url": "https://kanboard.net/news/version-1.0.47"
    },
    {
      "type": "WEB",
      "url": "http://openwall.com/lists/oss-security/2017/10/04/9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JQP3-QRGH-4846

Vulnerability from github – Published: 2026-04-28 21:36 – Updated: 2026-06-09 20:32
VLAI
Summary
NVIDIA NVFlare Dashboard: Authorization bypass through user-controlled key via user management and authentication system
Details

NVIDIA NVFlare Dashboard contains a vulnerability in the user management and authentication system where an unauthenticated attacker may cause authorization bypass through user-controlled key. A successful exploit of this vulnerability may lead to privilege escalation, data tampering, information disclosure, code execution, and denial of service.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "nvflare"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24178"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-09T20:32:55Z",
    "nvd_published_at": "2026-04-28T19:36:45Z",
    "severity": "CRITICAL"
  },
  "details": "NVIDIA NVFlare Dashboard contains a vulnerability in the user management and authentication system where an unauthenticated attacker may cause authorization bypass through user-controlled key. A successful exploit of this vulnerability may lead to privilege escalation, data tampering, information disclosure, code execution, and denial of service.",
  "id": "GHSA-jqp3-qrgh-4846",
  "modified": "2026-06-09T20:32:55Z",
  "published": "2026-04-28T21:36:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24178"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/NVIDIA/NVFlare"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/nvflare/PYSEC-2026-100.yaml"
    },
    {
      "type": "WEB",
      "url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5819"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-24178"
    }
  ],
  "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"
    }
  ],
  "summary": "NVIDIA NVFlare Dashboard: Authorization bypass through user-controlled key via user management and authentication system"
}

GHSA-JQVQ-GV67-3567

Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-06-29 23:03
VLAI
Summary
Concrete CMS is vulnerable to IDOR + wrong-authorization-level in the Express association Reorder dialog
Details

Concrete CMS 9.5.0 and below is vulnerable to IDOR + wrong-authorization-level in the Express association Reorder dialog.  This can cause Cross-entity state tampering with view-only permission on one entry. To be affected, a website has to be using express and relying on express entity ordering. Thanks Winston Crooker for reporting.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "concrete5/concrete5"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-8347"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-29T23:03:43Z",
    "nvd_published_at": "2026-05-22T15:16:26Z",
    "severity": "LOW"
  },
  "details": "Concrete CMS 9.5.0 and below is vulnerable to IDOR + wrong-authorization-level in the Express association Reorder dialog.\u00a0 This can cause\u00a0Cross-entity state tampering\u00a0with view-only permission on one entry.\u00a0To be affected, a website has to be using express and relying on express entity ordering.\u00a0Thanks Winston Crooker for reporting.",
  "id": "GHSA-jqvq-gv67-3567",
  "modified": "2026-06-29T23:03:43Z",
  "published": "2026-05-26T13:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8347"
    },
    {
      "type": "WEB",
      "url": "https://documentation.concretecms.org/9-x/developers/introduction/version-history/951-release-notes"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/concretecms/concretecms"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Concrete CMS is vulnerable to IDOR + wrong-authorization-level in the Express association Reorder dialog"
}

GHSA-JR45-52CW-69H5

Vulnerability from github – Published: 2026-06-18 17:20 – Updated: 2026-06-18 17:20
VLAI
Summary
NL Portal Backend Libraries: Document contents remained downloadable by any logged-in user (incomplete fix of CVE-2026-49463)
Details

Summary

A previous advisory (CVE-2026-49463 / GHSA-qpm9-h556-mwxm) reported that any logged-in user could download any document by its identifier, and stated this was fixed in 3.0.1. For the document-content part that fix was incomplete: documents remained downloadable by any authenticated user in 3.0.1 and 3.0.2, and the issue was only fully resolved in 3.0.3.

Relationship to CVE-2026-49463

This advisory is a follow-up to CVE-2026-49463. That advisory described the problem on the GraphQL getDocumentContent query and listed nl.nl-portal:documenten-api as fixed in 3.0.1. In practice:

  • The 3.0.1 change added an authentication parameter to the GraphQL query but never used it, so the query kept returning any document regardless of ownership.
  • The same flaw also existed on a REST endpoint that the original advisory did not cover, and that endpoint was not changed in 3.0.1 or 3.0.2.

Both were removed in 3.0.3, which is the first release where the document-content issue is actually fixed.

What was wrong

A document's contents could be fetched in two ways, and neither verified the caller's relationship to the document:

  • a REST endpoint: GET /api/documentapi/{documentapi}/document/{documentId}/content
  • a GraphQL query: getDocumentContent

Being logged in was required, but that was the only check — there was no per-document authorization. (A security rule meant to guard the REST endpoint also pointed at the wrong URL and never took effect; even if it had, it would only have required a login, not ownership.)

Proof of concept

While logged in as any portal user, request a document that belongs to someone else:

GET /api/documentapi/openzaak/document/<another-users-document-id>/content

The server returns the document contents (HTTP 200), even though the caller has no relationship to that document. The getDocumentContent GraphQL query behaves the same way.

Impact

A logged-in user could read the contents of documents belonging to other people. In a citizen or business portal these documents can contain sensitive personal information. To exploit this, an attacker needs a valid login and a target document's identifier. Document identifiers are random and hard to guess, which limits — but does not prevent — abuse, since identifiers can leak through other channels.

Patches

Fixed in 3.0.3. Both the REST endpoint and the GraphQL query were removed entirely. Document contents can now only be downloaded through endpoints that first confirm the caller is allowed to see the document:

  • one that requires the caller to have a role on the related case (zaak);
  • one that requires the caller to own the message (bericht) the document is attached to.

If your application relied on the removed endpoints, switch to one of these case- or message-scoped download endpoints.

Workarounds

If you cannot upgrade immediately, block the path GET /api/documentapi/*/document/*/content and the getDocumentContent GraphQL query at your gateway or reverse proxy, and remove any client code that calls them. There is no setting that adds the missing per-document check in affected versions; upgrading (or removing the endpoints) is the only complete fix.

References

  • Related advisory: GHSA-qpm9-h556-mwxm (CVE-2026-49463)
  • Fix commits: 6e738a87 (GraphQL query removed, PR #690), e326e6db (REST endpoint removed)
  • Affected module: nl.nl-portal:documenten-api

Credits

Reported by Ray Sabee, https://whitehatsecurity.nl/ (independent security researcher). Github handle: raysabee

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "nl.nl-portal:documenten-api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54683"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T17:20:14Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nA previous advisory (CVE-2026-49463 / GHSA-qpm9-h556-mwxm) reported that any logged-in user could download any document by its identifier, and stated this was fixed in 3.0.1. For the document-content part that fix was **incomplete**: documents remained downloadable by any authenticated user in 3.0.1 and 3.0.2, and the issue was only fully resolved in **3.0.3**.\n\n## Relationship to CVE-2026-49463\n\nThis advisory is a follow-up to CVE-2026-49463. That advisory described the problem on the GraphQL `getDocumentContent` query and listed `nl.nl-portal:documenten-api` as fixed in 3.0.1. In practice:\n\n- The 3.0.1 change added an authentication parameter to the GraphQL query but never used it, so the query kept returning any document regardless of ownership.\n- The same flaw also existed on a REST endpoint that the original advisory did not cover, and that endpoint was not changed in 3.0.1 or 3.0.2.\n\nBoth were removed in 3.0.3, which is the first release where the document-content issue is actually fixed.\n\n## What was wrong\n\nA document\u0027s contents could be fetched in two ways, and neither verified the caller\u0027s relationship to the document:\n\n- a REST endpoint: `GET /api/documentapi/{documentapi}/document/{documentId}/content`\n- a GraphQL query: `getDocumentContent`\n\nBeing logged in was required, but that was the *only* check \u2014 there was no per-document authorization. (A security rule meant to guard the REST endpoint also pointed at the wrong URL and never took effect; even if it had, it would only have required a login, not ownership.)\n\n## Proof of concept\n\nWhile logged in as any portal user, request a document that belongs to someone else:\n\n```\nGET /api/documentapi/openzaak/document/\u003canother-users-document-id\u003e/content\n```\n\nThe server returns the document contents (HTTP 200), even though the caller has no relationship to that document. The `getDocumentContent` GraphQL query behaves the same way.\n\n## Impact\n\nA logged-in user could read the contents of documents belonging to other people. In a citizen or business portal these documents can contain sensitive personal information. To exploit this, an attacker needs a valid login and a target document\u0027s identifier. Document identifiers are random and hard to guess, which limits \u2014 but does not prevent \u2014 abuse, since identifiers can leak through other channels.\n\n## Patches\n\nFixed in **3.0.3**. Both the REST endpoint and the GraphQL query were removed entirely. Document contents can now only be downloaded through endpoints that first confirm the caller is allowed to see the document:\n\n- one that requires the caller to have a role on the related case (*zaak*);\n- one that requires the caller to own the message (*bericht*) the document is attached to.\n\nIf your application relied on the removed endpoints, switch to one of these case- or message-scoped download endpoints.\n\n## Workarounds\n\nIf you cannot upgrade immediately, block the path `GET /api/documentapi/*/document/*/content` and the `getDocumentContent` GraphQL query at your gateway or reverse proxy, and remove any client code that calls them. There is no setting that adds the missing per-document check in affected versions; upgrading (or removing the endpoints) is the only complete fix.\n\n## References\n\n- Related advisory: GHSA-qpm9-h556-mwxm (CVE-2026-49463)\n- Fix commits: 6e738a87 (GraphQL query removed, PR #690), e326e6db (REST endpoint removed)\n- Affected module: `nl.nl-portal:documenten-api`\n\n## Credits\n\nReported by Ray Sabee, https://whitehatsecurity.nl/ (independent security researcher). Github handle: [raysabee](https://github.com/raysabee)",
  "id": "GHSA-jr45-52cw-69h5",
  "modified": "2026-06-18T17:20:14Z",
  "published": "2026-06-18T17:20:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nl-portal/nl-portal-backend-libraries/security/advisories/GHSA-jr45-52cw-69h5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nl-portal/nl-portal-backend-libraries/pull/690"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nl-portal/nl-portal-backend-libraries/commit/6e738a876ff9f581991b5b070706100b5516e183"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nl-portal/nl-portal-backend-libraries/commit/e326e6db862f71f76dd46d3b17cbb5fa6f2fba02"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nl-portal/nl-portal-backend-libraries"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "NL Portal Backend Libraries: Document contents remained downloadable by any logged-in user (incomplete fix of CVE-2026-49463)"
}

GHSA-JR5V-P4F2-W6W8

Vulnerability from github – Published: 2025-10-09 06:30 – Updated: 2025-10-09 06:30
VLAI
Details

The Lisfinity Core - Lisfinity Core plugin used for pebas® Lisfinity WordPress theme plugin for WordPress is vulnerable to privilege escalation via password update in all versions up to, and including, 1.4.0. This is due to the plugin not properly validating a user's identity prior to updating their password. This makes it possible for authenticated attackers, with Subscriber-level access and above, to change arbitrary user's passwords, including those of administrators.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-6038"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-09T04:16:47Z",
    "severity": "HIGH"
  },
  "details": "The Lisfinity Core - Lisfinity Core plugin used for pebas\u00ae Lisfinity WordPress theme plugin for WordPress is vulnerable to privilege escalation via password update in all versions up to, and including, 1.4.0. This is due to the plugin not properly validating a user\u0027s identity prior to updating their password. This makes it possible for authenticated attackers, with Subscriber-level access and above, to change arbitrary user\u0027s passwords, including those of administrators.",
  "id": "GHSA-jr5v-p4f2-w6w8",
  "modified": "2025-10-09T06:30:25Z",
  "published": "2025-10-09T06:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6038"
    },
    {
      "type": "WEB",
      "url": "https://themeforest.net/item/lisfinity-classified-ads-wordpress-theme/26342611"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/a3cd1c3e-5bb0-4653-8764-2ca38d9a7c77?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-JRVR-2G4H-RVR6

Vulnerability from github – Published: 2025-11-13 15:30 – Updated: 2025-11-13 15:30
VLAI
Details

Insecure Direct Object Reference (IDOR) vulnerability in DeporSite of T-INNOVA. This vulnerability allows an attacker to access or modify unauthorized resources by manipulating requests using the 'idUsuario' parameter in ‘/ajax/TInnova_v2/Formulario_Consentimiento/llamadaAjax/obtenerDatosConsentimientos’, which could lead to the exposure or alteration os confidential data.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-41069"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-13T14:15:48Z",
    "severity": "MODERATE"
  },
  "details": "Insecure Direct Object Reference (IDOR) vulnerability in DeporSite of T-INNOVA. This vulnerability allows an attacker to access or modify unauthorized resources by manipulating requests using the \u0027idUsuario\u0027 parameter in \u2018/ajax/TInnova_v2/Formulario_Consentimiento/llamadaAjax/obtenerDatosConsentimientos\u2019, which could lead to the exposure or alteration os confidential data.",
  "id": "GHSA-jrvr-2g4h-rvr6",
  "modified": "2025-11-13T15:30:31Z",
  "published": "2025-11-13T15:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41069"
    },
    {
      "type": "WEB",
      "url": "https://www.incibe.es/en/incibe-cert/notices/aviso/insecure-direct-object-references-idor-deporsite-t-innova-deporsite"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E: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.