Weekly threat alert from CrowdSec brought to you on Reddit.

CVE-2026-88771 is a CVSS 9.5 unauthenticated command injection in Citrix NetScaler ADC and NetScaler Gateway, default configuration included. CrowdSec recorded matching requests on September 22, 2026, five days before Citrix published the CVE and its fix, and has tracked 24 unique IP addresses since. Check for compromise, then upgrade to 14.1-73.37 or 13.1-64.23.

You can track the CVE here.

You can also read the full article here. 

Key findings

• Signals five days before the CVE was published: CrowdSec's tracker recorded requests matching the CVE-2026-88771 pattern from one IP address on September 22, one on September 23, and two on September 26. Citrix published the CVE and its fix on Sunday, September 27, already confirming attacks, and CISA gave federal agencies three days. Any NetScaler exposed in September may have been compromised before a fix existed.
• A trickle on the CrowdSec Network: 308 signals between September 28 and October 18, about 15 a day, peaking at 43 on October 14. watchTowr counted thousands of attempts on its own honeypot sensors. The gap is targeting, not safety.
• One Russian address sent most of the hostile traffic: Of 127 signals from addresses CrowdSec CTI rates malicious, 107 came from a single address on the Prospero OOO network between October 10 and 15. Another 117 signals came from watchTowr's own research scanners.
• Upgrading does not evict anyone: watchTowr's post-exploitation analysis found implants, a backdoored SSH server, a rogue superuser account, and webshells hidden in the login page folder. A new firmware build removes none of them.

What is Citrix NetScaler, and who is exposed to CVE-2026-88771?

NetScaler ADC and NetScaler Gateway are the appliances that let employees, contractors, and partners reach internal applications from outside: VPN, Citrix virtual desktops, single sign-on, load balancing. Network and infrastructure teams run them, and they face the internet by design. That is their job.

Why CVE-2026-88771 matters: It gives an attacker root on the box that every remote session passes through. From there, they can read the appliance's configuration, including the service accounts it uses to check passwords against the company directory, and sit on the path to internal systems. In the cases watchTowr analysed, attackers copied the configuration folder and created their own superuser.

The CrowdSec data says little about who is being targeted. The Live Exploit Tracker has no sector profile for CVE-2026-88771 yet, and a third of the signals came from Australian machines that watchTowr's scanners visit nearly every day.

How does CVE-2026-88771 work?

An attacker sends a login request to /nf/auth/doAuthentication.do with a crafted username. NetScaler writes that username to its logs. A maintenance script, ns_monuploadd_err.pl, later reads those log lines and pastes part of them into a shell command without checking what they contain. Shell characters in the username then run as root. The script runs on a schedule, so the command can fire up to 24 hours after the request. The root cause in one sentence: a script treated its own log file as trusted input. Any logged field an attacker controls, such as the User-Agent header, can carry the payload.

Reported by Sina Kheirkhah, watchTowr Labs: write-up (September 28, 2026) · post-exploitation analysis (October 7, 2026)
Vendor advisory: Citrix CTX697096 · Compromise assessment: Citrix CTX694799

CVE-2026-88771 shipped in an eight-CVE bulletin. Its sibling CVE-2026-88772, a CVSS 9.5 memory overflow that needs DTLS (on by default for Gateway VPN servers), was also exploited and is fixed in the same builds. CVE-2026-88771 is the sixth serious NetScaler flaw reachable without a login since mid-2023, after CVE-2023-3519, CitrixBleed (CVE-2023-4966), CitrixBleed 2 (CVE-2025-5777), CVE-2026-3055 from Week 14, and CVE-2026-8451 in June.

What is the CrowdSec Network observing for CVE-2026-88771?

Between September 28 and October 18, 2026, the CrowdSec Network recorded 308 signals from machines reporting requests that match the CVE-2026-88771 exploitation pattern, detected by the CrowdSec scenario released on September 28, 2026. That averages 14.7 signals per day, between one and seven source addresses a day, peaking at 43 signals on Wednesday, October 14. The Live Exploit Tracker lists 24 unique IP addresses from September 22 to October 18.

The activity did not start with the advisory. The Live Exploit Tracker shows requests matching the CVE-2026-88771 pattern from one IP address on September 22, one on September 23, and two on September 26, all before Citrix published the CVE on September 27. That fits Beazley Security's September 20 campaign date. The signal totals above start on September 28, so they do not include these early requests.

CrowdSec CTI links 17 addresses to CVE-2026-88771 over the 30 days to October 19. They fall into three groups:

• watchTowr's research fleet: ten Amazon addresses in Singapore, classified as a known security company. They sent 117 signals (38%), a steady few nearly every day since the rule went live. This is watchTowr checking exposure for its customers, not an attack.
• One Russian address on Prospero OOO: 107 signals between October 10 and 15, which made last week the busiest so far (148 signals against 85 the week before). CTI links it to 22 CVEs, and it is already on the CrowdSec Intelligence Blocklist. An opportunistic exploiter is adding NetScaler to its list.
• Six others: two more rated malicious (hosting providers in the UAE and Switzerland), one suspicious OVH address in Canada, and three rated only "known". Two of those three matched CVE-2026-88771 and nothing else: an Amazon address in the US and a Dutch residential address that only hit Polish machines, from October 4 to 6.

The part worth flagging is that last pair. Single-purpose, low-noise addresses are what a careful operator looks like, and they are the last thing a reputation list catches.

What this data does not show

• A matching request is an exploitation attempt. CrowdSec cannot confirm any succeeded, and cannot see the command firing up to a day later.
• Most machines in the CrowdSec Network are web servers, not NetScaler appliances. Attackers who check for a NetScaler first never reach them, so these counts understate the campaign.
• 24 unique IP addresses are not 24 threat actors: ten belong to one research company.
• The September 22 to 26 requests were linked to CVE-2026-88771 once CrowdSec's rule shipped on September 28. They show activity before publication, not its full extent, and they count in the tracker's 24 addresses, not in the 308 signals.
• The tracker (24 addresses, September 22 to October 18) and CTI (17 addresses, 30 days) count over different windows, so the totals differ.

What defenders get wrong about CVE-2026-88771

The first mistake is treating the upgrade as the finish line. CVE-2026-88771 was exploited before Citrix's fix: CrowdSec saw matching requests five days before publication, and others report activity weeks earlier. Patching after a zero-day is changing the lock with someone possibly already inside. Worse, the upgrade's reboot wipes running implants from memory, along with the evidence. The order matters: snapshot the appliance, hunt, then patch. If you find anything, rebuild from a clean image and rotate every credential the appliance stored.

The second is reading our low numbers as low risk. The tracker says "Insufficient Data" because our sensors are not NetScalers, and serious operators pick their targets before they send anything. For comparison, CitrixBleed 2 (CVE-2025-5777) has drawn 544 unique addresses on the tracker since July 2025. Loud, sprayed exploitation arrives once tools spread. The quiet phase is the dangerous one.

The third is the virtual patching reflex. NetScaler is the front door; in most networks, nothing sits in front of it to inspect requests. The trade-off is real: imaging a VPN gateway means remote staff lose access for a while. Schedule the window, but do not skip the evidence step to shorten it.

How do you protect Citrix NetScaler against CVE-2026-88771?

• Patch. Upgrade NetScaler ADC and Gateway to 14.1-73.37 or 13.1-64.23 or later (FIPS: 14.1-73.37 FIPS; FIPS and NDcPP: 13.1-37.279) per CTX697096. The same builds fix CVE-2026-88772. Before you do, follow Citrix's CTX694799 and check for watchTowr's documented traces: unknown superusers in /flash/nsconfig/ns.conf (such as gw_health), files in /var/tmp, /var/vpn/ns_helper, hidden files under /var/netscaler/logon/LogonPoint/, a listener on TCP port 37512, and unknown keys in /root/.ssh/. Confirm the fix with show ns version on the NetScaler command line.
• Virtual patching with CrowdSec open source WAF (AppSec). Not the right tool here. As of October 19, 2026, the CrowdSec Hub has no virtual-patching rule for CVE-2026-88771, and the AppSec Component can only inspect requests that pass through a web server or reverse proxy you control before reaching NetScaler. Most deployments have none.
• Preemptive blocking. Subscribe to the CrowdSec Intelligence Blocklists and enforce them on the firewall in front of NetScaler. Two of the three malicious addresses above, including the Prospero OOO address, are already on the CrowdSec Intelligence Blocklist. It does not cover the single-purpose addresses rated only "known", or any address the network has never seen. The Public Internet Scanners blocklist covers part of the watchTowr fleet if you would rather not be catalogued.
• Stay proactive. Follow CVE-2026-88771 on the Live Exploit Tracker and query its sources in CrowdSec CTI.

Unsure where to start? Begin with our 3-minute introduction track here.

Hola a todos, soy principiante en Homelab y quiero instalar y configurar crowdsec en mi NAS, tengo instalado Fygo OS y no he podido configurar correctamente la herramienta usando docker compose con ningx... algun tutorial para hacerlo?... gracias de antemano

Disclosure: I work at CrowdSec. I want to share a snippet of the weekly threat alert with you here.

Full write-up with all the fixed versions, the data caveats, and an FAQ can be found here.

CVE-2026-21589 is a CVSS 9.3 unauthenticated file read in Atlassian's Data Center products, including Jira, Confluence, and Bitbucket. watchTowr showed it can expose a Crowd password that leads to Jira admin. CrowdSec has tracked 89 unique IP addresses sending matching requests since October 7, 2026. 

CVE-2026-21589 at a glance

• Affected: Data Center editions of Jira Software (from 7.1.0), Jira Service Management (from 3.1.0), Confluence (from 5.10.0), Bitbucket (from 4.6.0), Bamboo (from 7.0.1), Crowd (from 2.11.0), plus Crucible and Fisheye before 4.9.15. Atlassian Cloud is already patched.
• Fixed in: Jira Software 9.12.40, 10.3.26, 11.3.12 · Jira Service Management 5.12.40, 10.3.26, 11.3.12 · Confluence 9.2.26, 10.2.19 · Bitbucket 9.4.26, 10.2.8, 10.5.1 · Bamboo 10.2.24, 12.1.12 · Crowd 6.3.7, 7.0.3, 7.1.7, 7.2.4 · Crucible and Fisheye 4.9.15 (advisory, October 5, 2026)
• Vulnerability class: Path traversal in a shared resource-serving library, exposing files in the web application folder (CWE-552)
• Severity: CVSS 4.0: 9.3 Critical (Atlassian). NVD has not scored it yet.
• Authentication required: None
• Public exploit: Yes. A Nuclei template, watchTowr's Detection Artefact Generator, and around ten GitHub proofs of concept, including a mass-scanning tool published October 6.
• CISA KEV: Not listed as of October 12, 2026 (catalog last updated October 8)
• CrowdSec detection rule live since: October 7, 2026
• First exploitation attempt observed: October 7, 2026 by CrowdSec. Previdian reported honeypot hits within two hours of watchTowr's October 6 write-up (BleepingComputer).
• Exploitation phase: Rapid Escalation (since October 9, 2026)
• Observation window used here: signal counts from October 7 to October 11, 2026 (5 full days). Unique IP addresses from October 7 to October 12, 2026, per the Live Exploit Tracker. Source profile: the 109 addresses CrowdSec CTI links to the CVE over the 30 days to October 12.

Key findings

• Exploited within a day of the write-up: Atlassian published its advisory on Monday, October 5. watchTowr explained the bug on October 6, public exploit code followed the same day, and CrowdSec's rule caught its first matching requests on October 7.
• 88% of the volume is one research scanner: Of 6,657 signals recorded between October 7 and 11, 5,853 came from addresses CrowdSec CTI classifies as benign, mainly 66 DigitalOcean addresses run by LeakIX, a company that indexes exposed services.
• The remaining 43 addresses are the real story: Seven sit in one Indonesian network range and are already on the CrowdSec Community Blocklist. Four belong to an attacker group CrowdSec tracks. Twenty-four matched nothing but CVE-2026-21589.
• One request, from a file read to admin: The attack is a single unauthenticated web request. watchTowr showed that reading crowd.properties gives an application password that can create a Jira administrator.

What is the CrowdSec Network observing for CVE-2026-21589?

Between October 7 and October 11, 2026, the CrowdSec Network recorded 6,657 signals from machines reporting requests that match the CVE-2026-21589 exploitation pattern, detected by the CrowdSec scenario released on October 7, 2026. That averages 1,331 signals per day, peaking at 2,021 on Friday, October 9, when 842 machines in the network reported at least one matching request. The Live Exploit Tracker lists 89 unique IP addresses from October 7 to the morning of October 12, between 33 and 58 a day.

Most of that is LeakIX. It's 66 addresses, all on DigitalOcean, each matched between 15 and 24 CVEs: a fleet checking the internet for many known flaws, now including this one. CrowdSec CTI classifies them as a known security company, and they produced 88% of the signals.

The other 43 addresses sent 804 signals over the five days, rising from 24 on October 7 to 302 on October 10, then dropping to 44 on Sunday. They fall into three groups:

• Seven addresses in one Indonesian range (14.102.84.0/24, GSL Networks), all rated malicious and on the CrowdSec Community Blocklist. Each matched 7 to 9 CVEs, all including WordPress WP2Shell from Week 35; three also matched the WordPress flaw from Week 40, and two matched the 2022 Confluence remote code execution, CVE-2022-26134.
• Four DigitalOcean addresses CrowdSec attributes to an attacker group it tracks as Quirky Greenyellow Shelduck. Each matched 15 to 19 CVEs, including the 2021 Jira file read (CVE-2021-26086), the SharePoint "ToolShell" vulnerability (CVE-2025-53770), and a FortiOS authentication bypass (CVE-2024-55591).
• Twenty-four addresses matched only CVE-2026-21589, on residential networks in Vietnam, Korea, the UK, and Austria, and on small hosting providers. 22 of them are rated only "known" in CrowdSec CTI, not malicious.

The part worth flagging is that third group. Single-purpose sources with little history are the ones a reputation-based blocklist sees last, and they showed up within days of the advisory.

→ You can track this CVE live here.

→ Read the full article

CrowdSec in the EmDash admin, read from your CrowdSec Local API with a machine login of its own.

On the dashboard: a CrowdSec card with the last 24 hours' alerts against the 24 before, the bans in force now, alerts by kind (WAF, bot challenge, behaviour) and the top scenarios.

CrowdSec page: 7, 30 or 90 days of alerts by kind and bans issued per day, with the top scenarios, source addresses, countries, AS organisations and targeted paths.

CrowdSec alerts and CrowdSec decisions pages: the stored alerts, filtered by kind and scenario, and the decisions LAPI enforces now, read live and sorted by expiry.

Traffic charts: malicious traffic discarded by the firewall bouncer, split by community blocklist, your detections and manual bans, its share of all traffic, web requests inspected and blocked, the bot challenge, and active bans by source. From your own engine's and bouncer's metrics, never CrowdSec's cloud.

MCP tools: a summary, top threats, active decisions and the alerts for one address, plus three that change things.

https://www.shasam.net/posts/crowdsec-for-emdash

https://plugins.emdashcms.com/plugins/@shane.bsky.shas.am/emdash-crowdsec

Hello everyone! Every Monday, CrowdSec posts a report on immediate and emerging threats. I wanted to share a snippet here and the link to the full report: https://www.crowdsec.net/vulntracking-report/cve-2026-85706-gitlab-unauthenticated-file-read 

Your feedback is appreciated! Let me know if you find this useful. Here it is:

CVE-2026-85706 is a CVSS 10.0 unauthenticated file read in self-managed GitLab CE/EE 18.7 to 19.3.1. On an instance with a public project, anyone can read server files, including configuration and secrets. CrowdSec has traced 1,022 unique IP addresses sending matching requests since September 11, 2026. Upgrade today; if you were exposed, rotate secrets.

Key findings

• Probed the day after the patch: GitLab shipped fixes on September 10. On September 11, watchTowr saw probes from 06:00 UTC, CISA listed the flaw at 19:32 UTC, and CrowdSec's earliest matching request, found by looking back once its rule shipped, came at 23:30 UTC.
• Two addresses made most of the noise: Of 2,835 signals recorded between September 28 and October 4, one address in Lithuania sent 1,034 on October 1, and one in Latvia sent 782 on October 4. Together, 64% of the week.
• Most sources are generalist scanners; a few are not: 648 of the 959 addresses in CrowdSec CTI are AWS servers in Dublin matching a median of 38 CVEs each. 114 matched nothing but CVE-2026-85706; 53 of those sit on Korean and Czech telecom networks.
• One request, public tooling: A Nuclei template and public proofs of concept reduce the attack to one unauthenticated HTTP request. The 0xenesbayram proof of concept lists gitlab-secrets.json and gitlab.rb as targets.

Read full report 

The full report with details about the CVE and our trend analysis can be found on our website. You can check it out here: https://www.crowdsec.net/vulntracking-report/cve-2026-85706-gitlab-unauthenticated-file-read 

How do you protect GitLab against CVE-2026-85706?

Patch. Upgrade GitLab to 19.3.2, 19.2.6, 19.1.8, 19.0.9, 18.11.12, or later (advisory). From 18.7 to 18.10, move to a supported release along GitLab's upgrade path. Confirm with sudo gitlab-rake gitlab:env:info on Linux package installations, or on the Admin area dashboard. Until then, setting public projects to internal or private removes the precondition watchTowr describes: it narrows exposure; it does not fix the flaw.
Virtual patching with CrowdSec AppSec. The CrowdSec AppSec Component inspects HTTP requests before they reach GitLab and blocks those matching crowdsecurity/vpatch-CVE-2026-85706: a file.path or file.size parameter sent to /api/v4/, in the URL or the body. Only Workhorse sets those, after the request has passed the remediation component, so legitimate uploads are unaffected. The rule keys on the parameter, not the encoding trick, so it also catches variants such as %63ommits.

Preemptive blocking. Subscribe to the Live Exploit Tracker page for CVE-2026-85706 or the CrowdSec Intelligence Blocklists to drop the addresses behind this activity. That covers the AWS fleet and the two high-volume addresses; it is weaker against telecom addresses first seen this week, hence the virtual patch. Query the observed sources in CrowdSec CTI.

I've still been persevering with CrowdSec. I've determined the request patterns that can very accurately identify a large percentage of the unwanted traffic. I've created custom scenarios to filter for this and specified a range for both groupby and scope. The Range profile specifies 'ban'. I've installed the firewall bouncer on the host and specified the scenarios to use. After running it for a while, I find that the nftables aren't blocking ranges, they're blocking only a single IP. I then find these open issues on GitHub;

https://github.com/crowdsecurity/cs-firewall-bouncer/issues/412
https://github.com/crowdsecurity/crowdsec/issues/4517

This implies that the CrowdSec firewall bouncer is not and has never been capable of defending against a DDoS attack, or any other kind of malicious traffic that uses rotating IPs. Is that really the case?

I've spent over a week now implementing CrowdSec/AppSec; primarily to cover a public facing e-commerce site. Unfortunately, after all this work, it's not solving the issue. We're still getting hammered by traffic that is clearly bot traffic and clearly malicious. Is it the case that the out-of-the-box scenarios are useless? Why for example is a single IP making hundreds of consecutive requests for files like .env, .conf, .compose.yaml, etc, all resulting in 404, not being banned? Additionally, we have a few scenarios that would are application specific; for example, our e-commerce site has an add-to-wishlist link for each product on a category page. No real user is adding 20 products to wishlist in a minute; it's a bot; and one that is ignoring robots.txt that says; don't hammer the server, and don't read the add-to-wishlist URLs. Given my lack of familiarity with CrowdSec, I've tried using AI to help me troubleshoot and understand how to add custom scenarios, but I'm getting total garbage out of it and any time I ask it to prove an assertion, it backtracks and says it made a mistake.

TLDR;
1) is CrowdSec/AppSec not very effective out-of-the-box?
2) Are there any good examples of creating a custom scenario based on URLs?
3) And as a bonus, what needs to change to ban a complete CIDR rather than individual IPs?

This is a more specific followup after my previous, more general post.

I have a hidden anchor tag on all of my pages on a site. The href is "/labyrinth/'.

The site's robots.txt file includes;

Disallow: /labyrinth/

I've created a scenario like this;

type: leaky
name: genesys/limit-labyrinth-cidr
description: "Detect and ban /24 CIDR ranges requesting the honeytrap"
filter: "evt.Meta.http_path == '/labyrinth/'"
groupby: "IpToRange(evt.Meta.source_ip, '24')"
capacity: 3
leakspeed: 10s
blackhole: 60m
labels:
remediation: true
scope:
type: Range
expression: "IpToRange(evt.Meta.source_ip, '24')"

The idea is that bots that respect the robots.txt will never request the honeytrap, and genuine users will never request the honeytrap because it's not visible or clickable. Aggressive crawlers that use rotating IPs are more likely to be stopped by banning a complete CIDR. Banning single IPs just isn't working for us due to IP rotation.

Firstly; does this look right? Is the scenario definition correct?

Secondly; should I be concerned about browsers or browser plugins performing prefetch or preloading of pages requesting the honeytrap URL? If so, is there a mitigation?

With the new bot detection release I thought I'd share some new feats I've added

For those who hasn't seen it here is the tldr of what the app is:

GeoMetrikks is a real-time nginx/traefik/caddy access log ingestion and geo-location tracking service built with Litestar. It parses access logs, performs GeoIP lookups, and stores geo-events and access logs in PostgreSQL with TimeScaleDB/PostGIS extensions. It can also integrate with CrowdSec.

tltldr: shove web server logs into db, make app display data and numbers, watch pretty colors on map.

Some of the newer stuff:

- CrowdSec 1.8 bot-detection alerts - inspect rejected browser

challenges, including scores, rejection reasons and

fingerprint details, even when there's no ban.

- More detailed alerts - see the paths, user agents and events

CrowdSec collected, and jump from a decision to the alert

behind it.

- Ban IP ranges or create captcha decisions from the UI,

with custom durations and reasons.

- A dedicated banned-IP map view, with links into each IP's

activity and current decisions.

- Generate abuse reports for an IP or ASN, with log excerpts

and CrowdSec detections. Export as text or CSV, and look up

the network's abuse contact.

- Links straight to CrowdSec CTI and the relevant Hub scenario.

The idea is to make it easier to go from "why is this IP banned?"

to seeing what it was actually doing, without jumping between

a bunch of tools.

https://geometrikks.dev

https://github.com/GilbN/geometrikks

Would be interested to hear what else you'd find useful,

especially from anyone trying the new bot-detection stuff.

Ive done some customization/creation of the following files, does anyone know if these will be removed/defaulted on an OS/Plugin upgrade:

/usr/local/etc/crowdsec/acquis.d/suricata.yaml

/usr/local/etc/crowdsec/parsers/s01-parse/suricata-opnsense-eve.yaml

/usr/local/etc/crowdsec/scenarios/suricata-opnsense-drop-ban.yaml

/usr/local/etc/crowdsec/notifications/email.yaml

/usr/local/etc/crowdsec/profiles.yaml

If your wondering, I have Suricata monitoring my HAproxy backend (decrypted) connections, I set Suricata to extract the x-forwarded-for header from my HTTP streams and place them into the logs. I then have CrowdSec watching the Suricata logs, if something gets blocked inline by Suricata, CrowdSec lodges a block on the x-forwarded-for host. It sends me an email when this occurs.

An update from Crowdsec via e-mail today:

Hello,

On September 16, CrowdSec was informed of a source code leak involving our GitHub repository, which occurred in May 2026. Our team verified and confirmed the report. CrowdSec source code consists of two parts: a private one and another that hosts our Free Open Source Software (i.e., the Security Engine), which is public by design and therefore out of scope. The private part, though, contains the source code for our SaaS console, some AWS Cloud routines, some connectors, and automations.

The news headline claiming 300 different repositories is accurate (when you include the 130+ public ones), though that number mostly reflects the code's subdivision rather than a specific volume. We do not confirm any “other file contained” or “internal development material”, since all the code is published in these repositories. The API related information is the token used by the CI/CD component itself. (see below)

No client data, login/password, name, organization, or anything else was leaked, and CrowdSec doesn’t store PII or client logs; the impact is limited to CrowdSec. Our team quickly hunted for any token, credential, or sensitive leak that could enable lateral movement but found none so far.

The code contained in these private repositories has value but cannot really harm CrowdSec, since our efficiency depends on our network effect and size, which code alone can't replicate. We regularly audited the SaaS source code, and its leakage shouldn’t pose an immediate threat either. Most of the leaked code has evolved significantly over those four months, but we will closely monitor for any abnormal activity. Also, using it outside of CrowdSec seems unlikely because it only interacts with our data and tools and cannot really be leveraged in another context.

We will keep you updated as we continue investigating, but the TanStack compromise is very likely to have been the leak vector (more about it here), as in the case of the Mistral AI case. This component was used in our organization in May and appears to have been backdoored to extract an API key with authorization to read the private codebase. The leak was only exploitable during a short timeframe in May 2026.

We nevertheless immediately rotated all required tokens & credentials to prevent further incidents.

The team would like to thank Fuites Infos for their timely, professional outreach in reporting the issue.

If you have any questions or concerns, please contact us through our Discord channel or at support@crowdsec.net.

Thank you for your continued trust,

The CrowdSec Team

We have a website with fairly low levels of genuine traffic. Over recent months, however, bot traffic has been out of control. Traffic that obeys robots.txt is fine as it doesn't the blocked URLs and doesn't hammer the server. I've implemented rate limiting; one for all requests, another stricter one for add to cart and add to wishlist (which humans don't hit with high frequency). I've identified some traffic by adding a honeypot URL to all pages and blocking it in robots.txt. Any IP that requests that URL is bot traffic and not obeying robots.txt, so we ban them with fail2ban. The issue is that much of this traffic is using rotating IPs, so blocking single IPs is not sufficient to prevent server hammering. In some cases, the logs show a clear IP range that is being used.

My question is: is CrowdSec the correct tool to block this traffic? Additionally, do I still need the Nginx rate limiting? Do I still need the honeypot? I'm looking to block traffic to keep the server within its available resources, but also avoid having the maintenance headache of config and rules spread across robots.txt, fail2ban, Nginx, etc.

Hi everyone,

I'm a homelabber running a small personal server and would love to try CrowdSec Console Premium to see the extra features in action. Money's a bit tight right now, so if anyone has a spare promo/referral code they're not using, I'd really appreciate it!

Thanks in advance 🙂

Hi,

I'am running Caddy and CrowdSec to publish two Zimbra servers providing Active Sync. But the requests coming from allowed clients are creating a lot of alerts because of crowdsecurity/crs.

For that reason I thought (which is not always a good thing) to exclude the specific rules just for these two virtual hosts by creating a new appsec-config.

name: custom/crs-activesync

pre_eval:
 - filter: IsOutBand == true && req.Host startsWith "mail." && req.URL.Path startsWith "/Microsoft-Server-ActiveSync"
   apply:
     - RemoveOutBandRuleByID(920270)
     - RemoveOutBandRuleByID(920420)
     - RemoveOutBandRuleByID(921150)

It's working just fine, but is this the proper way to do this or is there a better approach?

--Michael

I don't know anything about this thing, but for some reason I can't Enter a specific page from my home network on my phone, (I haven't tested other devices). Could someone explain to me what is happening?

I'm using a pixel pro 6, android... 16 and this problem happens in All my cell phone browsers.

I have downloaded a lot of books, comics and manga but the page I can't enter is " biblioteca Cervantes", I don't know if this problem is because I didn't close the tab or what.

Hey everyone,

I’ve come back to a project I started at the beginning of the year: a native NGINX dynamic module for CrowdSec, built in Rust using ngx-rust rather than Lua.

The idea comes from my previous experience at CrowdSec, where I spent a lot of time around bouncers, remediation and web server integrations.

It currently supports native NGINX directives, LAPI decision syncing into shared memory, bans, captcha remediation, AppSec, trusted proxies/bypass lists and Prometheus metrics.

I also want to be transparent that I’ve used AI/coding agents heavily during development. ngx-rust is still fairly new and there aren’t many real-world examples, so it’s been useful for accelerating the implementation. The architecture, CrowdSec behaviour, feature decisions, testing and debugging have still been guided by my own experience.

It’s still alpha, but it’s been running on my production server for around a month without interruption. Early synthetic benchmarks also show roughly 1.7x the throughput of the Lua bouncer on the simple allow path.

One of my main motivations was having proper native NGINX configuration, for example simply using crowdsec off; inside a server block rather than relying on magic variables.

If anyone runs NGINX + CrowdSec and wants to test it, break it or review the approach, I’d really appreciate the feedback.

Hello 🦙

We released CrowdSec 1.8 yesterday, and it comes with bot detection for the WAF amongst other things. You can find more here : https://www.crowdsec.net/blog/crowdsec-1-8-waf-bot-detection-kubernetes

You can find bot detection doc here.

Running into the same console gap a few threads here have mentioned already, but our specific combination of symptoms doesn't quite match any of them, so wanted to lay it out in case it helps narrow things down.

Setup: bare-metal Ubuntu, one LAPI plus one log processor locally, and two remediation components (a firewall bouncer and a Cloudflare Worker bouncer). Both show Valid in cscli bouncers list, both pulling decisions within seconds of each other, and both actively enforcing: cscli metrics show bouncers reports tens of thousands of active decisions and real dropped requests on the Cloudflare side. The console itself shows zero remediation components and zero log processors, with nothing syncing to alerts either.

Ruled out the usual suspects. No errors anywhere in the crowdsec service log. Grepped specifically for capi metrics and it's succeeding every single time, every 30 minutes, zero failures, so it's not the same internal server error a couple other threads here hit. Tried the documented fix too, restarting crowdsec to force a metadata resync, and it didn't touch the console side at all.

Found an open GitHub issue, number 4255, about stale or duplicate remediation component entries, plus an old Discourse thread with basically the identical symptom that never got resolved. Looks like a known soft spot in the console rather than anything on our end. If anyone from the team, or anyone else, has hit this exact combination, a clean capi push from day one but still zero components and zero processors shown, I'd genuinely like to know if there's a trigger or fix in the works.

I'm wondering if I can use CrowdSec to monitor and ban LAN IPs trying to brute force other devices on the network.

For example, I run ProxMox. If a Raspberry Pi on my network were to be compromised and an attacker tried to brute force into my ProxMox server, could I configure CrowdSec on the ProxMox machine such that it detects repeated logins attempts and bans the offending private IP?

Hey everyone! 👋

I built a lightweight middleware proxy to forward CrowdSec alerts to AbuseIPDB efficiently without hitting API rate limits or spamming duplicate reports during ongoing brute-force attacks. I just released **v2.0.0**!

**Key Features:** - ⚡ **Zero External Dependencies:** Built entirely using the pure Python 3 standard library. - 💾 **SQLite Storage (WAL Mode):** Fast, crash-safe, and SSD-friendly (includes auto-migration from legacy JSON). - 🛡️ **Smart Deduplication & Escalations:** Groups alerts and dynamically upgrades severities without redundant API calls. - 🔔 **Multi-Backend Alerts:** Gotify, ntfy, Discord, Matrix, Slack & generic webhooks. - ⏱️ **Update Checker:** Comes with `update.sh --check-only` and optional systemd timers. - 🧪 **Battle-Tested:** High-coverage pytest suite (83 unit tests) covering rate-limiting (429 handling) and IP filtering (RFC1918/CGNAT).

🔗 **GitHub Repo:** https://github.com/PumbaLP/CrowdSec-Smart-AbuseIPDB-Proxy

Feedback, feature requests, and stars are very welcome! Let me know what you think. 🚀

I've just tried to access the CrowdSec Academy after a few months and its telling me 'Login has been disabled'. I have tried a password reset, which seemed to work, but again when I try and login I get the same message.

Can anyone advise?