@babel/core CVE-2026-49356

Exploitation requires all three of the following conditions to be simultaneously true: (1) the attacker controls the content of the source code being compiled by @babel/core - this is the enabling condition and excludes all deployments that only compile internally authored, trusted code; (2) the attacker can read the output produced by Babel after compilation - this limits exploitation to scenarios where build artifacts, transpiled output, or logs are accessible to the attacker; (3) the attacker knows or can guess the absolute or relative path of the source map file they wish to read on the host system. Exploitation is also limited to files that the Babel process has read permissions for on the host filesystem. The inputSourceMap option must not have been explicitly set to false in the Babel configuration - the default behavior of following #sourceMappingURL comments is what creates the attack surface. Deployments that only compile trusted, internally controlled source code are explicitly not impacted.

The CVSS base score of 3.2 (Low) reflects a tightly constrained exploitation scenario: AV:L indicates the original assessment treats this as a local-vector attack, AC:H captures the high complexity due to three simultaneous conditions, S:C (Scope Changed) recognizes that Babel reads files outside its own data scope, and C:L reflects limited confidentiality impact. However, in real-world deployments where Babel compiles externally submitted or user-provided code - a common scenario in CI/CD systems accepting pull requests, online JavaScript playgrounds, or multi-tenant transpilation services - the effective attack vector is closer to network-accessible, making the practical risk materially higher than the raw score suggests. No EPSS data was provided in the input, and the vulnerability is not listed in CISA KEV, indicating no confirmed active exploitation. No public proof-of-concept is identified. The three-condition requirement (attacker controls input, attacker can read output, attacker knows the target path) meaningfully limits opportunistic exploitation, but in targeted scenarios - such as a malicious open-source contributor submitting code to a CI pipeline - all three conditions can plausibly be satisfied simultaneously. Teams running Babel against trusted-only code are explicitly not impacted per the vendor advisory.

A malicious contributor submits a pull request to an open-source project whose CI pipeline compiles JavaScript using @babel/core. The submitted file contains a crafted #sourceMappingURL comment pointing to a sensitive file path on the CI runner - for example, an SSH private key stored as a .map-extension file, or a JSON configuration file with credentials. Babel resolves the path, reads the file, and embeds its contents in the compilation output; the attacker then reads the CI artifact or build log where the output is stored, recovering the file contents. No public proof-of-concept has been identified, but the attack requires no special tooling beyond a crafted source file.