Babel CVE-2026-44728

Exploitation requires all of the following: (1) the target build uses @babel/plugin-transform-modules-systemjs directly, or @babel/preset-env with the non-default modules: "systemjs" option enabled; (2) a vulnerable version is installed (plugin 7.12.0-7.29.3 or 8.0.0-alpha.0-alpha.12); and (3) the pipeline compiles attacker-controlled/untrusted source code - the vendor states that users who compile only trusted code are not impacted. Limiting factors: the SystemJS module format is a specific opt-in configuration and not Babel's default output; exploitation is gated behind a developer/CI actually running the build over the malicious input (CVSS UI:R); and the impact is realized only when the generated output is subsequently loaded and executed. There is no network-facing service in Babel itself - the attack vector is the source fed into the build (CVSS AV:L).

Signals diverge sharply and should be weighed together. The CVSS 3.1 base is 8.2 (High) with vector AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H - a local vector requiring user interaction (a developer running the build) and a scope change (the injected code executes in a downstream runtime context), with full CIA impact. Against that, EPSS is only 0.02% (6th percentile), there is no CISA KEV listing and no public exploit identified at time of analysis, indicating negligible evidence of opportunistic mass exploitation. The dominant limiting factor is the trust boundary: exploitation requires compiling attacker-controlled source, which is uncommon outside services that build user-submitted code (SaaS build/CI, online playgrounds, plugin marketplaces). Net assessment: this is a legitimate high-severity supply-chain/build-integrity issue for the narrow population that compiles untrusted code with SystemJS output, but a low real-world priority for the majority who compile only their own trusted code. Note a minor tension worth verifying with the vendor: the vector uses PR:L, yet the practical prerequisite is supplying input rather than holding privileges on the build host - the meaningful gate is untrusted input plus the SystemJS configuration, not authentication level.

An attacker submits a specially crafted JavaScript module to a service that transpiles user-supplied code with Babel configured for SystemJS output (for example a CI job building a submitted plugin, or an online build/preview service). When Babel runs the SystemJS module transform, the generated bundle contains attacker-controlled statements, so arbitrary code executes wherever that output is later loaded and run. No public exploit is identified at time of analysis, and the local vector plus required build execution (UI:R) mean the attacker depends on the victim actually compiling the malicious input.