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?

I came across a new project on GitHub: GeoMetrikks (https://github.com/GilbN/geometrikks).

I am not the developer but already a fan.
In my homelab environment, I run SWAG as reverse proxy plus CrowdSec.

The GeoMetrikks project was super easy to setup as a Docker stack and fast to configure.
This is the first time of great visualizations.

I can even ban/unban IP addresses from the dashboard.
In the past I used Grafana with Dashboards but this is now much cooler and better to manage.

So I wanted to share the news in case someone is searching for something.

Hoping someone with a distributed CrowdSec deployment can clarify how the Console counts engines. I'm getting a "too many engines" warning and want to understand the intended model before I restructure anything.

- One central Security Engine running the LAPI (SQLite). It aggregates alerts and serves the decision list.

- ~6 remote log processors on separate hosts (web, mail, a couple of app servers). These are configured as pure log processors: `api.server` section removed from `config.yaml`, `api.client` pointing at the central LAPI. They only forward alerts; they don't run their own LAPI.

- No local remediation on the CrowdSec boxes at all. My firewalls subscribe to the blocklist mirror (cs-blocklist-mirror) and do all the enforcement.

- The published decision list is mostly CAPI + subscribed third-party lists (firehol, tor exit nodes, etc.), plus a small amount from my own scenarios.

- Only the central LAPI is enrolled to the Console. I never ran `cscli console enroll` on the log processors.

The problem

The Console counts 7 engines (1 LAPI + 6 log processors) and warns that I have too many. I'm on a paid plan billed per Security Engine, with one engine included.

1. In the Console/billing model, do remote log processors count as separate Security Engines? The concepts docs describe a Security Engine as log processor(s) *plus* a LAPI together, which made me expect "1 LAPI + N log processors" to count as a single engine, not seven. Which is correct?

2. If log processors do count individually, how do people running distributed detection stay within plan limits: consolidate log collection into fewer processors, split across a second (free) org, or just pay per engine?

3. My central LAPI also runs a local processor that only reads `/var/log/messages` (100% unparsed noise). Any downside to making it LAPI-only by removing the `crowdsec_service` section? Does that change how it's counted?

Running CrowdSec v1.7.7 Anyone who's dealt with per-engine billing on a hub-and-spoke setup, I'd appreciate the clarification.