GHSA-9wx9-5pv9-3349

### Summary seroval writes a `RegExp` as a regular expression literal. In affected versions, the `<` character in a `RegExp` source is written without escaping. A source built from untrusted input can then end the HTML `<script>` element that the serialized output is placed in, and run script in the page. ### Details seroval escapes `<` in strings, so string values cannot end a `<script>` element. `RegExp` sources did not get the same escaping: - Versions before 1.0.0 wrote the source as is. - Version 1.5.5 stopped escaping `<` in `RegExp` sources, so that named groups and lookbehinds keep working. This removed the escaping for every `<` in a source. These functions are affected: - `serialize`, `serializeAsync` - `crossSerialize`, `crossSerializeAsync`, `crossSerializeStream` - the `Serializer` class - `compileJSON` `toJSON`, `fromJSON`, `toCrossJSON` and `fromCrossJSON` are not affected, because they never produce JavaScript. ### Impact An application is affected when all of these are true: 1. It builds a `RegExp` from untrusted input that is used as regular expression syntax. Input passed through an escaping helper (such as an `escapeRegExp` function) is not enough to exploit this. 2. It serializes that `RegExp` with one of the functions above. 3. It places the output inside an HTML `<script>` element, as server rendering usually does. In that case an attacker can run script in the page of any user who receives that output. ### Patches Fixed in 1.6.10. A `RegExp` whose source contains `<` is now written with the `RegExp` constructor and an escaped string source. Named groups and lookbehinds keep working. ### Workarounds If you cannot upgrade: - Do not serialize a `RegExp` built from untrusted pattern syntax. Send its source and flags as strings, and build the `RegExp` on the client. - Or reject patterns that contain `<` before they reach the serializer.