Yesterday, BleepingComputer exclusively reported that hackers claimed to be selling Target’s internal source code and developer documentation after publishing a sample of stolen repositories on public software development platform, Gitea.
The hacker’s listings include 57,000 files and directory names, with an advertised total dump size of around 860 GB that the threat actor says is being offered for sale. The repositories appear to originate from Target’s private development environment, reportedly showing internal naming conventions, commit metadata with engineer names, and references to internal systems.
After security researchers contacted Target about the exposed repositories, the sample files were taken offline and Target’s developer Git server (git.target.com) became inaccessible from the internet, effectively taking the dev infrastructure offline as part of the company’s response. In parallel, Target also implemented an “accelerated” lockdown of its Git environment, restricting access to require connection via the company’s VPN or managed network to help prevent further unauthorized access.
Multiple current and former Target employees have since corroborated that the leaked source code samples match real internal platforms, tooling, and technology stacks used by the company, including references to CI/CD systems, Hadoop datasets, and proprietary service names.
Target has not publicly confirmed the full scope of any breach or whether the entire dataset was exfiltrated.
Michael Bell, Founder & CEO, Suzu Labs had this to say:
“Source code exposure gives attackers a roadmap. They can study authentication flows, find hardcoded secrets, identify vulnerable dependencies, and understand internal architecture before launching follow-on attacks. The code becomes reconnaissance.
“The “accelerated” lockdown to require VPN access raises an obvious question… why wasn’t that already required? Exposing internal Git servers to the public internet, even behind authentication, creates unnecessary attack surface. The fact that this change was accelerated after the breach suggests the access controls weren’t where they should have been.
“Employee confirmation of authenticity matters more than the threat actor’s claims. Anyone can claim to have breached a company. When current and former employees independently verify that internal system names, CI/CD tooling, and proprietary project references match real infrastructure, that’s substantive validation.
“The infostealer angle is worth watching. Hudson Rock identified a compromised Target employee workstation from September 2025 with access to IAM, Confluence, wiki, and Jira. No confirmation it’s connected, but infostealer logs are increasingly how initial access happens. Credentials get harvested, sit in underground markets, and show up months later when someone decides to monetize them.”
John Carberry, CMO, Xcape, Inc. follows with this comment:
“The reported thiler’s technical security, potentially giving attackers a detailed understanding of their digital infrastructure. The leak of 57,000 files, including CI/CD pipelines, Hadoop setups, and proprietary service names, offers a “blueprint for exploitation.” This enables future attackers to find hardcoded secrets or vulnerabilities in Target’s supply chain.
“Target’s quick response, including taking down its Git server, while necessary, shows a failure to protect its developers from credential theft or misconfiguration. This breach is especially harmful because it reveals the names and details of internal engineers, creating a targeted list for spear-phishing or social engineering.
“Unlike a simple data breach, a source code leak is a persistent threat on the dark web, as researchers can now analyze Target’s core business logic for vulnerabilities offline. Target spent over a decade rebuilding its reputation after the 2013 POS breach. This exposure of their internal code indicates the importance of network segmentation and identity-first security.
“When source code leaks, attackers stop probing and start hunting.”
Ryan McCurdy, VP of Marketing, Liquibase adds this:
“This is a reminder that delivery infrastructure is now part of the attack surface. Locking Git behind a managed network or VPN is a practical containment step, but containment isn’t the same as trust. At enterprise scale, the real control point is before production: governance at the point of change with enforced access, separation of duties, automated policy gates, and audit-grade evidence from commit to deployment. And the database layer is where this matters most, because one ungoverned schema change can ripple across applications, analytics, and AI workloads. Runtime is response. Trust is built before production.”
The good thing is that Target shut this down pretty quickly. But to be frank, they may have a fair amount of damage control to do as it’s hard to put the genie back in the bottle once is has been let out.
Guest Post: 115 CVEs Mark One of the Biggest January Patch Tuesdays Yet
Posted in Commentary with tags Fortra on January 13, 2026 by itnerdBy Tyler Reguly, Associate Director, Security R&D, Fortra
CISOs this month should be paying a lot of attention to CVE-2026-21265 and the guidance associated with it. More specifically, they should be looking at the Windows Secure Boot certificate expiration and CA Updates that Microsoft published June 26, 2025. When the Secure Boot certificates expire in June of this year, organizations that haven’t prepared will not only find Secure Boot no longer operational, but they may also find that Windows boot manager and Secure Boot vulnerabilities have become an issue. It is important to note that the document is not a single page, but contains a multitude of links – including an entire deployment playbook for IT professionals. With less than half a year to prepare, it is time to ensure that environments and teams are prepared for this update.
One of the more interesting updates this month is the Windows Agere Soft Modem Driver elevation of privilege (CVE-2023-31096). It is not often that you see a CVE from 3 years ago show up, but Microsoft is finally cleaning up a problem that has been around for a while. This driver ships with Microsoft Windows, but according to a post about this vulnerability, the driver has been EOL since 2016. The solution to this vulnerability is simply to remove the impacted drivers, agrsm64.sys and agrsm.sys, from systems.
If you’re a fan of statistics, here’s one for you. Microsoft moved away from the security bulletin system in February of 2017 and ushered in the new era of security guidance. Last year, January 2025, saw the largest January Patch Tuesday under this new system with 162 CVEs. This year, we see the third largest January Patch Tuesday with 115 CVEs. For those wondering, 2022 had the second largest January Patch Tuesday with 127 CVEs. This is also only the third time that we’ve seen more than 100 CVEs under the security guidance system. We’re sitting above the average 89 CVEs that we’ve seen over the 9 January Patch Tuesdays that we’ve had under the new system.
Leave a comment »