Log4Shell has a CVSS score of 10. As of this writing, our network gives it a 3.

Meanwhile, a remote code execution in BeyondTrust’s remote support product scores 9 on the same scale: attackers are picking their targets carefully, and activity is above average. So you have both on your patch list and a single maintenance window: which one goes first?

Here’s the short answer: prioritise by what attackers are doing right now. Is the CVE exploited at all? Are attackers choosing their victims or spraying the whole internet? Is the activity growing or fading? CVSS, EPSS and KEV give you the theory and the history. Live exploitation data gives you today’s order.

Back to Log4Shell: the folks still scanning for it today are more likely to be laggards, CERTs or pentesting companies than real bad guys. The really dangerous exploitation happens in the first hours and days after release: it’s the same window CISA now works with, since BOD 26-04 gives US federal agencies 72 hours to fix publicly exposed, highest-risk exploited vulnerabilities. And if Log4Shell is still an issue at your workplace in 2026, well, digital Darwinism will kick in fairly quickly 😅

What CVSS, EPSS and KEV actually tell you

All three are useful. They just answer a different question than “what should I patch first this week?”

• CVSS rates how bad a vulnerability could be, from its technical characteristics (attack vector, complexity, impact). It’s set at disclosure, so a 10 stays a 10 years after the attackers have moved on.
• EPSS estimates the probability that a vulnerability gets exploited in the wild in the next 30 days. It’s much closer to reality, but it’s a probability across everyone: it says little about who is being hit, or how. Don’t get me wrong, EPSS is useful: it’s a good complement to the existing scores.
• CISA KEV lists vulnerabilities with evidence of exploitation in the wild. Great for “must patch” lists, but it’s a yes/no with no sense of intensity or trend, and entries land after the evidence. The most important part, to me: things get added to KEV and practically never removed, so you end up with an ever-growing list, long after the attackers have moved on.

Do any of them tell you whether attackers are going after organisations like yours this week? No, and that’s the gap we wanted to fill.

Three signals that set the order

When we built the Live Exploit Tracker, we boiled exploitation down to three questions, each answered from the more than 40 million attack signals a day sent by 250,000+ active Security Engines.

1. Is it exploited now, and by how many IPs? Plenty of scary CVEs see little real exploitation, while some boring-looking ones get hammered. Counting the distinct IPs that exploited a CVE over the last few days is the first filter.

2. Targeted or mass scanning? We call this the Targeted score (0 to 5). At 0, attackers hit IPs at random in automated sweeps: you’re one of millions. At 5, they select their victims based on exposure and configuration, and an alert on your systems likely means someone picked you. CVSS is blind here: a CVSS 7.5 hunted precisely can hurt you more than a CVSS 10 nobody bothers with.

3. Growing or fading? The Momentum score (0 to 5) compares current volume with the CVE’s history. High momentum with low targeting usually means a new automated campaign: lots of noise, little signal per alert. High momentum with high targeting is the combination that should get you out of bed.

The tracker folds these into a CrowdSec Score from 0 to 10, and adds an exploitation phase, a plain-language label for where the CVE sits in its life. For a fresh CVE, things move fast:

Does every CVE follow that path? No, and that’s precisely why we watch it live.

From score to decision

Here’s the triage table we use in our own docs, slightly condensed:

Two more signals help break ties. The threat context tells you who is being targeted: attacker and victim countries, industries, and what the attackers seem to want (taking over infrastructure, stealing data, ransomware). And reconnaissance rules catch attackers probing a product (Exchange, F5, WordPress…) before any CVE is published, which often tells you where the next wave will land.

An example from our docs: for an authentication bypass in PAN-OS, the threat context showed mostly commercial and tech companies being targeted, with French and Hungarian organisations over-represented, and attackers going after control of the firewall management plane instead of data. If you run that product in a French tech company, that CVE goes to the top of the pile, whatever its rank in your scanner.

Block while you patch

Patching takes time, and some systems simply can’t be patched this week. The tracker lists the IPs exploiting each CVE, and you can subscribe a firewall to that list by CVE or by vendor (which also covers the vendor’s future CVEs). It works with Palo Alto, FortiGate, Check Point, Cisco, Juniper, Sophos, F5, pfSense, OPNsense, MikroTik, or any device that reads a plain IP list.

Large SOCs are rightly wary of broad blocklists they don’t control. A list scoped to the IPs exploiting the one CVE you can’t patch yet is an easier conversation, and it buys you time to patch properly.

What it can’t see

Is this a replacement for your vulnerability scanner or for CVSS? No. The tracker shows how a CVE is exploited in the wild; your scanner shows where you’re exposed. And we only see what hits internet-exposed systems: for products that are rare in our network, a CVE can sit in “insufficient data” for a while. The right move then is to fall back on CVSS and the vendor’s advisory until the data matures.

Try it

• Look up any CVE in the Live Exploit Tracker (book a demo to get your access key), or pull scores, phases and attacker IPs through the API and the Python SDK into your SIEM, SOAR or vulnerability-management workflow.
• For the bigger picture, our vulnerability and exploitation report covers the trends behind these scores.

Spotted a CVE whose score surprised you? Let us know on Discord: that’s how the scoring gets better.

PHP2Shell is the name given to two critical vulnerabilities in PHP’s core, tracked as CVE-2026-109618 and CVE-2026-109619. Because the flaws are in PHP itself, exposure is not limited to one CMS or framework.
Wiz Research estimates(*) that PHP powers 70% of websites worldwide, making the potential reach of these vulnerabilities unusually broad.

Updating PHP to a fixed release is essential. But upgrades can take time: teams may need to test compatibility, coordinate a maintenance window, or wait for a hosting provider or vendor to ship an update. For older systems, a supported update may not be immediately available.

If you have a healthy install of CrowdSec WAF already, you’re automatically protected via the automatic rules and scenario updates.

Is PHP2Shell being exploited? What our network saw

Yes, and fast. CrowdSec’s network recorded 450+ proven PHP2Shell attackers in the first 24 hours of observed exploitation. You can follow the activity live on the Live Exploit Tracker, and the IPs behind it are collected in the PHP2Shell Attackers blocklist, so your firewall can block them before they reach your servers.

How long until you can actually upgrade?

The answer depends on which PHP version you run, and there are three tiers:

W3Techs version data(*) puts 26.9% of PHP sites on PHP 7, 7.7% on PHP 5, and a further 21% of the PHP 8 population on 8.0 or 8.1. Combined, roughly 48% of PHP sites have no full official release to upgrade to, they are waiting on a vendor, a rebuild, or a migration.

Covering you while you patch, or when you can’t patch yet: that’s what virtual patching is for.

Respond quickly with a layer at the edge

Virtual patching adds a WAF rule that identifies a known exploit request and blocks it before it reaches PHP or the vulnerable application. CrowdSec has published virtual patches for both CVEs:

• vpatch-CVE-2026-109618 blocks multipart requests with form fields nested 12 levels or deeper, and multipart bodies with more than 50 file parts — the conditions needed to exhaust PHP’s memory during input parsing.
• vpatch-CVE-2026-109619 matches multipart requests carrying a php_session_upload_progress field, the route used to reach the stale-state bug. It inspects the raw body rather than parsed arguments to catch attempts a multipart parser would otherwise reject.

Both are distributed through CrowdSec’s Hub to protected servers and updated automatically.

This gives teams a way to react quickly when a vulnerability becomes public and peace of mind thanks to the exceptional reaction time of CrowdSec vpatch releases. Depending on the application and the rule’s coverage, it may also support a risk-based decision to keep a service available while a permanent fix is planned and applied. Virtual patching is useful beyond a single incident: it provides an ongoing layer that can be updated as new exploit rules become available.

Virtual patching is not a replacement for updating PHP, and it is not a guarantee against every exploit path. PHP’s security advisory(*) states plainly: “There are no complete mitigations; updating is the only safe choice.” A WAF also only inspects traffic that passes through it — if your origin is reachable directly, lock it down to your proxy. Use the WAF as an additional protection layer, and patch as soon as you can.

Get started with CrowdSec open source WAF 

CrowdSec WAF is open source. A basic deployment puts the CrowdSec Security Engine and AppSec component on the host, with a bouncer in Nginx, OpenResty, Apache, HAProxy, Envoy, or Traefik to inspect requests before they reach your PHP application.

Request path: website traffic reaches your webserver/reverse-proxy, where the CrowdSec bouncer forwards it to the AppSec WAF for inspection. Allowed requests continue to the PHP application; requests matching a known exploit pattern are blocked at the edge.

1. Install the Security Engine on your Linux host using the Linux installation guide.
2. Install a WAF-compatible bouncer for Nginx, OpenResty, Apache, HAProxy, Envoy, or Traefik
3. Install the WAF collections and enable AppSec. The virtual patching collection is the key step:

sudo cscli collections install crowdsecurity/appsec-virtual-patching crowdsecurity/appsec-generic-rules

4. Then follow the WAF quickstart to enable AppSec and connect the bouncer to it. The vpatch rules are distributed through the CrowdSec Hub and updated automatically.

CrowdSec WAF also supports bot detection as an additional feature. It is enabled separately from the virtual patching collection; see the CrowdSec 1.8 bot-detection overview.

For help with installation and troubleshooting, try the official CrowdSec skill for Claude Code and Codex.

Block the attackers already exploiting PHP2Shell

Virtual patching stops the exploit pattern and is part of our open-source solution. There is also a proactive approach enabled by the knowledge brought by the community and validated by CrowdSec IP Reputation Consensus, allowing you to block the IPs already running the vulnerability.

Our detection network validated 450+ proven PHP2Shell attackers in the first 24 hours of observed exploitation. They are published as a dedicated blocklist, PHP2Shell Attackers — CVE-2026-109618 and CVE-2026-109619, updated as new attackers are confirmed.

This is where our two approaches meet, and they are deliberately different products. Detection is open source: the virtual patching rules shared in this article are free, auditable on GitHub, and yours to run on any host. Proactive blocking is commercial: the curated list of IPs already confirmed to be exploiting PHP2Shell is a paid blocklist. One tells you what the attack looks like; the other tells you who is already launching it.

To get the blocklist on your engines, contact us for access.

References

• Wiz Research estimates
• Tenable – Minimal Source Backport
• W3Techs PHP data
• PHP Archives

More from CrowdSec

• CrowdSec Open Source WAF Bouncer for Apache
• CrowdSec Open Source WAF Bouncer for NGINX
• CrowdSec Open Source WAF Bouncer for OpenResty
• CrowdSec Open Source WAF Bouncer for HAProxy
• CrowdSec Open Source WAF Bouncer for Traefik

Frequently asked questions

Does a WAF stop PHP2Shell, or do I have to patch PHP?

You have to patch PHP. A WAF is a stopgap while you update: CrowdSec’s two free virtual patching rules block the request patterns the known exploit relies on, which buys you time until you can move to a fixed PHP version. The rules are labeled “tentative” on the Hub, and they can’t protect a server that attackers can reach directly without going through the WAF. Updating PHP is what actually removes the bug.

Is PHP2Shell being exploited in the wild?

Yes. CrowdSec’s network recorded 450+ proven PHP2Shell attackers in the first 24 hours of observed exploitation. The Live Exploit Tracker shows the latest activity, and the PHP2Shell Attackers blocklist collects the IPs behind it.

How do I protect a PHP 5 server?

The PHP project won’t release a fix for PHP 5, so the long-term answer is a vendor backport (if your distribution or LTS vendor offers one) or a migration to a supported version. In the meantime, put a WAF in front of the server: the CrowdSec WAF inspects requests before they reach PHP, whatever the PHP version behind it, and the two free virtual patches block the known PHP2Shell exploit patterns. It’s a stopgap, not a fix, so plan the migration while the rules hold the door.

Can I protect a PHP app in Docker without rebuilding the image?

Yes, for now. Run the CrowdSec WAF on the reverse proxy in front of the container: the rules inspect requests before they reach PHP, so the image itself doesn’t change. It’s a stopgap, so rebuild with a patched PHP image as soon as you can.

Here are the eight lessons, with the numbers behind them.

Where the data comes from

The CrowdSec Security Engine is free and open source. Each instance detects attacks locally (IDS, WAF, bot detection) and shares the metadata: which detection rule fired, when, and the attacking IP. When a new CVE gets a virtual patch, it goes out to hundreds of thousands of real servers, so we capture the exploitation momentum from the first attempts.

That’s also why VulnCheck’s State of Exploitation 2026 report, which counted 118 sources that were first to report exploitation in 2025, wrote that “the most notable increases in sources that were first to report KEVs included CrowdSec, which was onboarded as a new source and scaled significantly in 2025” (source).

1. The defenders’ window is now measured in hours

Of the 332 exploited CVEs we tracked from Q4 2024 to Q2 2026, 36% (121) were attacked within a day of publication, and 27% more within a week.

332 may look small next to the 9,000 to 15,000 new CVEs the NVD receives every month this year (NVD dashboard, October 2026). These are only the ones we saw actually exploited, and only those an attacker can reach on a server exposed to the internet: no Photoshop flaws, printer bugs, or obscure Windows local privilege escalations. That’s the short list that matters for anything you expose.

Since June 2026, CISA’s Binding Operational Directive 26-04 gives US federal agencies 72 hours to fix publicly exposed, highest-risk exploited vulnerabilities. Do the math: for more than a third of these vulnerabilities, the attack starts before the deadline clock has meaningfully run.

Early attackers are the most dangerous ones, because they hit before patches, signatures or blocklists exist.

2. More CVEs get exploited, and faster

Of the newly announced CVEs we track, the share exploited within 90 days of their announcement climbed from 8% in Q4 2024 to 67% in Q2 2026 (42 CVEs). CVE publication keeps accelerating, and so does the noise around it: scoring every CVE as urgent has stopped working.

3. CVE-geddon is not (yet) upon us

AI-driven vulnerability discovery makes headlines, but discovery is not exploitation. After Project Glasswing, VulnCheck’s Patrick Garrity looked at a sample: only 14 of 1,061 CVEs identified by Berkeley researchers had been exploited in the wild. His comparison also showed AI-rated severities running much hotter than maintainers’ ratings: 74% “high” for the model against 40% for maintainers. More findings, more scary scores, a small fraction actually used by attackers.

4. AI is making exploitation cheap, more than smart

AI got better at reconnaissance and exploitation, but token costs kept it for targeted attacks: only worth the money against a valuable victim. That’s changing. Local models plus better tooling make tokens effectively free, and a free weapon gets used like a machine gun, against everyone but with a high level of “personalization”. Actually, scratch that machine gun image; it’s more like industrializing sniper rifles.

5. Monster CVEs run on borrowed cloud IPs

React2Shell (CVE-2025-55182) is the behemoth of the year: 444,948 distinct IPs hunted it between 5 December 2025 and 8 September 2026, with a peak of 10,674 IPs on a single day, eight days after publication.

Two patterns stand out:

• Attackers move to the cloud. In the week of disclosure, 3% of the exploiting IPs came from hyperscaler ranges. A week later, around 80% did.
• The infrastructure is disposable. Four in five of the early hunters’ IPs were never seen again after day 1. Of that early cohort, only 5.3% were still reported a week later, and 0.2% after twelve weeks.

The lesson for defenders: block fast, and make sure what you block expires. A blocklist that never forgets ends up blocking a cloud IP your next customer will use.

6. Zero-days get exploited weeks before anyone writes about them

On CVE-2025-2748, our network saw 5 AWS IPs exploiting the vulnerability 42 days before watchTowr published their findings. We’ve seen similar patterns on SAP NetWeaver and Fortinet products. When a vulnerability is announced, assume someone has already used it. Spotting that activity before the CVE reaches the NVD is called pre-NVD detection.

7. Old vulnerabilities never die

The 50 most exploited CVEs still include vulnerabilities from 2002, 2012, and 2013, and CVEs from 2021 and 2022 make up 19 of them. PHPUnit’s CVE-2017-9841 was still hunted by 88,428 IPs, and Apache’s CVE-2021-41773 by 89,127. Patching last year’s backlog is still a security strategy.

8. Residential proxies, CGNAT, VPNs and cloud IPs blur the lines

Of the IPs we see attacking, 69% are residential addresses, and 25% are in data centers, with proxies/VPNs, AI services, and Tor making up the rest. Most attacks don’t come from “bad hosting providers” anymore: they come from addresses that look like your users. Telling them apart needs behavior and history per IP, beyond a hosting-provider list.

Bonus: attribution? Really?

A network of 300,000 Security Engines in 190 countries and 7,000 autonomous systems saw five disposable IPs exploit CVE-2025-2748 about 40 days before disclosure. For our friends who love attribution: who was it? And if you could tell, what would you do differently: let them in because they come from South Africa instead of North Korea?

Attribution matters for intelligence agencies and for reports. For the SOC on call, it changes nothing about the decision to block.

Your sector has its own threat profile

The weaknesses attackers go after aren’t spread evenly. In our data, organizations in industry see expression-language injection 3.8 times more than average, finance sees unrestricted file upload 2.7 times more, and government sees untrusted deserialization 2.1 times more. Prioritizing by “what’s exploited against organizations like mine” beats prioritizing by CVSS alone, and it’s why we build blocklists by industry and country.

What to do with this

The common thread: concentrate on the vector, not the payload.

1. Prioritize patching by live exploitation (is it exploited now, how targeted, growing or fading), with CVSS as a tie-breaker.
2. Block the IPs exploiting the CVEs you can’t patch yet, at the edge, with lists that expire.
3. Check the IPs hitting you against behavior and history, beyond a yes/no reputation.
4. Stop waiting for attribution before acting.

Want the slides? Download the SANS 2026 deck. Want to check IPs you’ve seen? Run them through IPDEX. Want to track CVE exploitation live? Ask us for a Live Exploit Tracker demo.

That question is answered by IP reputation. Most SOCs need a fast, contextual IP reputation lookup wired into their SIEM long before they need a full cyber threat intelligence (CTI) platform with actors, campaigns, and attribution. Full CTI earns its keep when you have the analysts to exploit it. IP reputation earns its keep on every single alert.

Let’s look at what each one actually gives you, where IP reputation runs out, and what to ask before you buy any feed (ours included).

Two different questions

The industry uses “threat intelligence” for everything from a text file of bad IPs to a team of analysts writing reports on a ransomware group. In practice, a SOC asks two very different questions.

Both are useful. The trap is buying the second one when your day-to-day pain is the first.

Where IP reputation earns its keep

Few organizations send their raw internet-facing traffic (web server logs, firewall accepts) to the SIEM: it costs too much and drowns the signal. The IPs that reach the SOC arrive inside alerts instead: a VPN or Entra ID login from an odd place, an IDS or WAF event, an EDR flagging a connection, a spike on an API. For each of those, the useful answer is short. Is this IP malicious? What did it do elsewhere? Is it still active? Is it aimed at organizations like mine?

A good IP reputation source lets you:

• Triage faster: the analyst sees “malicious, HTTP exploitation and SSH brute force, last seen 40 minutes ago, mostly targeting finance” next to the alert, instead of opening five tabs.
• Automate the boring part: enrichment rules can close or downgrade alerts on known mass-scanners and escalate the ones coming from IPs that pick their targets.
• Decide at the door: check an IP before you grant access to a VPN, an Entra ID login, an API, or a checkout page.
• Block before the alert exists: the internet-facing noise you never send to the SIEM still hits your servers. The same data, served as a blocklist, stops a chunk of it at the firewall.

All it takes is good data in the right place, and no threat-intel team.

Where full CTI earns its keep

Does IP reputation replace a threat-intel platform? No. Nothing that looks at IP addresses alone can.

If you’re tracking a specific group, investigating a breach, or briefing your board on the threats to your sector, you need what IP reputation doesn’t carry: malware families, phishing infrastructure, actor profiles, the “why” behind a campaign. That’s where full CTI platforms and the people who run them shine.

Attribution is the part I’d spend the least on. Whether it’s a famous APT or a kid with a rented botnet behind that IP, will you let it in? Will it change the action you enforce at the door? Rarely. And in an AI era, where anyone can industrialize an attack, the “attribution game” makes less sense than ever.

The honest split for most organizations: IP reputation for the volume, full CTI for the few cases that deserve an investigation. And if you only have budget and staff for one, the volume is where the hours go.

Not all IP reputation is equal: three questions to ask any vendor

1. Where does the data come from? A lot of IP reputation is built on honeypots: decoy machines that nobody legitimate talks to, so anything hitting them is suspicious. Fine for internet-wide scanning. But a honeypot has nothing worth stealing, so it rarely sees the attacks aimed at real businesses. Data that comes from production servers sees both the background noise and the targeted activity (we wrote about this trade-off here).

2. Do you get behavior, or just a verdict? “Malicious, score 87” is enough for a firewall. An analyst needs more: look for what the IP did (behaviors, ideally mapped to MITRE ATT&CK), which CVEs it exploited, which countries and industries it targeted, and how its activity evolved over the last day, week, and month.

3. How does an IP get off the list? IPs change hands. A residential address that was part of a botnet last month may be a customer today. Ask how false positives are handled, whether known-good services (CDNs, DNS resolvers, search engines) are excluded, and whether entries expire when the bad behavior stops. A feed that only ever grows will eventually block someone you care about.

How we built CrowdSec’s IP reputation

Since you’re reading this on our blog, here’s how we answer those three questions.

The data comes from production servers. More than 250,000 active CrowdSec Security Engines (open source) protect over 500,000 servers worldwide, and together they send us more than 40 million signals a day. When one of them blocks an attack, it shares the metadata (which detection rule fired, when, and the attacking IP) and keeps the logs to itself. Only unmodified, versioned detection rules count, and an IP is only flagged once many independent machines across many different networks report it, which is our main defense against poisoning.

You get the behavior. Over the past 3 months alone, more than 22 million IPs were reported, and every one of them comes with a verdict (malicious, suspicious, known, benign, safe) plus 30+ fields of context: behaviors and MITRE ATT&CK techniques, CVEs exploited, targeted countries and industries, background-noise level, the reputation of its /24 range and AS, first and last seen, and scores for aggressiveness, threat, trust and anomaly over the last day, week and month.

It’s early. 36% of the IPs on our high-threat list are exclusive to CrowdSec, compared with all other CTI sources, and we flag malicious IPs 1 to 10 weeks before other vendors. On the 2 a.m. alert, that’s the difference between “unknown” and “we’ve seen this one, here’s what it does”.

IPs leave when the bad behavior stops. Known-good services are excluded, and entries expire when reports dry up, which is why the blocklists we build from this data are curated to zero false positives.

Now the candid part: we only see what hits internet-exposed servers. CrowdSec is IP reputation for ingress traffic, built from real attacks. Will it give you phishing domains, malware hashes, or an actor’s biography? No. If that’s what you need, pair it with a CTI platform: we integrate with MISP, OpenCTI, and the major SIEMs and SOARs for exactly that reason.

Try it on your own data

The fastest way to judge any IP reputation source is to throw your own logs at it.

• One IP: paste it in the free CrowdSec IP lookup.
• A whole log file: run IPDEX on it and see how many of the IPs hitting you we already know, and what they were doing.
• In your SIEM: a free CTI API key gives you 120 lookups a month to test an integration. Splunk, QRadar, Microsoft Sentinel, MISP, OpenCTI, Cortex XSOAR, and TheHive are covered in the integration docs.

Already doing this in your SOC? We’d love to hear how you split IP reputation and full CTI: hop onto our Discord and tell us.

Time flies! It has already been 5 years since I joined CrowdSec. The recent events about the leakage of our codebase led me to realize: what if we had been totally open source in the first place? Would we have done the work differently?

Perhaps a bit in the formatting, I could have removed some stray comments in the Git history, but not much in the core work. The core responsibilities remain the same: accurately assessing network size, implementing safeguards against data poisoning, and training models to classify IP addresses based on behavior.

The Internet never forgets

But let’s be honest, the Internet never forgets, and the Internet likes gossip. There are already several curious souls trying to dissect our codebase to find the shammy commit where we take all the user data and sell it to Big Corp.

Don’t waste your sweat (and your LLM tokens); you won’t find anything, not even close. If it were the case, the codebase would not have been published for free 4 months after the extraction. Instead, what you will learn about us:

Our KPIs reflect real network growth

KPIs are not emphasized; they are built methodically to reflect our network growth. Let’s be honest: every company has marketing claims, and most of the time figures are inflated by 10x (if not 1000x). However, I can confidently say that that is not our case. In the data science team, our goal is to explain why it makes no sense to claim 10 million installations (what is a Docker pull nowadays?) but to care about how many active watchers (Security Engines) report on a daily basis.

Yes, there are canaries in our Blocklists

We did put some canaries in our blocklists (and will continue to). Companies out there are indeed stealing our work by redistributing our IP reputation, hence violating our Terms of Service, and even taking profit out of it sometimes.

Yes, we run honeypots (all 30 of them)

We do run a network of honeypots (you can read more about what a honeypot is here). A whopping network of 30 machines, actually. It was necessary at the beginning to build a reputation system on signals we could trust. It then proved useful to test the load of our Console Organization and try alpha features in CrowdSec. It was never our intention to make it a cornerstone of our business model – and looking at some competitors turning back from this idea led me to believe it was the right decision. Now they are still up and running, yet they only represent a drop in the ocean. They produce 10,000 signals a day; that’s not even 0.001% of the total network traffic.

Why we call malicious IPs “pokemons”

We do call a “malicious-IP-reported-by-a-user” a “pokemon”. There are even around 1000 occurrences, according to GitHub. That’s shorter, and it makes the day-to-day work much more fun when you have to catch them all. We even built a Pokedex for that, but that’s only internal, of course.

Our marketing is backed by real data

We did produce marketing articles backed by genuine data analysis. When we released the article “With or Without CrowdSec: a tale of two servers”, a kind of A/B experiment between 2 servers–one with CrowdSec, one without– it was based on authentic data. We don’t make numbers up when we say we have 250k machines live protected by CrowdSec. That’s not even accounting for log centralization: large organizations usually run one CrowdSec on top of 10 or 100 services.

How we score IP reputation

We evaluate the reliability of our IP reputation by aggregating statistics over pokemons and watchers. We score the watchers based on network contribution and longevity and integrate this with statistics aggregated over IP reports to determine a malevolence probability.

What leaked, and what we reported

We did leak 83 email addresses of Console users. This is unfortunate but rather marginal compared to the 150k user base. All the details were already reported to the relevant authorities and the affected users.

How we use Console user data

We do aggregate user data to identify segments inside our Console users. Sometimes we intend to figure out who the correct audience is to become beta testers for a new feature. Sometimes it’s protective: we do have free-riders trying to breach the rules (and license agreements) to avoid paying for our CTI access. Most of the time we engage in conversation with them and try to identify what limitation they found with our current pricing strategy. Hopefully, the more we correct the direction, the less of a necessity it becomes.

What’s next for the data team

All this retrospective is, in the end, very positive for me, as it revives new content ideas. What if we released an updated version of the Tale of Two Servers? Or an Internet IP reputation map,  implementing geohash-like tiles for IP ranges 😉?

There won’t be a best moment for a proposal, especially as I am pleased to announce that the team is expanding. Alexandre Monteil just joined to help me build more captivating stories about our network (and Pokemons).

Stay tuned!

The Challenge: A Stealthy, Highly Distributed Residential Botnet

MindMax is a small Finnish company running a handful of free consumer websites, including online dictionaries, a TV guide, a car marketplace, and a quiz platform. Run by a lean team of four, MindMax maintains a compact, self-hosted infrastructure dedicated to serving daily user needs seamlessly.

In early September 2026, MindMax’s online dictionary sites were hit by a massive scraping network. The attack was extraordinarily sneaky: it utilized hundreds of thousands of residential IPs, with each IP making only a single request. Coupled with legitimate browser headers and constantly rotating user agents, traditional rate limiting and IP reputation checks were completely useless; no single IP ever triggered standard alarm thresholds.

The persistent traffic spike threatened server performance and hurt MindMax’s ad-funded sites. CEO Juha and his team initially crafted custom Nginx rules, JavaScript cookie verification, and network fingerprint blocks. While these custom fixes provided temporary relief, the botnet rapidly adapted to every defense they threw at it.

The Solution: Open Source Bot Detection

Already relying on the CrowdSec Security Engine, MindMax eagerly jumped at the chance to test CrowdSec’s new bot detection feature in alpha. The solution perfectly aligned with their architectural values: open source, lightweight, running entirely on their own infrastructure, and requiring zero third-party traffic routing.

MindMax deployed the Security Engine alongside the CrowdSec WAF (AppSec component) and bot detection, using an OpenResty bouncer situated in front of PHP. They piloted the setup on one dictionary site before expanding protection across three portals, taking care to exempt verified search engine crawlers so SEO remained completely unharmed.

The Results: 99%+ Rejection Rate & Uninterrupted UX

The impact was immediate and dramatic:

• Massive Threat Neutralization: In the first week alone, roughly 1,000,000 challenges were served to suspicious clients.
• Over 99% Block Rate: More than 99% of non-human traffic failed or abandoned the challenge instantly.
• Zero Friction for Real Users: Genuine visitors passed challenges seamlessly in ~2 seconds, with search traffic remaining rock-solid.
• Accurate Targeting: Manual checks confirmed that only headless browsers and malicious crawlers were blocked; legitimate users experienced no interruption.

Looking Ahead

By stopping low-volume, highly distributed residential bots that traditional tools couldn’t touch, all while keeping full control of their self-hosted setup, MindMax successfully eliminated the bulk of their bot problem. CrowdSec continues to protect their infrastructure alongside custom rules, giving MindMax the peace of mind to focus on delivering great services to their users.

This allowed us to progressively collect some bot signal data that we promptly started to investigate. Until the addition of bot detection features within CrowdSec, the Security Engine and Web Application Firewall have been nearly exclusively focused on “what is the IP doing?”, so being able to look into “what is the client behind this IP running?” is for us a whole new perspective, and we’re digging into the data like kids into a bag of unmonitored candies. 

So today, I’m super happy to present to you the first of an hopefully long series of investigations where we discover together the fantastic world of large-scale scrappers that might quickly turn into “What the actual F is m247 up to?”

Yes, we identified a cluster of bots that we dubbed “paperphone”; let me walk you through! But first, the “big numbers” headline:

What CrowdSec bot detection revealed

• 75,000 IPs
• Spread across 230 IP blocks
• Located across 43 countries
• Spotted over the course of two weeks

The timeline

The timeline itself is to be taken with a grain of salt, as the beginning of the identification of the cluster started when the feature was released: the infrastructure is likely to have been running for a while already.

We can, however, see that the IPs are progressively rallying the cluster as our users are deploying the feature and start to contribute to the detection. Unsurprisingly, we can also see the operator starting to rotate and cycle its IP addresses as they get banned left and right for failing the challenges too often:

But I’m already digressing; let’s look at what this cluster is made of, and how it’s distributed!

Geographic diversity, or just a facade?

Very often “geoblocking” comes into people’s conversations when dealing with unwanted traffic. But as soon as you’re dealing with even remotely sophisticated (emphasis on the remotely) actors, it becomes very ineffective, as “it’s coming from everywhere!”

In this specific case, the traffic from the cluster is originating from 43 distinct countries (if you trust geolocation, but we’ll come back to this later). However, the time of the requests doesn’t align with the time zones of the countries they claim to originate from

It goes further than having night-bird users. While the traffic is spread over days, synchronization regardless of the origin countries still shows up. For example, while Japan and the US are 13 hours apart, request spikes from both countries are highly correlated. And this pattern repeats over and over: Australia and Canada (14 hours apart) infrastructure wakes up at the same time.

So, while this seems odd, if you look at it from a UTC time zone point of view, it makes a lot more sense:

Nationality is a field somebody types

The scraper network spreads over 230 distinct IP blocks (mostly /24’s) and 80 networks. But again, this apparent diversity is a mere facade. When looking more closely at the IP blocks, a lot of things start to stand out.

Nearly every block involved shows some inconsistencies.

For example, 103.216.1.0/24 was issued to APNIC (The Regional Internet Registry for Asia Pacific). But it’s registered to RIPE (The RIR for Europe, the Middle East, and Central Asia), meaning an inter-regional transfer happened (it was last transferred in 2025). The registrant itself is Lithuanian, while the country claimed by the WHOIS is “United States”. More concretely, it means that the range changed ownership during its lifetime (lastly in 2025) – which is fine – but more importantly, its registration region, the country of the organization managing it, and the claim geolocalisation all differ significantly.

If you start to look closely within the ranges allocated, you can quickly see that the geolocation is to be taken with a grain of salt, as a lot of adjacent ranges are artificially located in various countries:

• 62.105.200.0/22 : 🇧🇪 Brussels
• 62.105.204.0/23 : 🇹🇭 Bangkok 
• 62.105.208.0/23 : 🇯🇵 Tokyo
• 62.105.210.0/23 : 🇫🇷 Paris

And this pattern is quite systematic when you look at the 230 address blocks involved. The good news is that it all boils down to a few entities that are controlling a significant portion of the involved IP ranges:

Note: The graph above shows ownership of IP ranges: organisation -> country -> AS -> IP block.

What all this shows is that the entities that are in control of the IP blocks deliberately obscure their geographic footprint, making it harder to detect and block. We’re not facing someone renting machines in 43 countries, but an organization artificially claiming to have a diverse geographic presence.

Surprisingly, the name of M247 doesn’t appear in the graph above. Worry not, while none of the blocks belong to M247, it is still the transit provider for more than 20% of PaperPhone’s cluster.

iPhones, Android, and bot signals

These whopping 75 thousand IPs have been showing a very consistent behavior, meticulously cycling between thirteen different device identities, including 5 different Android devices and 7 variants of iOS.

However, within the signals, there were some funny giveaways of obvious lies:

An interesting inconsistency was that the viewport size – the effective visible rendering area – was 375×812 for 100% of the bots. This matches the iPhone 10/11 (to my knowledge) viewport size, inconsistent with the claimed devices.

All of them are also using Google SwiftShader as their WebGL renderer (UNMASKED_RENDERER_WEBGL), which is Google’s open-source CPU-based software renderer. This information means that the Chrome-based browser is running on hardware that doesn’t provide any hardware acceleration.

The claimed Android devices (Pixel 9, Samsung Galaxy S25 Ultra, etc.) are all fairly recent Android devices, so the likelihood of them not having hardware acceleration is approximately zero.

At the risk of stating the obvious, when it comes to iOS 14/15 triggering a SwiftShader signal, given that it’s running Apple’s WebKit, the likelihood of it happening is again zero.

Maxing out available ranges

In this specific case, the IP ranges were mostly already flagged as being data centers and “known” in our CTI, so we’re not facing the more sneaky case of residential proxy abuse, as the density of IP addresses also shows:

Note: The graphic above shows the percentage of IPs in each block that were involved in the scraping actions.

We can see that more of the blocks have been used to their full capacity during the scraping operation, and that all the “diversity” of the network (AS, ranges, countries) is a mere facade.

You’ve deployed detection tooling, the alerts are flowing, and your dashboards are lit up. Yet your servers are still absorbing brute-force attempts, scanner traffic, and the occasional exploitation probe. The problem usually isn’t that you need more tools. It’s that detection without enforcement is just expensive logging.

That’s the real framing for the CrowdSec vs Suricata question. Not “which is better” but “where do you want enforcement to happen, and what’s it going to cost you operationally?”

What each tool actually does

CrowdSec’s Security Engine is a collaborative IDS that aggregates behavioral signals across its global network, produces alerts, and converts them into enforcement decisions. The key architectural detail: blocking isn’t automatic. Per our Concepts documentation, “Threat prevention (blocking) is enforced by Remediation Components (bouncers).” The Security Engine detects and decides; the bouncer (integrated with your firewall, reverse proxy, or CDN) actually drops the traffic. No bouncer attached means no blocking, full stop.

Suricata is a network traffic inspection engine. In passive IDS mode, it observes and alerts. In IPS mode, it becomes, as the Suricata 9.0.0-dev documentation puts it, “the Suricata mode that makes it act as a traffic filter,” sitting inline and enforcing drop decisions against matching traffic. Both tools can detect. The enforcement model, operational cost, and failure mode are where they diverge sharply.

What CrowdSec is built for on internet-facing Linux servers

CrowdSec’s value on a Linux server is preemptive, IP-centric blocking at the perimeter. Our signal network spans more than 190 countries and 7,000+ autonomous systems, processing over 50 million daily signals from production environments globally. At that scale, CrowdSec identifies known-bad IPs and distributes them as collaborative threat intelligence blocklists before they even touch your infrastructure.

The alert-to-decision-to-bouncer chain matters here. When the Security Engine identifies an IP behaving aggressively (scanning, brute-forcing, exploiting CVEs), it produces a decision. A remediation bouncer then enforces that decision against your existing firewall rules or reverse proxy configuration. Roughly 92% of attacks get blocked at the border before they reach servers, with an 82% reduction in alert volume as a downstream effect.

For web-facing services, CrowdSec’s AppSec component adds WAF capabilities, virtual patching, and OWASP CRS support directly into the enforcement chain. That’s a meaningful addition if your threat surface includes web application exploitation rather than just network-layer abuse.

What Suricata is built for (and why IPS mode is operationally expensive)

Suricata’s strength is deep packet inspection: stream reassembly, application-layer protocol detection, and signature-based matching against specific exploit patterns. In IDS mode, it observes traffic passively and generates alerts, which is relatively safe to deploy and tune.

IPS mode is different. It’s inline; it filters live traffic, and the consequences of misconfiguration are immediate. From the Suricata 9.0.0-dev documentation: “By default, when IPS mode is enabled, the exception policies are set to block (drop). This is to make sure rules cannot be bypassed due to…” edge cases in stream handling. Fail-closed behavior is a sound security default, but it means an under-tuned ruleset can start dropping legitimate traffic. CPU and latency overhead also increase with inline inspection, especially at higher throughput.

That operational cost is significant for most lean security teams. IPS mode demands validated rulesets, performance testing, and ongoing tuning discipline before it’s safe to put in front of production traffic.

Do you actually need both?

For most internet-facing Linux server deployments, the honest answer is no, at least not simultaneously from day one.

If your primary pain is commodity noise (mass scanning, credential stuffing, abusive bots, opportunistic exploit attempts), automated IP blocking via CrowdSec’s enforcement chain handles the bulk of it. The collaborative threat intelligence model means you’re blocking IPs that other organizations have already confirmed as aggressive, not waiting for those IPs to complete an attack against you.

Add Suricata when you genuinely need packet-signature-driven detection for specific exploit classes, protocol compliance enforcement, or application-layer visibility that IP reputation alone can’t provide (see this article to learn how to set up the integration). Even then, start in IDS mode. Observe for a week or two before considering inline IPS deployment. The Suricata community’s own guidance supports this sequence, and the performance and false-positive data you collect in passive mode are what make IPS tuning tractable.

Running both makes sense in higher-maturity environments, but only with clear role boundaries: CrowdSec handles perimeter mitigation and noise reduction via collaborative threat intelligence; Suricata handles deep inspection for the residual traffic you want to analyze at the packet level.

Suricata sees deep. CrowdSec thinks broader. Together, they make a compelling combination. Suricata provides deep, signature-based network visibility, but typically requires additional tooling and administration to turn those signals into a complete detection and response workflow. CrowdSec takes a more all-in-one approach, combining behavioral detection, signal correlation, threat intelligence, and automated remediation in a single ecosystem. – Manuel Sabban, CrowdSec DevSecOps PHD. 

A practical layering model

Layer 1 is CrowdSec bouncers integrated into your existing firewall or reverse proxy. Known-bad IP traffic gets dropped before it consumes inspection resources. This also reduces the traffic volume Suricata needs to process, directly lowering IPS mode overhead.

Layer 2 is Suricata in IDS mode inspecting the remaining traffic. Validate your ruleset here. Identify false positives. Measure CPU impact under realistic load before enabling any inline drop behavior.

Before trusting any of this, verify your remediation components are actually active. CrowdSec’s troubleshooting documentation is explicit that “a Security Engine that detects threats but has no Remediation Component attached cannot act on its decisions; attackers are detected but never blocked.” Detections without an enforcing bouncer attached are one of the most common reasons teams feel like their security stack isn’t working.

The pitfalls that make teams think they need more tooling

Two failure modes drive most “I need both” conversations. The first is a CrowdSec deployment where the Security Engine is running, but no bouncer is configured or connected. Alerts accumulate. Decisions get made. Nothing is blocked. Adding Suricata on top of an unfinished CrowdSec deployment doesn’t fix the enforcement gap; attaching the right remediation component does.

The second is Suricata deployed directly in IPS mode without baseline tuning. Exception policies fail closed by default, performance impact hits production, false positives surface, and the ops team spends the next month chasing rule noise instead of actual threats.

Neither situation means you need both tools. Both situations mean you need to finish configuring the one you have.

Start with CrowdSec in enforcement mode. Let it block the commodity noise and reduce your alert volume. Then, if packet-level inspection of residual traffic surfaces gaps you can’t close with IP reputation and behavioral signals alone, layer Suricata in, in IDS mode first, and graduate to IPS only once you’ve validated that your rules and performance headroom support it. That sequencing keeps the operational cost manageable and keeps each layer doing the job it’s actually suited for.

FAQs

Do I need both CrowdSec and Suricata on my Linux server?
TL;DR of the article: Not necessarily. For most internet-facing Linux servers, CrowdSec alone can handle common threats such as brute-force attempts, scanning, and opportunistic attacks. Suricata can be added when you need deeper packet-level inspection or detection capabilities that CrowdSec doesn’t provide.

What is the difference between CrowdSec and Suricata?
CrowdSec focuses on behavioral detection, collaborative threat intelligence, and IP-based enforcement, while Suricata specializes in network traffic inspection and signature-based detection. CrowdSec can block malicious IPs through remediation components, while Suricata can inspect traffic at the packet and protocol level.

Does CrowdSec block attacks automatically?
Detection alone does not block traffic. CrowdSec’s Security Engine makes detection and enforcement decisions, but a remediation component (bouncer) must be configured to actually block malicious traffic.

Can CrowdSec and Suricata work together?
Yes. They can provide complementary layers of protection. CrowdSec can handle known malicious IPs and commodity attacks at the perimeter, while Suricata can inspect the traffic that remains for more specific network-level threats.

Should I run Suricata in IDS or IPS mode?
If you’re deploying Suricata for the first time, IDS mode is generally the safer starting point. It lets you observe alerts, tune rules, identify false positives, and measure performance before introducing inline blocking with IPS mode.

Does running CrowdSec reduce the workload for Suricata?
It can. By blocking known malicious IPs at the perimeter before they reach deeper inspection, CrowdSec can reduce the amount of traffic that Suricata needs to process.

Why is CrowdSec detecting attacks but not blocking them?
The most common issue is that no remediation component or bouncer is active. The Security Engine can detect threats and create decisions, but those decisions need an enforcement component connected to your firewall, reverse proxy, or other infrastructure to actually block traffic.

When should I add Suricata to my security stack?
Consider adding Suricata when you need packet-level visibility, protocol inspection, or signature-based detection for threats that IP reputation and behavioral detection alone cannot identify.

CrowdSec utilise GitHub pour versionner son code, tant open source que privé. Le code source privé de la console et de certains outils satellites a été mis en ligne par des cybercriminels. Ce code a été volé en mai 2026. Aucune donnée client, utilisateur ou fournisseur n’a été impactée, c’est essentiellement le code source de la console SaaS qui a été publié. L’attaque a été menée concomitamment à celle de Mistral.ai, et elle a consisté en la compromission de l’entité TanStack par un groupe du nom de TeamPCP. Tanstack met à disposition des paquets NodeJS dans lesquels une porte dérobée a été introduite. Un de nos anciens employés, toujours membre de l’organisation github (pour finaliser un projet) a été infecté par la récupération d’une version compromise du paquet lui a été servie par TanStack. Celle-ci contenait une backdoor du nom de Shai Ulud qui a permis à TeamPCP d’obtenir un token API GitHub valide lui permettant de lire les bases de code non-publiques de CrowdSec sur GitHub.

Contexte

Chaque hack intervient dans un contexte humain, business, technologique et sociologique en pleine évolution. Ce qui est douloureux pour CrowdSec aujourd’hui, c’est que beaucoup d’entre nous viennent du monde du test d’intrusion, ont fait des décennies de cybersécurité, et ont développé des réflexes « cybersec » dans leur travail quotidien. Dans ce contexte, découvrir que l’on “leak” du code privé prend une autre dimension.

CrowdSec a trouvé son business model (PMF, ou Product-Market Fit pour les intimes), et notre modèle SaaS low-touch a commencé à prendre auprès des utilisateurs. La société prend son envol. Certes, l’équipe s’est un peu réduite, car nous avons dû maîtriser les coûts dans un environnement où l’accès au capital était plus contraint qu’avant, mais globalement, nous sommes une startup heureuse, voguant vers le break-even. Récemment, nous avions d’ailleurs entamé des discussions avec des gouvernements et des ministères dans pas moins de 7 pays, tandis qu’un profil “AAA” de l’industrie toquait à notre porte. Tout allait donc pour le mieux, c’est pourquoi le 16 septembre nous a pris par surprise.

Que s’est-il passé, comment, quelle a été la réaction de l’équipe, la timeline, le point d’origine, comment réagir si quelque chose de similaire arrive à votre équipe, et que fera-t-on différemment à l’avenir ? Quel est l’impact réel derrière le gros titre ? Qu’est-ce qui est important, marginal, ou objectivement insignifiant ?

Mais d’abord… que s’est-il passé ?

The Timeline

• 11 mai 2026 : TeamPCP compromet un dépôt de paquets NPM célèbre nommé TanStack, largement utilisé par les développeurs pour créer des UI web basées sur Node.js. 42 packages sont backdoorés avec leur malware « Shai Hulud », spécialisé dans le vol de credentials et de tokens.
• 22 mai 2026 : TeamPCP (Threat Actor UNC6780) revendique le piratage de plusieurs dépôts de Mistral AI.
• 22 mai 2026 – 05h52:29 à 06h01:33 UTC : l’un des fondateurs de BreachForum et un membre, diencracked (a priori), télécharge le contenu de ~170 dépôts GitHub privés de CrowdSec depuis une adresse IP située à Toronto, au Canada (UTC-4). Le nombre de dépôts est relativement secondaire, tout comme leur taille absolue, puisque cela dit davantage de l’organisation du code et des images utilisées dans l’interface web qu’autre chose. Mais sur les forums de breach, les gros chiffres sont un argument de communication. Le point clé, c’est qu’il a eu accès à une base de code privée qui n’était pas censée être exposée, et ça, c’est un fait réel et vérifié par nos soins.
• 25 mai 2026 – après-midi : L’accès GitHub du laptop de l’employé compromis est révoqué (tous les autres l’étaient déjà et on reviendra sur ce point) pour une raison sans lien avec l’incident de sécurité. On l’avait laissé actif parce qu’on s’était séparés en bons termes avec notre développeur, qui souhaitait finaliser certains travaux.
• 17 août 2026 : Le token AWS utilisé pour les notifications SNS (contenu dans le leak) est testé afin de vérifier ses autorisations exactes.
• 16 sept. 2026 – 17h45 : Publication sur le forum.
• 16 sept. 2026 – 20h : Entre fuitesinfos.fr et CrowdSec, une cellule de crise est mise en place.
• 16 sept. 2026 – nuit : Actions forensiques initiales, rotation des identifiants et des tokens clés.
• 17 sept. 2026 – matin: Forensic, coordination, reporting, rotation des tokens/credentials restants.
• 17 sept. 2026 – midi : Communication  initiale exposant les faits dont on était déjà sûrs
• 17 sept. 2026 – 18h : GitHub nous apporte une réponse sur le token incriminé, ce qui nous permet de retracer son cycle de vie (la clé API que MrWHO évoque sur le forum).
• 18 sept. 2026 : Publication de ce rapport en Anglais
• 21 sept. 2026 : Publication de ce rapport en Français.
  

Évaluation des risques post-incident

Lors d’une analyse d’incident cyber, on est toujours sous pression pour déterminer si seule la base de code a été touchée ou si les données connectées et l’infrastructure cloud l’ont également été. En « théorie », le scénario idéal en cybersécurité, c’est que les mécanismes d’authentification, les tokens, les identités, et toute forme de credentials soient absolument absents de toute base de code. Sauf qu’on ne vit pas dans cette belle « théorie » ; on vit sur Terre, avec des humains.

Code:

Console : Pour la petite histoire, nous avons longuement réfléchi à open-sourcer la console elle-même, mais nous ne l’avons pas fait (encore) pour trois raisons principales: 

1/ Cet outil n’est pas utilisable sans les microservices AWS qui tournent derrière

2/ Structurellement, ce n’est pas réellement un projet où les utilisateurs peuvent contribuer, il est plus simple de demander une fonctionnalité que de l’ajouter soi-même 

3/ Le fait qu’une branche de code soit open source est délibérément planifié en amont. Même s’il est possible d’open-sourcer quelque chose a posteriori, les bases de code qui évoluent rapidement (comme la console SaaS) ne sont pas des candidats idéaux. 

Le réel problème, c’est que personne n’en aurait l’utilité. Ce code a-t-il de la valeur ? Oui, le temps que notre équipe a passé à coder, à réfléchir aux fonctionnalités, à leur agencement, aux interfaces de reporting, etc. Cela a-t-il de la valeur pour autrui ? Très probablement non, ce code est beaucoup trop contextuel. Contenait-il des secrets ? Non. La vraie question reste : la connaissance intime du code peut-elle aider à mener des attaques ultérieurement ? La sécurité par l’obscurité n’est jamais un bon modèle, mais avoir le code source complet en main peut accélérer la recherche de faiblesses potentielles, notamment à l’époque de l’IA-everywhere. Cela dit, CrowdSec a également accès à ces modèles d’IA et nous pouvons (et le faisons) évaluer la sécurité de notre propre code. Alors, est-ce idéal ? Non. Est-ce très grave ? Non. Nous continuerons à surveiller étroitement les diverses sources de logs, traces et audits à notre disposition, et à vérifier que rien ne dévie de la normale. De toute façon, cette base de code évolue rapidement, et 4 mois plus tard, elle est déjà significativement différente de ce qui a été publié.

Traitement des données : Certains scripts et modèles de data science font partie du leak mais sans les données pour entraîner ces modèles ou alimenter ces scripts, ils n’ont que peu de valeur. L’« algorithme de consensus » faisait aussi partie du leak, mais nous avions déjà expliqué très clairement comment il a été conçu. L’idée de l’open sourcer nous a également effleuré plusieurs fois, mais, pour les mêmes raisons énoncées plus haut, nous avions renoncé à le faire. Est-ce que le Consensus (l’algorithme qui ajoute des adresses IP aux blocklists) peut être empoisonné ou compromis ? De notre point de vue et de notre compréhension de notre propre système, non. L’algorithme nécessite des dizaines de signalements provenant de dizaines de security engines vérifiés, répartis sur des dizaines d’Autonomous Systems différents. Ce qui n’était pas public, ce sont principalement les seuils que nous avons fixés pour la diversité et le nombre de détections avant de considérer une IP comme dangereuse. Même si ces “poids” sont ajustés régulièrement. Il faudrait un attaquant motivé, disposant d’une importante somme d’argent, pour instancier suffisamment de serveurs afin d’influencer le réseau et bannir une IP non fautive. La différence, c’est qu’avant ce leak, l’attaquant ne savait pas exactement combien ; maintenant, les seuils sont connus. Nous pouvons les ajuster (comme nous le faisons fréquemment) et rester très vigilants quant aux écarts par rapport à la norme, mais l’effet de réseau et sa taille font que les variations statistiques sont très visibles sur notre radar, puisque la « moyenne » est très solide.

Scripts d’automatisation divers : Ce point couvre de nombreux scripts et contenus satellites. Des automatisations de robots Slack fournissant des statistiques ou des rappels, des sites pour publier des news ou du contenu, des scripts de déploiement pour les tests, la QC, la QA, etc. Les détails sont extrêmement ennuyeux, mais en résumé : aucune valeur, aucun risque pour les utilisateurs, les clients, le réseau ou l’intégrité des données, c’est essentiellement de la “plomberie digitale”.

Credentials : Nous étions très proches de zéro leak ici. Le seul identifiant utile qui a fuité était un token pour utiliser un service AWS appelé SNS, correctement scopé (dans notre jargon, limité au strict minimum en termes de droits). Techniquement « vivant » et utilisable, mais uniquement pour envoyer des notifications simples. Quelques autres tokens (très peu) étaient soit déjà remplacés, soit inutilisables via Internet.

Données : Ce n’est pas seulement critique pour la sécurité des clients, mais constitue également une violation du RGPD. Il n’y avait aucune information sur les clients ou partenaires dans le leak, à l’exception de 83 adresses e-mail utilisées spécifiquement par notre équipe Data Science pour suivre l’usage des projets, les réactions des utilisateurs à de nouvelles fonctionnalités ou des raisons statistiques. Cela reste peu, comparé aux ~150K utilisateurs (<0,05%), et nous ne parlons que de l’adresse e-mail (essentiellement des e-mails génériques). Ces adresses ne proviennent pas d’un accès à une base de données mais d’un extrait analysé localement. Nous avons contacté les utilisateurs concernés pour leur expliquer la situation, mais cela n’affaiblira pas leur posture de sécurité, les cybercriminels savent juste qu’ils utilisent CrowdSec. Nous avons aussi involontairement divulgué les noms et prénoms de 51 investisseurs réels ou potentiels de 2020, leurs adresses e-mail et le contexte de l’investissement, ce que nous leur avons signalé ainsi qu’aux autorités compétentes, et ce qui est plus regrettable dans cette fuite. 

Quels sont les impacts ?

En tant que fondateur, voici mon analyse plus détaillée des impacts potentiels.

La première chose qui m’est venue à l’esprit, était un sentiment d’injustice, lié à quelque chose hors de notre contrôle, qui allait avoir un impact négatif. La réalité m’apparaît assez différente 48 heures plus tard. En premier lieu, j’ai été bluffé par la compréhension et la bienveillance sincères de notre équipe, de nos clients, de nos partenaires et de nos prestataires.

Nous avons reçu beaucoup de soutien de notre communauté, de nos partenaires, et de nos VC. Aikido, Fuitesinfos.fr et GitGuardian nous ont proposé leurs outils, et l’intervention de l’équipe de GitHub a été fondamentale pour nos recherches. Certains clients ont posé des questions légitimes, mais ils ont tous (à ce jour) compris la posture, apprécié le professionnalisme et la transparence, et attendu patiemment des réponses factuelles plutôt que hâtives.

Et… notre équipe. Ce tango où tout le monde savait quoi faire, comment, de façon synchronisée, avec des recherches, des inspections, des introspections approfondies et des questions douloureuses, c’était impressionnant. Être le dirigeant d’une startup, c’est souvent un poste solitaire, mais ressentir tous ces experts construire ensemble une réponse professionnelle à un rythme soutenu, c’était aussi un moment de fierté, qui allégeait la douleur. Quant à mon cher réseau de professionnels sur LinkedIn, alumni et amis : merci beaucoup pour votre soutien. Enfin, on n’organise pas un effort aussi intense sans une équipe aussi professionnelle.

Bien sûr, certains ont souligné : « Ils prétendent savoir qui attaque sur Internet, mais n’arrivent pas à bloquer les attaques contre eux-mêmes », sans savoir ce qu’est une supply-chain attack, d’autres ont envoyé des smileys un peu passifs-agressifs, mais une large majorité de la communauté des professionnels de la sécurité a été solidaire et compréhensive.

Ne jamais gâcher une bonne crise… Nous avons amélioré notre temps de réaction : 48h pour couvrir l’inventaire complet, la rotation des tokens, le forensic et l’opération de communication, n’est pas un échec en soi. Mais si on devait faire face à une autre crise, cette timeline fondrait à 24 h, je pense, le vrai défi ici, est principalement d’éviter que d’autres supply chain attacks ne puissent se produire.

Pour revenir à la question « à quel point est-ce grave » ? La réponse est que cet incident constitue un véritable stress-test pour notre système de réseau distribué et crowdsourcé. Par conception, il devrait être résilient à ce type d’événement, et cette épreuve du feu devrait nous le prouver. De ce que l’on sait à ce stade : la séparation stricte des privilèges, les tokens AWS scopés, et la révocation rapide de l’accès principal de l’employé parti signifient que l’attaquant a fini dans une impasse. La résilience du consensus du réseau est liée majoritairement à sa taille et son architecture plus qu’à son code en soi. 

Les experts en sécurité ne m’ont pas semblé soucieux, car ils comprennent que nous n’avons pas échoué dans notre mission, ni pris de raccourcis en matière de sécurité. Les clients peuvent se demander ce qui s’est passé, mais nous pouvons leur expliquer ce qui s’est passé. Les prospects peuvent être effrayés, mais nous vendons un produit plutôt technique, donc la plupart comprendront une fois la situation exposée. Cet incident n’est pas idéal, évidemment, mais pas fatal non plus, très loin de là.

Mais ceux pour qui nous sommes le plus sincèrement désolés, ce sont nos premiers investisseurs, qu’ils aient concrétisé ou non. Divulguer vos noms et adresses e-mail est un problème que nous allons traiter directement avec vous et les autorités compétentes, et je m’en excuse personnellement. Le système qui, en 2020, rendait les interactions avec nous plus simples n’a jamais été conçu pour être public.

Quiconque a subi un problème comme celui-ci a moins de chances de le revivre, en raison de la douleur qu’il a causée. Nous sortons donc de cette crise plus forts et plus affûtés qu’avant, avec une blessure de guerre et une autre d’ego, ce dernier point étant sans importance. Globalement, il semble que CrowdSec ne soit pas seulement un effet de réseau, mais bien une véritable communauté de professionnels solidaires, ce qui est appréciable.

Méthode de l’attaque

Le 16 septembre, un utilisateur a publié sur pwnforum une archive contenant du code source de l’organisation GitHub de CrowdSec, comme relayé par https://fuitesinfos.fr/article/2026-09-16-crowdsec

Pour situer les faits : une fois que Christophe de https://fuitesinfos.fr/ nous a donné l’information et l’archive, on a pu constater que celle-ci contenait crowdsec-ghsa-273h-gvwr-c3qj, un dépôt qui a été détruit le 27 mai. Le dernier commit présent dans tous les dépôts date du 22 mai 2026 à 01 h 24 UTC, et le timestamp de l’archive est fixé au 22 mai ; ça correspond.

À ce stade, nous suspectons, avec un fort degré de confiance, que le leak est limité au code source de CrowdSecurity (dont 130+ des dépôts sur 300 étaient publics). L’infrastructure ou les bases de données de CrowdSec n’ont pas été accédées ou compromises. Aucun code n’a été altéré, ni dans le logiciel open source, ni dans notre code source privé, ni dans les pipelines de build, c’était de la “lecture uniquement”.

Notre infrastructure AWS est serverless et nous utilisons largement SSM/Secrets Manager, donc le nombre de credentials présents est très faible, mais cela requiert une analyse. La plupart des tokens et secrets avaient été révoqués ou remplacés, mais celui qui était présent et viable a été sondé :

Le dump incluait un secret AWS assertible-zapier-sns-sender, et quelqu’un a tenté de l’utiliser le 17 août 2026 depuis l’IP 23.234.84.102 pour effectuer un GetCallerIdentity et un ListTopics à la fois sur les topics dev et env. Ce rôle AWS était restreint à publier sur un seul topic SNS ; il n’a pas pu aller plus loin.

L’archive .github/.git/config contient l’origine utilisée pour cloner les dépôts :

...
[remote "origin"]
	url = https://oauth2:gho_xxxxxxxxx@github.com/crowdsecurity/.github.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
	remote = origin
	merge = refs/heads/main

Ceci nous indique que le token utilisé pour cloner les dépôts est un token OAuth (gho_xxx) ce qui semble réel car son checksum est correct [2]. La méthodologie est également alignée sur les tactiques du groupe de cybercriminels TeamPCP et sur son malware (Mini) Shai-Hulud.

Cependant, nous ne trouvons aucune trace de ce token OAuth dans le journal d’audit de notre organisation, ni dans les journaux d’audit des membres actuels de notre organisation GitHub. Nous  avons téléchargé ces journaux depuis l’interface web et recherché la version hachée du token (echo -n $token | openssl dgst -sha256 -binary | base64), sans succès.

Nous avons aussi passé au peigne fin la liste des intégrations OAuth actives dans l’organisation (en mode « Accès restreint ») mais elle ne contenait rien de suspect non plus. Aucune des intégrations n’a subi de breach public dans la période concernée.

Si c’était le jeton OAuth d’un utilisateur actif, on s’attendrait à voir une activité associée dans le journal d’activité. D’un autre côté, le journal d’audit de GitHub ne suit que des actions spécifiques [2.1], et seuls les plans entreprise (que nous n’avions pas) conservent l’activité git sur une fenêtre glissante de 7 jours.

[2] https://github.blog/engineering/platform-security/behind-githubs-new-authentication-token-formats/
[2.1] https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization

La vraie complexité derrière cette analyse forensique, réside dans le fait que le token utilisé pour télécharger les dépôts privés n’existait plus quand nous avons eu connaissance de la fuite du code. Il a donc été créé, a vécu, et est mort sans laisser de traces au-delà de son usage. 

À ce stade de l’investigation, nous ne connaissions toujours pas l’origine de la compromission. Après avoir vérifié les tokens des utilisateurs et scanné les packages malveillants, les extensions de VS Code, etc., les machines de tous les développeurs sont officiellement propres. 

Nous avons enquêté sur l’historique Git de nos propres dépôts pour voir si certains packages backdoorés avaient touché nos dépôts à un moment donné, mais ça n’a rien donné de concluant. Bien que certains packages TanStack soient présents, aucun n’est sur la liste backdoorée. Par ailleurs, nous imposons un âge minimum aux packages Node afin d’éviter qu’une compromission récente ne passe sous le radar.

Cependant, une chose qui nous intriguait, c’est que TeamPCP est connu pour ne pas se limiter aux identifiants GitHub, mais aussi pour rechercher d’autres tokens, comme les identifiants AWS, les clés SSH, etc. Alors que GitHub donne très peu de visibilité sur l’activité Git, nous avons une bonne visibilité sur les actions AWS, et rien de suspect ne s’est produit depuis les attaques de supply chain ou depuis que les identifiants du leak ont été sondés.

C’est là que le support de GitHub a été inestimable car ils ont pu retracer le cycle de vie complet du token dont nous n’avions que la trace d’usage et confirmer nos suspicions initiales concernant TanStack.

Avec le token OAuth et un créneau temporel précis pour l’activité, nous les avons contactés afin d’obtenir davantage d’informations. Ils ont pu nous fournir l’activité Git dans la fenêtre de 2 heures du dump. On a alors découvert qu’il s’agissait d’un employé qui venait juste de quitter l’entreprise, mais qui faisait toujours partie de l’organisation GitHub pour des raisons légitimes, et son compte a été utilisé pour dumper les dépôts :

2026-05-22 05:52:32.138 UTC – fetch – crowdsecurity/XYX – <redacted> – 178.249.214.XX

D’après les informations Git dans l’archive leakée, l’IP du cybercriminel se situe à Toronto, Canada, en zone horaire UTC-4. L’ex-employé a été compromis par l’attaque de supply chain TanStack, ce qui correspond à la méthodologie. Son compte a été retiré de l’organisation GitHub le 25 mai 2026, 3 jours après l’incident…

Ceci explique également pourquoi nous n’avons repéré aucune activité liée à AWS ou à l’infrastructure, puisque ses accès avaient déjà été révoqués.

Après avoir identifié la source et poussé davantage l’audit de l’activité Git de l’utilisateur et des comptes existants, nous pouvons confirmer que son accès a été utilisé uniquement pour effectuer les clones Git qui ont mené au leak et qu’aucune altération du code, de l’infrastructure, ou du pipeline de CI/CD n’a eu lieu.

Quelles actions ont été prises pour éviter tout nouvel incident

CrowdSec avait déjà de nombreux mécanismes de sécurité avant cet incident :

• Séparation stricte des privilèges (par exemple, en tant que CEO, je n’ai aucun accès aux comptes bancaires, aux outils d’admin de l’organisation, à la console AWS, etc., et c’est une bonne pratique appliquée à toutes et tous)
• Scoping strict : ce qui s’applique aux droits utilisateurs s’applique tout autant aux apps, accès API, IA, aux routines cloud, et aux scripts, pour éviter d’accorder un droit au-delà de ce qui est strictement nécessaire pour remplir leur rôle
• 2FA sur chaque outil pour tout le monde, avec passkeys et dispositifs physiques (Titan Key)
• Password wallet : évident, mais explicitement obligatoire
• Phrases de sécurité : si un membre clé de l’organisation avec des droits étendus est physiquement compromis (ou sa famille), nous avons convenu de mots spécifiques à glisser dans la conversation pour alerter notre interlocuteur de la compromission
• Audits : qu’ils soient internes, menés par IA, ou externes, ils font partie de notre hygiène
• Logs partout : durant cette crise, nous avons appris que l’archivage plus poussé des actions GitHub nous aurait fait gagner du temps, mais les logs de nos toolchains, composants CI/CD, et AWS étaient très solides. Avoir des traces permet de remonter le fil et de réagir tôt, et après tout, on est CrowdSec, donc plutôt sensibles sur le sujet
• Pentesting : À quelle fréquence les lancer, sous quelle forme, tout ça évolue dans le temps, mais tester les employés de l’entreprise et notre code source fait partie de nos habitudes
• Monitoring de l’âge des packages NPM : pour s’assurer qu’on ne tourne pas sur une version trop récente pour être auditée, ou trop ancienne pour comporter un risque de sécurité.
• Procédures d’onboarding/deboarding : le cycle de vie complet de vie des accréditations d’un employé, création et révocation (ou savoir pourquoi vous avez gardé). La conservation de toutes les traces d’usage une fois qu’il est parti compte encore plus.
• Analyse automatisée du code : chaque commit est scanné automatiquement pour détecter d’éventuelles vulnérabilités ou failles logiques
• Procédures et revues de publication, QA & QC : qu’elles soient automatisées ou manuelles, ce sont des composants classiques de la boîte à outils d’un éditeur
• Formation, et bien plus encore…

Pourtant, rien de tout ça n’a pu empêcher une attaque de chaîne d’approvisionnement, alors qu’est-ce qui aurait pu ?

EDR : Au moment de l’incident, on n’imposait pas d’EDR sur les machines des développeurs, mais on utilise depuis une protection endpoint qui se concentre activement sur les packages malveillants, les extensions, etc. Alors que les attaques de la chaîne d’approvisionnement deviennent le nouveau fléau et que virtuellement n’importe qui peut se retrouver dans le viseur, cette ligne de défense supplémentaire pourrait peut-être aider dans certains cas.

Les postes de travail/laptops des personnes interagissant avec notre code source ou notre infrastructure tournent maintenant sous un EDR pour réduire le risque d’attaques de supply chain, mais une analyse en mémoire et un monitoring runtime pourrait aussi couvrir les 0-days.

Every hack happens in a context where humans, business, technology, or society as a whole is evolving. What stings for CrowdSec is that many of us come from red-team pentesting backgrounds, have worked in cyber for decades, and have adopted a “cybersec” muscle memory in our daily work. So being caught leaking code is painful. 

CrowdSec is doing much better after we found deeper PMF (Product-Market Fit) for our data, and our low-touch SaaS model started to click with users. The team is a bit smaller because we had to keep costs under control in an environment where access to funds was more limited than before. Overall, we were a happy startup sailing toward break-even. We started discussing with governments and ministries in at least 7 countries. An industry AAA profile was knocking at the door; all was for the best until… September 16th happened and took us by surprise.

Now, what happened, how, what was the team’s reaction, the timeline, the origin point, how to react if something similar happens to your team, and what will we do differently? What is the real impact beyond the big news title? What’s important, marginal, or objectively meaningless?

But first things first… What happened?

The Timeline

• May 11th, 2026: TeamPCP compromises a famous NPM package repository named TanStack, widely used by developers to create Node-based web UI. 42 packages are backdoored with their malware “Shai Hulud”, specialized in credentials and token harvesting.
• May 22nd, 2026: TeamPCP (Threat Actor UNC6780) claimed responsibility for the hack of some Mistral AI repositories.
• May 22nd, 2026 – 05:52:29 until 06:01:33 UTC: one of the founders of BreachForum and a member, diencracked <diencracked@cock.li> downloaded the content of ~170 private CrowdSec GitHub repositories from an IP address in Toronto, Canada, with a computer Timezone set to UTC-4. At least that’s what the Git data shows. The number of repositories is relatively irrelevant, as is their absolute size, since they speak more to code organization and images used in the Web interface than anything else. But on breach forums, numbers are the name of the game. The key point is that he had access to a private codebase that wasn’t supposed to be exposed, and that’s a fact.
• May 25th, 2026 – afternoon: Compromised employee’s laptop GitHub access is revoked (all others were already). We kept them alive because we parted on good terms with our developer, and he wanted to finalize some work.  
• Aug 17th, 2026: The AWS token used for SNS notifications is tested to see its precise authorizations
• Sept 16th, 2026 – 17h45: Publication on the forum
• Sept 16th, 2026 – 20h: contact between our team and the Fuites Info staff; crisis cell is put together
• Sept 16th, 2026 – night: initial forensic actions, key credential and token rotation
• Sept 17th, 2026 – morning: forensic, coordination, reporting, remaining token/credentials rotation
• Sept 17th, 2026 – noon: initial PR explaining the facts we are already sure about
• Sept 17th, 2026 – 18h: GitHub to the rescue; they helped us identify the full story behind the token (the famous API key MrWHO talked about in the forum).
• Sept 18th, 2026: Wrap-up of the incident, release of this full final report.

Risk assessment

In any leak context, you’re always pressed to identify whether only the codebase was affected or whether connected data and cloud infrastructure were also affected. In “theory”, the ideal cybersecurity scenario is that authentication mechanisms, tokens, identities, and any form of credentials are absolutely absent from any codebase. Still, we don’t live in this beautiful “theory” world; we live on Earth, with humans.

So the first step is to make sure that anything that has leaked doesn’t contain any “credentials” (in its larger acceptation), any sensitive data, and if that’s the case, that those are deprecated (in our lingo, “rotated” to indicate they are not usable any longer).

Code: 

• Console: For the record, we thought a lot of time about open-sourcing the Console itself but didn’t do it (yet) for three main reasons.
  • 1/ It’s not something you can use without the AWS infrastructure and microservices running behind it.
  • 2/ Structurally, it’s not really a project where users can propose PR/MR or contribute; it’s actually easier to ask for a feature than add it yourself
  • 3/The code being open-sourced is always deliberately planned this way.
    While it’s doable to open source something that wasn’t intended to be, fast-moving codebases (like the SaaS console) aren’t ideal candidates. Code quality isn’t the issue here; it’s that no one would care about it or replicate it at home. Now, does it have value? Yes, the time our team spent coding it. Is it valuable to someone else? We can confidently say not really; it’s far too contextual. Did it contain secrets? No. Maybe the codebase wouldn’t yet fully meet our open-sourcing standards, but that would be it. Can it lead to a security concern is the real question. Security by obscurity is never a good model; having the full source code in hand can eventually fast-track research into potential weaknesses, specifically in the AI-everything timeline. Now we do have access to those AIs too and can (and do) assess our source code security as well. So is it ideal? No. Is it very bad? No. We’ll still monitor tightly the various log sources, trails, and audits we have and check that nothing deviates from normal. Anyway, this codebase is changing extremely fast, and 4 months down the road, it’s already meaningfully different from what was released.
• Data processing: Some data science scripts and models were part of the leak. Not ideal either, but honestly, without the data to train those models or feed those scripts, they have little value. The “Consensus Algorithm” was also part of the leak, but we already explained very transparently how it’s globally architected; we thought more than once about open-sourcing it, but for the same reasons stated above, we didn’t. Can the Consensus (the algorithm adding IP addresses to blocklists) be poisoned, compromised, or not? Well, to the best of our knowledge and understanding of our own system, no. The algorithm requires tens of sightings coming from at least tens of vetted security engines spread across tens of different Autonomous Systems. What isn’t public was mostly the thresholds we set for diversity and number of detections; still, those are moving targets. It would require a motivated attacker to spend an immense amount of money to instantiate enough servers to influence the network into banning a non-offending IP. The difference is that before this leak, the attacker wouldn’t know exactly how many; now, thresholds are known. Fine, we can adjust those thresholds (like we frequently do) and be very vigilant about discrepancies. Now the network effect and its sheer size make statistical variations very visible on our radar since the “mean” is very solid. 
• Various automation scripts: That covers many different scripts. Slack bot automations to report, some sites to publish news or content, deployment scripts for test purposes, QC, QA, etc. It would be extremely boring to go through the details. <TL/DR> no value, no risk for users, clients, or network, or data integrity.

Credentials: We were very close to clean. The useful “credential” leaked was a token to use an AWS service called SNS, and it was properly scoped (in our lingo, limited to just this), so it was “live” but not usable for anything beyond basic notifications. A few other tokens were either already rotated or not usable from the Internet, to our current knowledge.

Data: This is not only critical for clients’ safety but also reprehensible under the GDPR framework. There was no clients’ or partners’ information in the leak, except for a few email addresses used specifically by our Data Science team to monitor project usage, users’ reactions to a new feature, and overall statistical reasons. Not many compared to ~150K users: 83 (<0.05%), mostly Gmails. We’ll reach out to those users to explain the situation, but nothing in this can weaken their security posture except cybercriminals knowing they run CrowdSec. We also inadvertently disclosed the first/last names of 51 potential investors from 2020, their email addresses, and investment context, which we will report to them and the proper authorities.

What are the impacts?

As CEO, I have to evaluate the full scope, and it’s more complex than the headline news shows.

The first thing that popped into my head is, “It’s really unfair; we couldn’t do much about it, and it’ll have a negative impact on us.” The reality looks fairly different 48 hours later. First, I was astonished by how comprehensive and genuinely benevolent our team, clients, partners, and providers were. 

If anything, we’ve mostly received love and support from our community, partners, and VC alike. Aikido, Fuites Info, and GitGuardian offered their support, and GitHub staff were very helpful. Some clients asked legitimate questions but mostly understood the posture, appreciated the professionalism and transparency, and patiently waited for factual answers rather than hasty ones.

And… Our team. This tango where everyone knew what to do, how, synchronized, thoroughly searched, inspected, introspected, and asked painful questions was genuinely a blast. Being a CEO is often a lonely place, but feeling all those professionals building a professional response together at such a fast pace was a moment of pride. As for my beloved network of LinkedIn professionals, alumni, and friends, you know who you are; thanks a lot for the kind words. Last but not least, you don’t organize such an intense effort and carry it through the finish line.

Of course, some asked, “They claim to know who attacks us but cannot avoid them attacking themselves”, while others sent passive-aggressive crying smileys, but an overwhelming part of the security professional community was supportive and understanding.

Never let a good crisis go to waste. We’ve improved our reaction time: 48h to cover the full inventory, token rotation, forensic, and PR operation isn’t bad timing per se, but if we ever face another crisis, we can probably pack this timeline in under 24h. Now, preventing any other crisis from happening, specifically Supply Chain attacks, is the real challenge here.

But I won’t dodge the question, and I owe you an answer on “how bad is it.” Simple answer: it’s a strong stress test for our distributed, crowdsourced network system. By design, it should be resilient to this type of event, but now it’s being battle-tested. To the best of our knowledge, strict privilege separation, scoped AWS tokens, and prompt revocation of the departed employee’s core access meant the attacker hit a dead end. Security experts won’t mind because they understand we didn’t fail our mission or cut corners on security. Clients may wonder what happened, but we can explain it in layman’s terms. Prospects may be spooked, but we sell a fairly technical product, so most will understand once we explain the situation. Not ideal, obviously, but not fatal by a long shot. 

But the ones we’re most genuinely sorry for are our early investors, whether potential or those who took the move. Leaking your names and email addresses is an issue we’ll discuss directly with you and the competent authorities, and for this I personally apologize. The system that, back then in 2020, made interactions with us easier was never intended to be public.

Anyone who suffered an issue like this is less likely to face it again because of the pain it caused, so if anything, we walk out stronger and sharper from this crisis than before, with a brand and ego wound, the latter being irrelevant in the grand scheme of things. Overall, it seems CrowdSec isn’t just a network effect, but a real community of supportive professionals, which is heartwarming. 

How it happened exactly

On the 16th of September, a user published on pwnforum an archive containing source code from the CrowdSec GitHub organization, as relayed by https://fuitesinfos.fr/article/2026-09-16-crowdsec

Timeboxing the facts: once Christophe from Fuites Info gave us the information and archive, we could see that the archive contained crowdsec-ghsa-273h-gvwr-c3qj, a repository that was destroyed on May 27th. The latest commit present across all repositories is from May 22, 2026 01:24 UTC, and the archive timestamp is set to May 22; this lines up.

At that point, we know with a high degree of certainty that the leak is limited to CrowdSecurity’s source code, including 130+ public repositories and many private ones. CrowdSec’s infrastructure or databases have not been accessed or compromised. No code was altered, whether in the open-source software, our private source code, or the build pipelines.

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. 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:

For example, the dump included an AWS secret assertible-zapier-sns-sender, and someone tried to use it on 17 August 2026 from IP 23.234.84.102 to perform GetCallerIdentity and ListTopics on both dev and env topics. This AWS role was restricted to publishing on a single SNS topic; it didn’t go any further.

The archive .github/.git/config contains the origin that was used to clone the repositories:

...
[remote "origin"]
	url = https://oauth2:gho_xxxxxxxxx@github.com/crowdsecurity/.github.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
	remote = origin
	merge = refs/heads/main

This tells us the token used to clone the repositories is an OAuth token (gho_xxx), and the likelihood is higher because its checksum is correct [2]. The methodology is well aligned with the TeamPCP / Mini Shai-Hulud tactics.

However, we couldn’t find any trace of this OAuth token in our organization’s audit log or in any of the current GitHub organization members’ audit logs. You can download those from the web UI and look for the token’s hashed version (echo -n $token | openssl dgst -sha256 -binary | base64). This was a dead end.

We also reviewed the list of active OAuth integrations in the organization (in “Access Restricted” mode) but didn’t find anything suspicious either; none of the integrations suffered public breaches in the relevant timeframe.

If it was an active user’s OAuth token, we would expect to see related activity in the activity log. On the other hand, GitHub’s audit log only tracks specific actions [2.1], and only enterprise plans (which we’re not on) keep git activity on a rolling 7-day window.

[2] https://github.blog/engineering/platform-security/behind-githubs-new-authentication-token-formats/

[2.1] https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization

The real complexity behind this forensic analysis is that the token used to download the private repositories no longer existed when we became aware of the code leak. So it was created, lived, and died without leaving us any traces beyond its usage. This is where GitHub’s professional support was invaluable. They traced the token’s full lifecycle and confirmed our initial suspicions about TanStack.

At that point, our main concern was that we still didn’t know the origin of the compromise. We checked for user tokens and scanned for malicious packages, VS Code extensions, etc. The developer machines came back clean.

We promptly investigated our own repositories’ Git history to see if some of the backdoored packages touched our repositories at some point, but this was inconclusive. While some TanStack packages were present, none were on the backdoored list. Finally, we enforce a minimum age on Node packages. 

One thing that puzzled us was that TeamPCP is known to not restrict itself to GitHub credentials, but also to look for other tokens such as AWS credentials, SSH keys, etc. While GitHub gives you very little visibility into git activity, we have good visibility and alerting on AWS, and nothing suspicious has happened since the supply chain attacks or since the credentials in the leak were probed.

With the OAuth token and a precise timeframe for the activity, we reached out to GitHub support to see if we could get more information. They kindly provided the Git activity within the 2-hour timeframe of the dump. We then discovered that it was an 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:

2026-05-22 05:52:32.138 UTC – fetch – crowdsecurity/XYX – <redacted> – 178.249.214.XX

Based on the git information in the leaked archive, the IP is in Toronto, Canada, in the UTC -4 time zone. The ex-employee got compromised by the TanStack supply chain attack, matching the methodology. We removed his account from the GitHub organization on 25 May 2026, 3 days after the incident.

This also explains why we didn’t see AWS or infrastructure-related activity, as we had already revoked the employee’s access.

After identifying the root cause and further auditing the user’s Git activity and existing accounts, we confirmed that his account was used solely to perform the Git clones that led to the leak. No commit, no changes to the code, the infrastructure, or the CI was performed. 

What action we took to avoid any further incident

We had a lot of security mechanisms and procedures in place prior to this incident:

• Strict privilege separation (for example, as a CEO, I don’t have any access to bank accounts, organization admin tools, AWS console, etc., and this is best practice and applied to everyone, everywhere)
• Tight scoping: What applies to user rights equally applies to apps, AIs, cloud routines, and scripts, to avoid granting any right beyond what is strictly needed to fulfill their role.
• 2FA everywhere, for every tool and everyone, along with passkeys and physical (Titan Key) devices
• Password wallets: obvious, but security should always be explicit
• Safety sentences: if a key member of the organization with extended rights is physically compromised (or his family), we have agreed on specific words to drop in the conversation to alert our interlocutor we are compromised.
• Audits: whether internal, AI-led, or external, they became a routine. 
• Logs everywhere: During this crisis, we learned we want deeper logging of actions on GitHub, but the logs from our toolchains, CI/CD components, and AWS trails were very solid. Having traces allows us to trace but also to react early, and after all, we are CrowdSec, so pretty privy to the issue 🙂
• Pentesting: We come from this background, and we know how to value these. How frequently to run them, what form they should take- this all changes over time, but testing the company employees and our source code is part of what we do.
• NPM node age monitoring: to make sure we are not running on a version that is too recent to be audited or too old to carry security risk.
• Onboarding/deboarding procedures: The full lifecycle of an employee’s credentials matters, and removing (or knowing why you kept) all access once they are gone matters even more.
• Automated code analysis: Every commit is automatically scanned for potential vulnerabilities or logic flaws
• Publication, QA & QC procedures & reviews: whether automated or manual, these are classical components of an editor’s tool belt
• And much more…

Yet, all of this couldn’t prevent a Supply Chain Attack, so what could have?

EDRs: At the time of the incident, we didn’t enforce EDR on developers’ machines, but we’ve since started using endpoint protection that actively focuses on malicious packages, extensions, etc. As supply chain attacks become the new plague and virtually anyone can get caught in them, we should have done this earlier. 

The workstations/laptops of people interacting with our codebase or infrastructure now run EDRs (the Aikido Security one) to reduce the risk of supply-chain attacks, but in-memory analysis and runtime monitoring with something like CrowdStrike’s EDR could further close the gap. However, because the employee had already left the company, the likelihood that he still had endpoint protection on his machine was low.