CWE-862
Allowed-with-ReviewMissing Authorization
Abstraction: Class · Status: Incomplete
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
14554 vulnerabilities reference this CWE, most recent first.
GHSA-XJJH-W5WH-CGWV
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2026-04-01 18:31Missing Authorization vulnerability in BinaryCarpenter Ultimate Custom Add To Cart Button (Ajax) For WooCommerce by Binary Carpenter allows Cross-Site Scripting (XSS).This issue affects Ultimate Custom Add To Cart Button (Ajax) For WooCommerce by Binary Carpenter: from n/a through 1.222.16.
{
"affected": [],
"aliases": [
"CVE-2024-37202"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T14:15:12Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in BinaryCarpenter Ultimate Custom Add To Cart Button (Ajax) For WooCommerce by Binary Carpenter allows Cross-Site Scripting (XSS).This issue affects Ultimate Custom Add To Cart Button (Ajax) For WooCommerce by Binary Carpenter: from n/a through 1.222.16.",
"id": "GHSA-xjjh-w5wh-cgwv",
"modified": "2026-04-01T18:31:51Z",
"published": "2024-07-12T15:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37202"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/custom-add-to-cart-button-for-woocommerce/vulnerability/wordpress-ultimate-custom-add-to-cart-button-ajax-for-woocommerce-by-binary-carpenter-plugin-1-222-16-broken-access-control-to-xss-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/custom-add-to-cart-button-for-woocommerce/wordpress-ultimate-custom-add-to-cart-button-ajax-for-woocommerce-by-binary-carpenter-plugin-1-222-16-broken-access-control-to-xss-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-XJJJ-RCFC-FP6H
Vulnerability from github – Published: 2025-04-17 03:30 – Updated: 2025-04-17 03:30A missing authorization vulnerability in the retrieve teacher Information function of Wisdom Master Pro versions 5.0 through 5.2 allows remote attackers to obtain partial user data by accessing the API functionality.
{
"affected": [],
"aliases": [
"CVE-2025-31338"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-17T03:15:15Z",
"severity": "MODERATE"
},
"details": "A missing authorization vulnerability in the retrieve teacher Information function of Wisdom Master Pro versions 5.0 through 5.2 allows remote attackers to obtain partial user data by accessing the API functionality.",
"id": "GHSA-xjjj-rcfc-fp6h",
"modified": "2025-04-17T03:30:30Z",
"published": "2025-04-17T03:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31338"
},
{
"type": "WEB",
"url": "https://zuso.ai/advisory/za-2025-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-XJM2-V33P-4X8M
Vulnerability from github – Published: 2024-11-01 15:31 – Updated: 2024-11-01 15:31Missing Authorization vulnerability in Dropshipping Guru Ali2Woo Lite Exploiting Incorrectly Configured Access Control Security Levels, Stored XSS.This issue affects Ali2Woo Lite: from n/a through 3.3.5.
{
"affected": [],
"aliases": [
"CVE-2024-37214"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-01T15:15:20Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Dropshipping Guru Ali2Woo Lite Exploiting Incorrectly Configured Access Control Security Levels, Stored XSS.This issue affects Ali2Woo Lite: from n/a through 3.3.5.",
"id": "GHSA-xjm2-v33p-4x8m",
"modified": "2024-11-01T15:31:57Z",
"published": "2024-11-01T15:31:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37214"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/ali2woo-lite/wordpress-aliexpress-dropshipping-with-alinext-lite-plugin-3-3-5-broken-access-control-to-xss-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-XJMR-HVQ4-XRMR
Vulnerability from github – Published: 2025-09-09 18:31 – Updated: 2025-09-09 18:31Missing authorization in Ivanti Connect Secure before 22.7R2.9 or 22.8R2, Ivanti Policy Secure before 22.7R1.6, Ivanti ZTA Gateway before 2.8R2.3-723 and Ivanti Neurons for Secure Access before 22.8R1.4 (Fix deployed on 02-Aug-2025) allows a remote authenticated attacker with read-only admin privileges to configure authentication related settings.
{
"affected": [],
"aliases": [
"CVE-2025-55141"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-09T16:15:33Z",
"severity": "HIGH"
},
"details": "Missing authorization in Ivanti Connect Secure before 22.7R2.9 or 22.8R2, Ivanti Policy Secure before 22.7R1.6, Ivanti ZTA Gateway before 2.8R2.3-723 and Ivanti Neurons for Secure Access before 22.8R1.4 (Fix deployed on 02-Aug-2025) allows a remote authenticated attacker with read-only admin privileges to configure authentication related settings.",
"id": "GHSA-xjmr-hvq4-xrmr",
"modified": "2025-09-09T18:31:18Z",
"published": "2025-09-09T18:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55141"
},
{
"type": "WEB",
"url": "https://forums.ivanti.com/s/article/September-Security-Advisory-Ivanti-Connect-Secure-Policy-Secure-ZTA-Gateways-and-Neurons-for-Secure-Access-Multiple-CVEs?language=en_US"
}
],
"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-XJP5-M6C5-6C7W
Vulnerability from github – Published: 2023-03-09 21:30 – Updated: 2023-03-15 15:30onekeyadmin v1.3.9 was discovered to contain an arbitrary file delete vulnerability via the component \admin\controller\plugins.
{
"affected": [],
"aliases": [
"CVE-2023-26957"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-09T21:15:00Z",
"severity": "CRITICAL"
},
"details": "onekeyadmin v1.3.9 was discovered to contain an arbitrary file delete vulnerability via the component \\admin\\controller\\plugins.",
"id": "GHSA-xjp5-m6c5-6c7w",
"modified": "2023-03-15T15:30:22Z",
"published": "2023-03-09T21:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26957"
},
{
"type": "WEB",
"url": "https://github.com/keheying/onekeyadmin/issues/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XJPM-62P5-JW4J
Vulnerability from github – Published: 2026-06-09 06:31 – Updated: 2026-06-09 15:32The WPForms WordPress plugin before 1.10.0.5 does not verify the authenticity of incoming PayPal webhook events before processing them, allowing unauthenticated attackers to forge webhook payloads and manipulate the payment state of arbitrary transactions.
{
"affected": [],
"aliases": [
"CVE-2026-4986"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-09T06:16:53Z",
"severity": "MODERATE"
},
"details": "The WPForms WordPress plugin before 1.10.0.5 does not verify the authenticity of incoming PayPal webhook events before processing them, allowing unauthenticated attackers to forge webhook payloads and manipulate the payment state of arbitrary transactions.",
"id": "GHSA-xjpm-62p5-jw4j",
"modified": "2026-06-09T15:32:13Z",
"published": "2026-06-09T06:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4986"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/1d99eed6-9a16-4d5a-90f9-ab604dfd5b92"
}
],
"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-XJR6-JRH9-WC2P
Vulnerability from github – Published: 2026-03-13 21:31 – Updated: 2026-03-13 21:31Missing Authorization vulnerability in E2Pdf e2pdf e2pdf allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects e2pdf: from n/a through <= 1.28.15.
{
"affected": [],
"aliases": [
"CVE-2026-32442"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-13T19:55:04Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in E2Pdf e2pdf e2pdf allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects e2pdf: from n/a through \u003c= 1.28.15.",
"id": "GHSA-xjr6-jrh9-wc2p",
"modified": "2026-03-13T21:31:50Z",
"published": "2026-03-13T21:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32442"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/e2pdf/vulnerability/wordpress-e2pdf-plugin-1-28-15-broken-access-control-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:N",
"type": "CVSS_V3"
}
]
}
GHSA-XJVC-8MFJ-G22V
Vulnerability from github – Published: 2023-07-06 19:24 – Updated: 2026-04-08 18:31The Restaurant Menu – Food Ordering System – Table Reservation plugin for WordPress is vulnerable to authorization bypass via several AJAX actions in versions up to, and including 2.3.0 due to missing capability checks and missing nonce validation. This makes it possible for authenticated attackers with minimal permissions to perform a wide variety of actions such as modifying the plugin's settings and modifying the ordering system preferences.
{
"affected": [],
"aliases": [
"CVE-2022-2696"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-03T17:15:00Z",
"severity": "MODERATE"
},
"details": "The Restaurant Menu \u2013 Food Ordering System \u2013 Table Reservation plugin for WordPress is vulnerable to authorization bypass via several AJAX actions in versions up to, and including 2.3.0 due to missing capability checks and missing nonce validation. This makes it possible for authenticated attackers with minimal permissions to perform a wide variety of actions such as modifying the plugin\u0027s settings and modifying the ordering system preferences.",
"id": "GHSA-xjvc-8mfj-g22v",
"modified": "2026-04-08T18:31:58Z",
"published": "2023-07-06T19:24:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2696"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/menu-ordering-reservations/trunk/includes/admin/class-glf-admin-screens.php?rev=2664283"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=2793398%40menu-ordering-reservations\u0026new=2793398%40menu-ordering-reservations\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/01486af8-b378-4663-a9c5-167b8580db94?source=cve"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/vulnerability-advisories-continued/#CVE-2022-2696"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-XJX4-4JQ2-XCMR
Vulnerability from github – Published: 2025-08-27 18:31 – Updated: 2026-04-28 21:35Missing Authorization vulnerability in AfterShip & Automizely AfterShip Tracking allows Accessing Functionality Not Properly Constrained by ACLs. This issue affects AfterShip Tracking: from n/a through 1.17.17.
{
"affected": [],
"aliases": [
"CVE-2025-58201"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-27T18:15:47Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in AfterShip \u0026 Automizely AfterShip Tracking allows Accessing Functionality Not Properly Constrained by ACLs. This issue affects AfterShip Tracking: from n/a through 1.17.17.",
"id": "GHSA-xjx4-4jq2-xcmr",
"modified": "2026-04-28T21:35:49Z",
"published": "2025-08-27T18:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58201"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/aftership-woocommerce-tracking/vulnerability/wordpress-aftership-tracking-plugin-1-17-17-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XM3X-9CFW-JHX4
Vulnerability from github – Published: 2026-06-19 14:17 – Updated: 2026-06-19 14:17Summary
The public GraphQL resolvers getFormDefinitionByObjectenApiUrl(url) and the deprecated getFormDefinitionById(id) fetch a caller-supplied URL using the privileged Objecten-API token. Because the /graphql endpoint is permitAll() and these resolvers do not declare a CommonGroundAuthentication parameter, an unauthenticated caller can make the backend issue an outbound request carrying Authorization: Token <objecten-api-token> to a caller-influenced URL on the configured Objecten-API host. This is a constrained (same-host) server-side request forgery combined with missing authorization.
Reported responsibly and confirmed in a local lab build against the project's own WebFlux security stack. No production system was accessed.
Affected
nl.nl-portal:form(the public resolver / entry point) together withnl.nl-portal:objectenapi(where the host guard lives).- First shipped in 1.1.0.RELEASE (2023-10-31); the vulnerable code was introduced on 2023-08-12 (commit
b2f87ca) and is present in every release since (1.1.x, 1.2.5, 1.3.0, the 3.0.x line, and 3.1.0 /next-minor, HEAD45abcd2). Fixed in 3.0.4.RELEASE (see Fix below).
Data flow (confirmed in source)
form/.../graphql/FormDefinitionQuery.kt—@QueryMapping getFormDefinitionByObjectenApiUrl(@Argument url), noCommonGroundAuthenticationparameter (same forgetFormDefinitionById).- →
form/.../service/ObjectsApiFormDefinitionService.kt— passes the URL through unvalidated. - →
zgw/objectenapi/.../service/ObjectenApiService.ktgetObjectByUrl(url)— the only guard is host equality (URI.create(url).host == objectsApiClientConfig.url.host); no scheme/port/path check. - →
zgw/objectenapi/.../client/ObjectsApiClient.ktgetObjectByUrl(url)viawebClientWithoutBaseUrl(), which attaches the default headerAuthorization: Token <token>to the fully caller-supplied URL.
Reachability: /graphql is permitAll() (core/.../security/OauthSecurityAutoConfiguration.kt). Authentication is only enforced on resolvers that declare a CommonGroundAuthentication parameter; these do not, and there is no @PreAuthorize/instrumentation safety net. The project's own GraphQLEndpointAuthorizationIT lists getFormDefinitionByObjectenApiUrl as an intentionally public operation — so the unauthenticated reachability is by design; the defect is that an intentionally-public resolver forwards a privileged token to a caller-influenced URL.
Secondary (defense-in-depth): zgw/zaken-api/.../service/ZakenApiService.kt getZaakDetails calls objectsApiClient.getObjectByUrl directly, bypassing the service-level host guard. It is currently only reachable via the authenticated ZaakQuery.zaakdetails field resolver with server-derived URLs, so it is not an unauthenticated vector today — but it shows why the guard belongs in the client.
Proof of concept (lab, against the real WebFlux stack)
- An unauthenticated
POST /graphqlcallinggetFormDefinitionByObjectenApiUrl(url: ...)executes without authentication. - With the configured Objecten-API host pointed at a mock server, an outbound request to a caller-chosen port/path on that host carried
Authorization: Token <configured-token>— confirming the token is attached to caller-influenced URLs.
Impact and severity — important limitations
Assessed as Medium because two code-level facts constrain practical impact:
-
No cross-host SSRF / token exfiltration in standard deployments. The token only travels to the configured Objecten-API host. Exfiltration requires an attacker-controlled listener at that host (a different port/path routing elsewhere) — generally not the case in managed deployments. A range of URL-parser bypass payloads was tested (userinfo
@,%2f/%00/%09, backslash,#/?, double-host, trailing-dot, IDN/Unicode full-stop, fraction-slash, IPv6); no parser differential was found between thejava.net.URI-based guard and the Spring/Netty URI builder used by WebClient — every payload either kept the request on the configured host or was rejected (fail-closed). The lab token-leak PoC works only because the configured host there islocalhost; this does not generalize to production. -
Arbitrary PII object read is blocked by typed deserialization. The response is deserialized into
ObjectsApiObject<ObjectsApiFormIoFormDefinition>, whose envelope fields anddata.formDefinitionare all non-nullable Kotlin properties (JacksonKotlinModuleregistered). An object without a top-leveldata.formDefinition(e.g. taken/berichten/zaakdetails) fails to deserialize (DecodingException) and returns no data. The resolver can therefore only return objects shaped like a form definition — and form definitions are intentionally public (loaded pre-login).
Escalation conditions that would raise severity toward High: - the Objecten-API host shares infrastructure with an attacker-controllable endpoint (other port/path), enabling capture of the privileged token; or - a URL-parser differential is later found that escapes the host guard.
Remediation
- Move the host validation out of
ObjectenApiService.getObjectByUrland intoObjectsApiClient.getObjectByUrlso the direct callerZakenApiService.getZaakDetailsis covered too, and tighten it from host-only to scheme + host + port + path-prefix. Preferably, do not accept a full URL at all: validate/extract the object UUID and rebuild the URL from the fixed configured base (reuse the existingObjectsApiClient.getObjectByIdpattern,/api/v2/objects/{uuid}). - Separately decide whether
getFormDefinitionByObjectenApiUrl/getFormDefinitionByIdshould remain unauthenticated. They are currently intentionally public (forms load before login); for a stricter posture, add aCommonGroundAuthenticationparameter as in the other resolvers — noting this breaks pre-login form loading.
Credit
Reported responsibly by Ray Sabee (https://whitehatsecurity.nl), independent security researcher — GitHub @raysabee.
Fix
Fixed in 3.0.4.RELEASE (commit 39ad80f, PR #700, "rework form module"):
- The unauthenticated resolvers getFormDefinitionByObjectenApiUrl and the deprecated getFormDefinitionById were removed from both FormDefinitionQuery and the GraphQL schema.
- getFormDefinitionByName now requires a CommonGroundAuthentication parameter (no longer public).
- The URL-based service method findObjectsApiFormDefinitionByUrl(url) was removed and replaced by getObjectsApiFormDefinitionById(objectId: UUID), which fetches by UUID via the fixed /api/v2/objects/{uuid} path (no caller-supplied URL, so no SSRF) and validates the object type against the configured form-definition object type.
- Form definitions are now retrieved through the new authenticated query getFormDefinitionByTaskId(taskId) in nl.nl-portal:taak, which authorizes the caller against the task (CommonGroundAuthentication, BSN/KVK match, else 401) and derives the form-definition UUID from the task's own server-side data, not from caller input.
- No resolver feeds caller-controlled input into ObjectenApiService.getObjectByUrl anymore. The objectenapi module itself was not changed; the fix lives entirely in nl.nl-portal:form and the new nl.nl-portal:taak query.
Upgrade instructions
- Backend: upgrade
nl.nl-portal:*to 3.0.4 (or later). - Frontend: upgrade
nl-portal-frontend-librariesto v3.0.3 (or later). This is required: the removed GraphQL queries (getFormDefinitionByObjectenApiUrl,getFormDefinitionById) and the now-authenticatedgetFormDefinitionByNameare a breaking change. Frontend v3.0.3 uses the new authenticatedgetFormDefinitionByTaskId/getFormDefinitionByNamequeries.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "nl.nl-portal:form"
},
"ranges": [
{
"events": [
{
"introduced": "1.1.0"
},
{
"fixed": "3.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55414"
],
"database_specific": {
"cwe_ids": [
"CWE-862",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T14:17:18Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe public GraphQL resolvers `getFormDefinitionByObjectenApiUrl(url)` and the deprecated `getFormDefinitionById(id)` fetch a caller-supplied URL using the **privileged Objecten-API token**. Because the `/graphql` endpoint is `permitAll()` and these resolvers do not declare a `CommonGroundAuthentication` parameter, an **unauthenticated** caller can make the backend issue an outbound request carrying `Authorization: Token \u003cobjecten-api-token\u003e` to a **caller-influenced URL on the configured Objecten-API host**. This is a constrained (same-host) server-side request forgery combined with missing authorization.\n\nReported responsibly and confirmed in a local lab build against the project\u0027s own WebFlux security stack. No production system was accessed.\n\n## Affected\n\n- `nl.nl-portal:form` (the public resolver / entry point) together with `nl.nl-portal:objectenapi` (where the host guard lives).\n- First shipped in **1.1.0.RELEASE** (2023-10-31); the vulnerable code was introduced on 2023-08-12 (commit `b2f87ca`) and is present in every release since (1.1.x, 1.2.5, 1.3.0, the 3.0.x line, and 3.1.0 / `next-minor`, HEAD `45abcd2`). Fixed in 3.0.4.RELEASE (see Fix below).\n\n## Data flow (confirmed in source)\n\n1. `form/.../graphql/FormDefinitionQuery.kt` \u2014 `@QueryMapping getFormDefinitionByObjectenApiUrl(@Argument url)`, **no** `CommonGroundAuthentication` parameter (same for `getFormDefinitionById`).\n2. \u2192 `form/.../service/ObjectsApiFormDefinitionService.kt` \u2014 passes the URL through unvalidated.\n3. \u2192 `zgw/objectenapi/.../service/ObjectenApiService.kt` `getObjectByUrl(url)` \u2014 the only guard is host equality (`URI.create(url).host == objectsApiClientConfig.url.host`); **no scheme/port/path check**.\n4. \u2192 `zgw/objectenapi/.../client/ObjectsApiClient.kt` `getObjectByUrl(url)` via `webClientWithoutBaseUrl()`, which attaches the default header `Authorization: Token \u003ctoken\u003e` to the fully caller-supplied URL.\n\n**Reachability:** `/graphql` is `permitAll()` (`core/.../security/OauthSecurityAutoConfiguration.kt`). Authentication is only enforced on resolvers that declare a `CommonGroundAuthentication` parameter; these do not, and there is no `@PreAuthorize`/instrumentation safety net. The project\u0027s own `GraphQLEndpointAuthorizationIT` lists `getFormDefinitionByObjectenApiUrl` as an intentionally public operation \u2014 so the unauthenticated reachability is by design; the defect is that an intentionally-public resolver forwards a privileged token to a caller-influenced URL.\n\n**Secondary (defense-in-depth):** `zgw/zaken-api/.../service/ZakenApiService.kt` `getZaakDetails` calls `objectsApiClient.getObjectByUrl` **directly**, bypassing the service-level host guard. It is currently only reachable via the authenticated `ZaakQuery.zaakdetails` field resolver with server-derived URLs, so it is not an unauthenticated vector today \u2014 but it shows why the guard belongs in the client.\n\n## Proof of concept (lab, against the real WebFlux stack)\n\n- An unauthenticated `POST /graphql` calling `getFormDefinitionByObjectenApiUrl(url: ...)` executes without authentication.\n- With the configured Objecten-API host pointed at a mock server, an outbound request to a **caller-chosen port/path on that host** carried `Authorization: Token \u003cconfigured-token\u003e` \u2014 confirming the token is attached to caller-influenced URLs.\n\n## Impact and severity \u2014 important limitations\n\nAssessed as **Medium** because two code-level facts constrain practical impact:\n\n1. **No cross-host SSRF / token exfiltration in standard deployments.** The token only travels to the *configured* Objecten-API host. Exfiltration requires an attacker-controlled listener at that host (a different port/path routing elsewhere) \u2014 generally not the case in managed deployments. A range of URL-parser bypass payloads was tested (userinfo `@`, `%2f`/`%00`/`%09`, backslash, `#`/`?`, double-host, trailing-dot, IDN/Unicode full-stop, fraction-slash, IPv6); **no parser differential** was found between the `java.net.URI`-based guard and the Spring/Netty URI builder used by WebClient \u2014 every payload either kept the request on the configured host or was rejected (fail-closed). The lab token-leak PoC works only because the configured host there is `localhost`; this does not generalize to production.\n\n2. **Arbitrary PII object read is blocked by typed deserialization.** The response is deserialized into `ObjectsApiObject\u003cObjectsApiFormIoFormDefinition\u003e`, whose envelope fields and `data.formDefinition` are all non-nullable Kotlin properties (Jackson `KotlinModule` registered). An object without a top-level `data.formDefinition` (e.g. taken/berichten/zaakdetails) fails to deserialize (`DecodingException`) and returns no data. The resolver can therefore only return objects shaped like a form definition \u2014 and form definitions are intentionally public (loaded pre-login).\n\n**Escalation conditions** that would raise severity toward High:\n- the Objecten-API host shares infrastructure with an attacker-controllable endpoint (other port/path), enabling capture of the privileged token; or\n- a URL-parser differential is later found that escapes the host guard.\n\n## Remediation\n\n- Move the host validation out of `ObjectenApiService.getObjectByUrl` and into `ObjectsApiClient.getObjectByUrl` so the direct caller `ZakenApiService.getZaakDetails` is covered too, and tighten it from host-only to **scheme + host + port + path-prefix**. Preferably, do not accept a full URL at all: validate/extract the object UUID and rebuild the URL from the fixed configured base (reuse the existing `ObjectsApiClient.getObjectById` pattern, `/api/v2/objects/{uuid}`).\n- Separately decide whether `getFormDefinitionByObjectenApiUrl` / `getFormDefinitionById` should remain unauthenticated. They are currently intentionally public (forms load before login); for a stricter posture, add a `CommonGroundAuthentication` parameter as in the other resolvers \u2014 noting this breaks pre-login form loading.\n\n## Credit\n\nReported responsibly by **Ray Sabee** (https://whitehatsecurity.nl), independent security researcher \u2014 GitHub [@raysabee](https://github.com/raysabee).\n\n\n## Fix\n\nFixed in **3.0.4.RELEASE** (commit `39ad80f`, PR #700, \"rework form module\"):\n- The unauthenticated resolvers `getFormDefinitionByObjectenApiUrl` and the deprecated `getFormDefinitionById` were **removed** from both `FormDefinitionQuery` and the GraphQL schema.\n- `getFormDefinitionByName` now requires a `CommonGroundAuthentication` parameter (no longer public).\n- The URL-based service method `findObjectsApiFormDefinitionByUrl(url)` was removed and replaced by `getObjectsApiFormDefinitionById(objectId: UUID)`, which fetches by UUID via the fixed `/api/v2/objects/{uuid}` path (no caller-supplied URL, so no SSRF) and validates the object type against the configured form-definition object type.\n- Form definitions are now retrieved through the new authenticated query `getFormDefinitionByTaskId(taskId)` in `nl.nl-portal:taak`, which authorizes the caller against the task (`CommonGroundAuthentication`, BSN/KVK match, else `401`) and derives the form-definition UUID from the task\u0027s own server-side data, not from caller input.\n- No resolver feeds caller-controlled input into `ObjectenApiService.getObjectByUrl` anymore. The `objectenapi` module itself was not changed; the fix lives entirely in `nl.nl-portal:form` and the new `nl.nl-portal:taak` query.\n\n## Upgrade instructions\n\n- **Backend:** upgrade `nl.nl-portal:*` to **3.0.4** (or later).\n- **Frontend:** upgrade `nl-portal-frontend-libraries` to **v3.0.3** (or later). This is required: the removed GraphQL queries (`getFormDefinitionByObjectenApiUrl`, `getFormDefinitionById`) and the now-authenticated `getFormDefinitionByName` are a breaking change. Frontend v3.0.3 uses the new authenticated `getFormDefinitionByTaskId` / `getFormDefinitionByName` queries.",
"id": "GHSA-xm3x-9cfw-jhx4",
"modified": "2026-06-19T14:17:18Z",
"published": "2026-06-19T14:17:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nl-portal/nl-portal-backend-libraries/security/advisories/GHSA-xm3x-9cfw-jhx4"
},
{
"type": "WEB",
"url": "https://github.com/nl-portal/nl-portal-backend-libraries/pull/700"
},
{
"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:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "NL Portal Backend Libraries: Unauthenticated form resolver forwards the privileged Objecten-API token to a caller-supplied URL (SSRF)"
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.