<?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>Wed, 21 Oct 2026 06:34:24 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-113662</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-113662</link>
      <description>&lt;p&gt;ApostropheCMS is an open-source Node.js content management system. Prior to 3.7.0 of the import-export module, an authenticated user with import access to a target type can supply an object or operator as an update-key value, causing the import query to match an unidentified existing document that the user has generic edit permission to modify. The normal findForEditing permission filter still limits the candidate documents, so the issue does not permit permission-free overwrite of arbitrary protected content. This issue is fixed in version 3.7.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;ApostropheCMS is an open-source Node.js content management system. Prior to 3.7.0 of the import-export module, an authenticated user with import access to a target type can supply an object or operator as an update-key value, causing the import query to match an unidentified existing document that the user has generic edit permission to modify. The normal findForEditing permission filter still limits the candidate documents, so the issue does not permit permission-free overwrite of arbitrary protected content. This issue is fixed in version 3.7.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-113662</guid>
    </item>
    <item>
      <title>GHSA-jqw5-w6h3-44g6 — ApostropheCMS import-export: NoSQL injection via update-key value lets a crafted import match and overwrite an unidenti…</title>
      <link>https://db.gcve.eu/vuln/ghsa-jqw5-w6h3-44g6</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @apostrophecms/import-export&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`@apostrophecms/import-export`&amp;#39;s update-by-key feature lets an imported
document carry a `&amp;lt;field&amp;gt;:key` property (for example `slug:key`) whose
value is used to find an existing document to update instead of inserting
a new one. `getUpdateKey()`/`insertOrUpdateDocWithKey()`
(`lib/methods/import.js`) use that value directly as a MongoDB query value
with no laundering:&lt;/p&gt;
&lt;p&gt;```js
const matchingDraftPromise = manager.findForEditing(
  req.clone({ mode: &amp;#39;draft&amp;#39; }),
  {
    aposMode: &amp;#39;draft&amp;#39;,
    [updateField]: doc[updateKey]
  }).toObject();
```&lt;/p&gt;
&lt;p&gt;Archive documents are parsed with EJSON (see `lib/formats/gzip.js`), which
revives objects such as `{ $ne: null }` as live values, the same untrusted
data source and revival mechanism already fixed once in this module for
`findSingletonAposDocId`/`findParkedAposDocId` in GHSA-79qf-vqgc-7xx3. That
fix did not touch `insertOrUpdateDocWithKey`, so the identical class of bug
survives here: a crafted `&amp;#34;slug:key&amp;#34;: { &amp;#34;$ne&amp;#34;: null }` entry in an
archive&amp;#39;s `aposDocs.json` makes the import match (and then update) an
existing document the archive&amp;#39;s author never actually identified, instead
of failing to find a match.&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;Reaching this requires only an authenticated session with import access to
the target type (the built-in contributor role holds this, matching the
precondition of GHSA-79qf-vqgc-7xx3), and no admin interaction. Because the
match uses a MongoDB operator instead of an exact value, it is not limited
to a document the im…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @apostrophecms/import-export&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`@apostrophecms/import-export`&amp;#39;s update-by-key feature lets an imported
document carry a `&amp;lt;field&amp;gt;:key` property (for example `slug:key`) whose
value is used to find an existing document to update instead of inserting
a new one. `getUpdateKey()`/`insertOrUpdateDocWithKey()`
(`lib/methods/import.js`) use that value directly as a MongoDB query value
with no laundering:&lt;/p&gt;
&lt;p&gt;```js
const matchingDraftPromise = manager.findForEditing(
  req.clone({ mode: &amp;#39;draft&amp;#39; }),
  {
    aposMode: &amp;#39;draft&amp;#39;,
    [updateField]: doc[updateKey]
  }).toObject();
```&lt;/p&gt;
&lt;p&gt;Archive documents are parsed with EJSON (see `lib/formats/gzip.js`), which
revives objects such as `{ $ne: null }` as live values, the same untrusted
data source and revival mechanism already fixed once in this module for
`findSingletonAposDocId`/`findParkedAposDocId` in GHSA-79qf-vqgc-7xx3. That
fix did not touch `insertOrUpdateDocWithKey`, so the identical class of bug
survives here: a crafted `&amp;#34;slug:key&amp;#34;: { &amp;#34;$ne&amp;#34;: null }` entry in an
archive&amp;#39;s `aposDocs.json` makes the import match (and then update) an
existing document the archive&amp;#39;s author never actually identified, instead
of failing to find a match.&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;Reaching this requires only an authenticated session with import access to
the target type (the built-in contributor role holds this, matching the
precondition of GHSA-79qf-vqgc-7xx3), and no admin interaction. Because the
match uses a MongoDB operator instead of an exact value, it is not limited
to a document the im…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-jqw5-w6h3-44g6</guid>
    </item>
  </channel>
</rss>
