<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 20 Oct 2026 18:15:23 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-54683</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-54683</link>
      <description>&lt;p&gt;NL Portal Backend Libraries provide backend components for Dutch government portals that interact with residents, customers, suppliers, and partner organizations. Prior to 3.0.3, both the getDocumentContent GraphQL query and GET /api/documentapi/{documentapi}/document/{documentId}/content REST route allow any authenticated portal user to retrieve a document without checking ownership of or another authorized relationship to it. A user with a valid login and another person&amp;#39;s document identifier can read that document&amp;#39;s contents, which may include sensitive personal information. Document identifiers are random and difficult to guess, but they can leak through other channels. This issue is fixed in version 3.0.3.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;NL Portal Backend Libraries provide backend components for Dutch government portals that interact with residents, customers, suppliers, and partner organizations. Prior to 3.0.3, both the getDocumentContent GraphQL query and GET /api/documentapi/{documentapi}/document/{documentId}/content REST route allow any authenticated portal user to retrieve a document without checking ownership of or another authorized relationship to it. A user with a valid login and another person&amp;#39;s document identifier can read that document&amp;#39;s contents, which may include sensitive personal information. Document identifiers are random and difficult to guess, but they can leak through other channels. This issue is fixed in version 3.0.3.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-54683</guid>
    </item>
    <item>
      <title>GHSA-jr45-52cw-69h5 — NL Portal Backend Libraries: Document contents remained downloadable by any logged-in user (incomplete fix of CVE-2026-…</title>
      <link>https://db.gcve.eu/vuln/ghsa-jr45-52cw-69h5</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: nl.nl-portal:documenten-api&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;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**.&lt;/p&gt;
&lt;p&gt;## Relationship to CVE-2026-49463&lt;/p&gt;
&lt;p&gt;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:&lt;/p&gt;
&lt;p&gt;- 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.&lt;/p&gt;
&lt;p&gt;Both were removed in 3.0.3, which is the first release where the document-content issue is actually fixed.&lt;/p&gt;
&lt;p&gt;## What was wrong&lt;/p&gt;
&lt;p&gt;A document&amp;#39;s contents could be fetched in two ways, and neither verified the caller&amp;#39;s relationship to the document:&lt;/p&gt;
&lt;p&gt;- a REST endpoint: `GET /api/documentapi/{documentapi}/document/{documentId}/content`
- a GraphQL query: `getDocumentContent`&lt;/p&gt;
&lt;p&gt;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…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: nl.nl-portal:documenten-api&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;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**.&lt;/p&gt;
&lt;p&gt;## Relationship to CVE-2026-49463&lt;/p&gt;
&lt;p&gt;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:&lt;/p&gt;
&lt;p&gt;- 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.&lt;/p&gt;
&lt;p&gt;Both were removed in 3.0.3, which is the first release where the document-content issue is actually fixed.&lt;/p&gt;
&lt;p&gt;## What was wrong&lt;/p&gt;
&lt;p&gt;A document&amp;#39;s contents could be fetched in two ways, and neither verified the caller&amp;#39;s relationship to the document:&lt;/p&gt;
&lt;p&gt;- a REST endpoint: `GET /api/documentapi/{documentapi}/document/{documentId}/content`
- a GraphQL query: `getDocumentContent`&lt;/p&gt;
&lt;p&gt;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…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-jr45-52cw-69h5</guid>
    </item>
  </channel>
</rss>
