jashkenas underscore up to 1.13.7 _.flatten allocation of resources

Summaryinfo

A vulnerability marked as problematic has been reported in jashkenas underscore up to 1.13.7. This affects the function _.flatten. This manipulation causes allocation of resources. This vulnerability is registered as CVE-2026-27601. Remote exploitation of the attack is possible. No exploit is available. It is suggested to upgrade the affected component.

Detailsinfo

A vulnerability classified as problematic was found in jashkenas underscore up to 1.13.7. Affected by this vulnerability is the function _.flatten. The manipulation with an unknown input leads to a allocation of resources vulnerability. The CWE definition for the vulnerability is CWE-770. The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor. As an impact it is known to affect availability. The summary by CVE is:

Underscore.js is a utility-belt library for JavaScript. Prior to 1.13.8, the _.flatten and _.isEqual functions use recursion without a depth limit. Under very specific conditions, detailed below, an attacker could exploit this in a Denial of Service (DoS) attack by triggering a stack overflow. Untrusted input must be used to create a recursive datastructure, for example using JSON.parse, with no enforced depth limit. The datastructure thus created must be passed to _.flatten or _.isEqual. In the case of _.flatten, the vulnerability can only be exploited if it is possible for a remote client to prepare a datastructure that consists of arrays at all levels AND if no finite depth limit is passed as the second argument to _.flatten. In the case of _.isEqual, the vulnerability can only be exploited if there exists a code path in which two distinct datastructures that were submitted by the same remote client are compared using _.isEqual. For example, if a client submits data that are stored in a database, and the same client can later submit another datastructure that is then compared to the data that were saved in the database previously, OR if a client submits a single request, but its data are parsed twice, creating two non-identical but equivalent datastructures that are then compared. Exceptions originating from the call to _.flatten or _.isEqual, as a result of a stack overflow, are not being caught. This vulnerability is fixed in 1.13.8.

The advisory is shared at github.com. This vulnerability is known as CVE-2026-27601 since 02/20/2026. The exploitation appears to be easy. The attack can be launched remotely. The exploitation doesn't need any form of authentication. Technical details are known, but no exploit is available. MITRE ATT&CK project uses the attack technique T1499 for this issue.

The vulnerability scanner Nessus provides a plugin with the ID 300943 (Linux Distros Unpatched Vulnerability : CVE-2026-27601), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 1.13.8 eliminates this vulnerability. Applying the patch 411e222eb0ca5d570cc4f6315c02c05b830ed2b4 is able to eliminate this problem. The bugfix is ready for download at github.com. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (300943) and CERT Bund (WID-SEC-2026-1220). Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Affected

• IBM App Connect Enterprise

Productinfo

Vendor

• jashkenas

Name

• underscore

Version

• 1.13.0
• 1.13.1
• 1.13.2
• 1.13.3
• 1.13.4
• 1.13.5
• 1.13.6
• 1.13.7

License

• open-source

Website

• Product: https://github.com/jashkenas/underscore/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion