Every CVESearch/Get API key

GHSA-8rqh-vxpr-x77p

plone.restapi: Stored XSS by spoofing mime type

4.3 MediumFix available

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.restapi to 9.15.6.
  • For Plone 6.2, upgrade plone.restapi to 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 used4.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.restapi to 9.15.6.
  • For Plone 6.2, upgrade plone.restapi to 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 MediumCVSS: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
OSV4.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.restapi to 9.15.6.
  • For Plone 6.2, upgrade plone.restapi to 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 MediumCVSS: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

Affected packages
PackageAffectedFixed
plone-restapi
PyPI
before 9.15.6
9.15.6
plone-restapi
PyPI
10.0.0 to 10.0.0
10.0.1
plone-restapi
PyPI
before 9.15.6, plus listed versions
1.0.01.0a11.0a101.0a111.0a12
Show 45 moreShow less
1.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-restapi
PyPI
10.0.0 up to 10.0.1
10.0.1

History

History
RecordedChangedSources
first indexedGitHub 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

This page doesn't list everything

Left out here: 230 versions. The JSON record has them.

MoveEnter Open