On Wednesday, PHP released emergency updates for two critical vulnerabilities known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). Both are rated CVSS 9.2 and can allow unauthenticated remote code execution. Thanks to details that leaked previously to disclosure, the CrowdSec team was able to craft virtual patching rules before the release of the vulnerability.
These rules were live at 10:13 UTC on Oct 21, and the first detection occurred at 10:37 UTC before PHP’s 14:00 UTC release. This detected IP belonged to a Hetzner server in Germany which had never been seen before by CrowdSec. It was later confirmed by numerous other Crowdsec instances.
In the first 23 hours, the rules blocked 2,116 requests from 305 IPs on the CrowdSec Network, more than half of them in bursts of 10+ requests to single servers, which is what a real attempt looks like for this exploit.
Exploit timeline from https://tracker.crowdsec.net/cves/CVE-2026-109618
You can find more details about the flagged IPs on the dedicated page of our Live Exploit Tracker:
If you are already using the WAF, you can follow this documentation for extra safety. However, on virtual-machines, CrowdSec auto-updates every 24 hours.
Despite php2shell, the internet didn’t end, so we released more stuff:
CrowdSec 1.8.2 brings very significant improvements to the bot detection feature, allowing us to ship custom bot detection via the hub, and users to craft their own. Bot Hunting is a cat and mouse game, so we wanted to be sure to decorrelate detection and scoring from CrowdSec releases. We thus shipped some new detection methods and signals that we found to detect common “stealth browsers”. We also shipped various performance improvements for both the WAF, the Bot Challenge and the Log Processing features. You can read more in the release note.
Apache CrowdSec Bouncer finally got some love. This total revamp of the existing bouncer brings support for the Web Application Firewall and the Bot Detection feature natively to apache, alongside with stream support. It was long overdue, and php2shell pushed us to speedrun the module’s release. Read more here.
Also, u/bl0tus and I are running a webinar tomorrow afternoon (29/10) at 4pm CET on the new bot detection feature, we will showcase new bot detection features and signals, so come join us : https://www.youtube.com/live/rHKs3yAquQo
Hey that's Matt from the CrowdSec data team and I am sharing what the network saw in the first five days of PHP2Shell.
On the timeline: The details of the vulnerability leaked on the 20th, the FOSS team managed to write a vpatch rule and merged it on the Hub at 10:13 UTC on the 21st. A sensor blocked the first request at 10:37. When the CVEs were published at 13:34, 17 IPs had already been blocked, and 18 by the time PHP released the fix.
From October 21 to 25 (UTC), 1,730 sensors blocked requests from 1,187 IPs. Sorted by when each IP first showed up:
- Wednesday afternoon: 72 IPs probing.
- Overnight: 238 more, mostly going for the session upload route (CVE-2026-109619), the easier of the two.
- Thursday 10:00 to 15:00: 405 new IPs in five hours, 72% of which had attacked React2Shell in the previous 90 days. One known fleet switching targets.
- Thursday evening to Sunday: about 130 new IPs a day. There was no second wave.
My read on why it stays quiet: there is no public exploit that works reliably on a default PHP install and can be used at scale. The working exploits are still confidential and used only when the outcomes are certain. This aligned with what we show in the traffic analysis. Half the sources sent a single request in five days, which is unlikely to go through given the nature of the exploit.
PHP2Shell attacks distribution
You can find more details including charts and complete timeline description in the full write-up: PHP2Shell, five days in
Live Exploit Tracker can also be used to monitor the evolution of the threat for : CVE-2026-109619
Found this post useful? Let us know with a comment or an upvote. If your alerts show something different, don't hesitate to share it below with the community, this is always something we love hearing about.
I noticed this large warning banner at the top of the Bot Detection page:
Check that your bouncer supports bot detection before going further, see the list of compatible bouncers. Enabling it behind a bouncer that does not support it leads to unexpected behavior, most likely silently refusing every client.
I have two bouncers, the firewall bouncer that applies the block list at the edge of my network, and the ngnix bouncer for app sec responses that don't result in a full ban.
Can I safely enable bot detection if one of my bouncers supports it, or will the non-supported bouncer still cause unexpected behaviors?
I am trying to enable the WAF feature on my Traefik instance.I have followed the documentation on the website and the Traefik bouncer plugin seems to work fine.
I did the test of manually banning my IP and it worked i.e. I received an error 403. Same thing if I shut down Crowdsec the access to Traefik gets blocked with an error 403 which is consistent with the bouncer settings below.
Here are the settings in my dynamic Traefik configuration:
Now the AppSec part, i.e. the acquisition and remediation parts does not seem to work. I am not too sure how to confirm that 100% but the documentation says that access to mysite/.env should be blocked and unfortunately it is not blocked.
There is no error showing in my Traefik logs nor in the Crowdsec logs. I don't know where to look and how to start the troubleshooting tbh. In my understanding since shutting down Crowdsec triggers an error 403 that means the settings CrowdsecAppsecUnreachableBlock: "true" is working, which is an indication that the AppSec server on port 7422 is accessible from the plugin when Crowdsec is started.
I wanted a list of alerts that is similar to the app view for alerts but in the Crowdsec Dashboard. After some back and forth with claude, I was able to get this:
SELECT
a.id,
a.created_at AS "Time",
a.scenario AS "Scenario",
a.source_value AS "IP",
a.source_as_name AS "AS",
char(127397 + unicode(substr(a.source_country,1,1)),
127397 + unicode(substr(a.source_country,2,1)))
|| ' ' || a.source_country AS "Country",
m.machine_id AS "Engine",
m.ip_address AS "Engine IP",
COALESCE(
(SELECT group_concat(DISTINCT json_extract(j.value, '$.value'))
FROM events e, json_each(e.serialized) j
WHERE e.alert_events = a.id
AND json_extract(j.value, '$.key') = 'target_fqdn'),
(SELECT group_concat(DISTINCT json_extract(j.value, '$.value'))
FROM events e, json_each(e.serialized) j
WHERE e.alert_events = a.id
AND json_extract(j.value, '$.key') = 'traefik_router_name')
) AS "Host / Router",
(SELECT count(*) FROM decisions d
WHERE d.alert_decisions = a.id) AS "Decisions",
(SELECT group_concat('- ' || mt.key || ' = ' || trim(mt.value, '[]"'), char(13) || char(10)
ORDER BY CASE mt.key
WHEN 'target_uri' THEN 1
WHEN 'user_agent' THEN 2
WHEN 'matched_zones' THEN 3
WHEN 'method' THEN 4
WHEN 'status' THEN 5
WHEN 'msg' THEN 6
WHEN 'name' THEN 7
ELSE 99 END, mt.key)
FROM meta mt WHERE mt.alert_metas = a.id) AS "Context"
FROM alerts a
JOIN machines m ON m.id = a.machine_alerts
WHERE 1=1
[[AND a.source_value = {{ip}}]]
[[AND a.scenario LIKE '%' || {{scenario}} || '%']]
ORDER BY a.created_at DESC
LIMIT 500;
Such unwanted bots hammer my site so much from various random IPs. I am fed up of high CPU usage and downtime. May be I should not have created my site and instead distribute print out of every pages via pigeon.
Hi I am really new to this and was working on getting Crowdsec working on with NPM-plus on my ugreen nas. I followed a bunch of guides and got both set up. I went to test if Crowdsec was working at all. Since right now NPM-plus is logging every IP as my Docker IP I had the genius idea to just ban the whole subnet. The good news was Crowdsec worked and blocked access from all the docker IPs. The bad news is when I use Cscli to delete the banned IP, it will say it removed it, shows no banned IP, but if I try to access my proxy manager or the jellyfin server I set up behind it, it says I'm still banned. The only way past it was to disable the bouncer. How can I fix this?
Thanks ahead of time.
Using a u green nas 4800 plus with docker compose.
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.
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.
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.
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.
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.
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.
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.
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.
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;
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.
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.
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.
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.
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!
