<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-22T22:02:38.281537+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-113653</id>
    <title>fkie_cve-2026-113653</title>
    <updated>2026-10-22T22:02:38.305300+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>ApostropheCMS is an open-source Node.js content management system. Prior to 4.33.0, viewRole is not applied to anonymous visitors when a developer exposes user objects through a publicly rendered relationship or expressly enabled public API. Inadequately limited templates, including serialization of an entire related user object, can conditionally disclose user fields, but relationships do not automatically publish full user objects and password hashes are stored separately and are not affected. This issue is fixed in version 4.33.0.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-113653"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-xf6w-q65w-4f2w</id>
    <title>GHSA-xf6w-q65w-4f2w — ApostropheCMS: The general public can access @apostrophecms/user objects via a relationship (viewRole is not applied to…</title>
    <updated>2026-10-22T22:02:38.305396+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: apostrophe</p>
<p>### Impact
Even though it is correctly applied to guests, contributors, etc., `viewRole` is not applied to the general public. This means that a secured content type like `@apostrophecms/user` can in theory be accessed.</p>
<p>This is greatly mitigated by the fact that there is no automatic public REST API for any content type. One has to expressly allow it. However, it does mean that developers can make the mistake of setting up a relationship between a content type like a blog post, and `@apostrophecms/user`. This could potentially expose some sensitive information if templates were written poorly, e.g. if they JSON-serialized the entire object. Note that password hashes are NOT affected because they reside in a separate collection.</p>
<p>The public demo project and its various flavors must be updated first because it inadvertently relies on the bug.</p>
<p>### Patches
4.33.0</p>
<p>### Workarounds
Never create relationships with `@apostrophecms/user` that are intended for non-admin display. If you need a relationship that expresses authorship, create a separate author piece type to publicly represent that.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-xf6w-q65w-4f2w"/>
  </entry>
</feed>
