TeamPCP, the threat actor behind an unrelenting flurry of attacks on open-source software this year, has been active much longer than previously thought, according to research Oligo Security shared exclusively with CyberScoop. 

The threat actor, which gained notoriety and has captivated threat hunters as it compromised and injected malicious code into more than 1,000 software packages in less than four months earlier this year, was also responsible for attacks dating back to 2020, Oligo Security found. 

The security vendor’s research team found multiple attacks that bear the markings of TeamPCP, including a late 2025 campaign involving the exploitation of a ShadowRay vulnerability that resulted in the first self-propogating botnet running on hijacked AI infrastructure.

Evidence uncovered during that investigation into the ShadowRay 2.0 campaign was linked to more historical attacks originating from the same IPs, domains and other infrastructure TeamPCP used in attacks that captured widespread attention earlier this year. 

“The scariest thing in this campaign is the speed at which the payloads evolved and changed and adapted to the environment they run in. We saw changes in the speed that we’re not used to seeing in these kinds of attacks. They’re usually slow, careful,” said Uri Katz, director of research at Oligo Security. “This was clearly with the help of AI — the payloads changed rapidly to adjust and change to the environment that they were trying to attack.”

One of the domains that Oligo Security identified in July 2025 was in the profile of TeamPCP’s official GitHub account, said Avi Lumelsky, AI security researcher at Oligo Security. “It’s public, they’re not even trying to hide their identity,” he said. 

From there, Oligo linked TeamPCP to activity tracked under multiple names, including TA-NATALSTATUS and IronErn, spanning from 2020 to late 2025. Much of that activity was traced to the same IPs, domain names, a file server and command-and-control server, researchers said. 

TeamPCP emerged publicly as a brand in late 2025. Soon after, “TeamPCP started to go really broad and do campaigns, which are much more noisy,” said Gal Elbaz, co-founder and CTO at Oligo Security. 

Widespread adoption of AI and TeamPCP’s use of the technology supported this growth as the threat actor built a brand, got more active on social media and boasted publicly about its activities and claimed victims.

“The ability to control the infrastructure and orchestrate the attack with AI was also super new, and I’m sure it helps them,” Elbaz said. 

“All of the companies in the world are in this race to adopt AI because they are afraid their business will die, and they understand, of course, the opportunity. But it’s also what gives the attacker this power to go into it,” he added. “If you don’t really have visibility in what’s going on there or how it behaves, that’s exactly what attackers are after.”

TeamPCP’s more recent attacks have capitalized on new security gaps created by developers’ increasing reliance on AI and the automated systems companies use to deploy code. The threat actor is also consistently wrecking the open-source frameworks and software packages these systems rely on. 

“Most AI infrastructure is open source by design because nobody has the manpower and money to develop everything from scratch,” Lumelsky said. 

“We love open source. We use many of these products ourselves, but it’s all about reading the documentation, and I think many of these tools place the responsibility of using it right and security on the user, and developers are not used to these new kinds of animals,” he added. “That’s why the trust can be exploited at scale.”

As it uncovered a long operational history spanning multiple campaigns, Oligo Security has gained more confidence in understanding how TeamPCP operates. It also means TeamPCP was likely involved in other attacks that haven’t been attributed to it yet or attacks that haven’t been detected. 

“There’s a lot more out there that we haven’t caught or been able to prove up until now,” Elbaz said.

The post Open-source software’s archenemy TeamPCP goes back further than anyone thought appeared first on CyberScoop.

Malware targeting AI coding assistants and software developers’ automated workflows is spreading into more environments with more capabilities, placing defenders at a growing disadvantage.

A malware strain dubbed Sandworm_Mode, first discovered by Socket in February, represents a growing threat to software development. According to a CrowdStrike report, the self-propagating worm can spread through code repositories with minimal detection, raising alarms about software supply chains.

The malware’s capabilities are extensive, but not especially unique compared to the series of supply-chain worms known as Shai-Hulud, and more recently Mini Shai-Hulud.

“This is the new trend,” Adam Meyers, senior vice president of counter adversary operations at CrowdStrike, told CyberScoop. “This is something we’re seeing more and more. It’s the new hotness right now.”

Sandworm_Mode targets and steals sensitive data, including credentials, keys and secrets that unlock paths to additional services and dependencies throughout the AI toolchain. This includes AI assistants, cloud providers, API keys for nine major LLM providers, CI/CD pipelines and automated systems that build, test and publish code.

These actions blend in with tens of thousands of other commands occurring daily in any given environment infused with AI development tools. 

“Trying to find the signal of something malicious happening is very difficult because there’s so much noise out there,” Meyers said. 

The worm also paces itself, setting multi-day delays to separate initial access from follow-on malicious activity — creating a gap in victims’ telemetry windows, which makes it even more challenging for defenders to detect and attribute the chain of infection properly. 

“AI agents are pulling down all of these different dependencies continuously throughout the day,” Meyers said. “When you’re looking downrange from the perspective of the security operations team, you’re just seeing everybody pulling down these dependencies, and these dependencies self-unpacking and executing, so it just gets really, really noisy to try to find something bad happening.”

The malware covers its tracks further with a bit of a mean streak, by automatically destroying compromised environments if it can’t spread or accomplish its objectives.

“It’s well thought-through, and well developed, so somebody spent some time caring and feeding this thing,” Meyer said.

Despite CrowdStrike’s four-month review of Sandworm_Mode, the cybersecurity firm has yet to gain a firm handle on its intent, but Meyers said it is designed to attain a strong foothold, which could enable long-term access.

CrowdStrike hasn’t determined who is responsible for the malware, yet Meyers said he doesn’t think TeamPCP, a threat group that’s been on a rampage through open-source software this year, is involved. 

“It could be a nation-state threat actor, or it could be an e-crime actor that’s looking to use this to then sell access to other organizations,” he said. “We don’t really know what the intention is.”

The state of Sandworm_Mode and whether it remains active is also unclear. CrowdStrike said it continues to observe recently active malicious supply-chain packages that follow similar but technically divergent patterns.

Ultimately, “the world has changed,” Meyers said, adding that many attackers are pursuing similar paths in the AI toolchain, requiring defenders and threat hunters to place a greater focus on this burgeoning mode of aggression.

The post Malware is targeting AI tools in software development environments appeared first on CyberScoop.

Cyberstalkers are increasingly exploiting a feature in Google Chrome meant for mobile phone user convenience, but can give intruders broad access to a device owner’s private information, according to researchers.

Certo Software said in a blog post Tuesday that stalkers are making use of Chrome’s sync capability — meant to make it so signing into Chrome on one device makes it easier to do so on other devices, too — to spy on a phone owner’s browsing history and gain access to their stored passwords.

As an illustration, Certo used the case of a pseudonymous victim, Emma, who had searched for a family lawyer and visited a domestic violence support website while her partner was sleeping, only for him to bring up to her two days later.

“Emma had been careful to only ever use her own device, and she hadn’t noticed any new apps appear on her phone,” wrote Certo co-founder Russell Kent-Payne. “What she didn’t know was that weeks earlier, during a few unattended minutes with her phone, he had opened the Chrome app and quietly signed it into a Google account of his own. From that moment on, every site she visited was being copied straight to his account, viewable from any device, anywhere in the world.”

The surveillance is as easy as that: brief access to a phone, signing into a Google account and making sure sync is turned on for that account.

Eva Galperin, director of cybersecurity at the Electronic Frontier Foundation, said on the Bluesky social media app that Certo’s research serves as “an important reminder that tech-enabled abuse isn’t just limited to stalkerware.”

Certo said that Google could do a couple things, such as providing a temporary notification whenever a new account is added or sync is turned on or offering a regular marker to indicate when sync is active and which account it’s syncing to, to protect users.

Google did not respond to multiple requests for comment about Certo’s findings.

But the uptick in usage of that stalking method could be a byproduct of security successes elsewhere in the fight against spyware, Certo said.

“Modern smartphones are harder to compromise than ever. Regular security updates, stricter app store rules, and on-device threat detection have made traditional spyware a much riskier bet for a cyberstalker than it used to be,” Kent-Payne wrote. “As a result, we’re increasingly seeing abusers turn to something far simpler: the legitimate apps already sitting on their victim’s phone. No installation, no suspicious permissions, no telltale battery drain — just a quiet misuse of a feature the victim never knew existed.”

At the same time, Chrome is the world’s most popular browser, and this isn’t the first time security concerns have popped up about its sync feature, among other worries.

The post Security researchers find stalkers abusing Chrome’s sync feature appeared first on CyberScoop.

AI-generated code is part of everyday software development. Developers use it to prototype, refactor, troubleshoot, and move from idea to implementation with less friction than ever before. The productivity gains are undeniable, which means that security leaders now face a hard question: whether their organizations can govern the risk that AI creates at that same speed.

That challenge is rooted in scale. AI changes how quickly software can be created, while many application security programs still depend on controls designed for a slower development model. When code generation accelerates beyond the capacity to review, test, and remediate issues, security debt accumulates faster.

That is the hidden cost of AI-assisted development. Risk now enters the enterprise at machine speed, while many organizations still manage it with human-scale processes. CISOs should govern AI-generated code as a high-risk input: tested automatically, checked for unsafe dependencies, remediated quickly, and blocked from production if it fails policy.

The metric that matters is risk velocity

Application security has long been measured through discovery. Teams count vulnerabilities, categorize severity, report trends, and show whether the numbers are improving. Those questions still matter, but AI adds a more urgent metric: risk velocity. Security leaders need to know how quickly the organization creates new software risks and how quickly it can reduce or eliminate them.

AI changes the economics of security debt. A development team that produces significantly more code without a matching increase in security capacity will create more issues than it can reasonably review or fix. Even when AI-generated code is comparable to human-written code on a per-line basis, the total risk can rise because the volume of change is higher. The backlog grows, vulnerabilities persist, and security debt eventually constrains the business.

AI expands familiar failure modes

The failure modes are familiar. AI coding tools can reproduce insecure patterns found in training data, including weak input validation, unsafe authentication flows, insecure direct object references, hard-coded secrets, and vulnerable dependency choices. They can also miss the context that determines whether code is secure in a specific environment: authorization models, tenant boundaries, data sensitivity, production configurations, and how services interact in a real application.

There is also a human factor. Under the pressure of deadlines, developers may accept code that works without fully understanding how it does so. The result is misplaced confidence. Code compiles, tests pass, features ship, and hidden risk enters the system. Over time, the organization may lose sight of the security concerns that naturally arose during manual development.

The supply-chain risk is bigger than the code itself

The software supply chain adds another layer of risk. Modern applications are assembled from open-source components, frameworks, plugins, containers, APIs, and cloud services. AI coding tools can recommend outdated packages, vulnerable libraries, or nonexistent dependencies. Veracode’s 2025 GenAI Code Security report found that AI coding tools produce insecure code nearly half (45%) of the time. It may sound like an amusing hallucination until attackers register malicious packages with similar names and wait for developers or automated tools to pull them in. At that point, a coding shortcut becomes a supply chain exposure.

AI is already part of the development lifecycle, and its use will continue to expand. Security teams need a control model built for that reality.

“Shift Left” needs an enforcement layer

The industry has spent more than a decade moving security earlier in the development lifecycle, improving visibility and helping teams catch issues sooner. Many organizations, however, moved findings closer to developers without also moving enough ownership, automation, and remediation capacity with them. Developers received more alerts, while security teams gained more visibility into risks they still struggled to reduce.

AI makes that operating gap more urgent. As software output increases, security cannot remain a checkpoint near the end of the process. It must become a continuous control system built into the way software is created, tested, approved, and deployed.

Secure-by-design has to become infrastructure

Secure-by-design in the AI era requires an engineering environment where unsafe choices are harder to make and easier to catch. Approved frameworks, secure defaults, reference architectures, dependency controls, automated testing, and policy enforcement should be embedded directly into developer workflows and CI/CD pipelines.

Remediation also must move closer to the point of creation. When a coding assistant introduces a vulnerable pattern, the ideal response is an inline fix that is proposed, validated, and governed as part of the normal development process. AI can help defenders here when it is connected to reliable security signals, policy context, and evidence from real testing. Counterintuitively, developers using AI to write code often don’t trust AI to automatically remediate code without human review. This takes one of the best ways to keep up with machine-speed created vulnerabilities and slows it down to human speed. An acceptable balance between risk and speed must be found.

Approval is not governance

CISOs should focus on governance, not just approving AI coding tools. Governance means tracking where AI-generated code enters your environment, documenting the policies and tests applied, recording what issues were found and fixed, and keeping proof of these decisions. This documentation becomes critical as AI-assisted development becomes standard. If vulnerable code reaches production, you’ll need to show that adequate controls were in place and risks were managed according to policy.

What leaders should do now

CISOs and engineering leaders should treat AI-generated code as untrusted until proven otherwise. They must require automated testing before release, enforce dependency controls, prioritize remediation based on exploitability and business impact, and measure success by the rate at which critical risk is reduced.

Additionally, boards and organizational policymakers should ask whether organizations can demonstrate that AI-assisted software is governed before it is deployed. The key evidence should include the policies applied, the tests performed, the vulnerabilities remediated, the risks accepted, and the approvals recorded. Today, many organizations can confidently track what their AI tools produce, but they cannot demonstrate how that output was secured, reviewed, and governed before reaching production. The industry is still working to close this gap.

AI is changing how quickly software risk moves through the enterprise. The organizations that succeed will make security move just as quickly by embedding governance, remediation, and proof directly into the software delivery pipeline.

The post AI-generated code has made security debt a governance problem appeared first on CyberScoop.

An epidemic of cyberattacks on open-source software has mounted in recent months, making clear how uniquely difficult it is to protect the publicly available code, from both a policy and a technical perspective, that serves as the foundation for so much of the digital world.

While open-source software security got a boost in attention under President Joe Biden — whose administration grappled with the fallout from the potentially catastrophic Log4j flaw that emerged in 2021 — a number of open-source experts say that government protection efforts have suffered setbacks under President Donald Trump. Many also say companies that heavily rely on open-source software, which is basically all of them, haven’t shouldered enough of the responsibility for safeguarding it.

“What we’re seeing is years of lack of investment sustainment in open-source software that is finally starting to catch up to us, where it seems like every week there’s a new supply chain compromise,” said Jack Cable, who held a role at the Cybersecurity and Infrastructure Security Agency where he worked on open-source security before departing under Trump.

The advancements of frontier artificial intelligence models stand to exacerbate the risk further, while simultaneously illustrating what makes defending open source difficult: Project Glasswing said shortly after its announcement that it had uncovered 6,202 high- or critical-severity vulnerabilities in a scan of more than 1,000 open-source projects, but that it had disclosed only 502 of them to open-source project maintainers and only 75 had been patched as of May 22 (albeit some due to typical patching lagtimes).

At the same time, there are questions about how much the government can help, even as overseas governments seek to focus on open-source security.

The evolution of open-source risk 

There are a series of factors contributing to the current threat to open-source software, experts say.

One is simply that attackers go to the area where they can get the highest return on their work. Compromising open-source software gives them the chance to get into the supply chain and exploit additional targets.

“Twenty years ago, open source was still fairly niche,” said Æva Black, who also worked on open-source security at CISA but left when Trump came back into power. “The potential blast radius if you managed to compromise open source was relatively small, because back then the world didn’t run on open source. Now almost everything runs on open source,” she said, from modern cars to satellites.

Another part is the nature of open-source software itself.

“It’s a symptom [of having] lots of open source [that] is a little bit under-maintained or not cared for enough, so that we spend too little effort and money and infrastructure on them,” said Daniel Stenberg, who is the creator and maintainer of cURL, a popular open-source project. “Lots of open source is being maintained by small teams, lots of volunteers, and I think that that’s a tough situation.”

That doesn’t mean the maintainers are to blame, Stenberg said. The companies that rely on open-source need to be diligent about using it, Black said.

“What we’re seeing in that realm right now is not new; it is more advanced and far more widespread,” she said. “The problem remains that companies who use open source — because open source is by far the most efficient way to collaborate on non-product value features — most companies are not implementing a responsible and safe utilization pathway.”

Open-source projects lack a systematic way to handle coordinated vulnerability disclosures, unlike companies or industry groups with formal processes, said Dan Lorenc, CEO and co-founder of Chainguard. Project maintainers sometimes aren’t reachable, and those who are available are flooded with reports, many of them unverified findings from AI tools that waste their time without adding value..

Of course, some of those vulnerability reports turn out to be legitimate. “Mythos and AI models have contributed to an uptick in the number of vulnerabilities and things that we’re able to find” in open-source software, said Alex Zenla, chief technology officer for the cybersecurity company Edera.

All of that leaves more room for companies, non-profits and world governments to improve open-source security.

A moment of momentum

While open-source software security isn’t a new issue, the 2021 discovery of the Log4j flaw sounded alarms within the cybersecurity community. Jen Easterly, then the director of CISA, called it “one of the most serious I’ve seen in my entire career, if not the most serious,” with the potential to affect hundreds of millions of devices given the ubiquitous nature of the popular open-source logging library.

A year later, the Cyber Safety Review Board released its report on the incident, concluding that swift action from industry and government averted a disaster. But the incident “called attention to security risks unique to the thinly-resourced, volunteer-based open source community,” it wrote. “This community is not adequately resourced to ensure that code is developed pursuant to industry-recognized secure coding practices and audited by experts.”

The U.S. government actions after included some steps focused specifically on open-source software such as creation of the Open-Source Software Security Initiative and hires of well-regarded open-source security experts at CISA such as Black, but also some steps that could be applied more generally and still help with open-source security, such as greater promotion of secure-by-design, memory-safe languages and software bills of materials (SBOMs).

Some of the Biden administration work on open-source security started before Log4j, such as provisions from an executive order he issued in 2021 that directed CISA along with the Office of Management and Budget and General Services Administration to issue guidance to agencies. 

The administration’s 2023 cybersecurity strategy also stepped into the long, thorny discussions over software liability, with a mention of open-source security: “Responsibility must be placed on the stakeholders most capable of taking action to prevent bad outcomes, not on the end-users that often bear the consequences of insecure software nor on the open-source developer of a component that is integrated into a commercial product.“ The Biden administration always indicated that addressing software liability would take a prolonged battle ahead.

Under Trump, many of the Biden administration’s efforts have languished. CISA’s splashy hires on open-source are gone, including Black, Tim Pepper and Anjana Rajan. Also departed are leading figures on secure-by-design and SBOMs, with CISA personnel cutbacks slicing deep. 

No one has seen any sign that the national cyber director-led Open-Source Software Security Initiative is active, with few participants remaining in government today. The Trump administration cyber strategy doesn’t mention open-source.

“The loss of open-source experts at CISA “is unfortunate, and it will be hard for the government to try to rebuild capacity, but I do think now more than ever CISA has a core role to play to secure open source software,” Cable said.

The pressure is mounting

It’s not that the issue is getting zero attention from those in a position to make a difference. Nick Andersen, the acting director of CISA, said last month that open-source security was an area of particular concern for him.

Andersen responded to concerns about CISA staffing levels on open-source security and spoke more broadly on the topic in a statement to CyberScoop.

“As artificial intelligence and other technologies have the power to transform how vulnerabilities are discovered and exploited, CISA recognizes that the open source software (OSS) that underpins much of the nation’s critical infrastructure will need to be hardened,” he said. “CISA actively collaborates with our partners on shared priorities, including OSS security, to ensure time and resources are spent where they matter the most.  We have an immensely talented team, but are also accelerating our hiring in critical areas, to strengthen the nation’s defenses against cyber threats.”

The Office of the National Cyber Director did not respond to requests for comment.

There’s been some activity on Capitol Hill, too. The Securing Open Source Software Act, which Cable worked on during a stint as a Senate staffer, would direct CISA and other agencies to take actions to mitigate open-source software security risks, but the legislation has stalled since its introduction in 2022. A portion of the bill, however, was included in the Department of Homeland Security funding law Trump signed in April, directing CISA to brief Congress on the value of establishing something like an open source program office, which some companies use to manage open source within a given firm.

Senate Intelligence Committee Chairman Tom Cotton, R-Ark., has pushed the executive branch to improve its awareness of foreign adversaries playing roles in open-source software used by national security-focused agencies.

The annual defense policy bill in the House calls on the Defense Department’s chief information officer to report to Congress on a plan to secure open-source software supply chains, saying lawmakers are “concerned that the Department lacks sufficient visibility into the origins, maintenance, and security of OSS applications and software dependencies.”

That defense authorization bill language is “really beneficial, and I think it signals acknowledgement of this changing of culture” around open-source security risks, said Hayden Smith, founder of HuntedLabs, whose company won a contract with the Space Development Agency on supply chain security — agency work that the defense bill singled out.

“The report language is the first time the Hill is trying to get a true handle on foreign influence in open source code where they have oversight,” he said, saying it was a “piece of the puzzle” along with Cotton’s letter and a memo from Secretary of Defense Pete Hegseth last year about foreign influence in the Pentagon supply chain. “It’s good and would trickle down into everyone who provides software to the department.”

Zenla, though, believes trying to isolate China from open-source systems isn’t in and of itself a good idea. 

“I don’t think that that makes a lot of sense, because they’re actually pretty good things that people contribute to open source,” she said. “Not everyone is malicious, and what are we going to do, spy on every single open source maintainer?” It’s more about doing things like making sure that highly-classified systems are set up in a separate way, she said.

Europe is also taking action to secure open-source software that the United States doesn’t seem ready or willing to do right now. Germany, for instance, devotes grants to the security of open-source projects, although Stenberg pointed out that sometimes money doesn’t equate to maintainers being able to fix flaws more quickly, depending on the project’s size.

The Cyber Resilience Act (CRA) adopted by the Council of the European Union in 2024 could offer another road on open-source security. The CRA requires those who use open-source software products as part of any commercial activity to take certain security measures. 

Black said that when she was at CISA, there were discussions between the agency and European counterparts about finding compatible ideas on open-source security, but that momentum died with the Trump administration.

But “Europe kept rolling, and now has in place a new legal framework that is set to really reshape open-source security for potentially the whole world, but certainly for anyone who wants to work with Europe on open source,” she said.

Lorenc recently wrote that “open source isn’t governable.” He said an organization like a neutral nonprofit, possibly using some government funding, should take responsibility for things like coordinating vulnerability disclosure into one pipeline. He also said there needs to be one authority in charge of “forking” — that is, taking a project and assigning stewardship elsewhere — when a maintainer isn’t responsive to vulnerabilities. 

There are differing opinions on how much past government warnings, advisories and guidance have helped. Smith gave some credit to government agencies that “have all responded to open source attacks using the means they have.”

Stenberg said that “I don’t think they make any big dent at all in the big scheme of things.” They might get some attention initially, “then two years later we all forgot about them, and they actually didn’t change much.”

Ideally, everyone could get on the same page, Zenla said. “The best way to do this is if people actually collaborated on a global scale on some sort of regulation around this, but that seems nearly impossible at the current moment,” she said. (The United Nations’ Open Source Week runs all this week.)

But if there’s an upside to the spate of attacks on open-source software, it’s the energy it gives to how better to secure it, Lorenc said, invoking the political saying to never let a good crisis go to waste.

“Everyone knows the industry has to change,” he said. “This is a really good crisis, and the right things are happening in the right places, and organizations are rethinking their culture around software development, and they know what they have to do. It’s just something that’s never been top of the priority list for the last 10 years. Now it is, and they’re doing it, and it’s, ‘Can we do it fast enough?’”

The post Open-source security is posing challenges governments can’t easily solve appeared first on CyberScoop.

TeamPCP is on a rampage through open-source software.

In less than four months, the threat actor has compromised and injected malicious code into more than 1,000 software packages. The extraordinary spree has transformed how software developers and maintainers distribute and manage their code, as their dependencies and repositories have become one of the most effective and prevalent attack vectors this year.

While there has been a host of technical exploits, TeamPCP’s greatest attack has been the uprooting of trust — repeatedly proving that most organizations fail to verify the code they ingest into their systems is legitimate, abusing a nearly blind faith that much of the software development industry relies on to power today’s modern economy.

Starting with Trivy in February, TeamPCP’s attacks have shaken that trust many times over.

The scale of TeamPCP’s attacks lies partly in the automated systems companies use to deploy code, like CI/CD pipelines. It is also capitalizing on new security gaps created by developers’ increasing reliance on AI. Yet, with relatively low effort and unoriginal tactics, TeamPCP is wrecking open-source frameworks and underlying systems at levels the technology community has rarely reckoned with.

“Developers didn’t do a great job of analyzing the security of their open-source dependencies before but, now with AI, there’s in some cases virtually no human in the loop or any kind of sanity check on what these tools are doing,” Feross Aboukhadijeh, founder and CEO at Socket, told CyberScoop.

“You have agents installing packages that haven’t been vetted,” he said. “When an attacker gets in, the impact is even broader because there’s less checks and balances to stop it from affecting everybody.”

TeamPCP hasn’t identified a new problem or proved anything novel. The crux of these attacks hinge on a central theme — defensive vulnerabilities the entire software industry has known about for years. Researchers and developers know the open source trust model is broken and susceptible to sabotage. Yet, the software industry has not fixed this problem. 

“The speed and scale of these attacks is what makes it most notable, not necessarily the methodology behind it, because at the core it is really about exploiting third-party trusts that we have,” said Kimberly Goody, senior manager at Google Threat Intelligence Group.

Software packages are typically subjected to intensive security monitoring to test for vulnerabilities and poisoned updates before they are released to live environments. 

Yet, the real vulnerability highlighted by TeamPCP lies further up the chain of command with the organizations or individuals that publish these packages to the wider market, according to Nathaniel Quist, manager of cloud threat intelligence at Palo Alto Networks.

“It is their responsibility to secure their credentials and not provide a jump off point to trigger a supply-chain event,” he said. “Everything that interacts with or crosses through that zone must be highly monitored and controlled to ensure a compromise can be contained quickly and easily.”

TeamPCP’s motivation

TeamPCP, like any prolific cybercriminal, has captured significant attention from threat hunters since it emerged in late 2025. Google attributes the activity to one core operator.

The company said it traced TeamPCP’s residential and mobile IP address connections to South Africa, indicating the primary operator was located there during at least some of its attacks.

“We don’t believe that there’s an established core group, at least not yet, and that a lot of this has been conducted by an individual,” Goody said. Google declined to name the core operator or confirm it knows the person’s true identity. 

Palo Alto Networks said the core manager of TeamPCP uses the “ResoluteXBF” handle on multiple platforms. The cybersecurity firm is also tracking two additional core members: “diencracked” and “Shinigami.”

If TeamPCP is primarily run by one person, law enforcement has a rare opportunity to make a lasting impact with a single arrest.

TeamPCP has collaborated with other cybercriminals, but most of those partnerships were short-lived and ended in a public feud or otherwise failed to get off the ground in any meaningful way, Goody said.

Researchers have linked TeamPCP to extortion crews, dark web forums and affiliates including Lapsus$, ShinyHunters, Vect, DragonForce, BreachForums and “HasanBroker.” TeamPCP listed about 4,000 private code repositories on a dark web forum with an asking price of $95,000.

The actions to date, including unpredictable behavior, indicate motivations beyond financial gain and a “clear desire for notoriety,” Goody said. “They seem to like to make chaos.”

Quist draws the same conclusion from his months-long investigation, noting that it encourages other cybercriminals to get in on the action, at one point offering financial rewards for the largest software supply-chain attack. 

TeamPCP isn’t in the game for extortion payments, he said. “These actors are more interested in the underground street cred they are gaining” and “causing as much damage and mayhem as possible.”

Victims abound, but exposure limited

TeamPCP has been remarkably noisy, opportunistically injecting malware into open-source software for the purpose of stealing credentials for Kubernetes environments, Amazon Web Services, Microsoft Azure, Google Cloud and many other connected services.

The group’s claimed victim list is staggering: Checkmarx, Bitwarden, LiteLLM, Telnyx, Mercor AI, PyTorch Lightning, AntV, SAP, GitHub, TanStack, UiPath, MistralAI, Microsoft DurableTask, Red Hat and Nx Console.

The full collection of packages compromised or poisoned by TeamPCP to date accounts for roughly 500 million weekly downloads combined, according to Quist.

While the breadth of potential downstream compromise flowing from those downloads is substantial, many endpoints infected with those malware-riddled packages aren’t exposed to the internet and less susceptible to attack, he added.

“I don’t think there’s going to be a very extremely large number of victims,” Quist said. “There’s going to be a lot of people who potentially could be compromised and have potentially vulnerable packages in their environment, but that doesn’t necessarily mean they’re in an exploitable position.”

While these incidents have grabbed headlines, TeamPCP hasn’t accumulated payouts nearly as large as other cybercriminals. The broader reputational impact it has wrought, however, is massive.

TeamPCP has publicly claimed more than 10,000 victims and about $90,000 in extortions, according to Quist.

“They might not be making a lot of money, but they are causing a lot of impact,” Goody said. “Their campaigns have been very disruptive.”

How TeamPCP’s operating model targets development

TeamPCP’s victim list has grown as its hijacked open-source repositories on npm, PyPI, GitHub and other outsourced developer tools that are incorporated into upstream code running in production environments.

Developer laptops and other endpoints that are assigned to install, build and publish software widely contain keys and access to source code that create incredibly valuable supply-chain targets for attackers, Amitai Cohen, head of the attack vector intel team at Wiz, explained during a June presentation on TeamPCP at SleuthCon in Arlington, Va. 

The group targets CI runners, which are automated systems that build, test, and publish code. TeamPCP injects malware into the code repositories these runners maintain. When other developers pull that code into their own systems, they unknowingly download the malware alongside it. 

Some of these artifacts, including Python libraries, npm registries and GitHub Actions, are downloaded almost immediately by thousands or millions of developers who’ve set their runners up to consistently pull the latest version, according to Cohen. “We as a security industry have taught them that that is the right thing to do. You want to use the latest version because you want to be protected against vulnerabilities, and obviously you want to benefit from all the latest features.”

That instinct is exactly what TeamPCP exploits. By compromising one company’s CI/CD workflow, the group gains access to every downstream user who automatically pulls that infected code. “This is what allows [TeamPCP] to leverage initial access to some patient zero, some company that had a vulnerability in their CI/CD workflow, in order to gain access to their downstream users,” Cohen said. “That’s just how the software supply chain works. Everything has dependencies upon dependencies upon dependencies.”

Some of the packages compromised by TeamPCP were live for almost 13 hours, but security practitioners have responded by identifying code-injection attacks much quicker now, pulling some compromised repositories within 15 minutes, said Ben Read, director of strategic intelligence at Wiz.

The threat group’s operations remain high-tempo. TeamPCP infects new software packages almost daily, validates compromises and captures sensitive data within 24 hours, according to Wiz researchers.

The threat group has consistently evolved its tactics, developing payloads in JavaScript and Python while spreading from local files to Kubernetes application programming interfaces and bundled software development kits. Most recently, it’s been stealing credentials via custom protocols. 

The group’s ambitions have expanded beyond its own attacks. TeamPCP is also responsible for a self-replicating piece of malware known as Mini Shai-Hulud, which infected hundreds of software packages across open-source registries in back-to-back attack sprees last month. A TeamPCP affiliate published the full source code for the malware on GitHub last month and encouraged other cybercriminals to use it for their own campaigns.

“TeamPCP is going for volume. They are not being discriminating, they’re not necessarily trying to be stealthy or trying to maximize ROI. They’re going for an all-of-the-above strategy,” Read said during the Sleuthcon presentation.

Defensive gaps create openings for attack

TeamPCP’s attack spree has also underscored how difficult it is for organizations to revoke compromised secrets. Multiple victims have experienced recurring infections, sometimes falling prey to TeamPCP three times within a month, because they didn’t rotate secrets properly, Cohen said. 

At its core, these attacks highlight a direct trade-off organizations accept when they update software quickly to fix vulnerabilities, but learn that doing so too quickly could expose them to illegitimate registries containing malware.

TeamPCP has targeted what Aboukhadijeh describes as a “public good,” open-source registries that were never perfect but widely trusted and rarely turned into a point of entry for supply-chain attacks. 

Rapid open source software installation is one of the most dangerous things an organization can do right now, he said, adding that there’s a roughly 1 in 10 chance that any package installed by an organization could trigger an active attack. 

TeamPCP has compromised security scanners, password managers, automation tools, data visualization software, and CI/CD infrastructure across various environments.

And it’s lifted a trove of credentials and other sensitive data from victims.

Researchers like Cohen at Wiz, who have been tracking this attack spree since the beginning, are nearing a breaking point. 

“This is also too hard on us. We’re very tired. I’m sure a lot of people working on this problem space are very tired, and it’s just kind of become untenable,” Cohen said.

“You can’t keep existing in a world where you wake up every morning and some super prevalent package is compromised and everybody’s just going to be using it like nothing,” he added. “We need to start taking this a bit more seriously.”

The post How software development’s speed obsession enabled TeamPCP’s chaos crusade appeared first on CyberScoop.

GitHub said late Tuesday that internal repositories were exfiltrated after an employee device was compromised through a poisoned Visual Studio Code extension, an incident that underscores the growing risks facing software development platforms and the ecosystems built around third-party developer tools.

The Microsoft-owned company said in posts on X that it detected and contained the compromise, removed the malicious extension version, isolated the affected endpoint and began an incident response investigation. The company’s current assessment is that the activity involved GitHub-internal repositories only.

GitHub also said a claim from TeamPCP, a hacking group behind attacks targeting software development packages, that 3,800 repositories were impacted was “directionally consistent” with its investigation so far. It said critical secrets were rotated Tuesday, with the highest-impact credentials prioritized first. The company said it continued to analyze logs, validate secret rotation and monitor for follow-on activity.

The company has not publicly named the extension involved or attributed the activity to a particular group. TeamPCP reportedly advertised the material for sale on a cybercrime forum and threatened to release it if no buyer emerged. 

Information surfaced Wednesday that the incident may be related to a separate issue with Nx Console, a Visual Studio Code tool that helps engineering teams organize large codebases, coordinate build pipelines and run tests efficiently. According to a security advisory posted on GitHub, one of the Nx Console maintainers was compromised in a prior security incident that leaked their GitHub credentials. An attack then used those credentials to push a malicious version of the extension to the VS Code Marketplace. Those credentials have since been temporarily revoked.

With millions of installs, Nx Console is a fixture of professional JavaScript development. It is exactly the kind of tool that sits deep inside a developer’s working environment, which would have direct access to source code, credentials and build systems.

NX CEO Jeff Cross posted on X Wednesday that his company has been working with Microsoft to determine the full scope of the incident.

“Initially, Microsoft indicated to us that there were 28 installs of the malicious version 18.95.0. Based on our own analytics for the compromised version, we currently believe the number of users who received the malicious package may be significantly higher; potentially over 6k installs,” the post reads.

“This is my top priority right now,” Cross continued. “Our team has been, and continues to be focused on understanding exactly what happened, helping affected users, hardening our systems and release processes, and being as transparent as possible throughout the investigation.”

The episode also follows a series of supply chain attacks involving npm, PyPI, Docker and other developer ecosystems. In those incidents, attackers have often targeted maintainers, packages or credentials rather than attacking end users directly. The multiple attacks show how fragile development environments have become as threat actors increasingly target them. A single compromised developer account, package, extension or build process can create access to many downstream systems.

GitHub has said it has no evidence that customer data stored outside the affected repositories was affected.

Visual Studio Code extensions are widely used by developers to add functions to Microsoft’s code editor, including support for programming languages, testing tools, cloud services and artificial intelligence assistants. Because these extensions often operate inside development environments, a malicious or compromised extension can be positioned close to source code, credentials and build systems.

“The thing people underestimate about VS Code extensions is that they have full access to everything on the developer’s machine,” Charlie Eriksen, a security researcher at Aikido Security, told CyberScoop. “EDR doesn’t cover this layer at all. What’s missing for most organisations is any kind of visibility into what’s actually running on developer machines and the ability to control it.”

Trojanized extensions have appeared in the VS Code Marketplace before. Security researchers have identified malicious extensions posing as legitimate development tools, including packages used to steal credentials, mine cryptocurrency or exfiltrate data. Some have accumulated large installation counts before removal, reflecting the difficulty of policing open plugin ecosystems at scale.

For GitHub, the breach comes amid broader scrutiny of the security of developer infrastructure. The platform sits at the center of software production for companies, governments, open-source maintainers and independent developers. Its internal systems and code are of obvious interest to attackers because GitHub’s services support code hosting, package distribution, automation and identity workflows across much of the software industry.

GitHub said it would publish a fuller report when the investigation is complete.

Update: May 20, 12:55 p.m.: This story has been updated with information about a related security incident with Nx Console.

The post GitHub says internal repositories were impacted in poisoned VS Code extension attack appeared first on CyberScoop.

As defenders get their hands on newer AI models with more powerful cybersecurity capabilities like Anthropic’s Mythos and OpenAI’s Daybreak, organizations are being told to prepare for a flood of new vulnerability reports.

But for bug bounty programs across the nation, that day may already be here, as yesterday’s frontier models and today’s open-source AI tools have dramatically increased the volume of bug reports flowing into companies around their own products or on larger bounty platforms online.

GitHub, one of the world’s largest online code repositories, said it is tightening its definition of a “complete” bug report after a significant increase in AI-assisted submissions over the past year.

Although the influx has had some benefits, many reports are submitted without proof of concept, are reliant on unrealistic attack scenarios or cover issues already listed as ineligible. As a result, the company is having difficulty separating signal from noise.

“This isn’t unique to GitHub,” wrote Jarom Brown, senior product security engineer at GitHub. “Programs across the industry are grappling with the same challenge, and some have shut down entirely.”

Brown said GitHub does not want to ban the use of AI generated reports entirely, calling it a “force multiplier” for security in the right context. But in a world where it’s never been easier to use AI to generate theoretical bugs, the company wants researchers to go the extra mile to confirm that their discoveries can actually be exploited in real-world conditions.

What we need is the same standard we’ve always expected: validation,” Brown wrote. “An AI-assisted finding that’s been verified, reproduced, and submitted with a working proof of concept is a great submission. An unvalidated output submitted as-is without reproduction or demonstrated impact is not.”

Grant Bourzikas, chief security officer at Cloudflare, said triaging bugs and proving they can be exploited  has always been one of the hardest parts of vulnerability research, and AI vulnerability scanners and code have “made it worse.”

For instance, code written in C and C++ programming languages are vulnerable to a range of exploits – like buffer overflows and out-of-bounds reading and writing – that don’t exist in memory safe languages like Rust. AI tools scanning software written in memory unsafe programming languages are far more likely to generate false positives.

But one of the biggest flaws continues to be that AI tools are also designed to give the user what they’re asking for, even when it’s not there. This leads to the generation of bug reports filled with speculation and qualifiers around exploitability that require human follow up.

“That’s a reasonable bias for an exploratory tool,” Bourzikas wrote. “It’s a ruinous one for a triage queue, where every speculative finding spends human attention and tokens to dismiss, and that cost compounds across thousands of findings.”

Cloudflare recently shared results from testing Mythos on 50 of its own code repositories, looking for exploits. Bourzikas called Mythos “a different kind of tool doing a different kind of work” from other frontier models, and that it made significant progress in reducing false positives.

For example, he pointed to two Mythos capabilities that stood out compared to other models: chaining exploits together and generating its own proof-of-concept code to confirm exploitability.

Older models could spot many of the same bugs, but they often couldn’t figure out how to exploit them effectively, or show that the issue could be exploited in real world conditions.

Others have argued that the gap in bug hunting capabilities between newer frontier AI models and older ones, or open source models available today is not as large as advertised. 

Swedish software developer Daniel Stenberg, lead developer for curl, an open source file transfer tool used around the world, recently wrote about his experience with Mythos Preview. Like others, he has also seen a higher volume of AI-fueled bug reports over the past year, but said the flood of low-quality reports has tapered off significantly since March as models have improved.

Curl is mature and polished by the standards of most software: Stenberg estimates each line of code has been rewritten or altered at least four times, and he said he has used both human and AI tools in the past to implement hundreds of bug fixes over Curl’s existence.

That makes it a unique testing ground for the enhanced capabilities of Mythos, which was reportedly so powerful at finding vulnerabilities that Anthropic opted not to release it to the general public.

After gaining access to Mythos, Stenberg received the results of a scan of 178,000 lines of curl code. Ultimately, the scan flagged five “confirmed” vulnerabilities. Further exploration by human researchers found that 4 of the bugs were false positives or had no security impact. The one remaining bug Mythos found? A low-severity flaw that will be fixed in a regular June update.

Even as he praised the impact of AI on cybersecurity generally, Stenberg concluded that for all the hype, Mythos is only “a bit better” than previously released models.

“My personal conclusion can however not end up with anything else than that the big hype around this model so far was primarily marketing,” he wrote. “I see no evidence that this setup finds issues to any particular higher or more advanced degree than the other tools have done before Mythos.”

The post AI might cut false positives, but it won’t stop the slop  appeared first on CyberScoop.

A rapidly spreading malware campaign has infected hundreds of software packages across major open-source registries, embedding credential-stealing code into development tools downloaded millions of times a week.

The attack, referred to as “mini Shai-Hulud,” targeted prominent software libraries, including TanStack, UiPath, and MistralAI. TanStack’s React Router package alone accounts for more than 12 million weekly downloads, placing the malicious code deep within the software supply chain of modern enterprise applications.

In a blog post, Tanstack said security teams have pulled all compromised software versions from the registry. While there is no evidence that registry passwords were stolen, experts urge anyone who downloaded the affected tools Monday to immediately change all connected cloud, server, and developer credentials — including Amazon Web Services, Google Cloud, and GitHub.

The incident highlights a systemic vulnerability in automated software publishing. The compromised updates successfully bypassed two-factor authentication and carried cryptographically valid provenance signatures. These signatures verified that the packages originated from the correct continuous integration pipelines, but failed to detect that the pipelines themselves had been manipulated to authorize malicious code.

Security researchers attribute the campaign to TeamPCP, a cloud-focused cybercriminal group that emerged in late 2025 that specializes in automating supply-chain attacks and exploiting cloud-native infrastructure, including Docker and Kubernetes environments. The group, alleged to be responsible for earlier development of Shai Hulud, quietly slips their malware into trusted software updates, allowing them to infect thousands of companies at once without triggering security alarms. 

The group is notorious for its advanced ability to hide its tracks — such as disguising stolen data as anonymous messaging traffic — and its aggressive extortion tactics, which include threatening to completely erase victims’ computers if they attempt to remove the hackers’ access.

Attackers triggered the automated release process using an “orphaned commit” — code pushed to a repository fork without a corresponding branch. This allowed them to exploit overly broad permissions in GitHub Actions workflows. The malware was then delivered via a concealed dependency that fetched a heavily obfuscated 2.3-megabyte payload disguised as an initialization module.

Upon execution, the malware uses Bun — a high-speed software engine designed to run JavaScript — to systematically steal security keys and passwords. It targets high-level cloud infrastructure, including AWS, Google Cloud Platform, Kubernetes, and HashiCorp Vault. The code is engineered to infiltrate highly secure Amazon cloud networks. At the same time, it scours the developer’s local computer for secret files and SSH keys used to unlock other corporate systems.

Operating as a self-propagating worm, it publishes copies of itself to those projects, spoofing its activity to appear as automated commits from the Anthropic Claude bot. In a secondary extortion measure, the malware generates a new registry token containing a ransom note in its description, threatening a destructive computer wipe if the victim attempts to revoke the compromised access.

Despite the malware’s properties, researchers told CyberScoop they have not seen it spread. 

“We saw very limited community spread,” said Charlie Eriksen, a security researcher with application security firm Aikido Security.

To maintain continuous access to developer workstations, the malware embeds itself into the configuration files of popular developer tools, notably Visual Studio Code and Anthropic’s Claude Code. This ensures the malicious scripts execute automatically every time a developer opens a project or initiates an AI coding session.

Stephen Thoemmes, senior developer advocate at Snyk, told CyberScoop this is a particular blind spot for these types of attacks. 

“Directories like .claude/ and .vscode/ are typically excluded from version control via .gitignore and are rarely scrutinized as viable attack surfaces,” Thoemmes said. “While these hook and task systems provide valuable automation for legitimate work, they offer a silent execution environment for malicious code. To counter this, developers must move away from treating these local configurations as benign and begin applying the same rigorous security auditing to their tooling directories as they would to their production infrastructure.”

To avoid detection, the stolen data is exfiltrated using Session — an anonymous messaging app that bounces data across a decentralized network. By disguising the theft as ordinary, encrypted chat traffic, the hackers blend in with normal network activity. This allows the attackers to completely ditch the traditional “command” servers that corporate security teams usually hunt for and block.

The success of the “Mini Shai-Hulud” campaign exposes a major blind spot in software security: Current defenses check where an update comes from, but not if the code inside is actually safe. By hijacking the developers’ own automated systems, attackers were able to stamp their malware with official digital signatures — proving that attackers can bypass modern safeguards simply by turning a company’s own tools against them.

Socket CEO Feross Aboukhadijeh told CyberScoop that organizations should look for signs that a compromised package version was installed in CI/CD or developer environments, unexpected outbound connections to campaign infrastructure, suspicious changes in package lockfiles, unusual package publishes from their own maintainers or CI systems, and persistence artifacts in developer tooling directories. 

“There is no single centralized kill switch for this kind of campaign,” Aboukhadjieh said. “The hard part is that by the time a malicious package is confirmed, it may already have been installed inside the exact environments attackers want most: developer machines and CI runners. You can pull a package from the registry, but you cannot automatically pull back the credentials it may have already stolen.”

While these packages are maintained by volunteers, Eriksen said the incident is a huge issue for enterprises due to how many development teams use the software in their products and services. 

“This is not a ‘volunteer’ vs corporate thing,” Eriksen told CyberScoop. “This is an all-of-society problem.”

Aboukhadjieh told CyberScoop that these continuing attacks on popular open-source software packages is part of “a larger reckoning over how the software industry consumes open source.”

“This campaign shows how thin the line has become between a developer tool and critical infrastructure,” he said. “When attackers compromise tools that are already trusted inside build systems, they do not have to break into every company directly. They can ride the trust those tools already have.”

The post ‘Mini Shai-Hulud’ malware compromises hundreds of open-source packages in sprawling supply-chain attack appeared first on CyberScoop.