Search
Vulnerabilities 1–50 of 785, affecting the active versions
| Score | ID | Status | Published | Affected versions | Description | Notes |
|---|---|---|---|---|---|---|
| 10.0CVSS 4.0 | CVE-2024-52046
GHSA-76h9-2vwh-w278 |
Resolved | 2024-12-25 | 5.4 ×14 | The ObjectSerializationDecoder in Apache MINA uses Java’s native deserialization protocol to process incoming serialized data but lacks the necessary security checks and defenses. This vulnerability allows attackers to exploit the deserialization process by sending specially crafted malicious serialized data, potentially leading to remote code execution (RCE) attacks. This issue affects MINA core versions 2.0.X, 2.1.X and 2.2.X, and will be fixed by the releases 2.0.27, 2.1.10 and 2.2.4. It's also important to note that an application using MINA core library will only be affected if the IoBuffer#getObject() method is called, and this specific method is potentially called when adding a ProtocolCodecFilter instance using the ObjectSerializationCodecFactory class in the filter chain. If your application is specifically using those classes, you have to upgrade to the latest version of MINA core library. Upgrading will not be enough: you also need to explicitly allow the classes the decoder will accept in the ObjectSerializationDecoder instance, using one of the three new methods: /** * Accept class names where the supplied ClassNameMatcher matches for * deserialization, unless they are otherwise rejected. * * @param classNameMatcher the matcher to use */ public void accept(ClassNameMatcher classNameMatcher) /** * Accept class names that match the supplied pattern for * deserialization, unless they are otherwise rejected. * * @param pattern standard Java regexp */ public void accept(Pattern pattern) /** * Accept the wildcard specified classes for deserialization, * unless they are otherwise rejected. * * @param patterns Wildcard file name patterns as defined by * {@link org.apache.commons.io.FilenameUtils#wildcardMatch(String, String) FilenameUtils.wildcardMatch} */ public void accept(String... patterns) By default, the decoder will reject *all* classes that will be present in the incoming data. Note: The FtpServer, SSHd and Vysper sub-project are not affected by this issue. | |
| 10.0CVSS 3.1 | CVE-2026-45674
GHSA-676x-f7gg-47vc |
Resolved | 2026-06-12 | 5.7 ×35.6 ×95.5 ×205.4 ×14 | Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, Netty's DnsResolveContext fails to validate the origin (bailiwick) of CNAME records in DNS responses. Versions 4.1.135.Final and 4.2.15.Final patch the issue. | |
| 10.0CVSS 3.1 | CVE-2026-47691
GHSA-5pvg-856g-cp85 |
Resolved | 2026-06-12 | 5.7 ×35.6 ×95.5 ×205.4 ×14 | Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, Netty's `DnsResolveContext` insufficiently validates the bailiwick of NS records, enabling DNS Cache Poisoning. An attacker controlling an authoritative name server for a subdomain can poison the cache for parent domains (like `.co.uk`). In `io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#add` method accepts any NS record from the AUTHORITY section as long as the record's name is a suffix of the questionName. Subsequently, the `handleWithAdditional` method caches the associated A records from the ADDITIONAL section directly into the `authoritativeDnsServerCache` under the parent domain's key. This bypasses standard bailiwick rules, where a server authoritative for a subdomain should not be trusted to provide authoritative records for its parent. The poisoned cache is then used for all future resolutions under the parent domain's key. Versions 4.1.135.Final and 4.2.15.Final patch the issue. | |
| 10.0CVSS 4.0 | GHSA-76h9-2vwh-w278
CVE-2024-52046 |
Resolved | 2024-12-25 | 5.4 ×14 | The `ObjectSerializationDecoder` in Apache MINA uses Java’s native deserialization protocol to process incoming serialized data but lacks the necessary security checks and defenses. This vulnerability allows attackers to exploit the deserialization process by sending specially crafted malicious serialized data, potentially leading to remote code execution (RCE) attacks. This issue affects MINA core versions 2.0.X, 2.1.X and 2.2.X, and will be fixed by the releases 2.0.27, 2.1.10 and 2.2.4. It's also important to note that an application using MINA core library will only be affected if the IoBuffer#getObject() method is called, and this specific method is potentially called when adding a ProtocolCodecFilter instance using the `ObjectSerializationCodecFactory` class in the filter chain. If your application is specifically using those classes, you have to upgrade to the latest version of MINA core library. Upgrading will not be enough: you also need to explicitly allow the classes the decoder will accept in the ObjectSerializationDecoder instance, using one of the three new methods: 1. * Accept class names where the supplied ClassNameMatcher matches for deserialization, unless they are otherwise rejected. * `@param classNameMatcher` the matcher to use * / `public void accept(ClassNameMatcher classNameMatcher)` 2. * Accept class names that match the supplied pattern for deserialization, unless they are otherwise rejected. * `@param` pattern standard Java regexp * / `public void accept(Pattern pattern)` 3. * Accept the wildcard specified classes for deserialization, unless they are otherwise rejected. * `@param` patterns Wildcard file name patterns as defined by `{@link org.apache.commons.io.FilenameUtils#wildcardMatch(String, String) FilenameUtils.wildcardMatch}` * / `public void accept(String... patterns)` By default, the decoder will reject *all* classes that will be present in the incoming data. Note: The FtpServer, SSHd and Vysper sub-project are not affected by this issue. | |
| 9.9CVSS 3.1 | iCVE-2025-49113
|
Resolved | — | 5.7 ×65.6 ×95.5 ×185.4 ×14 | Roundcube Webmail before 1.5.10 and 1.6.x before 1.6.11 allows remote code execution by authenticated users because the _from parameter in a URL is not validated in program/actions/settings/upload.php, leading to PHP Object Deserialization. | |
| 9.8CVSS 3.1 | CVE-2017-8923
|
Resolved | 2017-05-12 | 5.5 ×205.4 ×14 | The zend_string_extend function in Zend/zend_string.h in PHP through 7.1.5 does not prevent changes to string objects that result in a negative length, which allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact by leveraging a script's use of .= with a long string. | |
| 9.8CVSS 3.0 | CVE-2017-9225
|
Resolved | 2017-05-24 | 5.5 ×205.4 ×14 | An issue was discovered in Oniguruma 6.2.0, as used in Oniguruma-mod in Ruby through 2.4.1 and mbstring in PHP through 7.1.5. A stack out-of-bounds write in onigenc_unicode_get_case_fold_codes_by_str() occurs during regular expression compilation. Code point 0xFFFFFFFF is not properly handled in unicode_unfold_key(). A malformed regular expression could result in 4 bytes being written off the end of a stack buffer of expand_case_fold_string() during the call to onigenc_unicode_get_case_fold_codes_by_str(), a typical stack buffer overflow. | |
| 9.8CVSS 3.1 | CVE-2019-13990
GHSA-9qcf-c26r-x5rf |
Not affected | 2019-07-26 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | initDocumentParser in xml/XMLSchedulingDataProcessor.java in Terracotta Quartz Scheduler through 2.3.0 allows XXE attacks via a job description. | |
| 9.8CVSS 3.1 | CVE-2019-9641
|
Resolved | 2019-03-09 | 5.5 ×205.4 ×14 | An issue was discovered in the EXIF component in PHP before 7.1.27, 7.2.x before 7.2.16, and 7.3.x before 7.3.3. There is an uninitialized read in exif_process_IFD_in_TIFF. | |
| 9.8CVSS 3.1 | CVE-2021-42740
GHSA-g4rg-993r-mgx7 |
Not affected | 2021-10-21 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | The shell-quote package before 1.7.3 for Node.js allows command injection. An attacker can inject unescaped shell metacharacters through a regex designed to support Windows drive letters. If the output of this package is passed to a real shell as a quoted argument to a command with exec(), an attacker can inject arbitrary commands. This is because the Windows drive letter regex character class is {A-z] instead of the correct {A-Za-z]. Several shell metacharacters exist in the space between capital letter Z and lower case letter a, such as the backtick character. | |
| 9.8CVSS 3.1 | CVE-2022-29078
GHSA-phwq-j96m-2c2q |
Not affected | 2022-04-25 | 5.6 ×95.5 ×205.4 ×14 | The ejs (aka Embedded JavaScript templates) package 3.1.6 for Node.js allows server-side template injection in settings[view options][outputFunctionName]. This is parsed as an internal option, and overwrites the outputFunctionName option with an arbitrary OS command (which is executed upon template compilation). | |
| 9.8CVSS 3.1 | CVE-2023-39017
|
Not affected | 2023-07-28 | 5.5 ×95.4 ×12 | quartz-jobs 2.3.2 and below was discovered to contain a code injection vulnerability in the component org.quartz.jobs.ee.jms.SendQueueMessageJob.execute. This vulnerability is exploited via passing an unchecked argument. NOTE: this is disputed by multiple parties because it is not plausible that untrusted user input would reach the code location where injection must occur. | |
| 9.8CVSS 3.1 | CVE-2024-3566
|
False positive | 2024-04-10 | 5.5 ×205.4 ×14 | A command inject vulnerability allows an attacker to perform command injection on Windows applications that indirectly depend on the CreateProcess function when the specific conditions are satisfied. | |
| 9.8CVSS 3.1 | CVE-2025-46295
|
Resolved | 2025-12-16 | 5.5 ×45.4 ×9 | Apache Commons Text versions prior to 1.10.0 included interpolation features that could be abused when applications passed untrusted input into the text-substitution API. Because some interpolators could trigger actions like executing commands or accessing external resources, an attacker could potentially achieve remote code execution. This vulnerability has been fully addressed in FileMaker Server 22.0.4. | |
| 9.8CVSS 3.1 | CVE-2026-33943
GHSA-6q6h-j7hj-3r64 |
False positive | 2026-03-27 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | Happy DOM is a JavaScript implementation of a web browser without its graphical user interface. In versions 15.10.0 through 20.8.7, a code injection vulnerability in `ECMAScriptModuleCompiler` allows an attacker to achieve Remote Code Execution (RCE) by injecting arbitrary JavaScript expressions inside `export { }` declarations in ES module scripts processed by happy-dom. The compiler directly interpolates unsanitized content into generated code as an executable expression, and the quote filter does not strip backticks, allowing template literal-based payloads to bypass sanitization. Version 20.8.8 fixes the issue. | |
| 9.8CVSS 3.1 | CVE-2026-41409
GHSA-f2wh-grmh-r6jm |
Resolved | 2026-04-27 | 5.7 ×55.6 ×95.5 ×205.4 ×14 | The fix for CVE-2024-52046 in Apache MINA AbstractIoBuffer.getObject() was incomplete. The classname allowlist of classes allowed to be deserialized was applied too late after a static initializer in a class to be read might already have been executed. Affected versions are Apache MINA 2.0.0 <= 2.0.27, 2.1.0 <= 2.1.10, and 2.2.0 <= 2.2.5. The problem is resolved in Apache MINA 2.0.28, 2.1.11, and 2.2.6 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade | |
| 9.8CVSS 3.1 | CVE-2026-41635
GHSA-8297-v2rf-2p32 |
Resolved | 2026-04-27 | 5.7 ×55.6 ×95.5 ×205.4 ×14 | Apache MINA's AbstractIoBuffer.resolveClass() contains two branches, one of them (for static classes or primitive types) does not check the class at all, bypassing the classname allowlist and allowing arbitrary code to be executed. The fix checks if the class is present in the accepted class filter before calling Class.forName(). Affected versions are Apache MINA 2.0.0 <= 2.0.27, 2.1.0 <= 2.1.10, and 2.2.0 <= 2.2.5. The problem is resolved in Apache MINA 2.0.28, 2.1.11, and 2.2.6 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade. | |
| 9.8CVSS 3.1 | CVE-2026-42581
GHSA-xxqh-mfjm-7mv9 |
Resolved | 2026-05-13 | 5.7 ×35.6 ×25.5 ×205.4 ×14 | Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, HttpObjectDecoder strips a conflicting Content-Length header when a request carries both Transfer-Encoding: chunked and Content-Length, but only for HTTP/1.1 messages. The guard is absent for HTTP/1.0. An attacker that sends an HTTP/1.0 request with both headers causes Netty to decode the body as chunked while leaving Content-Length intact in the forwarded HttpMessage. Any downstream proxy or handler that trusts Content-Length over Transfer-Encoding will disagree on message boundaries, enabling request smuggling. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final. | |
| 9.8CVSS 3.1 | CVE-2026-42778
GHSA-995c-6rp3-4m4x |
Resolved | 2026-05-01 | 5.7 ×55.6 ×95.5 ×205.4 ×14 | The fix for CVE-2026-41409 was not applied to the 2.1.X and 2.2.X branches. Here was the original issue description: The fix for CVE-2024-52046 in Apache MINA AbstractIoBuffer.getObject() was incomplete. The classname allowlist of classes allowed to be deserialized was applied too late after a static initializer in a class to be read might already have been executed. Affected versions are Apache MINA 2.1.0 <= 2.1.11, and 2.2.0 <= 2.2.6. The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade The fix for CVE-2024-52046 in Apache MINA AbstractIoBuffer.getObject() was incomplete. The classname allowlist of classes allowed to be deserialized was applied too late after a static initializer in a class to be read might already have been executed. Affected versions are Apache MINA 2.1.0 <= 2.1.110, and 2.2.0 <= 2.2.6. The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade | |
| 9.8CVSS 3.1 | CVE-2026-42779
GHSA-vf5j-865m-mq7c |
Resolved | 2026-05-01 | 5.7 ×55.6 ×95.5 ×205.4 ×14 | The fix for CVE-2026-41635 was not applied to the 2.1.X and 2.2.X branches. Here was the original issue description: Apache MINA's AbstractIoBuffer.resolveClass() contains two branches, one of them (for static classes or primitive types) does not check the class at all, bypassing the classname allowlist and allowing arbitrary code to be executed. The fix checks if the class is present in the accepted class filter before calling Class.forName(). Affected versions are Apache MINA 2.1.0 <= 2.1.11, and 2.2.0 <= 2.2.6. The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade. | |
| 9.8CVSS 3.1 | CVE-2026-47065
GHSA-v3pr-hxpr-mfm8 |
Resolved | 2026-06-03 | 5.7 ×55.6 ×95.5 ×205.4 ×14 | ZDRES-232: resolveProxyClass Not Overridden - acceptMatchers Filter Bypass via java.lang.reflect.Proxy Assessment: Fully addressed. When the serialised stream contains a TC_PROXYCLASSDESC (the marker for a java.lang.reflect.Proxy ), JDK’s ObjectInputStream.readProxyDesc() is dispatched. JDK then calls the default ObjectInputStream.resolveProxyClass(interfaces) implementation, which performs Class.forName(intf, false, latestUserDefinedLoader()) for EACH interface name and constructs the proxy class — bypassing the accepted classes list . ZDRES-233: Class.forName(name, initialize=true, classLoader) in readClassDescriptor Triggers Static Initialiser of Allow-Listed Classes Assessment: Fully addressed. For ANY class on the allow-list, deserialising a stream that names it triggers the class’s (static initialiser) BEFORE any instance is constructed. This means an attacker who supplies a class name on the allow-list (e.g., the developer wrote accept(“com.myapp.*") , attacker supplies com.myapp.SomeClass ) causes <clinit> of SomeClass — and many real-world classes have side-effecting static initialisers Both issues have been fixed. | |
| 9.8CVSS 3.1 | CVE-2026-4800
|
Not affected | 2026-03-31 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | The fix for CVE-2021-23337 added validation for the variable option in _.template but did not apply the same validation to options.imports key names, and both paths flow into the same Function() constructor sink. When an application passes untrusted input as options.imports key names, an attacker can inject default-parameter expressions that execute arbitrary code at template compilation time. Additionally, _.template uses assignInWith to merge imports, which enumerates inherited properties via for..in, so if Object.prototype has been polluted by another vector the polluted keys are copied into the imports object and passed to Function(). The issue is fixed in 4.18.1 for lodash, lodash-es, lodash-amd, and lodash.template. As a workaround, do not pass untrusted input as key names in options.imports; use only developer-controlled, static key names. | |
| 9.8CVSS 3.1 | GHSA-5xrq-8626-4rwp
CVE-2026-47429 |
False positive | 2026-06-01 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Summary Arbitrary file can be read on Windows when Vitest UI server is listening, especially when exposed to the network. ### Impact Only users that match either of the following conditions are affected: - explicitly exposes the Vitest UI server to the network (using `--api.host` or [`api.host` config option](https://vitest.dev/config/api.html)) - running the Vitest UI or Browser Mode on Windows ### Details The API handler for `/__vitest_attachment__` uses the deprecated `isFileServingAllowed` incorrectly. https://github.com/vitest-dev/vitest/blob/eb1abf08573032a532015b999ad3501c5e89e3bb/packages/ui/node/index.ts#L77 The function expects the passed value to use `cleanUrl` after the check before file system related operation. Because of this, it is possible to bypass the check by `\\?\\..\\`. This is not possible on Linux as Linux errors if a directory named `?` does not exist. A similar problem exists in other places as well. - https://github.com/vitest-dev/vitest/blob/eb1abf08573032a532015b999ad3501c5e89e3bb/packages/vitest/src/api/setup.ts#L103-L105 - https://github.com/vitest-dev/vitest/blob/eb1abf08573032a532015b999ad3501c5e89e3bb/packages/vitest/src/api/setup.ts#L119-L121 - https://github.com/vitest-dev/vitest/blob/eb1abf08573032a532015b999ad3501c5e89e3bb/packages/browser/src/node/commands/fs.ts#L10-L11 - https://github.com/vitest-dev/vitest/blob/eb1abf08573032a532015b999ad3501c5e89e3bb/packages/browser/src/node/plugin.ts#L194-L196 - https://github.com/vitest-dev/vitest/blob/eb1abf08573032a532015b999ad3501c5e89e3bb/packages/browser/src/node/rpc.ts#L115-L121 **That said**, this `isFileServingAllowed` check does not actually prevent the API to be abused. Since the API has rerun feature and file write feature, it's possible to run arbitrary script by writing a script as a test file using `saveTestFile` and running it using `rerun`. This means exposing the API / Vitest UI is equivalent to giving script execution access. On the browser mode side, there're `readFile` / `writeFile` / `saveSnapshotFile`. So exposing the browser mode is equivalent to giving file read / write access. ### PoC 1. Run Vitest UI 2. Get the API token by `curl http://localhost:51204/__vitest__/` 3. Run `curl "http://localhost:51204/__vitest_attachment__?path=C:\\path\\to\\project\\?\\..\\..\\secret.txt&contentType=text/plain&token=$TOKEN"` (TOKEN is the API token) 4. curl shows the content of `secret.txt` that is outside the project directory ### Mitigations Vitest now ships two configuration flags, [`allowWrite`](https://vitest.dev/config/api.html#api-allowwrite) and [`allowExec`](https://vitest.dev/config/api.html#api-allowexec), that gate the privileged operations exploited by this vulnerability. Both are disabled by default whenever the API server is bound to a non-`localhost` host, ensuring that exposing the server to the network no longer implicitly grants write or execute capabilities to remote clients. When these flags are disabled, the UI also enters a read-only mode: in-browser code editing and test file execution are turned off, removing the attack surface that allowed remote code execution. Many Browser Mode features are also disabled, like attachments, artifacts or snapshots. See [`browser.api`](https://vitest.dev/config/browser/api.html#api-allowwrite). Users who require the full interactive UI on a networked host must explicitly opt in by setting `allowWrite` and/or `allowExec` to `true`. | |
| 9.8CVSS 3.1 | GHSA-8297-v2rf-2p32
CVE-2026-41635 |
Resolved | 2026-04-27 | 5.7 ×55.6 ×95.5 ×205.4 ×14 | Apache MINA's AbstractIoBuffer.resolveClass() contains two branches, one of them (for static classes or primitive types) does not check the class at all, bypassing the classname allowlist and allowing arbitrary code to be executed. The fix checks if the class is present in the accepted class filter before calling Class.forName(). Affected versions are Apache MINA 2.0.0 <= 2.0.27, 2.1.0 <= 2.1.10, and 2.2.0 <= 2.2.5. The problem is resolved in Apache MINA 2.0.28, 2.1.11, and 2.2.6 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade. | |
| 9.8CVSS 3.1 | GHSA-995c-6rp3-4m4x
CVE-2026-42778 |
Resolved | 2026-05-01 | 5.7 ×55.6 ×95.5 ×205.4 ×14 | The fix for CVE-2026-41409 was not applied to the 2.1.X and 2.2.X branches. Here was the original issue description: The fix for CVE-2024-52046 in Apache MINA AbstractIoBuffer.getObject() was incomplete. The classname allowlist of classes allowed to be deserialized was applied too late after a static initializer in a class to be read might already have been executed. Affected versions are Apache MINA 2.1.0 <= 2.1.11, and 2.2.0 <= 2.2.6. The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade. | |
| 9.8CVSS 3.1 | GHSA-9qcf-c26r-x5rf
CVE-2019-13990 |
Not affected | 2020-07-01 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | initDocumentParser in xml/XMLSchedulingDataProcessor.java in Terracotta Quartz Scheduler through 2.3.0 allows XXE attacks via a job description. | |
| 9.8CVSS 3.1 | GHSA-f2wh-grmh-r6jm
CVE-2026-41409 |
Resolved | 2026-04-27 | 5.7 ×55.6 ×95.5 ×205.4 ×14 | The fix for CVE-2024-52046 in Apache MINA AbstractIoBuffer.getObject() was incomplete. The classname allowlist of classes allowed to be deserialized was applied too late after a static initializer in a class to be read might already have been executed. Affected versions are Apache MINA 2.0.0 <= 2.0.27, 2.1.0 <= 2.1.10, and 2.2.0 <= 2.2.5. The problem is resolved in Apache MINA 2.0.28, 2.1.11, and 2.2.6 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade | |
| 9.8CVSS 3.1 | GHSA-g4rg-993r-mgx7
CVE-2021-42740 |
Not affected | 2022-05-24 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | The shell-quote package before 1.7.3 for Node.js allows command injection. An attacker can inject unescaped shell metacharacters through a regex designed to support Windows drive letters. If the output of this package is passed to a real shell as a quoted argument to a command with `exec()`, an attacker can inject arbitrary commands. This is because the Windows drive letter regex character class is `[A-z]` instead of the correct `[A-Za-z]`. Several shell metacharacters exist in the space between capital letter Z and lower case letter a, such as the backtick character. | |
| 9.8CVSS 3.1 | GHSA-phwq-j96m-2c2q
CVE-2022-29078 |
Not affected | 2022-04-26 | 5.6 ×95.5 ×205.4 ×14 | The ejs (aka Embedded JavaScript templates) package 3.1.6 for Node.js allows server-side template injection in settings[view options][outputFunctionName]. This is parsed as an internal option, and overwrites the outputFunctionName option with an arbitrary OS command (which is executed upon template compilation). | |
| 9.8CVSS 3.1 | GHSA-v3pr-hxpr-mfm8
CVE-2026-47065 |
Resolved | 2026-06-03 | 5.7 ×55.6 ×95.5 ×205.4 ×14 | ZDRES-232: resolveProxyClass Not Overridden - acceptMatchers Filter Bypass via java.lang.reflect.Proxy Assessment: Fully addressed. When the serialised stream contains a TC_PROXYCLASSDESC (the marker for a java.lang.reflect.Proxy ), JDK’s ObjectInputStream.readProxyDesc() is dispatched. JDK then calls the default ObjectInputStream.resolveProxyClass(interfaces) implementation, which performs Class.forName(intf, false, latestUserDefinedLoader()) for EACH interface name and constructs the proxy class — bypassing the accepted classes list . ZDRES-233: Class.forName(name, initialize=true, classLoader) in readClassDescriptor Triggers Static Initialiser of Allow-Listed Classes Assessment: Fully addressed. For ANY class on the allow-list, deserialising a stream that names it triggers the class’s (static initialiser) BEFORE any instance is constructed. This means an attacker who supplies a class name on the allow-list (e.g., the developer wrote accept(“com.myapp.*") , attacker supplies com.myapp.SomeClass ) causes <clinit> of SomeClass — and many real-world classes have side-effecting static initialisers Both issues have been fixed. | |
| 9.8CVSS 3.1 | GHSA-vf5j-865m-mq7c
CVE-2026-42779 |
Resolved | 2026-05-01 | 5.7 ×55.6 ×95.5 ×205.4 ×14 | The fix for CVE-2026-41635 was not applied to the 2.1.X and 2.2.X branches. Here was the original issue description: Apache MINA's AbstractIoBuffer.resolveClass() contains two branches, one of them (for static classes or primitive types) does not check the class at all, bypassing the classname allowlist and allowing arbitrary code to be executed. The fix checks if the class is present in the accepted class filter before calling Class.forName(). Affected versions are Apache MINA 2.1.0 <= 2.1.11, and 2.2.0 <= 2.2.6. The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade. | |
| 9.5CVSS 4.0 | CVE-2026-104848
GHSA-5gmw-xhrv-c9v3 |
In triage | 2026-10-02 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | Tinypool is a minimal Node.js worker thread pool implementation. Prior to 2.1.1, Tinypool constructs ThreadPool.options from a normal options object and reads the execArgv and env worker options in dist/index.js, allowing values inherited from a polluted Object.prototype to be copied into own properties and passed to worker_threads.Worker. An attacker who can first pollute either property can cause each newly spawned worker to load attacker-selected JavaScript through command-line preload arguments or NODE_OPTIONS, resulting in code execution with the host process's privileges and possible access to CI secrets, signing material, or build artifacts. This issue is fixed in version 2.1.1. | |
| 9.5CVSS 4.0 | CVE-2026-104849
GHSA-85c8-ppgw-ccpr |
In triage | 2026-10-02 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | Tinypool is a minimal Node.js worker thread pool implementation. Prior to 2.1.2, Tinypool reads filename from a caller-supplied options object in pool.run(task, options) without requiring an own property, so a polluted Object.prototype.filename can replace the intended worker module. Applications are affected only when they pass their own second-argument options object to pool.run(); calls without that argument use the trusted default options object. An attacker who can first pollute the prototype can cause the worker pool to load attacker-selected JavaScript and can read or modify task data with the host process's privileges. This issue is fixed in version 2.1.2. | |
| 9.5CVSS 4.0 | GHSA-5gmw-xhrv-c9v3
CVE-2026-104848 |
In triage | 2026-10-05 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | `tinypool` passes worker options to `new Worker()` by reading them off a plain object whose prototype is `Object.prototype`. Options the application did not set are resolved through the prototype chain and then passed explicitly to `worker_threads.Worker`. Node core ignores `Worker` options inherited from `Object.prototype`. By reading them and passing them explicitly, tinypool re-materialises them as own properties and defeats that protection. Two keys reach code execution: 1. **`execArgv`** — polluting `Object.prototype.execArgv = ['--require', '/path/to/attacker.js']` causes every pool worker to load the attacker's script. 2. **`env`** — polluting `Object.prototype.env = { NODE_OPTIONS: '--require /path/to/attacker.js' }` achieves the same via environment injection. ## Root cause `dist/index.js` lines 508-511: ```js env: this.options.env, argv: this.options.argv, execArgv: this.options.execArgv, resourceLimits: this.options.resourceLimits, ``` `this.options` is built at line 470 via object spread: ```js this.options = { ...kDefaultOptions, ...options, filename, maxQueue: 0 }; ``` ## Impact Arbitrary code execution inside every worker the pool spawns, with the privileges of the host process. Because tinypool is the worker pool behind Vitest (~42M downloads/week), the natural blast radius is developer machines and CI runners — an attacker who lands a prototype-pollution primitive anywhere in the dependency tree gets code execution in the build/test pipeline, which is a supply-chain foothold (access to CI secrets, signing keys, artifact publishing). ## Proof of concept Minimal reproduction (3 files): **worker.mjs** — the application's own legitimate worker: ```js export default function double(n) { return n * 2 } ``` **payload.js** — attacker-controlled code (never referenced by the app): ```js const fs = require('fs') fs.writeFileSync('/tmp/RCE_PROOF.txt', 'code execution achieved, pid=' + process.pid) console.log('*** RCE ***') ``` **app.js** — normal tinypool usage: ```js const path = require('path') // Simulates an upstream PP source (lodash/qs/minimist/set-value/deepmerge) Object.prototype.execArgv = ['--require', path.join(__dirname, 'payload.js')] const { Tinypool } = require('tinypool') const pool = new Tinypool({ filename: path.join(__dirname, 'worker.mjs'), minThreads: 1, maxThreads: 1 }) pool.run(21).then(r => { console.log('pool returned:', r) // 42 — app works normally pool.destroy() }) ``` Run: ``` npm i tinypool@2.1.0 node app.js cat /tmp/RCE_PROOF.txt # attacker's code ran ``` Both `execArgv` and `env` vectors confirmed on Node 20. ## Suggested fix Resolve worker options with own-property semantics: ```js this.options = Object.assign(Object.create(null), kDefaultOptions, options, { filename, maxQueue: 0 }); ``` | |
| 9.5CVSS 4.0 | GHSA-85c8-ppgw-ccpr
CVE-2026-104849 |
In triage | 2026-10-05 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | `tinypool` is a fork of `piscina` and inherited the same prototype-pollution surface. When `pool.run(task, options)` is called, the `filename` option is read from the provided `options` object. If that object does not have an own `filename` property, the lookup falls through to `Object.prototype`. An attacker who can pollute `Object.prototype.filename` (for example, via a vulnerable `lodash.merge`, `qs.parse`, or similar elsewhere in the application) can make tinypool load and execute an attacker-controlled worker module. This is the tinypool counterpart to the piscina root discovery [GHSA-x9g3-xrwr-cwfg](https://github.com/piscinajs/piscina/security/advisories/GHSA-x9g3-xrwr-cwfg). `pool.run(task)` with no second argument is not affected, because `kDefaultOptions.filename` is `null` and the options object is not user-controlled. The exploit only triggers when the caller passes their own options object to `pool.run()`. ## Impact Arbitrary JavaScript execution in the worker pool. If the application passes attacker-controlled data as the `run()` task and also supplies a `run()` options object, the attacker can redirect execution to a malicious worker that exfiltrates or modifies that data, achieving remote code execution and/or data exfiltration. ## Proof of Concept ```js // legitimate-worker.mjs export default async (task) => ({ by: 'legitimate-worker', processed: task }) // malicious-worker.mjs export default async (task) => ({ by: 'attacker', stolenRequestBody: task }) // main.js import express from "express"; import Tinypool from "tinypool"; import { fileURLToPath } from "node:url"; import path from "node:path"; const __dirname = path.dirname(fileURLToPath(import.meta.url)); // Simulate upstream prototype pollution (lodash merge, qs parse, etc.) Object.prototype.filename = path.join(__dirname, "malicious-worker.mjs"); const pool = new Tinypool({ filename: path.join(__dirname, "legitimate-worker.mjs"), }); express() .use(express.json()) .post("/", async (req, res) => { const ac = new AbortController(); const result = await pool.run(req.body, { signal: ac.signal }); res.json(result); }) .listen(31337); ``` ## Suggested fix Read all user-supplied options from own properties only (`Object.hasOwn` or `Object.prototype.hasOwnProperty.call`) and build the internal `ThreadPool.options` object with a null prototype. | |
| 9.4CVSS 4.0 | CVE-2025-62410
|
Resolved | 2025-10-15 | 5.4 ×5 | In versions before 20.0.2, it was found that --disallow-code-generation-from-strings is not sufficient for isolating untrusted JavaScript in happy-dom. The untrusted script and the rest of the application still run in the same Isolate/process, so attackers can deploy prototype pollution payloads to hijack important references like "process" in the example below, or to hijack control flow via flipping checks of undefined property. This vulnerability is due to an incomplete fix for CVE-2025-61927. The vulnerability is fixed in 20.0.2. | |
| 9.4CVSS 4.0 | CVE-2025-7783
GHSA-fjxv-7rqg-78g4 |
Resolved | 2025-07-18 | 5.6 ×95.5 ×205.4 ×14 | Use of Insufficiently Random Values vulnerability in form-data allows HTTP Parameter Pollution (HPP). This vulnerability is associated with program files lib/form_data.Js. This issue affects form-data: < 2.5.4, 3.0.0 - 3.0.3, 4.0.0 - 4.0.3. | |
| 9.4CVSS 4.0 | CVE-2026-107282
GHSA-jmqq-x5g9-9p2w |
Resolved | 2026-10-07 | 5.7 ×35.6 ×95.5 ×205.4 ×14 | The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.13 and 2.16.1, cross-host request replay updates the current request but leaves the target request and related proxy context pointing at the original origin. Connection-pool selection, CONNECT handling, realm selection, and TLS setup can consequently send the original host's path, Host header, Authorization credentials, or plaintext request to the replay destination. Documented ResponseFilter failover and retry paths can trigger the replay. This issue is fixed in versions 3.0.13 and 2.16.1. | |
| 9.4CVSS 4.0 | GHSA-fjxv-7rqg-78g4
CVE-2025-7783 |
Resolved | 2025-07-21 | 5.6 ×95.5 ×205.4 ×14 | ### Summary form-data uses `Math.random()` to select a boundary value for multipart form-encoded data. This can lead to a security issue if an attacker: 1. can observe other values produced by Math.random in the target application, and 2. can control one field of a request made using form-data Because the values of Math.random() are pseudo-random and predictable (see: https://blog.securityevaluators.com/hacking-the-javascript-lottery-80cc437e3b7f), an attacker who can observe a few sequential values can determine the state of the PRNG and predict future values, includes those used to generate form-data's boundary value. The allows the attacker to craft a value that contains a boundary value, allowing them to inject additional parameters into the request. This is largely the same vulnerability as was [recently found in `undici`](https://hackerone.com/reports/2913312) by [`parrot409`](https://hackerone.com/parrot409?type=user) -- I'm not affiliated with that researcher but want to give credit where credit is due! My PoC is largely based on their work. ### Details The culprit is this line here: https://github.com/form-data/form-data/blob/426ba9ac440f95d1998dac9a5cd8d738043b048f/lib/form_data.js#L347 An attacker who is able to predict the output of Math.random() can predict this boundary value, and craft a payload that contains the boundary value, followed by another, fully attacker-controlled field. This is roughly equivalent to any sort of improper escaping vulnerability, with the caveat that the attacker must find a way to observe other Math.random() values generated by the application to solve for the state of the PRNG. However, Math.random() is used in all sorts of places that might be visible to an attacker (including by form-data itself, if the attacker can arrange for the vulnerable application to make a request to an attacker-controlled server using form-data, such as a user-controlled webhook -- the attacker could observe the boundary values from those requests to observe the Math.random() outputs). A common example would be a `x-request-id` header added by the server. These sorts of headers are often used for distributed tracing, to correlate errors across the frontend and backend. `Math.random()` is a fine place to get these sorts of IDs (in fact, [opentelemetry uses Math.random for this purpose](https://github.com/open-telemetry/opentelemetry-js/blob/2053f0d3a44631ade77ea04f656056a2c8a2ae76/packages/opentelemetry-sdk-trace-base/src/platform/node/RandomIdGenerator.ts#L22)) ### PoC PoC here: https://github.com/benweissmann/CVE-2025-7783-poc Instructions are in that repo. It's based on the PoC from https://hackerone.com/reports/2913312 but simplified somewhat; the vulnerable application has a more direct side-channel from which to observe Math.random() values (a separate endpoint that happens to include a randomly-generated request ID). ### Impact For an application to be vulnerable, it must: - Use `form-data` to send data including user-controlled data to some other system. The attacker must be able to do something malicious by adding extra parameters (that were not intended to be user-controlled) to this request. Depending on the target system's handling of repeated parameters, the attacker might be able to overwrite values in addition to appending values (some multipart form handlers deal with repeats by overwriting values instead of representing them as an array) - Reveal values of Math.random(). It's easiest if the attacker can observe multiple sequential values, but more complex math could recover the PRNG state to some degree of confidence with non-sequential values. If an application is vulnerable, this allows an attacker to make arbitrary requests to internal systems. | |
| 9.4CVSS 4.0 | GHSA-jmqq-x5g9-9p2w
CVE-2026-107282 |
Resolved | 2026-10-08 | 5.7 ×35.6 ×95.5 ×205.4 ×14 | ### Impact When a request is replayed onto a different host, the client updates only the current request and leaves the target request pointing at the original host. Four consumers read that stale value, and each one sends the first host's request, credentials, or both to the second host. A replay happens through documented, ordinary features: a `ResponseFilter` that returns a different request, which is the supported failover pattern, and the IOException retry path. The attacker does not need to induce the replay; an application that uses failover produces it by design. * The socket to host B is filed in the connection pool under host A's key. A later request the application addresses to A is served over the connection to B, and A's `Authorization` header goes to B. * Over a CONNECT tunnel, the client tunnels to B and negotiates TLS with B correctly, then writes A's request into that tunnel. B receives A's path, A's `Host`, and A's `Authorization`. TLS does not protect against this, because the handshake really is with B, so no certificate mismatch occurs. * The replay reuses the original realm, so A's credentials are regenerated onto a replay request that carries no realm of its own. The cross-origin redirect path strips realms for exactly this reason; the replay path never did. * The stale value also decides whether TLS is used at all. When the original request was `http://` and the replay is `https://`, no SSL handler is installed and the replayed request, credentials included, is written in cleartext. ### Affected versions * 3.x: up to and including 3.0.12 * 2.x: up to and including 2.16.0 Both lines are affected identically. This is long-standing behaviour, not a recent regression. ### Patches Fixed in 3.0.13 on the 3.x line and in 2.16.1 on the 2.x line. The target request now moves when a request is replayed, and the proxy moves with it: the proxy is part of the connection pool key, so correcting only the host would convert a harmless pool miss into a hit and route a proxied connection to a direct request. ### Workarounds Do not use a `ResponseFilter` that replays to a different host, and disable request retries, if the client is configured with credentials or used through a proxy. Replaying to the same host is not affected. ### Details `NettyRequestSender.newNettyRequestAndResponseFuture` calls `setCurrentRequest` without `setTargetRequest`, and `replayRequest` does not move the target either. The stale target is then read by the pool key derivation in `NettyResponseFuture`, by `ConnectSuccessInterceptor` when it writes the tunnelled request, by the realm selection in `NettyRequestSender`, and by `NettyConnectListener` when it decides whether to install an SSL handler. Existing replay tests do not cover this, because all of them replay to the same host. | |
| 9.3CVSS 4.0 | CVE-2025-14813
GHSA-574f-3g2m-x479 |
Resolved | 2026-04-15 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | : Use of a Broken or Risky Cryptographic Algorithm vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA bcprov on all (core modules). This vulnerability is associated with program files G3413CTRBlockCipher. This issue affects BC-JAVA: from 1.59 before 1.80.2, from 1.81 before 1.81.1, from 1.82 before 1.84. | |
| 9.3CVSS 4.0 | CVE-2026-33701
|
Not affected | 2026-03-27 | 5.6 ×95.5 ×205.4 ×14 | OpenTelemetry Java Instrumentation provides OpenTelemetry auto-instrumentation and instrumentation libraries for Java. In versions prior to 2.26.1, the RMI instrumentation registered a custom endpoint that deserialized incoming data without applying serialization filters. On JDK version 16 and earlier, an attacker with network access to a JMX or RMI port on an instrumented JVM could exploit this to potentially achieve remote code execution. All three of the following conditions must be true to exploit this vulnerability: First, OpenTelemetry Java instrumentation is attached as a Java agent (`-javaagent`) on Java 16 or earlier. Second, JMX/RMI port has been explicitly configured via `-Dcom.sun.management.jmxremote.port` and is network-reachable. Third, gadget-chain-compatible library is present on the classpath. This results in arbitrary remote code execution with the privileges of the user running the instrumented JVM. For JDK >= 17, no action is required, but upgrading is strongly encouraged. For JDK < 17, upgrade to version 2.26.1 or later. As a workaround, set the system property `-Dotel.instrumentation.rmi.enabled=false` to disable the RMI integration. | |
| 9.3CVSS 4.0 | CVE-2026-8763
GHSA-9pwp-9qqc-pr26 |
Resolved | 2026-08-03 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | In Bouncy Castle for Java before 1.85, Name Constraints bypass via trailing dot in rfc822Name and URI. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series). | |
| 9.3CVSS 4.0 | GHSA-37j7-fg3j-429f
CVE-2025-61927 |
False positive | 2025-10-10 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | # Escape of VM Context gives access to process level functionality ## Summary Happy DOM v19 and lower contains a security vulnerability that puts the owner system at the risk of RCE (Remote Code Execution) attacks. A Node.js VM Context is not an isolated environment, and if the user runs untrusted JavaScript code within the Happy DOM VM Context, it may escape the VM and get access to process level functionality. It seems like what the attacker can get control over depends on if the process is using ESM or CommonJS. With CommonJS the attacker can get hold of the `require()` function to import modules. Happy DOM has JavaScript evaluation enabled by default. This may not be obvious to the consumer of Happy DOM and can potentially put the user at risk if untrusted code is executed within the environment. ## Reproduce ### CommonJS (Possible to get hold of require) ```javascript const { Window } = require('happy-dom'); const window = new Window({ console }); window.document.write(` <script> const process = this.constructor.constructor('return process')(); const require = process.mainModule.require; console.log('Files:', require('fs').readdirSync('.').slice(0,3)); </script> `); ``` ### ESM (Not possible to get hold of import or require) ```javascript const { Window } = require('happy-dom'); const window = new Window({ console }); window.document.write(` <script> const process = this.constructor.constructor('return process')(); console.log('PID:', process.pid); </script> `); ``` ## Potential Impact #### Server-Side Rendering (SSR) ```javascript const { Window } = require('happy-dom'); const window = new Window(); window.document.innerHTML = userControlledHTML; ``` #### Testing Frameworks Any test suite using Happy-DOM with untrusted content may be at risk ## Attack Scenarios 1. **Data Exfiltration**: Access to environment variables, configuration files, secrets 2. **Lateral Movement**: Network access for connecting to internal systems. Happy DOM already gives access to the network by fetch, but has protections in place (such as CORS and header validation etc.). 3. **Code Execution**: Child process access for running arbitrary commands 4. **Persistence**: File system access ## Recommended Immediate Actions 1. Update Happy DOM to v20 or above - This version has JavaScript evaluation disabled by default - This version will output a warning if JavaScript is enabled in an insecure environment 2. Run Node.js with the "--disallow-code-generation-from-strings" if you need JavaScript evaluation enabled - This makes sure that evaluation can't be used at process level to escape the VM - `eval()` and `Function()` can still be used within the Happy DOM VM without any known security risk - Happy DOM v20 and above will output a warning if this flag is not in use 4. If you can't update Happy DOM right now, it's recommended to disable JavaScript evaluation, unless you completely trust the content within the environment ## Technical Root Cause All classes and functions inherit from [Function](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function). By walking the constructor chain it's possible to get hold of [Function](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function) at process level. As [Function](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function) can evaluate code from strings, it's possible to execute code at process level. Running Node with the "--disallow-code-generation-from-strings" flag protects against this. | |
| 9.3CVSS 4.0 | GHSA-574f-3g2m-x479
CVE-2025-14813 |
Resolved | 2026-04-17 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | The GOST 28147-2015 CTR mode implementation (`G3413CTRBlockCipher`) in the Legion of the Bouncy Castle BC-JAVA `bcprov` core module only increments the final byte of the counter, so the counter wraps after 255 blocks and the keystream is reused. Reusing CTR keystream allows an attacker who can observe two ciphertexts produced with the same key/IV to recover the XOR of the plaintexts, breaking confidentiality. Affects BC-JAVA from 1.59 before 1.84 (with backported fixes in 1.80.2 and 1.81.1). | |
| 9.3CVSS 4.0 | GHSA-9pwp-9qqc-pr26
CVE-2026-8763 |
Resolved | 2026-08-03 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | In Bouncy Castle for Java before 1.85, Name Constraints bypass via trailing dot in rfc822Name and URI. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series). | |
| 9.2CVSS 4.0 | CVE-2024-53990
GHSA-mfj5-cf8g-g2fv |
Resolved | 2024-12-02 | 5.4 ×12 | The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. When making any HTTP request, the automatically enabled and self-managed CookieStore (aka cookie jar) will silently replace explicitly defined Cookies with any that have the same name from the cookie jar. For services that operate with multiple users, this can result in one user's Cookie being used for another user's requests. | |
| 9.2CVSS 4.0 | CVE-2026-109619
|
Resolved | 2026-10-21 | 5.5 ×205.4 ×14 | PHP has various global state that temporarily points into request memory. In some scenarios, global state may not be correctly reset, or may be repopulated after being reset. The global state may then refer to request memory even after it has been freed. Subsequent requests may read or branch on this stale state before it is fully initialized. Multiple strategies can trigger this condition and produce remote code execution (RCE). | |
| 9.2CVSS 4.0 | CVE-2026-25547
|
False positive | 2026-02-04 | 5.5 ×85.4 ×11 | @isaacs/brace-expansion is a hybrid CJS/ESM TypeScript fork of brace-expansion. Prior to version 5.0.1, @isaacs/brace-expansion is vulnerable to a denial of service (DoS) issue caused by unbounded brace range expansion. When an attacker provides a pattern containing repeated numeric brace ranges, the library attempts to eagerly generate every possible combination synchronously. Because the expansion grows exponentially, even a small input can consume excessive CPU and memory and may crash the Node.js process. This issue has been patched in version 5.0.1. | |
| 9.2CVSS 4.0 | CVE-2026-54466
GHSA-xv26-6w52-cph6 |
Resolved | 2026-07-17 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | websocket-driver is a WebSocket protocol handler with pluggable I/O. Prior to 0.7.5, the frame format in draft versions of the WebSocket protocol includes a length header that allows an arbitrarily large integer to be encoded as a sequence of bytes with the high bit set. By sending an indefinite sequence of bytes with values 0x80 or above, a client can make the server parse these bytes into an ever-growing integer in lib/websocket/driver/draft75.js; because JavaScript numbers are 64-bit floating point values, this number will eventually lose precision and lead to the subsequent payload being parsed incorrectly. This issue is fixed in version 0.7.5. |