Source Map Leak in a Closed-Source AI Coding CLI: Technical Postmortem and Hardening Guide

1. Incident overview: a debug file that turned into a release failure

On 31 March 2026, a closed-source intelligent coding command-line tool published a new version on a public package registry. The package included a source map of nearly 60MB. The map not only listed compressed frontend and backend source paths, but also retained large amounts of near-original TypeScript.

Worse, the source map contained paths to internal object-storage resources. Because access control on those resources was weak, outsiders could fetch unobfuscated source archives. What started as a single debug file in a release package quickly became a full codebase circulating on the internet.

Public disclosures indicated roughly 1,900 files and more than 500,000 lines of code, covering authorization, query execution, multi-agent collaboration, editor integration, session persistence, and internal experimental features. This was not a typical client-script leak; it was broad exposure of a production-grade AI coding platform.

Source-code exposure does not mean every system was compromised. It does, however, lower the cost of understanding the system and raises the risk of API abuse, logic bypasses, supply-chain attacks, and inference of internal details.

2. Timeline: from publish to wide diffusion

2.1 06:36 UTC: new version reaches the public channel

A new version was pushed to the public package registry. The package contained a cli.js.map file of about 59.8MB. Source maps exist so developers can map minified JavaScript back to original files, line numbers, and identifiers at runtime.

Shipping source maps in production is not always forbidden, but closed-source products must decide based on policy. If debugging is required, maps belong in controlled storage, behind tokens, and in a dedicated error-tracking system—not in a public installer.

2.2 08:23 UTC: researchers disclose publicly

Researchers published analysis and a direct download path on public social channels. The material spread quickly.

Risk shifted from “one package accidentally included a debug file” to “anyone can download and analyze the sources.” Even if the publisher later deleted the version, copies that had been downloaded, cached, or mirrored could remain.

2.3 Following hours: code is archived repeatedly

Multiple hosting locations preserved the leak. Community members classified, deduplicated, and annotated files. Some focused on permission checks, tool invocation, config loading, internal commands, and environment variables; others tried to reconstruct agent orchestration and session management.

Secondary spread creates two problems: organizations cannot easily know how far the code went, and attackers may modify and republish it as fake packages, malicious install scripts, or backdoored derivatives.

2.4 Later the same day: rewrites and substitutes appear

Soon after, projects appeared that reimplemented similar behavior from public descriptions and general programming skill, typically avoiding verbatim copies and redesigning modules while matching CLI behavior.

A rewrite does not prove the original system was fully cloned, but it shows that a leak can change competition, ecosystem compatibility, and defense. For a closed-source tool, code assets, architecture experience, and unreleased feature plans can lose confidentiality.

3. Direct technical causes

3.1 Production builds emit source maps by default

Modern frontend and CLI tools are bundled, minified, and transpiled. Source maps map the final artifact back to original sources and are valuable in development.

A default that is right for local debugging is not automatically right for production. If the build always emits maps and the release pipeline never strips them, debug artifacts enter the public package.

3.2 Package manifests lack an allowlist

Teams often rely on exclude rules (ignore certain directories or suffixes). Excludes break when directories move, bundlers upgrade, or names change.

A more reliable pattern is an allowlist: only named files may enter the installer; everything else is forbidden. Closed-source packages should typically contain only runtime scripts, required assets, license text, and minimal configuration.

3.3 Object storage was too open

If a source map retains internal resource URLs and the bucket allows anonymous reads, a second leak path exists. Withdrawing the public package does not stop the leak if storage objects remain readable.

Object storage should require authentication, short-lived tokens, origin restrictions, download audit, and anomaly alerts. Source archives, internal build artifacts, and debug dumps should never use public-read policies.

4. Risks from the leaked content

4.1 Business logic and permission boundaries

Source helps attackers see how identity, tool permissions, session state, and feature flags are decided. Even without secrets, they can craft more targeted inputs and hunt for logic bypasses.

Watch for “client checks instead of server checks.” If authorization lives only in local code, attackers can patch the client and still call backend APIs.

4.2 Internal features and unpublished configuration

Code may contain experimental commands, hidden flags, environment-variable names, debug switches, and internal service paths. These are not always vulnerabilities, but they speed reconnaissance.

Variable names alone are not secrets, but together with defaults, service URLs, token formats, or load logic they can reveal architecture.

4.3 Third-party dependencies and supply chain

With sources public, others can pinpoint dependency versions, build scripts, and install flow. If install-time scripts run, attackers may impersonate package names, alter resolution, or lure users into malicious variants.

Response must go beyond the source tree: signatures, publish permissions, build nodes, lockfiles, and download logs.

5. Incident response for organizations

Step 1: Stop distribution of affected versions

Pause publish and install of impacted versions, pull sensitive files from public packages, and retain evidence: package hashes, build logs, access logs, and object-storage audit records. Do not wipe all evidence; that harms investigation.

Step 2: Rotate every credential that might have been exposed

Inventory tokens, keys, test accounts, internal service credentials, and signing certificates that appear in code. Rotate them as if they were already compromised, even without proof of use.

Step 3: Hunt for access and abuse

Analyze unusual downloads, API calls, authorization failures, config reads, and mass scanning. For high-risk operations, temporarily add step-up verification, rate limits, and human approval.

Step 4: Rebuild and verify the package

Do not merely delete the source map and re-upload. Rebuild from a clean environment, then run file-list audit, sensitive-string scan, credential detection, dependency audit, and install tests so the final package contains only what is required.

6. Long-term release-pipeline improvements

1. Disable source maps in production builds by default. If they are required, store them in a controlled location, fully isolated from public installers.

2. Allowlist the release package. Emit a file inventory before publish; reject source, test data, internal docs, private keys, debug logs, and unauthorized config.

3. Add blocking checks in CI. Scan for high-risk suffixes, suspected secrets, internal domains, object-storage URLs, and debug fields. Fail the release; do not only warn.

4. Two-person review and traceable publish. Separate build, review, signing, and publish, with tamper-evident audit logs.

5. Default-deny object storage. No anonymous read without explicit authorization; sensitive files use short-lived grants and download audit.

6. Withdrawal and notification. After a leak, quickly publish affected version ranges, risk notes, upgrade guidance, and credential-handling requirements so users do not keep running a risky build.

7. Core takeaway

The warning is not one product’s internals, but stacked defaults in the delivery chain: bundlers emit debug files, packagers scoop up directories, storage allows access, and teams assume closed source will not be downloaded.

A reliable security program cannot depend on “nobody notices.” From commit through artifact, packaging, object storage, review, and user install, each step needs explicit boundaries, automated checks, and least privilege.

For engineering teams, the lesson is practical: closed source is not invisible, the release package is an attack surface, and debug files are a data exfil path. Move controls into build and publish so problems are found before code leaves the internal environment, and a simple misconfiguration does not become a large supply-chain incident.