CVE-2026-4800: lodash vulnerable to Code Injection via `_.template` imports key names

Published Mar 31, 2026
·
Updated

Impact

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. 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. If Object.prototype has been polluted by any other vector, the polluted keys are copied into the imports object and passed to Function().

Patches

Users should upgrade to version 4.18.0.

The fix applies two changes: 1. Validate importsKeys against the existing reForbiddenIdentifierChars regex (same check already used for the variable option) 2. Replace assignInWith with assignWith when merging imports, so only own properties are enumerated

Workarounds

Do not pass untrusted input as key names in options.imports. Only use developer-controlled, static key names.

Other sources

Impact:

The fix for CVE-2021-23337 (https://github.com/advisories/GHSA-35jh-r3h4-6jhm) added validation for the variable option in .template but did not apply the same validation to options.imports key names. 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. If Object.prototype has been polluted by any other vector, the polluted keys are copied into the imports object and passed to Function().

Patches:

Users should upgrade to version 4.18.0.

Workarounds:

Do not pass untrusted input as key names in options.imports. Only use developer-controlled, static key names.

MITRE

The non-blocking (async) JSON parser in jackson-core bypasses the maxNumberLength constraint (default: 1000 characters) defined in StreamReadConstraints. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS). The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.

IBM

Affected Software

12 affected componentsFixes available
npm/lodash<4.18.0
npm/lodash.template>=4.0.0<4.18.0
4.18.0
npm/lodash-amd>=4.0.0<=4.17.23
4.18.0
npm/lodash-es>=4.0.0<=4.17.23
4.18.0
npm/lodash>=4.0.0<=4.17.23
4.18.0
Lodash Lodash Node.js>=4.0.0<4.18.0
Lodash Lodash-amd Node.js>=4.0.0<4.18.0
Lodash Lodash-es Node.js>=4.0.0<4.18.0
Lodash Lodash.template Node.js>=4.0.0<4.18.0
IBM MQ Operator<=SC2: v3.2.0 - v3.2.23 CD:  v3.3.0, v3.4.0, v3.4.1, v3.5.0, v3.5.1 - v3.5.3, v3.6.0 - v3.6.4, v3.7.0 - v3.7.2, v3.8.0, v3.8.1, v3.9.0, v3.9.1 LTS: v2.0.0 - 2.0.29
IBM supplied MQ Advanced container images<=SC2: 9.4.0.6-r1, 9.4.0.6-r2, 9.4.0.7-r1, 9.4.0.10-r1, 9.4.0.10-r2, 9.4.0.11-r1, 9.4.0.11-r2, 9.4.0.11-r3, 9.4.0.12-r1, 9.4.0.15-r1 - 9.4.0.15-r4, 9.4.0.16-r1, 9.4.0.16-r2, 9.4.0.17-r1, 9.4.0.17-r2, 9.4.0.20-r1CD: 9.4.1.0-r1, 9.4.1.0-r2, 9.4.1.1-r1, 9.4.2.0-r1, 9.4.2.0-r2, 9.4.2.1-r1, 9.4.2.1-r2, 9.4.3.0-r1, 9.4.3.0-r2, 9.4.3.1-r1 - 9.4.3.1-r3, 9.4.4.0-r1 - 9.4.4.0-r4, 9.4.4.1-r1, 9.4.5.0-r1, 9.4.5.0-r2LTS: 9.3.0.0-r1, 9.3.0.0-r2, 9.3.0.0-r3, 9.3.0.1-r1, 9.3.0.1-r2, 9.3.0.1-r3, 9.3.0.1-r4, 9.3.0.3-r1, 9.3.0.4-r1, 9.3.0.4-r2, 9.3.0.5-r1, 9.3.0.5-r2, 9.3.0.5-r3, 9.3.0.6-r1, 9.3.0.10-r1, 9.3.0.10-r2, 9.3.0.11-r1,9.3.0.11-r2, 9.3.0.15-r1, 9.3.0.16-r1, 9.3.0.16-r2, 9.3.0.17-r1, 9.3.0.17-r2, 9.3.0.17-r3, 9.3.0.20-r1, 9.3.0.20-r2, 9.3.0.21-r1, 9.3.0.21-r2, 9.3.0.21-r3, 9.3.0.25-r1, 9.4.0.0-r1, 9.4.0.0-r2, 9.4.0.0-r3, 9.4.0.5-r1, 9.4.0.5-r2
debian/node-lodash<=4.17.21+dfsg+~cs8.31.173-1, <=4.17.21+dfsg+~cs8.31.198.20210220-9
4.18.1+dfsg-3

Event History

Mar 31, 2026
CVE Published
via MITRE·07:25 PM
Data Sourced
via MITRE·07:25 PM
DescriptionSeverityWeakness
Data Sourced
via Red Hat·08:01 PM
DescriptionSeverityAffected Software
Data Sourced
via NVD·08:16 PM
DescriptionSeverityWeaknessAffected Software
Apr 1, 2026
Advisory Published
via GitHub·11:51 PM
Data Sourced
via GitHub·11:51 PM
DescriptionSeverityWeaknessAffected Software
May 15, 2026
Data Sourced
via IBM·12:00 AM
DescriptionAffected Software
Jun 9, 2026
Data Sourced
via Debian·06:09 PM
DescriptionAffected Software
Data Sourced
via Launchpad·06:09 PM
Description
Jun 10, 2026
Data Sourced
via Ubuntu·06:08 PM
RemedyDescriptionSeverityAffected Software

Parent advisories

This vulnerability appears in the following advisories.

Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-4800?

CVE-2026-4800 is rated as a high severity vulnerability due to its potential for code injection.

2

How can I fix CVE-2026-4800?

To fix CVE-2026-4800, update lodash to version 4.18.1 or later, where the issue has been addressed.

3

What impact does CVE-2026-4800 have on my application?

CVE-2026-4800 allows attackers to execute arbitrary code within the context of the application that uses lodash's template function.

4

Which versions of lodash are affected by CVE-2026-4800?

Lodash versions before 4.18.1 are affected by CVE-2026-4800.

5

Is there a workaround for CVE-2026-4800?

There is no effective workaround for CVE-2026-4800 other than upgrading to a patched version of lodash.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203