<?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>Thu, 22 Oct 2026 20:55:01 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-112951</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-112951</link>
      <description>&lt;p&gt;ApostropheCMS is an open-source Node.js content management system. Prior to 4.34.0, the color field accepts trailing content after a valid rgb() or hsl() prefix because its TinyColor validation does not require the entire value to match a color. An authenticated user with edit rights can store arbitrary HTML after a valid color prefix. When the stored value is rendered, the payload executes, resulting in stored XSS. This issue is fixed in version 4.34.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;ApostropheCMS is an open-source Node.js content management system. Prior to 4.34.0, the color field accepts trailing content after a valid rgb() or hsl() prefix because its TinyColor validation does not require the entire value to match a color. An authenticated user with edit rights can store arbitrary HTML after a valid color prefix. When the stored value is rendered, the payload executes, resulting in stored XSS. This issue is fixed in version 4.34.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-112951</guid>
    </item>
    <item>
      <title>GHSA-vmgj-9cwm-cf3h — ApostropheCMS: Color field validation bypass allows stored XSS via HTML appended after rgb()/hsl() prefix</title>
      <link>https://db.gcve.eu/vuln/ghsa-vmgj-9cwm-cf3h</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: apostrophe&lt;/p&gt;
&lt;p&gt;### Summary
The color field accepts any string that *begins* with a valid `rgb()` / `hsl()` color, because `TinyColor.isValid` does not anchor its match at the end of the string. An authenticated user with edit rights can store arbitrary HTML after a valid color prefix. When the stored value is rendered , the payload executes, resulting in stored XSS.&lt;/p&gt;
&lt;p&gt;### Details
Server-side validation of the color field relies on TinyColor:&lt;/p&gt;
&lt;p&gt;```js
const { TinyColor } = require(&amp;#39;@ctrl/tinycolor&amp;#39;);
if (!new TinyColor(value).isValid) throw self.apos.error(&amp;#39;invalid&amp;#39;);
```&lt;/p&gt;
&lt;p&gt;TinyColor&amp;#39;s `rgb`/`hsl` matchers are not anchored at the end of the string, while hex matchers are. Tested with @ctrl/tinycolor&lt;/p&gt;
&lt;p&gt;| Input | `isValid` |
|---|---|
| `rgb(1,2,3)&amp;lt;img src=x onerror=alert(1)&amp;gt;` | `true` |
| `rgb(1,2,3)&amp;lt;/textarea&amp;gt;&amp;lt;script&amp;gt;alert(1)&amp;lt;/script&amp;gt;` | `true` |
| `hsl(0,100%,50%);--x:1}&amp;lt;/style&amp;gt;&amp;lt;script&amp;gt;alert(1)&amp;lt;/script&amp;gt;` | `true` |
| `#ff0000&amp;lt;img src=x onerror=alert(1)&amp;gt;` | `false` |&lt;/p&gt;
&lt;p&gt;The value is saved to MongoDB unchanged (not normalized to hex8).&lt;/p&gt;
&lt;p&gt;### Relation to GHSA-97v6-998m-fp4g
GHSA-97v6 addressed CSS custom property injection escaping a `&amp;lt;style&amp;gt;` context. The root cause (validation that accepts trailing content after a valid color) still exists in &amp;lt;= 4.32.2, so [FILL IN: either &amp;#34;the style-tag sink remains exploitable via `&amp;lt;/style&amp;gt;`&amp;#34; OR &amp;#34;a separate HTML sink at X is exploitable&amp;#34;]. Fixing the validation (requiring the full string to be a color, or storing only TinyColor&amp;#39;s normalized output) would close bo…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: apostrophe&lt;/p&gt;
&lt;p&gt;### Summary
The color field accepts any string that *begins* with a valid `rgb()` / `hsl()` color, because `TinyColor.isValid` does not anchor its match at the end of the string. An authenticated user with edit rights can store arbitrary HTML after a valid color prefix. When the stored value is rendered , the payload executes, resulting in stored XSS.&lt;/p&gt;
&lt;p&gt;### Details
Server-side validation of the color field relies on TinyColor:&lt;/p&gt;
&lt;p&gt;```js
const { TinyColor } = require(&amp;#39;@ctrl/tinycolor&amp;#39;);
if (!new TinyColor(value).isValid) throw self.apos.error(&amp;#39;invalid&amp;#39;);
```&lt;/p&gt;
&lt;p&gt;TinyColor&amp;#39;s `rgb`/`hsl` matchers are not anchored at the end of the string, while hex matchers are. Tested with @ctrl/tinycolor&lt;/p&gt;
&lt;p&gt;| Input | `isValid` |
|---|---|
| `rgb(1,2,3)&amp;lt;img src=x onerror=alert(1)&amp;gt;` | `true` |
| `rgb(1,2,3)&amp;lt;/textarea&amp;gt;&amp;lt;script&amp;gt;alert(1)&amp;lt;/script&amp;gt;` | `true` |
| `hsl(0,100%,50%);--x:1}&amp;lt;/style&amp;gt;&amp;lt;script&amp;gt;alert(1)&amp;lt;/script&amp;gt;` | `true` |
| `#ff0000&amp;lt;img src=x onerror=alert(1)&amp;gt;` | `false` |&lt;/p&gt;
&lt;p&gt;The value is saved to MongoDB unchanged (not normalized to hex8).&lt;/p&gt;
&lt;p&gt;### Relation to GHSA-97v6-998m-fp4g
GHSA-97v6 addressed CSS custom property injection escaping a `&amp;lt;style&amp;gt;` context. The root cause (validation that accepts trailing content after a valid color) still exists in &amp;lt;= 4.32.2, so [FILL IN: either &amp;#34;the style-tag sink remains exploitable via `&amp;lt;/style&amp;gt;`&amp;#34; OR &amp;#34;a separate HTML sink at X is exploitable&amp;#34;]. Fixing the validation (requiring the full string to be a color, or storing only TinyColor&amp;#39;s normalized output) would close bo…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-vmgj-9cwm-cf3h</guid>
    </item>
  </channel>
</rss>
