GHSA-8rqh-vxpr-x77p
plone.restapi: Stored XSS by spoofing mime type
Impact
A stored XSS affecting RichText fields. RichTextValue.output returns the raw, unsanitized stored value whenever the stored mimeType equals the outputMimeType. Because the safe-HTML output type (text/x-html-safe) is the type that signifies "already sanitized", any value whose stored mimeType equals it bypasses the safe_html transform entirely on render. The transform itself is sound — it correctly strips on* event-handler attributes and javascript:/data: URIs; the defect is that it is never invoked for these values. The unsanitized value is then emitted via tal:content="structure ...", which performs no escaping, so the payload executes in the viewer's browser.
This can be a problem when a RichText field is wrongly defined in code with a mimeType and outputMimeType that are the same, or when the REST API is used to the same effect.
This is the same vulnerability as reported in plone.app.textfield:
https://github.com/plone/plone.app.textfield/security/advisories/GHSA-4r4f-gg25-rmg5
Patches
The problem has been patched:
- For Plone 6.0 and 6.2, upgrade
plone.restapito 9.15.6. - For Plone 6.2, upgrade
plone.restapito 10.0.1.
This will prevent abusing the REST API to store wrong rich text values.
This will not prevent XSS from rich text fields that already have wrong values. For that, you will need a patched plone.app.textfield version. See the plone.app.textfield advisory linked above for versions.
Workarounds
There is no known workaround.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- Low
- User interaction
- None
What an attacker can affect
- Confidentiality
- Low
- Integrity
- None
- Availability
- None
What each source reports
GitHub Advisories Score used 4.3
plone.restapi: Stored XSS by spoofing mime type
Impact
A stored XSS affecting RichText fields. RichTextValue.output returns the raw, unsanitized stored value whenever the stored mimeType equals the outputMimeType. Because the safe-HTML output type (text/x-html-safe) is the type that signifies "already sanitized", any value whose stored mimeType equals it bypasses the safe_html transform entirely on render. The transform itself is sound — it correctly strips on* event-handler attributes and javascript:/data: URIs; the defect is that it is never invoked for these values. The unsanitized value is then emitted via tal:content="structure ...", which performs no escaping, so the payload executes in the viewer's browser.
This can be a problem when a RichText field is wrongly defined in code with a mimeType and outputMimeType that are the same, or when the REST API is used to the same effect.
This is the same vulnerability as reported in plone.app.textfield:
https://github.com/plone/plone.app.textfield/security/advisories/GHSA-4r4f-gg25-rmg5
Patches
The problem has been patched:
- For Plone 6.0 and 6.2, upgrade
plone.restapito 9.15.6. - For Plone 6.2, upgrade
plone.restapito 10.0.1.
This will prevent abusing the REST API to store wrong rich text values.
This will not prevent XSS from rich text fields that already have wrong values. For that, you will need a patched plone.app.textfield version. See the plone.app.textfield advisory linked above for versions.
Workarounds
There is no known workaround.
- Record
GHSA-8rqh-vxpr-x77p- CVSS 3.1
- 4.3 Medium
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N - Weakness
- CWE-80
- Updated
- 2026-11-02
OSV 4.3
plone.restapi: Stored XSS by spoofing mime type
Impact
A stored XSS affecting RichText fields. RichTextValue.output returns the raw, unsanitized stored value whenever the stored mimeType equals the outputMimeType. Because the safe-HTML output type (text/x-html-safe) is the type that signifies "already sanitized", any value whose stored mimeType equals it bypasses the safe_html transform entirely on render. The transform itself is sound — it correctly strips on* event-handler attributes and javascript:/data: URIs; the defect is that it is never invoked for these values. The unsanitized value is then emitted via tal:content="structure ...", which performs no escaping, so the payload executes in the viewer's browser.
This can be a problem when a RichText field is wrongly defined in code with a mimeType and outputMimeType that are the same, or when the REST API is used to the same effect.
This is the same vulnerability as reported in plone.app.textfield:
https://github.com/plone/plone.app.textfield/security/advisories/GHSA-4r4f-gg25-rmg5
Patches
The problem has been patched:
- For Plone 6.0 and 6.2, upgrade
plone.restapito 9.15.6. - For Plone 6.2, upgrade
plone.restapito 10.0.1.
This will prevent abusing the REST API to store wrong rich text values.
This will not prevent XSS from rich text fields that already have wrong values. For that, you will need a patched plone.app.textfield version. See the plone.app.textfield advisory linked above for versions.
Workarounds
There is no known workaround.
- Record
GHSA-8rqh-vxpr-x77p- CVSS 3.1
- 4.3 Medium
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N - Weakness
- CWE-80
- Updated
- 2026-11-02
Affected packages
| Package | Affected | Fixed |
|---|---|---|
plone-restapiPyPI | before 9.15.6 | 9.15.6 |
plone-restapiPyPI | 10.0.0 to 10.0.0 | 10.0.1 |
plone-restapiPyPI | before 9.15.6, plus listed versions 1.0.01.0a11.0a101.0a111.0a12 Show 45 moreShow less1.0a131.0a141.0a151.0a161.0a171.0a181.0a191.0a21.0a201.0a211.0a221.0a231.0a241.0a251.0a31.0a41.0a51.0a61.0a71.0a81.0a91.0b11.1.01.2.01.3.01.3.11.4.01.4.11.5.01.6.02.0.02.0.12.1.02.2.02.2.13.0.03.1.03.2.03.2.13.2.23.3.03.4.03.4.13.4.23.4.3 | 9.15.6 |
plone-restapiPyPI | 10.0.0 up to 10.0.1 | 10.0.1 |
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | GitHub Advisories, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
GHSA-8rqh-vxpr-x77p is a medium vulnerability (CVSS 4.3) in plone-restapi, published July 17, 2026. No source lists public exploit code. Fixed in plone-restapi 9.15.6.
References
Left out here: 230 versions. The JSON record has them.