Target Confirms Source Code Leak After Emergency Git Server Lockdown

Multiple Target employees have independently verified that source code samples leaked by threat actors match the retailer's proprietary systems, confirming a significant security incident after hackers claimed to be selling 860GB of stolen repositories. The verification comes as internal communications reveal Target accelerated emergency security measures restricting access to its internal Git server.

Employees Corroborate Leaked Artifacts

Current and former Target engineers confirmed to BleepingComputer that leaked samples contain authentic references to internal systems, including:

• Deployment platforms BigRED (cloud orchestration) and TAP Provisioning (on-prem infrastructure)
• Proprietary CI/CD tooling built on Vela
• Hadoop datasets matching internal configurations
• Unique internal identifiers like "blossom IDs"

"The repository structure and project codenames align exactly with our development environment," one current employee stated under anonymity. "These aren't generic samples."

The findings validate concerns raised when hackers published partial repositories on public Gitea instances last week, claiming broader access to Target's source code and documentation.

Emergency Infrastructure Lockdown

Within 24 hours of BleepingComputer's inquiry, Target implemented accelerated security changes confirmed by internal Slack communications. A senior product manager announced:

"Effective January 9th, 2026, access to git.target.com now requires connection to a Target-managed network (either on-site or via VPN). This change was accelerated."

Previously, git.target.com—Target's internal GitHub Enterprise Server—was accessible via public internet with employee authentication. The server hosts proprietary code while open-source projects reside on GitHub.com.

Infection Vector Investigation

Security researcher Alon Gal, CTO at Hudson Rock, identified a critical lead: A Target employee workstation compromised by infostealer malware in September 2025 that held credentials for IAM systems, Confluence, Wiki, and Jira.

"Among dozens of infected Target systems we track, only two had IAM access," Gal told BleepingComputer. "This one also had wiki privileges—a rare combination."

While unconfirmed if this infection caused the leak, infostealers like RedLine and Vidar routinely harvest credentials and session cookies that could bypass repository access controls. The timing aligns with threat actors' common practice of delaying data monetization by 3-6 months post-theft.

Practical Security Recommendations

Based on this incident, security teams should:

1. Enforce Zero-Trust Repository Access

   • Require VPN or network-level authentication for all code repositories
   • Implement IP allowlisting for critical infrastructure

2. Monitor for Credential Leaks

   • Deploy tools like SpyCloud or Have I Been Pwned to detect compromised employee credentials
   • Automate secrets rotation after detection

3. Segment Development Environments

   • Isolate CI/CD systems (Jenkins, Artifactory) from general corporate networks
   • Restrict developer workstations from accessing production credentials

4. Audit Access Logs Frequently

   • Analyze Git server logs for abnormal access patterns (unusual hours, bulk downloads)
   • Implement SAML SSO with MFA for all repository access

Target has not commented on whether they're investigating insider threats or confirmed the breach's full scope. The 14MB sample reviewed represents just 0.0016% of the claimed 860GB cache—leaving critical questions about potential exposure of payment systems, inventory management, or customer data platforms.

BleepingComputer has offered threat intelligence to Target's security team and continues monitoring for updates.