Cloudanix VulnDB

CVE-2026-49356

Low · 3.2

CVSS

3.2

EPSS

0.2%

Published

Jun 22, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in a common JavaScript build tool could let someone who submits code to be compiled read certain local source map files from the build machine.

Chainable
Exploitation
Local Privilege
Attacker needs
None
Complexity
High
Impact
Data Exposure
Component
Library
Class
Information Disclosure
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The flaw is an information disclosure issue in @babel/core before 7.29.6 and 8.0.0-rc.6. When Babel compiles attacker-controlled JavaScript containing a crafted sourceMappingURL comment, Babel can resolve and read a source map file from the local filesystem of the machine performing compilation. If the attacker can view the compiled output and knows or can guess the target source map path, the contents of that source map may be exposed. Impact is limited to confidentiality; the vulnerability does not directly allow code execution, file modification, or denial of service.

Why it matters to the business

Organizations that run Babel on untrusted or externally supplied JavaScript could unintentionally expose local source map files from build systems, CI workers, developer machines, or hosted compilation services. Exposed source maps may reveal proprietary source code, internal paths, comments, build structure, or other sensitive development details. The risk is lower than typical remote compromise because exploitation requires control of input code, visibility into the compiler output, and knowledge of a target source map path, but Babel is widely used in JavaScript build pipelines, so exposed build services should be reviewed promptly.

How an attack unfolds

An attacker first identifies a workflow where their JavaScript is processed by @babel/core, such as an online transpilation service, plugin marketplace workflow, CI job, code preview feature, or any system that compiles user-submitted code. They craft JavaScript containing a sourceMappingURL comment that points to a local source map file path on the Babel host. During compilation, vulnerable Babel versions may resolve that reference and read the referenced source map. If the build or service returns the generated output to the attacker, the attacker inspects the output for embedded source map content or derived information. Repeated attempts may be used to guess common build paths and source map filenames. There is no known KEV listing, no reported ransomware association, and exploit maturity is currently listed as none, so defensive focus should be on exposure reduction and log review for suspicious source map references rather than active mass exploitation indicators.

How to fix it

Upgrade @babel/core to a fixed version: 7.29.6 or later for the 7.x line, or 8.0.0-rc.6 or later for the 8.x release-candidate line. Regenerate lockfiles and redeploy build images, CI runners, developer containers, and hosted compilation services so the patched dependency is actually in use. If immediate upgrade is not possible, avoid compiling untrusted JavaScript with Babel, strip or reject sourceMappingURL comments from untrusted input before compilation, run Babel in a sandbox with minimal filesystem access, and ensure build outputs returned to users do not include source map contents. Also restrict source map generation and publication to only what is required, and avoid storing sensitive source maps on shared build hosts.

How to confirm the fix worked

Confirm dependency resolution with package-manager tooling such as npm ls @babel/core, yarn why @babel/core, pnpm why @babel/core, or by inspecting package-lock.json, yarn.lock, pnpm-lock.yaml, and container image SBOMs. Validate that all build, CI, and runtime images using Babel resolve @babel/core to 7.29.6 or later, or 8.0.0-rc.6 or later. Test exposed compilation features by submitting input containing suspicious sourceMappingURL comments and confirming the service does not read local files or return embedded source map content. Review build artifacts to ensure they do not include unexpected sourcesContent, local filesystem paths, or source maps sourced from outside the intended workspace.

Typical attack path

  1. Find an application, build service, CI workflow, or developer tool that runs @babel/core on attacker-controlled JavaScript.
  2. Submit JavaScript containing a crafted sourceMappingURL comment referencing a local source map path on the compilation host.
  3. Cause the vulnerable Babel process to compile the malicious input.
  4. Retrieve or view the compiled JavaScript output produced by the service or build workflow.
  5. Inspect the output for leaked source map contents, embedded sources, local filesystem paths, or other source metadata.
  6. Repeat with guessed source map paths to enumerate additional readable source map files.

How to detect it

Look for evidence that untrusted JavaScript submitted to Babel contained crafted sourceMappingURL comments. Useful sources include application request logs for code-submission endpoints, CI job logs, build service logs, artifact storage, source-code preview records, temporary build workspaces, and compiled JavaScript outputs returned to users. Search for sourceMappingURL values using absolute Unix paths, Windows drive paths, file:// URLs, path traversal sequences, or references to source map files outside the expected project workspace. In generated artifacts, look for unexpected sourcesContent fields, internal filesystem paths, or source map JSON from unrelated projects. Because there are no public threat-actor or KEV exploitation indicators for this issue, detection should focus on suspicious source map references and unusual disclosure of build-host file paths rather than known malware or network indicators.

  • sourceMappingURL=
  • //# sourceMappingURL=
  • /*# sourceMappingURL=
  • sourceMappingURL=file://
  • sourceMappingURL=/
  • sourceMappingURL=../
  • sourceMappingURL=..\\
  • sourceMappingURL=C:\\
  • sourceMappingURL=D:\\
  • sourcesContent
  • webpack://
  • /node_modules/
  • .js.map
  • .map

What your security team should do

  • Inventory all applications, CI jobs, build containers, developer tooling, and hosted services that use @babel/core, including transitive usage through build frameworks.
  • Prioritize remediation for any service that compiles user-submitted or third-party JavaScript and returns compiled output to the submitter.
  • Upgrade @babel/core to 7.29.6 or later, or 8.0.0-rc.6 or later, and verify lockfiles and deployed artifacts reflect the patched version.
  • Add input validation or preprocessing to remove sourceMappingURL comments from untrusted JavaScript where source maps are not required.
  • Run Babel processing of untrusted code in a restricted sandbox with read access limited to a disposable working directory.
  • Search historical logs and submitted code samples for sourceMappingURL values containing absolute paths, file URLs, traversal sequences, or unexpected .map filenames.
  • Review previously returned build outputs for unexpected embedded source map content, sourcesContent fields, or internal filesystem paths.
  • Reduce sensitive information in source maps and avoid storing proprietary or production source maps on systems that process untrusted code.

The record

Babel is a compiler for writing next generation JavaScript. Prior to 8.0.0-rc.6 and 7.29.6, @babel/core affected by an arbitrary file read via a sourceMappingURL comment. Using @babel/core to compile maliciously crafted code can allow an attacker to read any source map from the system that is running Babel, if the attacker controls the input source code, can read the output source code, and knows the path of the source map file that they want to read. This vulnerability is fixed in 8.0.0-rc.6 and 7.29.6.

Affected packages

Ecosystem Package Introduced Fixed
npm @babel/core 0 7.29.6
npm @babel/core 8.0.0-alpha.0 8.0.0-rc.6

Related vulnerabilities