Anatomy of an AI Coding Tool Source Code Leak: Full Timeline and Security Post-Mortem

1. Incident Overview

On March 31, 2026, an AI coding command-line tool distributed as a closed-source product was found to have inadvertently exposed its full source code. The problem did not stem from a sophisticated intrusion, but from a basic configuration mistake in production artifact management and the package publishing process: source map files generated during development debugging were uploaded to a public package registry along with the release. These files not only retained source code paths but also referenced publicly accessible object storage resources.

In terms of scope, what was exposed was not a handful of sample files or API wrappers, but a complete production-grade development agent system. Roughly 1,900 files with more than 510,000 lines of code became public, covering permission control, task orchestration, query execution, multi-agent coordination, editor connections, persistent memory, and command-line interaction.

The danger of this type of incident is that an attacker does not need to breach servers or steal accounts. Simply obtaining a legitimately published package may be enough to reconstruct extensive internal implementation details.

2. Full Timeline

06:36 UTC: The Affected Version Is Published

Earlier that day, the development team published a new version to a public package registry. The release included a source map file of approximately 59.8 MB.

Source map files are normally used for debugging. They map minified, obfuscated, or bundled production code back to the original source files, directory structure, variable names, and line numbers. For frontend applications and CLI programs, these files help trace production issues—but if they embed a full sourcesContent field, they can carry the original source code outright.

Ideally, a production release pipeline should enforce the following:

• Production packages contain no source map files;
• Even if maps are generated, they must not embed original source content;
• Debug artifacts live in an access-controlled internal artifact repository;
• Package contents are automatically inspected before release;
• Build directories and release directories are strictly separated.

In this incident, the bundler generated source map files by default, and the release manifest failed to exclude them, allowing debug artifacts into the official public package.

08:23 UTC: Researchers Disclose the Finding

Security researchers discovered the file and published their analysis through public channels, including directly accessible download paths. Since the links required no authentication, anyone could retrieve the files.

Once the information became public, the incident spread rapidly. Community users began downloading, unpacking, and searching the code, and mirrors appeared across multiple code hosting spaces. What could have been contained by withdrawing a single version quickly escalated into a problem of public distribution, repeated backups, and archives in multiple locations.

It is worth emphasizing: once a package enters the public internet, it is nearly impossible to fully eradicate by simply deleting the original file. Caches, mirrors, offline backups, and search engine indexes may all continue to retain the content.

Within Hours: Code Structure Fully Analyzed

After the community organized the leaked content, the system was found to include several key capabilities:

• More than 40 permission and operation control modules;
• Roughly 46,000 lines of query and task execution code;
• Multi-agent task dispatch and result coordination logic;
• An editor-facing connection layer;
• Session state and long-term memory mechanisms;
• About 35 compile-time feature flags;
• Over 120 undocumented environment variables;
• Multiple internal commands never publicly documented.

The value of this information goes beyond “seeing the source.” From the code, outsiders could infer trust boundaries, internal call ordering, exception handling approaches, debug switches, staged rollout features, and the organization of backend resources.

If the code had also contained test endpoints, internal paths, access tokens, key fragments, or service account information, the incident could have escalated from “source code exposure” to “credential leakage” and “infrastructure risk.”

Later That Day: A Compatible Rewrite Appears

After the source code became public, a developer quickly built a compatible version based on the observed behavior and generic functionality, without relying on the original code. The project reimplemented the core pipeline in a different programming language and attracted significant attention in a short time.

This phenomenon highlights two points.

First, the core capabilities of AI coding tools are rapidly becoming modular. Task parsing, tool invocation, context management, code modification, and result verification can now be reimplemented following common architectural patterns.

Second, a source code leak dramatically lowers the analysis cost for competitors and attackers. Even without copying code directly, outsiders can use the public implementation to understand the product design, then combine public interfaces and behavioral testing to quickly build alternatives.

3. Root Causes of the Leak

1. Blurred Boundary Between Debug and Production Artifacts

Source map files are not malicious in themselves—the problem is that they should never end up in a public production package. Many build tools generate maps by default to improve the debugging experience. When a team relies purely on “default behavior” without a second verification pass at release time, internal debug information can easily slip into public channels.

2. No Mandatory Validation in the Release Manifest

Package publishing typically depends on ignore files, build scripts, and directory conventions. But once these mechanisms are misconfigured, overlooked, or bypassed by a new packaging approach, they fail.

A more robust approach is not to rely solely on ignore rules, but to run automated checks before publishing, for example:

# Package manager pack
# Inspect archive contents
# Scan for source map files
# Scan for secrets and internal domains
# Scan for debug configs and test data
# Publish only after all checks pass

The release process should split “generate the candidate package” and “push to the public registry” into two stages, requiring both machine checks and human approval to pass.

3. Underestimating the Risks of Public Packages

Many teams treat package registries as ordinary file storage, but they are inherently highly propagative. Once a version is published, it can immediately be cached, mirrored, and redistributed.

Therefore, publishing a package should be managed as an irreversible public action—treating a version withdrawal as a complete remedy is not acceptable.

4. No Audit of Source Map Contents

Even if business code is minified or obfuscated, the protection largely collapses once the map file contains the original content. Security audits should not stop at file names; they should parse the map file structure and confirm whether it includes:

• Original source file content;
• Internal directories and usernames;
• Private API endpoints;
• Test credentials;
• Build environment variables;
• Undisclosed feature names;
• Internal service call relationships.

4. Impact Assessment

1. Intellectual Property Risk

With the full source code exposed, the system architecture, implementation approach, and business logic could be copied, modified, or used to build competing products. Even if external projects do not copy code verbatim, they can quickly produce similar implementations based on the exposed design.

2. Expanded Attack Surface

Source code helps attackers pinpoint key areas such as permission checks, input validation, command execution, file access, and network requests. They can craft more targeted test cases, reducing the cost of black-box probing.

3. Supply Chain Risk Propagation

If the leaked version was widely installed, secondary contamination becomes a real risk. For example, someone could create a malicious variant based on the public package—embedding backdoors or data-stealing logic—and use a similar name to trick users into installing it.

4. Erosion of User Trust

For closed-source tools, users generally assume that internal code, service endpoints, and security policies are protected. Once source code and internal configuration become public, enterprise customers may re-evaluate the vendor’s compliance posture, data isolation capabilities, and supply chain reliability.

5. Correct Emergency Response Workflow

After discovering an issue like this, teams should prioritize risk containment over assigning blame.

Step 1: Immediately stop further distribution of the affected version and freeze automated release pipelines.

Step 2: Withdraw the public version, and contact the package registry, code hosting platforms, and mirror services to request removal of copies that clearly contain sensitive content.

Step 3: Fully rotate any potentially exposed keys, tokens, service accounts, and signing credentials. Do not skip this step just because “no obvious secrets appear in the source code.”

Step 4: Review access logs for object storage, logging systems, build platforms, and internal services to identify abnormal downloads and subsequent calls.

Step 5: Publish a clear security advisory covering the scope of impact, affected versions, actions users should take, and the patched release.

Step 6: Preserve complete evidence, including publish timestamps, file hashes, access logs, propagation paths, and remediation records, to support the post-incident review.

6. Safeguards to Build Before Release

Organizations should introduce the following controls across their software delivery pipeline:

1. Build isolation: Use separate directories and permissions for development, testing, and production builds.
2. Package minimization: Include only runtime-required files in release packages.
3. Automated scanning: Detect map files, private keys, tokens, internal addresses, and debug switches.
4. Artifact signing: Generate hashes and signatures for official packages to prevent unauthorized content from being published.
5. Dual approval: High-risk packages must be jointly confirmed by engineering and security staff.
6. Release drills: Regularly simulate scenarios such as accidental publishing, credential exposure, and mirror propagation.
7. Continuous monitoring: Watch public registries, code hosting spaces, and abnormal download behavior.
8. Clear classification: Define which files may be made public and which may only enter internal artifact repositories.

7. Conclusion

On the surface, this incident was a mistakenly uploaded source map file. In reality, it exposed broken handoffs across multiple stages of the software supply chain: building, packaging, publishing, storage, and monitoring.

For engineering teams, the most important lesson is not simply deleting a file—it is treating the release process itself as a security boundary. Default configurations are no substitute for auditing, ignore rules are no substitute for content scanning, and withdrawing a version is no substitute for rotating credentials.

For enterprises adopting AI coding tools, the recommendation is to evaluate their release mechanisms, data flows, permission models, and incident response capabilities before introducing them, and to establish internal package admission policies internally. Only by moving security checks upstream into the build and release stages can issues be caught before code reaches the public internet—preventing a single configuration slip from escalating into a large-scale source code and supply chain security incident.