Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
13 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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. Details 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`, `serializeAsync` - `crossSerialize`, `crossSerializeAsync`, `crossSerializeStream` - the `Serializer` class - `compileJSON` `fromJSON` 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`…
Recommended action: Upgrade to 1.6.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
seroval writes a `RegExp` as a regular expression literal. In affected versions, the ` ` element that the serialized output is placed in, and run script in the page. Details seroval escapes ` ` 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 ` ` 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.
Recommended action: Upgrade to 1.6.10 or 1.0.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
`fromJSON` and `fromCrossJSON` used two node fields without checking them. - An array node's element list was not checked to be an array. A small payload could set the length the decoder looped over. This part is also tracked in GHSA-wp97-x4hv-qvhp. - A sequence node's done index was not checked. A crafted value produced an iterator that never finished. Impact A service that passes untrusted input to `fromJSON` or `fromCrossJSON` can be made unavailable by an unauthenticated request. - The array case blocks the thread while the decoder runs. - The sequence case makes any code that reads the resulting iterator to the end run forever. Patches Fixed in `seroval@1.6.8`. - Element lists must be arrays. - A sequence node's throw and done indices must be integers from -1 up to the last element index. Invalid input throws `SerovalMalformedNodeError`. Workarounds None. Upgrade to 1.6.8.
Recommended action: Upgrade to 1.6.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
`fromJSON` and `fromCrossJSON` did not check that an array node's element list is an array. A small crafted payload could set the length the decoder used. That length controlled how much memory was allocated and how many times the decoder looped, and it did not depend on the size of the payload. Impact A service that passes untrusted input to `fromJSON` or `fromCrossJSON` can be made unavailable by an unauthenticated request. - A small payload can allocate enough memory to end the process. - A small payload can block the thread for seconds, or without end. This affects any framework that decodes request bodies with these functions before its own validation runs. This issue is a bypass of the fix for GHSA-66fc-rw6m-c2q6 in 1.4.1. Patches Fixed in `seroval@1.6.8`. The deserializer now rejects any node whose element list is not an array, and throws `SerovalMalformedNodeError`. Workarounds None. Upgrade to 1.6.8.
Recommended action: Upgrade to 1.6.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When `fromJSON` rebuilt an async iterator, it called `on()` on the iterator's source without checking that the source was a seroval stream. A crafted payload could pick another value as the source, such as a function returned by an application plugin. The deserializer then called that value's `on` method. This is a variant of GHSA-mv8w-475r-vwqw. That fix covered the promise and stream control nodes but not the async iterator node. Impact An application that passes untrusted input to `fromJSON` with plugins that return callable values can have those callables invoked during deserialization. What this allows depends on what the plugin's values do. Affected versions - Versions up to 1.6.3 accept any value as the source. - 1.6.4 rejects the reported payload. - 1.6.5 to 1.6.7 check the source by node type, which a payload can get around by reusing a node id. - All versions up to 1.6.7 should be treated as affected. Patches Fixed in `seroval@1.6.8`. Streams and…
Recommended action: Upgrade to 1.6.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A fulfilled Promise node deserialized by fromJSON() can trigger unintended invocation of a plugin-produced callable through native ECMAScript thenable assimilation. This bypasses the type-confusion fix in seroval@1.5.3 (GHSA-mv8w-475r-vwqw / CVE-2026-59940) and affects every plugin-capable release from 0.12.0 through the current 1.6.0.
Recommended action: Upgrade to 1.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
deserializeTypedArray casts the source node to ArrayBuffer without checking it and never bounds the element count. Pass a plain object with a length property and it hits the array-like TypedArray constructor, allocating that many elements. The offset guard above it can't stop this: source.byteLength is undefined, so the comparison is always false. The length is one integer in the JSON, so a tiny payload can name any allocation size, and it runs synchronously inside fromJSON, starving the event loop instead of just slowing one request. fromCrossJSON is the same. Impact is unauthenticated CPU/memory exhaustion for any service deserializing untrusted Seroval JSON: same profile as the array-length and nested-depth DoS issues already fixed here. No confidentiality or integrity impact. DataView has the same unchecked cast but throws instead of allocating. A runtime instanceof ArrayBuffer check plus a size cap should fix it.
Recommended action: Upgrade to 1.6.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A type confusion issue in seroval.fromJSON() allowed attacker-controlled JSON input to cause Promise control nodes to operate on values from the general deserialization reference table without first verifying that those values were genuine internal promise resolver records. In applications that deserialize untrusted Seroval JSON with plugins enabled, this could allow attacker-controlled deserialization side effects. In downstream server frameworks that register plugins returning callable wrappers, this primitive could become unintended server-side invocation and, depending on exposed application functionality, remote code execution or equivalent server compromise. The issue was fixed in seroval@1.5.3. Affected package - Package: seroval - Affected API: fromJSON() - Affected versions: versions prior to 1.5.3 that contain the vulnerable Promise resolver reference handling - Patched version: 1.5.3 Impact The vulnerable deserialization path could confuse attacker-created values…
Recommended action: Upgrade to 1.5.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Serialization of objects with extreme depth can exceed the maximum call stack limit. Mitigation: Seroval introduces a depthLimit parameter in serialization/deserialization methods. An error will be thrown if the depth limit is reached.
Recommended action: Upgrade to 1.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Overriding encoded array lengths by replacing them with an excessively large value causes the deserialization process to significantly increase processing time. Mitigation: Seroval no longer encodes array lengths. Instead, it computes length using Array.prototype.length during deserialization.
Recommended action: Upgrade to 1.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Overriding RegExp serialization with extremely large patterns can exhaust JavaScript runtime memory during deserialization. Additionally, overriding RegExp serialization with patterns that trigger catastrophic backtracking can lead to ReDoS (Regular Expression Denial of Service). Mitigation: Seroval introduces disabledFeatures (a bitmask) in serialization/deserialization methods, with Feature.RegExp as a dedicated flag. Users are recommended to configure disabledFeatures to disable RegExp serialization entirely.
Recommended action: Upgrade to 1.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Improper input handling in the JSON deserialization component can lead to arbitrary JavaScript code execution. The vulnerability can be exploited via overriding constant value and error deserialization, which allows indirect access to unsafe JS evaluation. This requires at least the ability to perform 4 separate requests on the same function and partial knowledge of how the serialized data is used during later runtime processing. This vulnerability affects the fromJSON and fromCrossJSON functions in a client-to-server transmission scenario. No known workarounds or mitigations are known, so please upgrade to the patched version.
Recommended action: Upgrade to 1.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Due to improper input validation, a malicious object key can lead to prototype pollution during JSON deserialization. This affects only JSON deserialization functionality. As there is no known workaround, please upgrade to the latest version.
Recommended action: Upgrade to 1.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.