
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: >= 1.6.0, < 1.6.11
Patched in 1.6.11
Details
seroval writes a typed array as a call to its constructor. In affected versions, the constructor name in the output is read from a property that data on the value can replace, and it is written without checks. A typed array that received properties from untrusted data can then put arbitrary code into the serialized output.
Version 1.6.0 changed how seroval finds the class of an object, so that objects with their own constructor property serialize correctly. Typed arrays still took the constructor name from the value itself, so the name could come from the untrusted property instead of the array's real type.
These functions are affected:
serialize, serializeAsynccrossSerialize, crossSerializeAsync, crossSerializeStreamSerializer classcompileJSONfromJSON and fromCrossJSON are not affected: they only accept the names of the built-in typed arrays. With the compactArrayBufferViews option, the same lookup throws a TypeError instead of writing code.
An application is affected only when it serializes a typed array that has an own constructor property set from untrusted data. That requires code that copies properties from untrusted objects onto a typed array. This is unusual, so the severity is rated Low, even though the result is script execution in the page that receives the output.
Fixed in 1.6.11. The constructor name now comes from the array's internal type, which properties on the value cannot change. compactArrayBufferViews uses the real type as well.
If you cannot upgrade, do not copy properties from untrusted objects onto typed arrays, or remove an own constructor property from a typed array before serializing it.
EPSS, exploit probability
Low0.27%
estimated chance of real-world exploitation in the next 30 days, higher than 18.9% of every CVE FIRST.org scores
Refreshed 10/28/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.