staging-devopsy.kinsta.cloud

Tag: NPM security

TeamPCP Supply Chain Attack Leads to CrowdSec Source Code Being Stolen

About 170 private GitHub repositories belonging to French cybersecurity company CrowdSec were compromised and source code was stolen by attackers earlier this year in the wake of an npm supply chain attack in May by the notorious TeamPCP threat group on TanStack.

TeamPCP used the Mini Shai-Hulud self-propagating worm to grab credentials and tokens and published 84 malicious artifacts across 42 TanStack packages, and CrowdSec GitHub repositories were caught up in the attack.

CrowdSec, which crowdsources threat intelligence, earlier this month learned that source code had been stolen from the laptop of a former employee that was compromised in the TanStack attack. An OAuth token taken from the ex-employee’s GitHub account still had permission to read the vendor’s private inventories.

TeamPCP on May 22 took credit for the supply-chain attack on TanStack 11 days earlier. In all, about 300 CrowdSec public and private repositories were compromised. Also on May 22, one of the founders of the BreachForum hacking site and another member downloaded the contents of the private CrowdSec GitHub repositories from an IP address in Toronto, Canada, a process that took about nine minutes.

Revocation Was Too Late

Three days later, the company revoked GitHub access to the former employee’s laptop, but by that time the damage was done. However, the theft of the source code was undetected until September 16, when it was leaked on pwnforum, a dark web cybercrime marketplace.

The damage wasn’t widespread, with CrowdSec researchers writing that “no client data, login/password, name, organization, or anything else was leaked, and CrowdSec doesn’t store PII or client logs; the impact is limited to CrowdSec.”

However, as CrowdSec CEO Philippe Humeau wrote in a blog post, “we were very close to clean.” Among the leaked information was a token for using Amazon Web Services’ (AWS) Simple Notification Service.

“Our infrastructure is AWS serverless, and we make heavy use of SSM/Secrets Manager, so the number of credentials present is very low but still warrants analysis,” Humeau wrote. “Most of the tokens and secrets present in the source code had been revoked or rotated before the leak, but we can see that the ones present and usable have been probed.”

Information Leaked

In addition, a small amount of client and partner information was leaked, including some email addresses – mostly Gmail – of 83 users, or less than 1% of the company’s 150,000 users. Also disclosed were the first and last names of 51 potential investors dating back to 2020, along with their email addresses and their investment context.

CrowdSec researchers initially had trouble tracking the stolen OAuth token to the source, but with help from GitHub support staff, they were able to determine it was taken from the laptop of the former employee “who had just left the company, but that was still part of the GitHub organization for legitimate reasons, and his account was used to dump the repositories,” the CEO wrote.

He detailed the range of security features CrowdSec has in place, including privilege separation, two-factor authentication, audits, logs, penetration testing, automated code analysis, and age monitoring for npm nodes.

No EDR or Access Cutoff

However, there were a couple of security issues. One was not having endpoint detection and response (EDR) on developers’ systems, though that’s changed, according to Humeau. He wrote that the company is using it to focus on such threats as malicious packages and extensions.

“As supply chain attacks become the new plague and virtually anyone can get caught in them, we should have done this earlier,” he wrote.

The other was not immediately cutting off access to the former employee’s laptop after he left the company. In a study by job search platform Zippia, 76% of IT leaders surveyed strongly agreed that offboarding represents a significant security threat, with 20% of companies saying they had experienced a data breach connected to a former employee.

“Prompt access revocation is important during the offboarding process to protect company data, prevent security breaches, and maintain compliance with legal and regulatory standards,” officials with identity management vendor Lumos wrote. “When an employee leaves, failing to revoke their access rights can quickly lead to unauthorized access, data breaches, and the potential misuse of sensitive information.”

September 24, 2026
Cyber Threats to DevOps Platforms Rising Fast, GitProtect Report Finds

Software developers, CI/CD pipelines, and the tools they rely on are increasingly becoming attractive targets for threat groups. The number of cyberattacks on code repositories like npm and GitHub continues to mount as threat actors push their supply chain attacks.

Compromising open source packages, fake development tools, and social engineering are among the tactics bad actors use against developers. Researchers with Kaspersky Lab this month wrote that a combination of programmers’ unfounded belief that they are good at spotting threats and jobs that require them to often download and run third-party code “makes them sitting ducks for cyberattackers.”

GitProtect.io analyst this week detailed the mounting and evolving threats facing developers and their operations. In its DevOps Threats Unwrapped Report 2026, the DevOps backup and recovery specialists found that the number of incidents targeting DevOps environments in 2025 grew 21% year-over-year, and that the number of hours of impacted performance those incidents caused doubled to 9,255, costing more than $740,000 in lost engineering productivity.

The numbers in the report are based on publicly available information published by vendors on their status pages, security advisories, databases, and publicly reported incidents, according to GitProtect.

‘A Playground for Cyber Criminals’

“What could we remember 2025 for when it comes to DevOps threats?” Daria Kulikova, head of GitProtect Lab, wrote in the report. “It was a year when trusted development platforms, automation pipelines, and cloud identities became a playground for cyber criminals. Attackers leveraged platforms such as GitHub, GitLab, Atlassian, and Microsoft as part of their malware campaigns – they used trusted DevOps platforms as malware distribution channels, command-and-control infrastructure, and credential harvesting pipelines.”

Kulikova pointed to how various campaigns – such as Shai-Hulud, GhostAction, GPUGate, and GitVenom – abused automation and stole tokens to compromise repositories, listed a range of malware families like PyStoreRAT, SmartLoader, Lumma Stealer, and AsyncRAT that were distributed through fake libraries, poisoned packages, and other means, and noted that AI-generated repositories and dormant accounts were used for credential theft and covert reconnaissance.

“However, attackers werenʼt only limited to distributing the code on DevOps platforms,” she wrote. “Identity was another attack direction. Hackers abused OAuth flows, long-lived Personal Access Tokens (PATs), and MFA-bypassing phishing kits to bypass defenses on Microsoft 365, GitHub, and collaboration tools at scale.”

By the Numbers

The numbers in the report illustrate the turn bad actors are taking toward developers. In 2024, GitHub, GitLab, Azure DevOps and Jira saw a total of 364 incidents, and that number jumped last year to 607, about a 40% rise. Among those incidents, 156 were critical or major events that consumed more than 1,750 hours of downtime, a 69% increase in high-severity disruptions from 2024, when there were only 48 such cases.

The need to patch software vulnerabilities also grew throughout 2025, according to the report. In all, vendors reported 236 security flaws that were patched across DevOps services, with 14 deemed critical, with a CVSS severity score of 9.0 or higher, and another 126 given high-severity ratings.

In addition, there was a 30% increase in patched vulnerabilities between the first and second halves of the year, Kulikova wrote.

Downtime Increases

The downtime caused by the growing number and severity of incidents was significant, according to the analysts. While the while there was the 21% increase in the number of incidents – from 502 in 2024 to 607 last year – and total downtime jumped almost 95%, from 4,755 hours to 9,225. The frequency of the disruptions didn’t just grow, but became more difficult to resolve, they wrote.

About 62% of the outages of DevOps platforms were driven by the degraded performance caused by attacks, according to GitProtect’s numbers. That said, they accounted for only 34% of the total downtime. Maintenance that needed to be done following incidents – which made up only 4% of the total number of outages – consumed 30% of the lost time, showing that planned and unplanned maintenance was the primary reasons for platforms not being available.

Some Things Stay the Same

There are some areas that didn’t change much year-to-year, according to the report. The technology and software sectors were still the most targeted, with others like telecommunications, automotive, and education also in the crosshairs, and ransomware and extortion groups, such as Hellcat and Crimson Collective, were behind a large number of data breaches, which targeted high-profile companies like Red Hat, Nissan, and Europcar.

“As attackers blend trusted platforms, hardware-aware evasion, malicious AI-generated code, and phishing-as-a-service into their arsenals, the 2025 threat landscape makes one thing clear: traditional perimeter defenses and reactive monitoring are no longer enough,” Kulikova wrote. “Organizations need to ensure the resilience of their environment.”

April 29, 2026
The Hidden Security Risks in Modern JavaScript Frameworks and How React Teams Can Reduce Them
In modern web development, JavaScript lays the foundation for all sorts of interfaces, scalable apps, and interactive platforms. And of course, React and other popular dev frameworks make it a whole lot easier to build large scale Single Page Apps. The problem is, this convenience comes with a price – a bunch of hidden security risks embedded in JavaScript frameworks.

These risks can be hard to spot. RAD tools are great for speeding up development by cutting out some of the logic and hiding the internal workings of the app from the dev. Trouble is, every extra dependency you add, every bit of dynamic rendering, every incorrect input handling is a potential vulnerability waiting to be exploited by some malicious hacker. So, paying attention to security every step of the way is now pretty much non-negotiable.

Understanding where modern JavaScript frameworks introduce implicit security assumptions is critical. Only then can you make informed technical decisions rather than reacting to incidents after deployment.

Modern JavaScript Frameworks and Sources of Vulnerability – Where Do They Come From?

One of the main reasons why web projects end up with JavaScript security vulnerabilities is the over-reliance on third-party libraries. There are hundreds of thousands of packages floating around the npm ecosystem, and even popular ones can contain vulnerabilities or be compromised in some way. Which means even in the React environment, you need to have a good eye for spotting not just the direct dependencies, but the transitive ones as well. These can hide all sorts of nasty JavaScript exploits or logics find a way to bypass the app’s security entirely.

Practically speaking, the risk is not solely down to packages that are clearly malicious. Legitimate libraries can still introduce vulnerabilities, like:
- Default settings that just aren’t secure enough
- Inadequate input validation
- Or outdated cryptographic practices that quietly slip into production builds.
For React teams, this means application security very much depends on keeping those dependencies clean, just as much as on writing top-quality first-party code.

Client-side Rendering

One of the main reasons why React and similar frameworks are vulnerable to certain types of attacks is client-side rendering. The whole UI is rendered in the browser, which means attackers can use input mechanisms to create unverified content. Rendering tools are generally safer than just throwing in HTML, but if developers use unsafe APIs, the risk of XSS attacks increases significantly. And if proper validation and data filtering aren’t implemented for each API call, asynchronous data loading can create all sorts of security entry points for attackers to exploit.

A lot of these issues are down to common JavaScript security anti-patterns, not any framework-specific flaws. We see the following issues popping up time and time again across different frameworks and application types:
- Handling input badly
- Using browser APIs in unsafe ways
- Weak authentication flows
- Putting too much trust in client-side logic.
For a more in-depth look at these recurring security pitfalls and mitigation strategies, check out industry-focused analyses on best practices. The ones that help you spot patterns that go beyond any single library or tool.

The Safe Path to Development with React – Don’t Get Lost

In practical terms, security is all about how the entire development process is set up. In this context, React isn’t just a library for building interfaces; it’s part of a whole product ecosystem where React development entails architectural decisions, working with business logic, backend integration, and getting the app ready for scaling.

Teams working on long-term projects usually break down their React apps into a collection of independent components. These components have their own clear-cut boundaries of responsibility and well-defined points of interaction with external services.

This approach can reduce the number of unknown indirect dependencies in your code base, making it simpler to check for bugs. It also helps you catch potential security issues related to data transfer or state handling a lot sooner than you would without it. It’s worth remembering that building a secure React app isn’t just about writing secure code, but also having processes like code reviews, writing standards, automated testing, and keeping an eye on your dependencies in place.

Experienced teams find it most effective to make these practices part of their normal workflow. Security-related checks that fail your build, stop you from making a change that could make your app more vulnerable, or flag high-risk dependency changes before you push them out to production tend to produce more consistent results than relying on manual checks alone.

A mature approach to React development is all about collaboration. You want teams where front-end development is happening in close coordination with back-end, DevOps, and security considerations.

Practical Steps to Reduce Risks
1. Managing Your Dependencies
Third-party packages are always a good way to save time, but they also give an outsider a window into your app. Regular audits of your dependencies using tools like npm audit or running them through a trusted scanner can help you spot any potential problems as well as find out about newly discovered security issues. Locking down specific versions of your dependencies is another good way to avoid any unexpected updates that might slip past your checks and bring security issues back to your doorstep.
1. Safe State Handling
You should never store sensitive stuff like tokens in a Redux state or local storage unless it’s encrypted. Using HttpOnly cookies and checking things on the server side is a good way to make it harder for people who might get hold of your client state to do any damage. Even if you don’t leak anything, if you’ve got tokens on the client for a long time, it makes it easier for them to reuse or steal credentials. And if you can get access to the client state via the developer tools or even just from the cache, it increases your area of vulnerability, even if some hacker isn’t actively trying to exploit any XSS issues.

Just keep in mind that the more sensitive data you’ve got on the client, the more of a risk it is, so try to keep it to a minimum and transfer as much logic as you can to the server to reduce the impact of any potential vulnerabilities in your code.
1. Limit how Vulnerable You Are.
To keep the surface of potential attacks as small as possible in your React apps, you need to be intentional about what actually runs in the browser. Some APIs are just plain unsafe and should only be used in rare cases. You should always make sure to sanitize whatever user input comes in and have a good Content Security Policy in place to stop anyone from running code they shouldn’t be able to run.

All these things can help reduce the window for XSS attacks, especially when you combine them with clear boundaries around what is running on the client and not exposing as much of your internal state as you can.

Conclusion

Modern JavaScript frameworks, such as React, make development fast, but that speed comes with hidden risks. The framework itself is rarely the problem; it’s how we use it. Unchecked dependencies start to pile up, exposed state and redundant client-side logic can creep in, and before you know it, a small issue has turned into a major problem waiting to happen.

The teams that stay ahead don’t rush to add even more tools or processes at the end; they take a step back and think really critically about their architecture from the start. Being super mindful about what actually runs in the browser, which packages you can trust, and how the client-side interacts with the backend is what stops these hidden risks from turning into real problems.
February 24, 2026
Chainguard Adds Curated Repository to Secure JavaScript Libraries

Chainguard today made available via a private beta program a set of curated JavaScript libraries to its portfolio of curated libraries that it provides to secure software supply chains.

Patrick Donahue, senior vice president for product at Chainguard, said that in the wake of a series of incidents involving node package manager (NPM) repositories, including now the infamous Shai-Hulud cyberattack, the need for an alternative Chainguard Libraries for JavaScript repository that reduces the chances of malware being introduced into a JavaScript software supply chain has become especially acute.

The Chainguard Libraries for JavaScript service from Chainguard provides access to a collection of curated builds of thousands of common JavaScript dependencies that were created from source using a platform based on the Supply-chain Levels for Software Artifacts (SLSA) framework originally developed by Google.

Chainguard then makes those libraries available in whatever way they already consume libraries, either through direct download from Chainguard or with existing artifact managers, such as JFrog Artifactory and Sonatype Nexus.

As valuable a service that npm repositories have provided, the simple fact of the matter is that the maintainers of these platforms simply lack the resources and expertise required to curate JavaScript libraries, noted Donahue. As such, the need for an alternative approach that provides enterprise IT organizations with access to a set of curated libraries that are free of known malware is now critical, said Donahue. Additionally, if any new type of malware is discovered, Chainguard will refresh the libraries it provides to eliminate it.

DevSecOps teams have been struggling with securing open source software for years now, but more recently, cybercriminals have become more adept at injecting malware into software supply chains that they hope to activate at some later date. They may not know which downstream application malware might one day manifest itself in, but they are betting that a significant percentage of them will present them with high-value targets after they have been deployed in a production environment.

Hopefully, cybersecurity teams are using scanning tools to discover any malware before an application is deployed, but in many instances, that malware may be difficult to discover because it is hidden in an open source software component that was downloaded from a public repository. More troubling still, much of that malware is being designed in ways that enable it to evade detection by the scanners used by cybersecurity teams.

It’s not clear to what degree cybersecurity threats aimed at software supply chains have become a crisis, but as regulations holding organizations more accountable for flaws in the software they ship become more stringent, more organizations than ever are adopting best DevSecOps practices to improve application security. Unfortunately, adoption of best DevSecOps practices has been historically uneven so the chance there will be more application security incidents in the months ahead is fairly high at a time when, thanks to the rise of artificial intelligence (AI), the pace at which insecure applications are being built and deployed is only going to accelerate.

September 25, 2025