TrollEye Security

Cyber News

The Access Was Closed. The Risk Had Already Materialized.

CrowdSec’s compromised GitHub access was closed just three days after roughly 170 private repositories were copied, but the theft remained undiscovered for nearly four months.

How a Repository Theft Stayed Hidden for Four Months

On May 22, an attacker used a stolen GitHub OAuth token to copy roughly 170 private repositories belonging to CrowdSec. Three days later, the access that made the theft possible was gone.

CrowdSec removed a recently departed employee from its GitHub organization on May 25. What the company did not know was that his laptop had been compromised through the TanStack npm supply chain attack, his OAuth token had been stolen, and the repositories had already been copied.

For nearly four months, the access was closed while the consequences remained unknown.

What Happened Between May and September

The compromise began with malicious versions of 42 TanStack npm packages published on May 11 as part of CVE-2026-45321. The packages could harvest GitHub tokens, SSH keys, cloud credentials, and other secrets from developer machines.

CrowdSec later traced the repository theft back to the laptop of a recently departed employee. Most of his access had already been removed, but his GitHub access had deliberately remained active so he could finish outstanding work. That remaining access was removed on May 25 without CrowdSec knowing it had been compromised three days earlier.

What followed was nearly four months in which the access path was gone but the theft itself remained undiscovered.

What Closing the Access Couldn't Tell Them

CrowdSec says the OAuth token left no trace in the GitHub logs it could check. When the company eventually investigated, the token itself no longer existed. GitHub support later helped reconstruct its history.

Meanwhile, the copied repositories contained private source code, 83 user email addresses, information about 51 prospective investors, and a still-usable AWS SNS credential limited to publishing to a single topic.

On August 17, someone attempted to use that AWS credential but got no further. Then, on September 16, the stolen code appeared on a public forum.

Only then did CrowdSec learn that repositories had been copied months earlier and begin reconstructing what had happened.

That reconstruction eventually produced an answer. CrowdSec reported that the account had been used only to copy code, and that nothing was altered, not the open-source code, not the private repositories, and not the build pipelines. Reaching that conclusion required rebuilding the window in which the token was live, because the access itself was long gone.

Sometimes Verification Has to Look Backward

This was not a case of CrowdSec knowing about the compromise in May and failing to verify its response. The company did not know the laptop or GitHub token had been compromised.

Security teams do not always discover an exposure while it is still open. An account may already be disabled. A credential may already have been rotated. A vulnerable system may already have been patched.

By the time the exposure is discovered, looking at the current environment may show that the original path is already closed.

That answers what is true now. It does not answer what was true while the exposure existed.

In CrowdSec’s case, the GitHub access had been gone for months by the time the company understood what happened. The investigation therefore had to work backward: when was the token compromised, what could it reach, and what happened before the access disappeared?

Apply the Same Test to Your Own Exposures

When your team discovers an exposure, don’t stop at asking whether it still exists.

Ask:

  • When did the exposure begin?
  • What could it reach during that period?
  • Is there evidence that it was exploited?
  • Could anything taken or changed during that window still create risk today?

That last question matters. Closing an access path prevents it from being used again. It cannot undo something an attacker already did while the path was open.

CrowdSec’s access was closed within three days of the theft. The theft itself remained unknown for nearly four months.

That’s the distinction verification needs to account for.

Don’t only verify that an exposure is closed. Verify what happened while it was open.

Continuous Threat Exposure ManagementClose the Exposure. Verify the Outcome.TrollEye runs exposure management as a continuous cycle: scoped to the business, prioritized by consequence, validated against what an attacker can actually reach, and closed only once the outcome is confirmed rather than assumed.
Explore Our CTEM Solution

Sources: The Hacker News

Share:

Live Webinar

From Discovery to
Risk Reduction

Operationalizing CTEM in Modern Security Programs

Date September 24, 2026
Time 2:00 PM Eastern

Learn how modern security teams can move beyond finding exposures and operationalize every stage of Continuous Threat Exposure Management.

01 Scope
02 Discover
03 Prioritize
04 Validate
05 Mobilize
Reserve Your Spot

Free registration · Live discussion and Q&A

This Content Is Gated