CVE-2026-112951: apostrophecms apostrophe · Cross-site Scripting
Affects apostrophecms apostropheSource CVE Database V5
Not known to be exploited · CVSS 5.4 Medium : upgrade to 4.34.0 when convenient.
Data as of 26 Oct 2026, 17:30 UTC
- EPSS
- 0.3% chance of exploitation in 30 days – higher than 22% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 4.34.0
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:NExploitation evidence
Disclosed: evidence found.
CVE published 20 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade apostrophe and apostrophecms/apostrophe to 4.34.0.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| apostrophecmsapostrophe | Affected
| Fixed in
|
GitHubapostrophecms/apostrophepkg:github/apostrophecms/apostropheOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
Upgrade ApostropheCMS to version 4.34.0 or later, where this vulnerability is fixed. No other mitigation is specified or required as the fix addresses the root cause in input validation.
Description
### 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. ### Details Server-side validation of the color field relies on TinyColor: ```js const { TinyColor } = require('@ctrl/tinycolor'); if (!new TinyColor(value).isValid) throw self.apos.error('invalid'); ``` TinyColor's `rgb`/`hsl` matchers are not anchored at the end of the string, while hex matchers are. Tested with @ctrl/tinycolor | Input | `isValid` | |---|---| | `rgb(1,2,3)<img src=x onerror=alert(1)>` | `true` | | `rgb(1,2,3)</textarea><script>alert(1)</script>` | `true` | | `hsl(0,100%,50%);--x:1}</style><script>alert(1)</script>` | `true` | | `#ff0000<img src=x onerror=alert(1)>` | `false` | The value is saved to MongoDB unchanged (not normalized to hex8). ### Relation to GHSA-97v6-998m-fp4g GHSA-97v6 addressed CSS custom property injection escaping a `<style>` context. The root cause (validation that accepts trailing content after a valid color) still exists in <= 4.32.2, so [FILL IN: either "the style-tag sink remains exploitable via `</style>`" OR "a separate HTML sink at X is exploitable"]. Fixing the validation (requiring the full string to be a color, or storing only TinyColor's normalized output) would close both. ### Impact Any user with edit permission can plant persistent JavaScript that runs in the browser of visitors and administrators viewing the affected page, enabling session hijacking and actions as an admin. ### Suggested fix Reject values unless the entire string is a valid color, e.g. normalize on save: ```js const c = new TinyColor(value); if (!c.isValid) throw self.apos.error('invalid'); value = c.toHex8String(); // store only normalized output ```
References
- github.com/apostrophecms/apostrophe/security/advisories/GHSA-vmgj-9cwm-cf3h (opens in a new tab)
- github.com/apostrophecms/apostrophe/commit/06e4b377f3c360f9e89c32dccd7e505ad5ddf498 (opens in a new tab)
- github.com/apostrophecms/apostrophe/commit/40b989b1a9dd23d30029b8ce7668634265cfe5ea (opens in a new tab)
- github.com/apostrophecms/apostrophe/releases/tag/apostrophe@4.34.0 (opens in a new tab)