How severe is GHSA-r5fr-rjxr-66jc?

GHSA-r5fr-rjxr-66jc has a CVSS score of 8.1/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by GHSA-r5fr-rjxr-66jc?

GHSA-r5fr-rjxr-66jc affects the following packages: lodash (npm), lodash-es (npm), lodash-amd (npm), lodash.template (npm). Ecosystems affected: npm.

How do I fix GHSA-r5fr-rjxr-66jc?

Update lodash to 4.18.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-r5fr-rjxr-66jc is resolved across your whole dependency graph.

How do I detect GHSA-r5fr-rjxr-66jc in my npm dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for lodash. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-r5fr-rjxr-66jc if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-r5fr-rjxr-66jc?

O3 pinpoints whether GHSA-r5fr-rjxr-66jc is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-r5fr-rjxr-66jc actively exploited in the wild?

Yes. There are 6 known exploit references for GHSA-r5fr-rjxr-66jc, including 6 in-the-wild exploitations observed on GitHub and other sources. Treat this as actively exploitable and prioritize patching immediately. All exploit code should only be run in an isolated sandbox environment for research or authorized testing — never against production systems without explicit written authorization.

What is the EPSS score for GHSA-r5fr-rjxr-66jc?

GHSA-r5fr-rjxr-66jc has an EPSS (Exploit Prediction Scoring System) score of 21.3%, placing it in the 97th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score warrants monitoring and prompt remediation.

What type of vulnerability is GHSA-r5fr-rjxr-66jc?

GHSA-r5fr-rjxr-66jc is classified as Code Injection (CWE-94). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation. This is a high-impact weakness class that often enables remote code execution or data exposure.

Is there exploit tooling available for GHSA-r5fr-rjxr-66jc?

A Nuclei detection template exists for GHSA-r5fr-rjxr-66jc, meaning automated scanners can fingerprint it. Public exploit tooling significantly increases real-world risk — prioritize patching and ensure detection coverage. Exploit tooling should only ever be used in isolated, authorized testing environments.

When was GHSA-r5fr-rjxr-66jc published, and has it been updated?

GHSA-r5fr-rjxr-66jc was published on April 1, 2026 and was last updated on July 8, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦 npm

GHSA-r5fr-rjxr-66jc

HIGH

lodash vulnerable to Code Injection via `_.template` imports key names

Also known asCVE-2021-23337 CVE-2026-4800 GHSA-35jh-r3h4-6jhm

Published

Apr 1, 2026

Updated

Jul 8, 2026

Affected

4 pkgs

Patched

4 / 4

Exploits

6 known

EPSS Exploitation Probability

via FIRST.org ↗

21.3%probability of exploitation in next 30 days

Moderate Risk97th percentile-1.08%

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

4 pkgs affected

Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.

lodashnpm

163.6Mdownloads / week

lodash-esnpm

42.0Mdownloads / week

lodash.templatenpm

4.4Mdownloads / week

Description

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:

Validate importsKeys against the existing reForbiddenIdentifierChars regex (same check already used for the variable option)
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.

Affected Packages

4 total 4 fixed

Ecosystem	Package	Vulnerable range	Fix
📦npm	`lodash`	≥ 4.0.0&&< 4.18.0	4.18.0
📦npm	`lodash-es`	≥ 4.0.0&&< 4.18.0	4.18.0
📦npm	`lodash-amd`	≥ 4.0.0&&< 4.18.0	4.18.0
📦npm	`lodash.template`	≥ 4.0.0&&< 4.18.0	4.18.0

Exploits & PoCs

Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.