## Impact In versions up to and including 3.0.0, two parts of the GraphQL API returned data without checking whether the data belonged to the logged-in user: - **Document content.** A logged-in user could download the raw content of any document by its ID, regardless of who owned it. The resolver has lacked an authentication parameter since the initial commit of the project (2022-11-22) — so every version of `nl.nl-portal:documenten-api` ever published is affected (the earliest one on Maven Central is `0.2.2.RELEASE`, published 2023-08-31). - **Decisions (`besluiten`).** A logged-in user could list, search, and read decision records — including their audit trails and the documents attached to them — for any user. The list query also accepted filters (decision type, identification, responsible organisation, related case), which made it easy to enumerate decisions across the user base. The `besluiten` module was introduced in the `1.5.x` release line (commit `9229460b`, 2024-08-19), so versions of `nl.nl-portal:besluiten` from `1.5.0` through `3.0.0` are affected. Decisions and their attachments often contain sensitive personal data (decisions on benefits, permits, objections, and similar), so the confidentiality impact is high. The two endpoints also chain naturally: once an attacker has discovered another user's document IDs by enumerating decisions, they can pull those documents' contents through the document endpoint. ### Why these two findings are reported together They share the same root cause and the same shape. Both GraphQL resolvers were declared without an authentication parameter on the method signature, which meant the framework never bound the authenticated user into the resolver and the resolver therefore could not perform per-user authorization checks. The fix pattern is the same — bind the authenticated principal into the resolver, or remove the resolver entirely. And in practice the two endpoints reinforce each other as a chain (enumerate via decisions, exfiltrate via documents), so they describe a single end-to-end weakness in the GraphQL surface. ## Patches Upgrade to **3.0.1** or later. - **`nl.nl-portal:documenten-api`** — the resolver now declares the authentication parameter, so the framework binds the authenticated user into the call path. Fix commit: `32e0ebdf` — "Add auth on DocumentContentQuery.kt". - **`nl.nl-portal:besluiten`** — the entire `besluiten` module is removed in 3.0.1. Consumers who rely on the besluiten functionality must implement a replacement at the application layer with explicit per-user authorization on every resolver before upgrading. Fix commit: `f592af1b` — "Removal of Besluiten API". ## Workarounds For deployments that cannot upgrade immediately: - Block the following GraphQL operations at the API gateway: `getDocumentContent`, `getBesluiten`, `getBesluit`, `getBesluitAuditTrails`, `getBesluitAuditTrail`, `getBesluitDocumenten`, `getBesluitDocument`. - If per-operation blocking is not possible, block the `besluiten` module's GraphQL types entirely and block the document-content query. ## Technical details - `nl.nlportal.documentenapi.graphql.DocumentContentQuery.getDocumentContent(documentApi, id)` did not declare a `CommonGroundAuthentication` parameter on the resolver. The authenticated principal was therefore not bound into the call path and document content could be retrieved without the resolver participating in user-scoped authorization. Patched by adding `authentication: CommonGroundAuthentication` to the resolver signature, so Spring's argument resolution rejects unauthenticated invocations of the query. - `nl.nlportal.besluiten.graphql.BesluitenQuery` exposed six GraphQL operations — `getBesluiten`, `getBesluit`, `getBesluitAuditTrails`, `getBesluitAuditTrail`, `getBesluitDocumenten`, `getBesluitDocument` — none of which declared a `CommonGroundAuthentication` parameter. In particular, `getBesluiten` accepted filter arguments (`besluitType`, `identificatie`, `verantwoordelijkeOrganisatie`, `zaak`, `pageNumber`) but performed no user scoping, allowing callers to enumerate besluit records across users. The point-lookup operations (`getBesluit`, `getBesluitAuditTrail`, `getBesluitDocument`) returned data for any UUID without ownership checks. The fix is the removal of `BesluitenQuery`, `BesluitenAutoConfiguration`, and the integration test, and the autoconfiguration entry has been unwired from the application defaults. ## Credits Discovered during the nl-portal-backend-libraries penetration testing engagement (phase 1, May 2026). Vendor attribution to be added before publication.
## Impact In versions up to and including 3.0.0, two parts of the GraphQL API returned data without checking whether the data belonged to the logged-in user: - **Document content.** A logged-in user could download the raw content of any document by its ID, regardless of who owned it. The resolver has lacked an authentication parameter since the initial commit of the project (2022-11-22) — so every version of `nl.nl-portal:documenten-api` ever published is affected (the earliest one on Maven Central is `0.2.2.RELEASE`, published 2023-08-31). - **Decisions (`besluiten`).** A logged-in user could list, search, and read decision records — including their audit trails and the documents attached to them — for any user. The list query also accepted filters (decision type, identification, responsible organisation, related case), which made it easy to enumerate decisions across the user base. The `besluiten` module was introduced in the `1.5.x` release line (commit `9229460b`, 2024-08-19), so versions of `nl.nl-portal:besluiten` from `1.5.0` through `3.0.0` are affected. Decisions and their attachments often contain sensitive personal data (decisions on benefits, permits, objections, and similar), so the confidentiality impact is high. The two endpoints also chain naturally: once an attacker has discovered another user's document IDs by enumerating decisions, they can pull those documents' contents through the document endpoint. ### Why these two findings are reported together They share the same root cause and the same shape. Both GraphQL resolvers were declared without an authentication parameter on the method signature, which meant the framework never bound the authenticated user into the resolver and the resolver therefore could not perform per-user authorization checks. The fix pattern is the same — bind the authenticated principal into the resolver, or remove the resolver entirely. And in practice the two endpoints reinforce each other as a chain (enumerate via decisions, exfiltrate via documents), so they describe a single end-to-end weakness in the GraphQL surface. ## Patches Upgrade to **3.0.1** or later. - **`nl.nl-portal:documenten-api`** — the resolver now declares the authentication parameter, so the framework binds the authenticated user into the call path. Fix commit: `32e0ebdf` — "Add auth on DocumentContentQuery.kt". - **`nl.nl-portal:besluiten`** — the entire `besluiten` module is removed in 3.0.1. Consumers who rely on the besluiten functionality must implement a replacement at the application layer with explicit per-user authorization on every resolver before upgrading. Fix commit: `f592af1b` — "Removal of Besluiten API". ## Workarounds For deployments that cannot upgrade immediately: - Block the following GraphQL operations at the API gateway: `getDocumentContent`, `getBesluiten`, `getBesluit`, `getBesluitAuditTrails`, `getBesluitAuditTrail`, `getBesluitDocumenten`, `getBesluitDocument`. - If per-operation blocking is not possible, block the `besluiten` module's GraphQL types entirely and block the document-content query. ## Technical details - `nl.nlportal.documentenapi.graphql.DocumentContentQuery.getDocumentContent(documentApi, id)` did not declare a `CommonGroundAuthentication` parameter on the resolver. The authenticated principal was therefore not bound into the call path and document content could be retrieved without the resolver participating in user-scoped authorization. Patched by adding `authentication: CommonGroundAuthentication` to the resolver signature, so Spring's argument resolution rejects unauthenticated invocations of the query. - `nl.nlportal.besluiten.graphql.BesluitenQuery` exposed six GraphQL operations — `getBesluiten`, `getBesluit`, `getBesluitAuditTrails`, `getBesluitAuditTrail`, `getBesluitDocumenten`, `getBesluitDocument` — none of which declared a `CommonGroundAuthentication` parameter. In particular, `getBesluiten` accepted filter arguments (`besluitType`, `identificatie`, `verantwoordelijkeOrganisatie`, `zaak`, `pageNumber`) but performed no user scoping, allowing callers to enumerate besluit records across users. The point-lookup operations (`getBesluit`, `getBesluitAuditTrail`, `getBesluitDocument`) returned data for any UUID without ownership checks. The fix is the removal of `BesluitenQuery`, `BesluitenAutoConfiguration`, and the integration test, and the autoconfiguration entry has been unwired from the application defaults. ## Credits Discovered during the nl-portal-backend-libraries penetration testing engagement (phase 1, May 2026). Vendor attribution to be added before publication.
## Impact In versions up to and including 3.0.0, two parts of the GraphQL API returned data without checking whether the data belonged to the logged-in user: - **Document content.** A logged-in user could download the raw content of any document by its ID, regardless of who owned it. The resolver has lacked an authentication parameter since the initial commit of the project (2022-11-22) — so every version of `nl.nl-portal:documenten-api` ever published is affected (the earliest one on Maven Central is `0.2.2.RELEASE`, published 2023-08-31). - **Decisions (`besluiten`).** A logged-in user could list, search, and read decision records — including their audit trails and the documents attached to them — for any user. The list query also accepted filters (decision type, identification, responsible organisation, related case), which made it easy to enumerate decisions across the user base. The `besluiten` module was introduced in the `1.5.x` release line (commit `9229460b`, 2024-08-19), so versions of `nl.nl-portal:besluiten` from `1.5.0` through `3.0.0` are affected. Decisions and their attachments often contain sensitive personal data (decisions on benefits, permits, objections, and similar), so the confidentiality impact is high. The two endpoints also chain naturally: once an attacker has discovered another user's document IDs by enumerating decisions, they can pull those documents' contents through the document endpoint. ### Why these two findings are reported together They share the same root cause and the same shape. Both GraphQL resolvers were declared without an authentication parameter on the method signature, which meant the framework never bound the authenticated user into the resolver and the resolver therefore could not perform per-user authorization checks. The fix pattern is the same — bind the authenticated principal into the resolver, or remove the resolver entirely. And in practice the two endpoints reinforce each other as a chain (enumerate via decisions, exfiltrate via documents), so they describe a single end-to-end weakness in the GraphQL surface. ## Patches Upgrade to **3.0.1** or later. - **`nl.nl-portal:documenten-api`** — the resolver now declares the authentication parameter, so the framework binds the authenticated user into the call path. Fix commit: `32e0ebdf` — "Add auth on DocumentContentQuery.kt". - **`nl.nl-portal:besluiten`** — the entire `besluiten` module is removed in 3.0.1. Consumers who rely on the besluiten functionality must implement a replacement at the application layer with explicit per-user authorization on every resolver before upgrading. Fix commit: `f592af1b` — "Removal of Besluiten API". ## Workarounds For deployments that cannot upgrade immediately: - Block the following GraphQL operations at the API gateway: `getDocumentContent`, `getBesluiten`, `getBesluit`, `getBesluitAuditTrails`, `getBesluitAuditTrail`, `getBesluitDocumenten`, `getBesluitDocument`. - If per-operation blocking is not possible, block the `besluiten` module's GraphQL types entirely and block the document-content query. ## Technical details - `nl.nlportal.documentenapi.graphql.DocumentContentQuery.getDocumentContent(documentApi, id)` did not declare a `CommonGroundAuthentication` parameter on the resolver. The authenticated principal was therefore not bound into the call path and document content could be retrieved without the resolver participating in user-scoped authorization. Patched by adding `authentication: CommonGroundAuthentication` to the resolver signature, so Spring's argument resolution rejects unauthenticated invocations of the query. - `nl.nlportal.besluiten.graphql.BesluitenQuery` exposed six GraphQL operations — `getBesluiten`, `getBesluit`, `getBesluitAuditTrails`, `getBesluitAuditTrail`, `getBesluitDocumenten`, `getBesluitDocument` — none of which declared a `CommonGroundAuthentication` parameter. In particular, `getBesluiten` accepted filter arguments (`besluitType`, `identificatie`, `verantwoordelijkeOrganisatie`, `zaak`, `pageNumber`) but performed no user scoping, allowing callers to enumerate besluit records across users. The point-lookup operations (`getBesluit`, `getBesluitAuditTrail`, `getBesluitDocument`) returned data for any UUID without ownership checks. The fix is the removal of `BesluitenQuery`, `BesluitenAutoConfiguration`, and the integration test, and the autoconfiguration entry has been unwired from the application defaults. ## Credits Discovered during the nl-portal-backend-libraries penetration testing engagement (phase 1, May 2026). Vendor attribution to be added before publication.
## Impact In versions up to and including 3.0.0, two parts of the GraphQL API returned data without checking whether the data belonged to the logged-in user: - **Document content.** A logged-in user could download the raw content of any document by its ID, regardless of who owned it. The resolver has lacked an authentication parameter since the initial commit of the project (2022-11-22) — so every version of `nl.nl-portal:documenten-api` ever published is affected (the earliest one on Maven Central is `0.2.2.RELEASE`, published 2023-08-31). - **Decisions (`besluiten`).** A logged-in user could list, search, and read decision records — including their audit trails and the documents attached to them — for any user. The list query also accepted filters (decision type, identification, responsible organisation, related case), which made it easy to enumerate decisions across the user base. The `besluiten` module was introduced in the `1.5.x` release line (commit `9229460b`, 2024-08-19), so versions of `nl.nl-portal:besluiten` from `1.5.0` through `3.0.0` are affected. Decisions and their attachments often contain sensitive personal data (decisions on benefits, permits, objections, and similar), so the confidentiality impact is high. The two endpoints also chain naturally: once an attacker has discovered another user's document IDs by enumerating decisions, they can pull those documents' contents through the document endpoint. ### Why these two findings are reported together They share the same root cause and the same shape. Both GraphQL resolvers were declared without an authentication parameter on the method signature, which meant the framework never bound the authenticated user into the resolver and the resolver therefore could not perform per-user authorization checks. The fix pattern is the same — bind the authenticated principal into the resolver, or remove the resolver entirely. And in practice the two endpoints reinforce each other as a chain (enumerate via decisions, exfiltrate via documents), so they describe a single end-to-end weakness in the GraphQL surface. ## Patches Upgrade to **3.0.1** or later. - **`nl.nl-portal:documenten-api`** — the resolver now declares the authentication parameter, so the framework binds the authenticated user into the call path. Fix commit: `32e0ebdf` — "Add auth on DocumentContentQuery.kt". - **`nl.nl-portal:besluiten`** — the entire `besluiten` module is removed in 3.0.1. Consumers who rely on the besluiten functionality must implement a replacement at the application layer with explicit per-user authorization on every resolver before upgrading. Fix commit: `f592af1b` — "Removal of Besluiten API". ## Workarounds For deployments that cannot upgrade immediately: - Block the following GraphQL operations at the API gateway: `getDocumentContent`, `getBesluiten`, `getBesluit`, `getBesluitAuditTrails`, `getBesluitAuditTrail`, `getBesluitDocumenten`, `getBesluitDocument`. - If per-operation blocking is not possible, block the `besluiten` module's GraphQL types entirely and block the document-content query. ## Technical details - `nl.nlportal.documentenapi.graphql.DocumentContentQuery.getDocumentContent(documentApi, id)` did not declare a `CommonGroundAuthentication` parameter on the resolver. The authenticated principal was therefore not bound into the call path and document content could be retrieved without the resolver participating in user-scoped authorization. Patched by adding `authentication: CommonGroundAuthentication` to the resolver signature, so Spring's argument resolution rejects unauthenticated invocations of the query. - `nl.nlportal.besluiten.graphql.BesluitenQuery` exposed six GraphQL operations — `getBesluiten`, `getBesluit`, `getBesluitAuditTrails`, `getBesluitAuditTrail`, `getBesluitDocumenten`, `getBesluitDocument` — none of which declared a `CommonGroundAuthentication` parameter. In particular, `getBesluiten` accepted filter arguments (`besluitType`, `identificatie`, `verantwoordelijkeOrganisatie`, `zaak`, `pageNumber`) but performed no user scoping, allowing callers to enumerate besluit records across users. The point-lookup operations (`getBesluit`, `getBesluitAuditTrail`, `getBesluitDocument`) returned data for any UUID without ownership checks. The fix is the removal of `BesluitenQuery`, `BesluitenAutoConfiguration`, and the integration test, and the autoconfiguration entry has been unwired from the application defaults. ## Credits Discovered during the nl-portal-backend-libraries penetration testing engagement (phase 1, May 2026). Vendor attribution to be added before publication.
Update nl.nl-portal:besluiten to 3.0.1; nl.nl-portal:documenten-api to 3.0.1 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanNL Portal: Missing per-user authorization on document and decision GraphQL queries in nl-portal-backend-libraries affects nl.nl-portal:besluiten (maven), nl.nl-portal:documenten-api (maven). Severity is medium. ## Impact In versions up to and including 3.0.0, two parts of the GraphQL API returned data without checking whether the data belonged to the logged-in user: - **Document content.** A logged-in user could download the raw content of any document by its ID, regardless of who owned it. The resolver has lacked an authentication parameter since the initial commit of the project (2022-11-22) — so every version of `nl.nl-portal:documenten-api` ever published is affected (the earliest one on Maven Central is `0.2.2.RELEASE`, published 2023-08-31). - **Decisions (`besluiten`).** A logged-in user could list, search, and read decision records — including their audit trails and the documents attached to them — for any user. The list query also accepted filters (decision type, identification, responsible organisation, related case), which made it easy to enumerate decisions across the user base. The `besluiten` module was introduced in the `1.5.x` release line (commit `9229460b`, 2024-08-19), so versions of `nl.nl-portal:besluiten` from `1.5.0` through `3.0.0` are affected. Decisions and their attachments often contain sensitive personal data (decisions on benefits, permits, objections, and similar), so the confidentiality impact is high. The two endpoints also chain naturally: once an attacker has discovered another user's document IDs by enumerating decisions, they can pull those documents' contents through the document endpoint. ### Why these two findings are reported together They share the same root cause and the same shape. Both GraphQL resolvers were declared without an authentication parameter on the method signature, which meant the framework never bound the authenticated user into the resolver and the resolver therefore could not perform per-user authorization checks. The fix pattern is the same — bind the authenticated principal into the resolver, or remove the resolver entirely. And in practice the two endpoints reinforce each other as a chain (enumerate via decisions, exfiltrate via documents), so they describe a single end-to-end weakness in the GraphQL surface. ## Patches Upgrade to **3.0.1** or later. - **`nl.nl-portal:documenten-api`** — the resolver now declares the authentication parameter, so the framework binds the authenticated user into the call path. Fix commit: `32e0ebdf` — "Add auth on DocumentContentQuery.kt". - **`nl.nl-portal:besluiten`** — the entire `besluiten` module is removed in 3.0.1. Consumers who rely on the besluiten functionality must implement a replacement at the application layer with explicit per-user authorization on every resolver before upgrading. Fix commit: `f592af1b` — "Removal of Besluiten API". ## Workarounds For deployments that cannot upgrade immediately: - Block the following GraphQL operations at the API gateway: `getDocumentContent`, `getBesluiten`, `getBesluit`, `getBesluitAuditTrails`, `getBesluitAuditTrail`, `getBesluitDocumenten`, `getBesluitDocument`. - If per-operation blocking is not possible, block the `besluiten` module's GraphQL types entirely and block the document-content query. ## Technical details - `nl.nlportal.documentenapi.graphql.DocumentContentQuery.getDocumentContent(documentApi, id)` did not declare a `CommonGroundAuthentication` parameter on the resolver. The authenticated principal was therefore not bound into the call path and document content could be retrieved without the resolver participating in user-scoped authorization. Patched by adding `authentication: CommonGroundAuthentication` to the resolver signature, so Spring's argument resolution rejects unauthenticated invocations of the query. - `nl.nlportal.besluiten.graphql.BesluitenQuery` exposed six GraphQL operations — `getBesluiten`, `getBesluit`, `getBesluitAuditTrails`, `getBesluitAuditTrail`, `getBesluitDocumenten`, `getBesluitDocument` — none of which declared a `CommonGroundAuthentication` parameter. In particular, `getBesluiten` accepted filter arguments (`besluitType`, `identificatie`, `verantwoordelijkeOrganisatie`, `zaak`, `pageNumber`) but performed no user scoping, allowing callers to enumerate besluit records across users. The point-lookup operations (`getBesluit`, `getBesluitAuditTrail`, `getBesluitDocument`) returned data for any UUID without ownership checks. The fix is the removal of `BesluitenQuery`, `BesluitenAutoConfiguration`, and the integration test, and the autoconfiguration entry has been unwired from the application defaults. ## Credits Discovered during the nl-portal-backend-libraries penetration testing engagement (phase 1, May 2026). Vendor attribution to be added before publication.
AI coding agents often install or upgrade packages automatically in maven. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| nl.nl-portal:besluitenmaven | >=1.5.0,<=3.0.0 | 3.0.1 |
| nl.nl-portal:documenten-apimaven | <=3.0.0 | 3.0.1 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate nl.nl-portal:besluiten to 3.0.1; nl.nl-portal:documenten-api to 3.0.1 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanNL Portal: Missing per-user authorization on document and decision GraphQL queries in nl-portal-backend-libraries affects nl.nl-portal:besluiten (maven), nl.nl-portal:documenten-api (maven). Severity is medium. ## Impact In versions up to and including 3.0.0, two parts of the GraphQL API returned data without checking whether the data belonged to the logged-in user: - **Document content.** A logged-in user could download the raw content of any document by its ID, regardless of who owned it. The resolver has lacked an authentication parameter since the initial commit of the project (2022-11-22) — so every version of `nl.nl-portal:documenten-api` ever published is affected (the earliest one on Maven Central is `0.2.2.RELEASE`, published 2023-08-31). - **Decisions (`besluiten`).** A logged-in user could list, search, and read decision records — including their audit trails and the documents attached to them — for any user. The list query also accepted filters (decision type, identification, responsible organisation, related case), which made it easy to enumerate decisions across the user base. The `besluiten` module was introduced in the `1.5.x` release line (commit `9229460b`, 2024-08-19), so versions of `nl.nl-portal:besluiten` from `1.5.0` through `3.0.0` are affected. Decisions and their attachments often contain sensitive personal data (decisions on benefits, permits, objections, and similar), so the confidentiality impact is high. The two endpoints also chain naturally: once an attacker has discovered another user's document IDs by enumerating decisions, they can pull those documents' contents through the document endpoint. ### Why these two findings are reported together They share the same root cause and the same shape. Both GraphQL resolvers were declared without an authentication parameter on the method signature, which meant the framework never bound the authenticated user into the resolver and the resolver therefore could not perform per-user authorization checks. The fix pattern is the same — bind the authenticated principal into the resolver, or remove the resolver entirely. And in practice the two endpoints reinforce each other as a chain (enumerate via decisions, exfiltrate via documents), so they describe a single end-to-end weakness in the GraphQL surface. ## Patches Upgrade to **3.0.1** or later. - **`nl.nl-portal:documenten-api`** — the resolver now declares the authentication parameter, so the framework binds the authenticated user into the call path. Fix commit: `32e0ebdf` — "Add auth on DocumentContentQuery.kt". - **`nl.nl-portal:besluiten`** — the entire `besluiten` module is removed in 3.0.1. Consumers who rely on the besluiten functionality must implement a replacement at the application layer with explicit per-user authorization on every resolver before upgrading. Fix commit: `f592af1b` — "Removal of Besluiten API". ## Workarounds For deployments that cannot upgrade immediately: - Block the following GraphQL operations at the API gateway: `getDocumentContent`, `getBesluiten`, `getBesluit`, `getBesluitAuditTrails`, `getBesluitAuditTrail`, `getBesluitDocumenten`, `getBesluitDocument`. - If per-operation blocking is not possible, block the `besluiten` module's GraphQL types entirely and block the document-content query. ## Technical details - `nl.nlportal.documentenapi.graphql.DocumentContentQuery.getDocumentContent(documentApi, id)` did not declare a `CommonGroundAuthentication` parameter on the resolver. The authenticated principal was therefore not bound into the call path and document content could be retrieved without the resolver participating in user-scoped authorization. Patched by adding `authentication: CommonGroundAuthentication` to the resolver signature, so Spring's argument resolution rejects unauthenticated invocations of the query. - `nl.nlportal.besluiten.graphql.BesluitenQuery` exposed six GraphQL operations — `getBesluiten`, `getBesluit`, `getBesluitAuditTrails`, `getBesluitAuditTrail`, `getBesluitDocumenten`, `getBesluitDocument` — none of which declared a `CommonGroundAuthentication` parameter. In particular, `getBesluiten` accepted filter arguments (`besluitType`, `identificatie`, `verantwoordelijkeOrganisatie`, `zaak`, `pageNumber`) but performed no user scoping, allowing callers to enumerate besluit records across users. The point-lookup operations (`getBesluit`, `getBesluitAuditTrail`, `getBesluitDocument`) returned data for any UUID without ownership checks. The fix is the removal of `BesluitenQuery`, `BesluitenAutoConfiguration`, and the integration test, and the autoconfiguration entry has been unwired from the application defaults. ## Credits Discovered during the nl-portal-backend-libraries penetration testing engagement (phase 1, May 2026). Vendor attribution to be added before publication.
AI coding agents often install or upgrade packages automatically in maven. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| nl.nl-portal:besluitenmaven | >=1.5.0,<=3.0.0 | 3.0.1 |
| nl.nl-portal:documenten-apimaven | <=3.0.0 | 3.0.1 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard