Robots.txt is a sign that says “please don’t” in a language only polite people read. It has worked exactly as well as you’d expect for thirty years. Unfortunately, defending yourself against bots that are unwilling to comply is something that is notably hard, and even more so if you don’t have thousands of dollars and the willingness to give up privacy.

But fear not, CrowdSec comes in to save the day as CrowdSec 1.8 ships bot protection!

What the challenge actually does

Bot detection ships inside CrowdSec’s WAF. While the WAF itself focuses more on virtual patching, CVE rules, and generic attack signatures (see  Open-Source WAF for Nginx on Ubuntu with CrowdSec), we will focus purely on the bot detection feature.

The bot detection answers one question: what is on the other end of the wire, a real browser or a script wearing one as a costume? It does that with a proof-of-work and device-fingerprint page in front of your app, in four beats:

1. A request arrives with no valid challenge cookie. Instead of your page, the engine serves a small challenge page.
2. That page runs three things in the browser: the open-source fpscanner fingerprinting library, a proof-of-work puzzle in a worker, and a per-epoch signing module.
3. The browser POSTs the result to /crowdsec-internal/challenge/submit. The engine validates the crypto and the PoW, then scoring rules look at the fingerprint and produce a verdict.
4. A client that passes gets a sealed __crowdsec_challenge cookie and is waved through until it expires (12 hours by default). A client that fails never reaches your origin.

A clarification, because the vocabulary here gets abused: This is not a captcha, nothing for a human to solve; the page solves itself.

Three kinds of clients, and what happens to each

Bots that do not run JavaScript are the easy tier. curl, wget, most scraping frameworks and every “I’ll just parse the HTML” script get the challenge page and stop there.

Naive automation is the second tier. Selenium, Playwright, Puppeteer, and anything driven over the Chrome DevTools Protocol will happily solve the proof of work (the PoW is only the ticket to the fingerprint check, which is where the filtering happens). They get caught on a declared-automation signal instead. All the fingerprints that are collected in the browser award scores, and if your score gets too high, you’re rejected. As an example, cdp, webdriver, selenium, playwright, and bot_user_agent are each worth 100 points on their own, which clears every shipped threshold.

The third tier is automation that knows all this and tries to hide those flags. This is the tier people write off, and the default config still catches a fair share of it. Hiding obvious flags gets you past two signals out of about two dozen, and the environment still has to hold up.

Does this make the barrier disappear? No. Nothing does. A patient adversary running a real browser on real hardware at a human pace is the case nobody solves, at any price, from any vendor. What you get is cost: their per-request budget goes up, and the cheap end of the scraping market (which is most of it) stops being profitable against you.

Setting it up on Nginx

Let’s start from an Ubuntu box that already serves something with nginx, and nothing else.

1. Install the engine.

curl -s https://install.crowdsec.net | sudo sh
sudo apt-get install -y crowdsec

The installer runs cscli setup for you, which detects your running services and wires the log acquisition on its own. On this box, it found nginx, sshd, postfix, and haproxy and installed the matching collections. That side of things is a happy accident here: we came for the bot challenge and got the log-based detection thrown in.

2. Install the bot challenge collection.

sudo cscli collections install crowdsecurity/appsec-bot-challenge

Three bundles ship, and they differ only in where they draw the line:

Install only one of them: if you install two, the strictest one silently wins.

3. Point a WAF listener at it. Create /etc/crowdsec/acquis.d/appsec.yaml:

listen_addr: 127.0.0.1:7422
appsec_configs:
  - crowdsecurity/appsec-bot-*
labels:
  type: appsec
source: appsec

Such a config carries only the bot-detection, which is what the second line below is telling you:

level=info msg="Loaded 0 inband rules" component=appsec_config
level=info msg="WAF challenge runtime initialized" cookie_ttl=12h0m0s max_cookie_len=4096 module=challenge pow_difficulty=20 rotation_interval=5m0s

WAF challenge runtime initialized is the line you want.

4. Install the bouncer.

sudo apt-get install -y crowdsec-nginx-bouncer

The package registers its own bouncer and key, drops the lua snippet into /etc/nginx/conf.d/, and reloads nginx. Then point it at the WAF:

sudo sed -i 's|^APPSEC_URL=.*|APPSEC_URL=http://127.0.0.1:7422|' \
    /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf
sudo nginx -t && sudo systemctl restart nginx

That is the whole wiring.

Does it work?

Ask curl, the most honest bot you have on hand:

/                            200  293950 bytes   -> challenge page
/style.css                   404  162 bytes      -> origin page
/robots.txt                  404  162 bytes      -> origin page

Key points:

• 200 with a 290 KB body means you are looking at the challenge page. The engine answers the bouncer with an envelope, and the bouncer renders the page inside it with the status the envelope asks for.
• /style.css and /robots.txt skipped the challenge entirely. The collection ships path exclusions for static assets, crawler files, feeds, API paths, and webhooks.

Now point an automated browser at it. Anything CDP-driven does the job: Puppeteer, Playwright, or a Chrome started with --remote-debugging-port. It solves the puzzle, submits, and:

level=info msg="on_challenge_submit rejected" automation=true is_bot=true \
  reason="request score 100" signals="[cdp]" source=203.0.113.7 \
  timezone=Europe/Paris url="http://198.51.100.10/no-bots-please/"
level=info msg="WAF bot-detection: 203.0.113.7 rejected by crowdsecurity/rejected-browser-submission (request score 100)"

Key points:

• signals="[cdp]" is the whole story: the Chrome DevTools Protocol was live in that browser, which is worth 100 points on its own.
• reason="request score 100" against a balanced threshold of 75, so the submission is refused and no cookie is issued.
• automation=true and is_bot=true are the engine’s summary flags.

The nginx access log shows the same thing from the other side, and it is the clearest picture of the protocol:

"GET /no-bots-please/ HTTP/1.1" 200 139306
"GET /crowdsec-internal/challenge/fpscanner.js HTTP/1.1" 200 36328
"GET /crowdsec-internal/challenge/pow-worker.js HTTP/1.1" 200 7544
"POST /crowdsec-internal/challenge/submit HTTP/1.1" 200 32

In layman’s terms: the bot got the challenge page, downloaded the fingerprinting library and the PoW worker, did the work, submitted, and got 32 bytes of rejection JSON back. There is no fifth line. It never reached the page.

The alert lands with kind set to bot-detection:

| ID | value           | reason                                    | decisions | kind          |
| 2  | Ip:203.0.113.7  | crowdsecurity/rejected-browser-submission |           | bot-detection |

The decisions column is empty on purpose. One rejection records the catch without banning anyone, which is the right default: a single odd fingerprint is weak evidence. Keep the bot running, and crowdsecurity/appsec-bot-challenge-too-many-submissions fills up (5 submissions in 20 seconds) and turns it into a real decision. A human browser solves once, takes its cookie, and stops submitting, so it never goes near that bucket.

sudo cscli metrics show bot-detection

| Bot Detection   | Requested | Submitted | Solved | Granted | Exempt | Submissions Rejected |
| 127.0.0.1:7422/ | 3         | -         | -      | -       | 2      | -                    |

How CrowdSec bot detection compares to the commercial anti-bot vendors

Let’s be fair about the starting position: Cloudflare, Akamai, DataDome, and the rest have been doing anti-bot for years, and we are the newcomers in this particular field.

However, we have a couple of hundred thousand CrowdSec installations sitting on a couple of hundred thousand different networks, each an independent vantage point, each reporting what actually hit it into a pool everyone pulls from. When a scraper works its way down a list of targets, the ones it reaches later already know about it.

Tenure is worth less in 2026 than it used to be, though. Detection and evasion are being rewritten on a much shorter cycle now, with the same tooling on both sides, so a long head start matters less than how fast you can change your own rules. Which brings us to the part that separates these products.

With a managed vendor, the thing deciding whether your visitor is a human is a black box you rent. You get a dashboard, a sensitivity slider, and a score you cannot audit. When it is right, fine. When it is wrong, you file a ticket.

With CrowdSec, the scoring is a file you can cat:

# /etc/crowdsec/appsec-configs/appsec-bot-challenge-scoring.yaml
- filter: EvaluateMismatches().Has("cdp")
  apply:
    - AddRequestScore(100, "cdp")

And the threshold that acts on it is four lines:

name: crowdsecurity/appsec-bot-challenge-scoring-balanced
inband:
  on_challenge_submit:
    - filter: RequestScore() >= 75
      apply:
        - 'RejectSubmission("request score " + string(RequestScore()), "verbose")'

That is the entire decision. Read it, diff it, change it. I would rather argue with a YAML file than with a support queue.

A few concrete things follow from that:

• Your users’ traffic stays on your infrastructure. A cloud anti-bot service is a reverse proxy: it terminates TLS, so every request body, cookie, and credential your users send transits a third party in the clear on their side. CrowdSec computes the fingerprint in the browser and scores it in the engine on your own box, and nothing about your visitors leaves your infrastructure for that decision to be made.
• False positives are debuggable. Block a legitimate visitor, and score_reasons on the alert tells you which signals fired and what each was worth. You re-weight the offending one yourself in about four lines, rather than reporting it upstream and waiting.
• Cost does not scale with the attack. Per-request pricing has an awkward property: your popularity with the wrong people increases your bill. Metering differs by vendor and by plan, so the arithmetic is yours to do, and the shape holds either way: your bill tracks their volume. Self-hosted costs you some CPU on a box you already pay for.
• Leaving is an apt purge. DNS-layer onboarding is great until the day you want to move, at which point your exit is a DNS migration. Here, it is uninstalling a package.

However, self-hosting means you own the tuning. If your threat model is a 2 Tbps DDoS, buy the CDN. If it is scrapers, credential stuffing, scalpers, and AI crawlers eating your content, you can do this yourself, on your own terms, for free.

Going further

Out of the box, every request gets challenged, which might not be what you want.

Nearly all of it is one custom appsec-config. Write yours under /etc/crowdsec/appsec-configs/, and list them by name in your acquisition: the crowdsecurity/appsec-bot-* glob does not match your namespace.

Challenge only the part of the site that matters

Invert the problem and exempt everything except the funnel you care about.

name: mycorp/appsec-bot-challenge-path-scope
inband:
  pre_eval:
    - filter: >-
        !(req.URL.Path startsWith "/no-bots-please/")
      apply:
        - ExemptFromChallenge("outside-protected-path")

Swap the path for whatever actually matters on your site.

Per host works the same way with req.Host, though proxies sometimes forward foobar.com:443 rather than the bare host, so prefer startsWith or endsWith ".foobar.com".

Check your work with the exempt counters, which break down by reason:

| Bot Detection — Exempted                         |
+-----------------+------------------------+-------+
| Appsec Engine   | Reason                 | Count |
+-----------------+------------------------+-------+
| 127.0.0.1:7422/ | googlebot              | 1     |
| 127.0.0.1:7422/ | outside-protected-path | 24    |
| 127.0.0.1:7422/ | static                 | 1     |
+-----------------+------------------------+-------+
| Total           |                        | 26    |

Twenty-four requests skipped the challenge for sitting outside the protected path; one was a verified crawler, and one a static asset.

Let your own bots through

Your uptime monitor, your internal crawler, your partner’s integration. MatchKnownBot checks a JSON definition file, and its rule is deliberately strict: (user-agent matches AND at least one path matches) AND (exact IP OR CIDR range OR forward-confirmed reverse DNS).

{"name":"mybot","user_agent":"mycorp-monitor","paths":["^/health(/|$)"],"ranges":["10.42.0.0/16"],"ips":["192.0.2.77"]}

name: mycorp/appsec-bot-challenge-known-bot
inband:
  pre_eval:
    - filter: MatchKnownBot(req.RemoteAddr, req.UserAgent(), req.URL.Path, "legit_bots/mybot.json")
      apply:
        - ExemptFromChallenge("mybot")
data:
  - source_url: https://example.com/mybot.json
    dest_file: legit_bots/mybot.json
    type: bots

The data: block is not optional even when you place the file yourself: only declared files get registered in the datafile registry. A definition carrying only a user-agent, with no IP, range, or rDNS, is rejected outright at load. A user-agent proves nothing at all.

This is how the shipped good-bot exclusions work too. The googlebot definition carries no IP list at all:

{"name":"googlebot","user_agent":"googlebot","rdns":["(^|\\.)googlebot\\.com$"]}

Everything rests on forward-confirmed reverse DNS: resolve the IP to a name, resolve that name back, check they agree. A scraper setting User-Agent: Googlebot/2.1 from a random VPS gets challenged like everyone else. Anchor your own rDNS patterns the same way, or evilgooglebot.com will match.

Waive the challenge for a specific user

For an authenticated session or an internal probe, GrantChallengeCookie hands out the cookie directly rather than exempting a single request:

name: mycorp/appsec-bot-challenge-internal-probe
inband:
  pre_eval:
    - filter: req.Header.Get("X-Internal-Probe") == "s3cr3t" && req.RemoteAddr startsWith "10."
      apply:
        - GrantChallengeCookie("internal-probe", "24h")

The client gets a 307 back to where it was going, carrying the cookie. Note that a shared-secret header on its own is a bypass token from the moment it leaks, so this is a purely technical example.

Re-weight the scoring for your own traffic

Every signal’s value is a line in a YAML file, so tune it for the audience you actually have:

name: mycorp/appsec-bot-challenge-reweight
inband:
  on_challenge_submit:
    # A UTC-only audience is unusual for us, so treat it as stronger evidence.
    - filter: EvaluateMismatches().Has("utc_timezone")
      apply:
        - AddRequestScore(45, "utc_timezone_mycorp")
    # We are mobile-first, so a mobile UA mismatch is expected noise.
    - filter: EvaluateMismatches().Has("ua_mobile")
      apply:
        - AddRequestScore(-15, "ua_mobile_expected")

Scores can go negative, and you can add evidence the fingerprint cannot see, such as a checkout hit with no Referer.

Load order is not cosmetic here. RejectSubmission() is terminal: it halts every remaining on_challenge_submit rule. So your re-weighting has to load after the scoring engine and before the threshold config, which means listing them explicitly instead of leaning on one glob:

listen_addr: 127.0.0.1:7422
appsec_configs:
  - crowdsecurity/appsec-bot-challenge-exclude-*
  - mycorp/appsec-bot-challenge-path-scope
  - mycorp/appsec-bot-challenge-known-bot
  - mycorp/appsec-bot-challenge-internal-probe
  - crowdsecurity/appsec-bot-challenge-scoring
  - mycorp/appsec-bot-challenge-reweight
  - crowdsecurity/appsec-bot-challenge-scoring-balanced
labels:
  type: appsec
source: appsec

The quickest way to convince yourself is to break it on purpose. Drop a temporary rule subtracting 60 points from cdp, then send the same CDP browser that scored 100 and got rejected earlier. 100 - 60 = 40, comfortably under the balanced threshold of 75:

"GET /no-bots-please/ HTTP/1.1" 200 140417     ← challenge page
"POST /crowdsec-internal/challenge/submit HTTP/1.1" 200 25     ← accepted
"GET /no-bots-please/ HTTP/1.1" 200 231        ← the real page

| Bot Detection   | Requested | Submitted | Solved | Granted | Exempt |
| 127.0.0.1:7422/ | 4         | 1         | 1      | 1       | 3      |

Same browser, same box, one config file moved into one position, opposite verdict. Solved: 1, cookie issued, origin page delivered in 231 bytes.

Where this is at

Bot detection is marked alpha upstream; however, it works, it is in 1.8.0, and we run it.

The scoring rules are hub content, so they are only as good as what the community feeds back into them. Found a signal that misfires on your traffic, or a bot family that walks straight through? That is a useful bug report: open an issue on the Hub, or hop onto our Discord and tell us what you are seeing. We would rather fix a signal than ship a slider. 🙂

As the holidays are ending for most of us, it’s time for us to showcase what we’ve been cooking: CrowdSec 1.8 and more!

WAF: Bot Detection 

Your average bot in 2026 has a real Chrome with a consistent TLS fingerprint, a residential IP, and a lot more patience than your on-call engineer: According to most metrics, it’s a more exemplary user than your actual users. That’s why it’s tricky: blocking bots is easy, but not your users.

That’s why we’re bringing bot detection to CrowdSec’s WAF! This is something that we’ve been contemplating for a while, have worked on for the past 6 months, and can finally release.

What it actually means is that the WAF can now not only react to “what the user does” but also to “what the user is”: a human and a browser, or a bot pretending to be one. For a legitimate user, this is solved transparently, while an automated client cannot cheaply fake it.

Our approach combines several techniques, most notably fingerprinting and proof of work: it forces the attacker to play on the anti-detection side, but also stack compute cost on top of it, raising the economics of botting.

From a use-case perspective, it’s an efficient way to deal with distributed attacks, scraping, scalping, and generally any kind of aggressive automation.

To ensure a production-ready approach, it comes with sets of allowlists and exclusions to avoid blocking legitimate bots that cannot solve such challenges, while also providing the usual fine-grained configuration to solve more edge cases that one might encounter – support for Web Bot Authentication is also planned. While provided baselines should deal with most common bots, the operator can easily implement its own detection patterns, relying on weak signals and various anomalies to deter specific bots targeting you.

It’s already compatible with the latest nginx/openresty release; haproxy is imminent, and we’re waiting on traefik and envoy releases. The goal is to have it supported by all major web bouncers; it’s just a small step for those already supporting the WAF feature. In terms of deployments, we tried our best to make it industrialization-friendly, with multi-tenancy support and a good amount of observability.

You can find everything here.

Dedicated Kubernetes datasource

Previously, our Kubernetes users had to deploy multiple CrowdSec instances as a daemonset to monitor their infrastructure. This led to various undesired side-effects, mostly as a result of the induced complexity. The new datasource talks directly to the Kubernetes API, following pods/logs for pods matching the given selector, allowing users to deploy a single CrowdSec instance to monitor multiple pods.

This will hopefully make both the build, the run, and the architecture of CrowdSec’s Kubernetes deployments a lot easier and cheaper.

You can find more here.

Bouncer to LAPI optimisation

We made significant optimisations to the interaction between the Local API and the bouncer to improve performance of decision synchronization. 

For example, on a setup with 1M alerts and 10 bouncers, time spent reduction ranges from x600 (MySQL) to x13 (PgSQL): This aims at better supporting the larger setups that we are seeing more and more often, while also improving the performance for the rest of us.

Console: new alerts page

The console’s alert page is one of the most used features of the console – as it’s available to all tiers of users. We’re bringing a very significant revamp of this page to help our users make the most out of it:

• Leveraging IP reputation in signals allows you to easily cut through the noise and isolate outliers.
• IP grouping and merging allow you to get a better overview of activity without having to look at detailed alerts.
• Detailed breakdown to explore data via any angle of the alert, from scenario to targeted asset to IP reputation.
• Save views to create shortcuts to your relevant alerts to streamline recurrent workflows.

CrowdSec skill

Although technically not tied to this CrowdSec release, we continue to expand our crowdsec skill : all of CrowdSec’s knowledge at your LLM’s fingertips!

Closing word

By the time you’re reading this blog post, *nix packages, Docker images, and Helm charts should already be available; Windows packages, {opn,pf}sense are on their way (keep in mind some of those require 3rd-party validation).

Don’t be a stranger; drop on Discord to ask for help or report bugs,

Happy hacking 🦙

Sometimes, a setup can go wrong. A bouncer that installs cleanly but never blocks a thing, or a parser that reads zero lines, and you just want the shortest path out. So you do what everyone actually does in 2026: you don’t open the docs, you alt-tab to an LLM and paste the question. Answer in seconds.

And it sounds right. It hands you a packagecloud URL, a cscli command or two, a config path. You copy-paste. Sometimes it works. Sometimes the URL is two years stale, one of those confident flags doesn’t exist, and the config path moved three releases ago. Now you’re debugging the helper on top of the thing you started with.

To be fair to the model: You handed a fast improviser a question with no map, so it did the thing that setup rewards: it improvised. That’s just what you get when you ask someone to recite a manual they were only ever allowed to skim.

So the fix is simple: give it a better map with the CrowdSec Skill.

That’s what a skill is: our own CrowdSec docs, restructured into rails the agent can’t wander off. Context7 and friends already pipe fresh reference into your agent’s context, and that helps, but reference is still something the model has to read and choose to act on. A skill goes further and turns those docs into a procedure: the exact install command, a heads-up on the cscli flags that don’t exist, and a hard rule that it won’t touch your firewall without asking. Auto-generated docs make the model better informed, while skill makes it better behaved.

Last year we shipped an MCP to author and test WAF rules for CrowdSec  (crowdsec-local-mcp), but it seems most people just want the boring part to work: install it, wire a bouncer, stop the probes. MCPs were so 2025, so this time we tried something simpler: a skill.

And building it did something I didn’t plan for: it made our own docs better and improved the release testing process. I’ll come back to that.

What a skill adds to an already powerful model

Models can now hack the planet over a weekend unnoticed and solve 87-year-old mathematical problems while you watch a football match – does it struggle to set up a simple piece of software as CrowdSec? (Spoiler: yes, it did).

I ran the same experiment with a “vanilla” model (Opus 4.8 High) and then with the CrowdSec skill enabled, and here is what changed:

• With the skill, it looked before it leapt. After the initial install, it inspected what service was detected  (nginx, sshd, postfix) and if the logs were correctly ingested and parsed.
• Vanilla model did some very reasonable guessing that ended up being wrong: It reached for /etc/crowdsec/acquis.yaml to add nginx log files monitoring. But the initial setup already detected and monitored those log files, so now they’re read twice, making every scenario twice as sensitive as it should be.
• With the skill, it checked the outcome of its action before declaring victory, because the skill taught him to do so: inspect cscli metrics, run diagnostics, perform proper testing instead of “assuming”.
• Vanilla model failed to properly test if the WAF was correctly configured and curled the AppSec port without the API-key header, declaring it a success prematurely.
• Last but not least, the Vanilla model tried to whitelist itself. It ran cscli decisions add --ip <ip> --type whitelist. The command itself is syntaxically correct and even prints a “Decision successfully added”, but it does nothing: whitelist isn’t a decision type that has any meaning in a default setup.

Long story short: one setup was correct and relied on an actual check to ensure correctness; the other one made reasonable guesses that unfortunately ended up being just wrong enough. You can consider the skill as a loose form of harness – thanks to the feedback loop that cscli verification provides – and domain-specific knowledge in addition to an already powerful model.

The fine line between “reasonable guess” and “improvisation”

As LLMs will never say no, the skill is also a good way to draw limits on what we know the model would get confidently wrong if we didn’t stop it. For example, the skill explicitly states that it doesn’t know how to write WAF rules or scenarios without a significant error margin.

The skill is also a useful place to flag destructive and dangerous actions it shouldn’t attempt. I guess the internet is filled with enough “omg claude deleted database !!11” horror stories that I don’t need to expand on this.

And the best part of it is that a skill is mostly just a bunch of markdown files that dictate how it should behave in a very plain, human language.

The part that helped us, too

Here is the thing we did not expect when we started.

To build this skill, we let Claude run unchained on dedicated VMs, with the actual docs as a bible, and told it to actually do the work: bare-metal, Docker, Kubernetes, OPNsense, with the nginx, haproxy, traefik, and firewall bouncers. Install, wire, break, verify; on real boxes it was free to trash.

We also fed him a thousand or so of support threads from our Discord server as exercises to test its effectiveness.

And it kept tripping over our own documentation.

A command that had quietly changed. A config path that moved two releases ago and got left behind in the docs (that acquis.yaml the plain model reached for earlier? we still had stale references to it too). An approximation that was close enough to read past, but wrong enough to break a copy-paste. A flag that no longer existed. None of these were dramatic. All of them were the small lies that turn a ten-minute setup into a lost afternoon.

Every time the agent hit one, it was a bug report we could not argue with, because there was a broken box sitting right there proving it. So we fixed the docs. Then re-ran. Then fixed the next one.

That is the loop:

   docs  ──►  run live on real VMs  ──►  build the skill
    ▲                                          │
    └──────────  fix the docs  ◄───────────────┘

Our docs were not – are not and never will be perfect. They had the same stale corners and confident approximations that tripped the plain model up in the comparison above. The difference is that we went looking, with a tool relentless enough to find them, and now there are fewer. The skill made CrowdSec easier to install.

Beyond first-time setup

Setup is where I started because it is the wall most people hit first. The same conversation handles the two that come next.

Debug. When things go the wrong way (logs parsed but no alerts, a decision that exists but does not block), you point the agent at it and let it perform exhaustive diagnostics by relying on metrics, cscli support dump and alike.

Tune. The first false positive is a rite of passage, and the tempting fix, disabling a whole collection, trades one problem for a worse one. The skill walks you to the right suppression layer instead (allowlist, whitelist parser, or postoverflow).

Setup is just the starting point. The same principle carries through debugging and tuning: give the model the right procedure, and make it verify its work.

That someone is a WAF, and on Traefik it slots in exactly where the gap is: as one more middleware in the chain. CrowdSec gives you an open-source one, and you can switch it on the safe way first. That safe way is virtual patching, which blocks the specific shapes of known exploits and known-bad paths and leaves everything else untouched. You get real protection immediately, with no tuning required.

This guide takes a Traefik + Docker Compose stack from no request inspection to a working WAF in virtual-patching mode, the safest way to start, because it refuses attacks it can name without ever getting in your users’ way.

Why Traefik needs a WAF of its own

Three reasons this earns a place in your middleware chain.

You are running code you did not write. Traefik almost never sits in front of your own application. It fronts other people’s: a self-hosted dashboard, a vendor’s container, an app built on a framework you pulled from a registry. You cannot add a security library inside software you do not maintain, and you are not going to audit all of it. Traefik is the one place every one of those requests passes through in the clear, which makes it the only practical place to inspect them. A WAF here protects the apps you depend on but do not control.

It closes the gap between a CVE and your upgrade. When a vulnerability in a popular app goes public, mass scanning for it starts within hours, the same internet-wide spray that finds every new host within minutes of it coming online. Your realistic window to read the advisory, test the patch, and roll it out is measured in days. Virtual patching covers that gap: the moment a rule for the exploit’s shape ships, the WAF refuses that request at the edge, whether or not the app behind it is patched yet. You stop racing the scanners and buy the time to upgrade on your own schedule.

Its rules come from a network, not just a file. A classic WAF knows exactly what its own signature set knows, and nothing more. CrowdSec’s is fed by every other engine running it: an IP caught probing someone else’s server becomes an IP yours refuses before it ever reaches your apps, and the same Traefik plugin enforces those community bans in the same pass as the WAF verdict. Your defense gets sharper because everyone else’s is running too, something a lone WAF, however good its rules, cannot do.d, first-party path is gone, and rebuilding a dynamic module against every Nginx release was never anyone’s idea of fun. ModSecurity earned its place; it is not the villain of this story. But if you are choosing a WAF for Nginx in 2026, you want something actively maintained and open source.

What “CrowdSec’s WAF” actually is on Traefik

Two pieces do the work, and it helps to know which is which before you touch a config file.

• The AppSec component is an HTTP server bundled inside the CrowdSec agent. It holds the rules and returns a verdict, allow or block, for any request it is shown. It does not sit inline with your traffic.
• The Traefik bouncer is a middleware plugin (maxlerebourg/crowdsec-bouncer-traefik-plugin), loaded through Traefik’s built-in Yaegi engine, with no separate binary and no sidecar. It intercepts each request, shows a copy to AppSec, and enforces whatever verdict comes back.

client ───▶ traefik ───▶ bouncer plugin ───▶ AppSec (crowdsec:7422)
                         │                    │
                         │          verdict ◀─┘
                         ▼
                    allow (200) / block (403)

Key points:

• AppSec is the brain, the plugin is the muscle. AppSec never blocks anything itself; the plugin does.
• The verdict round-trip stays on the Docker network, so it costs microseconds, not an internet hop.
• The same plugin that enforces WAF verdicts also enforces IP bans from CrowdSec’s community blocklist. One middleware, two jobs.
• The plugin speaks the same protocol to the same AppSec component that the Nginx, HAProxy, Caddy, and Envoy bouncers do, so the WAF rules and verdicts are identical whatever proxy you run.

Full reference: the AppSec component docs.

Prerequisites

• A host with Docker and the Compose plugin.
• Outbound HTTPS to the CrowdSec hub (rules) and api.crowdsec.net (community signals).

That is the whole list. No database to stand up, no proxy rearchitecting; the WAF slots in as one more middleware.

Step 1 — Stand up CrowdSec next to Traefik

The whole stack is one Compose file: the CrowdSec agent (which carries the WAF), Traefik, and a whoami container as the app to protect.

# docker-compose.yml
services:
  crowdsec:
    image: crowdsecurity/crowdsec:v1.7.8
    container_name: crowdsec
    restart: unless-stopped
    environment:
      COLLECTIONS: "crowdsecurity/appsec-virtual-patching crowdsecurity/appsec-generic-rules"
      BOUNCER_KEY_traefik: "${BOUNCER_KEY_TRAEFIK}"
    volumes:
      - ./acquis.d:/etc/crowdsec/acquis.d
      - crowdsec-config:/etc/crowdsec        # persist config, credentials, Console enrollment
      - crowdsec-data:/var/lib/crowdsec/data
    networks: [web]

  traefik:
    image: traefik:v3.5
    container_name: traefik
    restart: unless-stopped
    depends_on: [crowdsec]
    ports: ["80:80"]
    volumes:
      - ./traefik.yml:/etc/traefik/traefik.yml:ro
      - ./dynamic:/etc/traefik/dynamic:ro
      - traefik-plugins:/plugins-storage
    networks: [web]

  whoami:
    image: traefik/whoami:latest
    container_name: whoami
    restart: unless-stopped
    networks: [web]

networks:
  web:
volumes:
  crowdsec-config:
  crowdsec-data:
  traefik-plugins:

Two lines in the crowdsec service do the heavy lifting. COLLECTIONS installs the virtual-patching rule sets on first boot. BOUNCER_KEY_traefik mints a fixed API key for the plugin, so it authenticates on start with no manual key copying. Pick any long random string and set it in a .env file next to the Compose file:

echo "BOUNCER_KEY_TRAEFIK=$(openssl rand -hex 24)" > .env

Tell the AppSec component to listen, in acquis.d/appsec.yaml:

# acquis.d/appsec.yaml
appsec_config: crowdsecurity/appsec-default
labels:
  type: appsec
listen_addr: 0.0.0.0:7422
source: appsec

Bring it up and confirm AppSec is listening:

$ docker compose up -d
$ docker compose logs crowdsec | grep Appsec
crowdsec | Appsec listening on 0.0.0.0:7422
$ docker exec crowdsec cscli metrics show appsec
 Appsec Engine | Processed | Blocked
 0.0.0.0:7422/ | 0         | 0

Key points:

• Install both collections together. crowdsecurity/appsec-default draws on rules from appsec-virtual-patching and appsec-generic-rules; the pair gives you the complete virtual-patching set.
• AppSec binds 0.0.0.0:7422, not 127.0.0.1. Loopback inside the CrowdSec container is unreachable from the Traefik container; they only share the web network. The listener is not published to the host, so it is not exposed outside Docker.
• Persist both volumes. crowdsec-data holds the decisions and alerts database; crowdsec-config holds /etc/crowdsec, where your API credentials and Console enrollment live. Leave the config volume out and a docker compose down drops the enrollment, so you re-enroll after every recreate.
• At this stage CrowdSec detects. It does not yet block anything reaching Traefik; that is the plugin’s job, next.

Step 2: Load the plugin and wire the middleware

Register the plugin in Traefik’s static config, and trust the proxy hop so Traefik keeps the real client IP:

# traefik.yml (static)
entryPoints:
  web:
    address: ":80"
    forwardedHeaders:
      trustedIPs:
        - "172.16.0.0/12"      # the Docker network / any LB in front of Traefik

experimental:
  plugins:
    bouncer:
      moduleName: github.com/maxlerebourg/crowdsec-bouncer-traefik-plugin
      version: v1.6.0

providers:
  file:
    directory: /etc/traefik/dynamic
    watch: true

Then define the middleware (and attach it to a router) in the dynamic config:

# dynamic/middlewares.yml
http:
  routers:
    whoami:
      rule: "PathPrefix(`/`)"
      entryPoints: [web]
      service: whoami
      middlewares: [crowdsec]        # every request is screened by the WAF

  services:
    whoami:
      loadBalancer:
        servers:
          - url: "http://whoami:80"

  middlewares:
    crowdsec:
      plugin:
        bouncer:
          enabled: true
          crowdsecMode: stream               # poll the decision list (prod default)
          updateIntervalSeconds: 10          # a fresh ban lands within this window
          crowdsecLapiScheme: http
          crowdsecLapiHost: crowdsec:8080    # LAPI, over the Docker network
          crowdsecLapiKey: ""   # == BOUNCER_KEY_traefik above
          crowdsecAppsecEnabled: true        # turn ON the inline WAF
          crowdsecAppsecHost: crowdsec:7422  # the AppSec listener
          forwardedHeadersTrustedIPs:
            - "172.16.0.0/12"

Reload Traefik (or let the file provider pick it up, since watch: true) and confirm the plugin registered as a bouncer:

$ docker exec crowdsec cscli bouncers list
 Name    Valid  Type                             Version  Auth Type
 traefik  ✔️     Crowdsec-Bouncer-Traefik-Plugin  1.5.0    api-key

Prove the enforcement path works before trusting the WAF with anything. Ban an IP, wait one stream interval, and present it as the forwarded client:

$ curl -s -o /dev/null -w 'before ban: %{http_code}\n' -H 'X-Forwarded-For: 192.168.1.142' http://127.0.0.1/   # 200
$ docker exec crowdsec cscli decisions add --ip 192.168.1.142 --duration 5m --reason test
$ curl -s -o /dev/null -w 'after ban:  %{http_code}\n' -H 'X-Forwarded-For: 192.168.1.142' http://127.0.0.1/   # 403
$ curl -s -o /dev/null -w 'clean IP:   %{http_code}\n' -H 'X-Forwarded-For: 192.168.1.1'  http://127.0.0.1/   # 200
$ docker exec crowdsec cscli decisions delete --ip 192.168.1.142

200 → 403 → 200, and an unrelated IP stays 200. The plugin is live and enforcing decisions.

Key points:

• crowdsecLapiKey must equal the BOUNCER_KEY_traefik you set in Compose. Traefik’s file provider does not expand environment variables, so this one is a literal.
• crowdsecAppsecEnabled defaults to false, so the WAF is off until you set it true. That single line is the difference between an IP-ban bouncer and a WAF.
• crowdsecMode: stream means the plugin polls the full decision list every updateIntervalSeconds and answers locally. A fresh ban lands within that window, so a ban-then-curl with no pause looks like a miss when it isn’t.

Step 3: What virtual patching is doing for you

The WAF is already on: crowdsecAppsecEnabled: true plus the two collections is the whole switch. Here is what it turned on.

Virtual patching blocks requests that match specific, known-bad shapes: the query string of a published CVE exploit, a POST to a management endpoint for software you don’t even run, an injection payload that only a scanner would ever send. These patterns have no legitimate reason to appear in your traffic, so the false-positive risk is close to zero. You are not guessing whether a request is malicious; you are recognizing an exploit you already know by name. That is what makes it the safe first move: turn it on in blocking mode on day one and sleep fine.

Step 4: Prove it blocks real attacks

Nothing exotic here. These are the exact paths scanners try on every host: a peek at a leaked /.env, a grab for /.git/config, an Exchange RCE probe. Each is a plain curl, so you can run them yourself.

One wrinkle: to make CrowdSec record the attacks, not just answer them with a 403, the source has to look like a public IP, because CrowdSec whitelists private and loopback ranges by default. Testing from the box itself, you fake that with an X-Forwarded-For header (Traefik trusts it thanks to the entrypoint config from Step 2); from a separate machine you would not need to.

IP=192.168.1.42   # any non-whitelisted address
curl -s -o /dev/null -w '%{http_code}  .env\n'       -H "X-Forwarded-For: $IP" http://127.0.0.1/.env
curl -s -o /dev/null -w '%{http_code}  git\n'        -H "X-Forwarded-For: $IP" http://127.0.0.1/.git/config
curl -s -o /dev/null -w '%{http_code}  exchange\n'   -H "X-Forwarded-For: $IP" 'http://127.0.0.1/autodiscover/autodiscover.json?a=powershell'
curl -s -o /dev/null -w '%{http_code}  benign\n'     -H "X-Forwarded-For: $IP" http://127.0.0.1/

403  .env
403  git
403  exchange
200  benign

Three refused, one allowed. Send each bad request a few more times (scanners never knock once), then read the WAF’s own counters:

$ docker exec crowdsec cscli metrics show appsec
 Appsec Engine | Processed | Blocked
 0.0.0.0:7422/ | 11        | 9

 Rule ID                             | Triggered
 crowdsecurity/vpatch-CVE-2022-41082 | 1
 crowdsecurity/vpatch-env-access     | 4
 crowdsecurity/vpatch-git-config     | 4

Each block is attributed to the exact rule that caught it. Now look at what CrowdSec recorded:

$ docker exec crowdsec cscli alerts list
 value           | reason                              | kind     | decisions
 Ip:192.168.1.42 | crowdsecurity/vpatch-git-config     | waf      |
 Ip:192.168.1.42 | crowdsecurity/vpatch-env-access     | waf      |
 Ip:192.168.1.42 | crowdsecurity/appsec-vpatch         | crowdsec | ban:1
 Ip:192.168.1.42 | crowdsecurity/vpatch-CVE-2022-41082 | waf      |

Two things happened at once, and this is where CrowdSec pulls ahead of a plain WAF:

1. kind: waf: each malicious request was refused on the spot with a 403. That is virtual patching doing its job, per request.
2. kind: crowdsec with ban:1: because the same IP kept probing, a CrowdSec scenario aggregated the behavior and banned the address outright. The next request from that IP, to any path, is refused before the WAF even looks at it.

$ docker exec crowdsec cscli decisions list
 Source   | Scope:Value     | Reason                      | Action | Expiration
 crowdsec | Ip:192.168.1.42 | crowdsecurity/appsec-vpatch | ban    | 3h59m

And the ban is real, enforced by the same plugin:

$ curl -s -o /dev/null -w '%{http_code}\n' -H 'X-Forwarded-For: 192.168.1.42' http://127.0.0.1/   # 403

A classic WAF blocks the request. CrowdSec blocks the request and remembers the attacker.

There is also an official smoke test that ships with CrowdSec: requesting /crowdsec-test-NtktlJHV4TfBSK3wvlhiOBnl trips the crowdsecurity/appsec-generic-test rule so you can confirm the pipeline end to end. The full health-check flow is documented here.

Step 5: See it in the Console

Blocking attacks from the command line is satisfying, but you will want a dashboard, one place to watch alerts across every proxy and server you protect. The CrowdSec Console is that view, and it is free for the community tier.

Enroll this engine (grab a key from app.crowdsec.net → Security Engines → Enroll):

docker exec crowdsec cscli console enroll  --name crowdsec-vm-traefik-waf
docker exec crowdsec cscli console enable context   # richer alert detail for the WAF view
docker restart crowdsec

Then accept the instance in the Console webapp. Enrollment is two-step, and nothing appears until you click Accept.

Key points:

• You enroll the engine, not the bouncer; the Traefik plugin appears in the Console through the engine it reports to.
• cscli capi status confirms the community signal loop: sharing enabled, community blocklist pulling. That blocklist is the payoff of open source: every CrowdSec user’s confirmed attackers become IPs you block before they ever reach Traefik.
• The Console is a lens on data that already lives on your box. Turn it off and the WAF keeps working exactly the same.

Where this leaves you

In a few minutes you went from an unprotected Traefik stack to an open-source WAF that:

• refuses known exploit shapes on sight, with virtually no false-positive risk;
• bans persistent attackers automatically, across every route Traefik serves;
• pulls a community-sourced blocklist so you benefit from attacks aimed at everyone else;
• reports into a single Console dashboard.

Virtual patching is the floor, not the ceiling. It only catches attacks it already knows by name. To catch the ones it doesn’t, the novel injection or the odd traversal, you bring in the OWASP Core Rule Set, and you decide whether to run it inband (block now) or out-of-band (watch first, block once you trust it). That is exactly the false-positive tradeoff virtual patching let you skip, and it is a natural next step from here.

You built all of this with software you can read, audit, and run for free. No black box, no vendor lock, no per-request meter. Just Traefik, refusing the requests that were never meant well.

Full documentation lives at docs.crowdsec.net/docs/appsec, the Traefik plugin is open at github.com/maxlerebourg/crowdsec-bouncer-traefik-plugin, and the rules are on the CrowdSec Hub.

You can refuse that traffic on day one, without deploying a heavy ruleset that trips over your own customers. The approach is called virtual patching: block the exact request shapes of known exploits and leave everything else alone. CrowdSec gives you an open-source WAF that does exactly this, on Nginx and on whatever else you run in front of your apps.

This is the first post in a series on running that WAF on Nginx. Here we take a single Ubuntu box from a bare apt install to a working WAF in virtual-patching mode. It’s the safest way to start, because it blocks known-bad requests without second-guessing legitimate traffic. Later posts add the OWASP Core Rule Set and the things a classic WAF can’t do.

Why a new WAF, and why now

Three reasons to do this now rather than someday.

ModSecurity’s Nginx era is ending. If you have run a WAF on Nginx before, it was probably ModSecurity. F5 ended support for the Nginx ModSecurity WAF module on March 31, 2024. The engine still runs, but the maintained, first-party path is gone, and rebuilding a dynamic module against every Nginx release was never anyone’s idea of fun. ModSecurity earned its place; it is not the villain of this story. But if you are choosing a WAF for Nginx in 2026, you want something actively maintained and open source.

Virtual patching lets you start without fear of false positives. The usual reason people put off a WAF is exactly that fear: a broad ruleset that blocks real customers the day it goes live. Virtual patching sidesteps it. It matches the specific shapes of known exploits and known-bad paths, so legitimate traffic is never in question. You get real protection immediately, with almost nothing to tune. When you want broader, anomaly-based coverage, that’s the OWASP Core Rule Set, which is the subject of the next post. It comes deliberately later precisely because it does need tuning.

It is not tied to Nginx. The WAF logic lives in the CrowdSec agent, not in your web server. A thin bouncer plugs into whatever sits in front of your apps: Nginx and OpenResty here, but equally HAProxy, Traefik, Caddy, or Envoy. Change proxies, or run several at once, and the same rules and the same dashboard follow you. You are not buying into one web server’s plugin ecosystem.

CrowdSec is free and open source: no license key, no trial clock, and nothing metered per request. And it does something ModSecurity never did: every blocked attack becomes a signal the whole community benefits from.

What “CrowdSec’s WAF” actually is

Two pieces do the work, and it helps to know which is which before you start typing commands.

• The AppSec component is an HTTP server bundled inside the CrowdSec agent. It holds the rules and returns a verdict (allow or block) for any request it is shown. It does not sit inline with your traffic.
• The Nginx bouncer is a small Lua module inside Nginx. It intercepts each request, shows a copy to AppSec, and enforces whatever verdict comes back.

client ──► nginx ──► nginx bouncer ──► AppSec (127.0.0.1:7422)
                          │                  │
                          │      verdict ◄───┘
                          ▼
                    allow (200) / block (403)

Key points:

• AppSec makes the decision and the bouncer carries it out. AppSec never blocks anything on its own; the bouncer does.
• The verdict round-trip is local (loopback), so it costs microseconds, not a network hop.
• The same bouncer that enforces WAF verdicts also enforces IP bans from CrowdSec’s community blocklist, so it’s one module doing two jobs.
• We use the Nginx bouncer here. The HAProxy, Traefik, Caddy, and Envoy bouncers speak the same protocol to the same AppSec component, so from Step 3 on, the WAF rules and verdicts are identical whatever proxy you run.

Full reference: the AppSec component docs.

Prerequisites

• An Ubuntu server (we used 24.04/26.04) with Nginx already serving a site.
• Root or sudo.
• Outbound HTTPS to packagecloud.io (packages) and api.crowdsec.net (community signals).

That’s the whole list. You don’t need to stand up a database or rearchitect your reverse proxy.

Step 1 — Install the CrowdSec engine

Add the official repository and install the agent:

curl -s https://install.crowdsec.net | sudo sh   # adds the signed CrowdSec repo

sudo apt install crowdsec

$ sudo cscli version
version: v1.7.8-debian-pragmatic-amd64
Codename: alphaga

The installer runs a setup wizard that detects what is already on the box, Nginx included, and wires up log acquisition for you. You can see it did:

# /etc/crowdsec/acquis.d/setup.nginx.yaml
filenames:
  - /var/log/nginx/*.log
labels:
  type: nginx
source: file

Key points:

• Install from the official packagecloud repo, not Ubuntu’s own crowdsec package, since the distro copy can be years behind.
• The wizard already installed the crowdsecurity/nginx collection, so CrowdSec is parsing your access logs from the first second.
• At this stage CrowdSec detects bad behavior. It does not yet block anything; that’s the bouncer’s job, next.

Step 2 — Install and wire the Nginx bouncer

sudo apt install crowdsec-nginx-bouncer

The package registers itself with the local API and drops its Nginx config in place, with no manual key copying:

$ sudo cscli bouncers list

 Name                               Valid  Auth Type

 crowdsec-nginx-bouncer-1783001915  ✔️     api-key

Prove the enforcement path works before adding any WAF rules. Ban your own loopback for two minutes and watch Nginx start refusing you:

$ curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/          # 200

$ sudo cscli decisions add --ip 127.0.0.1 --duration 2m --reason test

$ curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/          # 403

$ sudo cscli decisions delete --ip 127.0.0.1

$ curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/          # 200

200 → 403 → 200. The bouncer is live and enforcing decisions. Now we give it a WAF to consult.

Step 3 — Deploy the WAF in virtual-patching mode

This is the core of the setup, and the reason to start here rather than with a big generic ruleset.

Virtual patching blocks requests that match specific, known-bad shapes: the URL of a published CVE exploit, a request for /.env, an attempt to read /.git/config. These patterns have no legitimate reason to appear in your traffic, so the false-positive risk is close to zero. You are not guessing whether a request is malicious; you are recognizing an exploit you already know by name. That makes it the safe first move: turn it on in blocking mode on day one and sleep fine.

Install the WAF collections:

sudo cscli collections install \

    crowdsecurity/appsec-virtual-patching \

    crowdsecurity/appsec-generic-rules

Install both together — the default AppSec config draws on rules from each, and the two collections give you the full virtual-patching set (191 rules on our box).

Tell the AppSec component to listen, by creating /etc/crowdsec/acquis.d/appsec.yaml:

appsec_config: crowdsecurity/appsec-default

labels:

  type: appsec

listen_addr: 127.0.0.1:7422

source: appsec

Reload and confirm the WAF is listening:

$ sudo systemctl reload crowdsec

$ sudo ss -lntp | grep 7422

LISTEN 0 4096 127.0.0.1:7422 0.0.0.0:*  users:(("crowdsec",...))

Finally, point the Nginx bouncer at it. The bouncer ships with the WAF switched off (APPSEC_URL empty); one line turns it on:

sudo sed -i 's|^APPSEC_URL=.*|APPSEC_URL=http://127.0.0.1:7422|' \

    /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf

sudo systemctl reload nginx

Key points:

• crowdsecurity/appsec-default is the config that carries the virtual-patching rules and the health-check test rule, all in one config, ready to go.
• The listener is loopback-only (127.0.0.1) because AppSec and Nginx share this host. On a distributed setup you would bind a private interface instead, which is a topic for a later post.
• Reusing the bouncer’s existing API key for AppSec is automatic. There is no second key to create.

Step 4 — Prove it blocks real attacks

Fire a few malicious requests at the server and one honest one:

.env access             -> 403

phpunit CVE-2017-9841   -> 403

git config leak         -> 403

benign homepage         -> 200

Then read the WAF’s own counters:

$ sudo cscli metrics show appsec

 Appsec Engine   | Processed | Blocked

 127.0.0.1:7422/ | 6         | 3

 Rule ID                             | Triggered

 crowdsecurity/appsec-generic-test   | 2

 crowdsecurity/vpatch-CVE-2017-9841  | 1

 crowdsecurity/vpatch-env-access     | 2

Each block is attributed to the exact rule that caught it. Now look at what CrowdSec recorded:

$ sudo cscli alerts list

 value           | reason                             | kind     | decisions

 Ip:203.0.113.42 | crowdsecurity/vpatch-git-config    | waf      |

 Ip:203.0.113.42 | crowdsecurity/CVE-2017-9841        | crowdsec | ban:1

 Ip:203.0.113.42 | crowdsecurity/appsec-vpatch        | crowdsec | ban:1

 Ip:203.0.113.42 | crowdsecurity/vpatch-CVE-2017-9841 | waf      |

 Ip:203.0.113.42 | crowdsecurity/vpatch-env-access    | waf      |

Two things happened at once, and this is where CrowdSec pulls ahead of a plain WAF:

1. kind: waf: each malicious request was refused on the spot with a 403. That’s virtual patching doing its job, per request.
2. kind: crowdsec with ban:1: because the same IP kept probing, CrowdSec’s scenarios aggregated the behavior and banned the address outright. The next request from that IP, to any path, is refused before the WAF even looks at it.

$ sudo cscli decisions list

 crowdsec | Ip:203.0.113.42 | crowdsecurity/CVE-2017-9841 | ban | FR | 3h59m

A classic WAF blocks the request. CrowdSec blocks the request and remembers the attacker.

There is also an official smoke test that ships with CrowdSec. Requesting the path /crowdsec-test-NtktlJHV4TfBSK3wvlhiOBnl triggers the crowdsecurity/appsec-generic-test rule; the full health-check flow is documented here.

Step 5 — See it in the Console

Blocking attacks from the command line is satisfying, but you will want a dashboard, one place to watch alerts across every server you protect. The CrowdSec Console is that view, and it is free for the community tier.

Enroll this engine (grab an enrollment key from app.crowdsec.net → Security Engines → Enroll):

sudo cscli console enroll  --name crowdsec-vm-nginx-waf

sudo systemctl reload crowdsec

Then accept the instance in the Console webapp — enrollment is two-step, and nothing shows up until you click Accept. Turn on richer alert detail while you are at it:

sudo cscli console enable context

sudo systemctl reload crowdsec

Key points:

• You enroll the engine, not each bouncer; bouncers appear in the Console through the engine they report to.
• cscli capi status confirms the community signals loop: sharing enabled, community blocklist pulling. That blocklist is the payoff of open source: every CrowdSec user’s confirmed attackers become IPs you block before they ever reach you.
• The Console is a lens on data that already lives on your box. Turn it off and your WAF keeps working exactly the same.

Where this leaves you

In a few minutes you went from a bare Nginx server to an open-source WAF that:

• refuses known exploit shapes on sight, with virtually no false-positive risk;
• bans persistent attackers automatically, across your whole site;
• pulls a community-sourced blocklist so you benefit from attacks aimed at everyone else;
• reports into a single Console dashboard.

Virtual patching is a floor, not a ceiling. It only catches attacks it already knows by name. To catch the ones it doesn’t, the novel injection or the odd traversal, you bring in the OWASP Core Rule Set, and you decide whether to run it inband (block now) or out-of-band (watch first, block once you trust it). That’s exactly the false-positive tradeoff virtual patching let us skip, and it’s where the next post picks up.

After that: the hooks that let CrowdSec’s WAF do things a signature engine can’t, and how to run the WAF and the engine as a distributed pair across many servers.

You built all of this with software you can read, audit, and run for free. No black box, no vendor lock-in, nothing metered per request: just your server, refusing the requests that were never meant well.

Next in this series: Going further — OWASP CRS inband vs out-of-band with CrowdSec. Full documentation lives at docs.crowdsec.net/docs/appsec, and the rules are open on the CrowdSec Hub.

What BOD 26-04 actually changes

Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk”, supersedes both BOD 22-01 (KEV remediation) and BOD 19-02 (internet-accessible systems). The flat “it’s in the KEV, patch it in 14 days” era is over. In its place: a graduated model built on four binary risk variables, evaluated per vulnerability, per asset:

1. Publicly exposed — is the vulnerable asset reachable from the internet?
2. Known exploitation — is the CVE in CISA’s KEV catalog?
3. Automatable — can an adversary automate the full exploitation chain?
4. Technical impact — does exploitation yield total or partial control?

The combination of answers maps to remediation timelines ranging from three calendar days with mandatory forensic triage at the top, down to “fix on next system upgrade” at the bottom. Notably, CISA no longer requires CVSS for prioritization. Severity scores are out; evidence of real-world exploitation is in.

CISA is explicit about why now: AI is compressing the window between disclosure and weaponization, while remediation performance is moving the wrong way — per the 2026 Verizon DBIR figures CISA cites, only 26% of KEV vulnerabilities were fully remediated in 2025, down from 38% the year before.

The directive’s logic is sound. Its operational demand is brutal: agencies now need continuous, current, per-CVE exploitation intelligence — not a quarterly threat report, not a static severity score. And for the highest tier, they need to determine within 72 hours whether they’ve already been compromised.

This is exactly the gap Live Exploit Tracker closes.

Live Exploit Tracker: ground truth on exploitation, from hundreds of thousands of real sensors

Live Exploit Tracker (L.E.T.) is powered by the CrowdSec Network — the largest crowdsourced threat intelligence network in the world, with servers deployed across real production infrastructure in 180+ countries. When an attacker probes or exploits a CVE anywhere in the network, we see it. Not a honeypot guess. Not a vendor advisory. Actual exploitation attempts against actual workloads.

For every tracked CVE, L.E.T. tells you:

• The exploitation phase — recon, targeted exploitation, mass exploitation, or decline. Watching a CVE move from “insufficient data” to “targeted exploitation” is watching your remediation deadline accelerate in real time.
• Momentum — is this threat growing, stable, or fading? A KEV entry from 2023 that nobody exploits anymore and a CVE that gained 80 attacking IPs this week are not the same priority. BOD 26-04 finally lets agencies act on that distinction.
• Who is attacking — every observed attacker IP, with full CTI profiling: origin, hosting provider, known/unknown actor, behavioral history across the network.
• What they’re after — takeover, ransom, or exfiltration, derived from observed attacker behavior.
• Indicators of compromise — the actual HTTP patterns and payloads observed exploiting the CVE in the wild.

Mapping L.E.T. to the directive, variable by variable

Variable 1 — knowing which of your assets are publicly exposed — is your asset inventory’s job (EASM). L.E.T. doesn’t scan your network; it tells you what the adversary is doing, so your exposure data plus our exploitation data equals a complete BOD 26-04 picture.

Case in point: when CVSS says 5.3 and reality says 9/10

CISA dropped CVSS as a mandatory prioritization input for good reason. Here’s a live example of why.

CVE-2025-13956 is a missing-authorization flaw in LearnPress, a WordPress LMS plugin. CVSS score: 5.3. Medium. Under severity-based triage, it sits in the backlog forever.

Here’s what the CrowdSec Network actually observed: the CVE was published in March 2025 and stayed quiet for over a year. Then, in April 2026, we detected the first in-the-wild exploitation. By June 12, 2026, exploitation patterns shifted enough that our system reclassified it to targeted exploitation — 168 unique attacker IPs, momentum 4/5, targeting score 5/5, with 79% of attacking IPs profiled as pursuing system takeover. CrowdSec Score: 9/10 — critical active campaign.

A CVSS-driven program ignores this CVE. An exploitation-evidence-driven program — the kind BOD 26-04 now mandates — catches the phase transition the day it happens and re-prioritizes immediately. That’s the difference between a severity score assigned once at publication and a risk signal recomputed continuously from live attack data.

The vendor view: see the campaign, not just the CVE

Agencies don’t run CVEs; they run products. Federal networks are full of the exact appliances attackers systematically target—and if the last few years of emergency directives have taught us anything, it’s that edge devices from a handful of vendors pose disproportionate risk.

L.E.T.’s vendor pages aggregate all observations across a vendor’s entire product line. Take our Ivanti page: 20 tracked CVEs, 3 active recon campaigns, and 12,800+ attacker IPs currently engaged — including 13,500 IPs probing Connect Secure panels before any specific CVE is even in play. That recon activity is your earliest warning signal: adversaries are mapping targets for the next vulnerability before it becomes publicly known.

For a federal security team, this turns the directive’s per-CVE obligation into something manageable: one view of your actual vendor exposure, ranked by live adversary attention.

Beyond prioritization: shrink the exposure window while you patch

BOD 26-04 gives you three days for the worst cases. Patching an enterprise fleet in three days is hard. Patching it while the vulnerability is under active exploitation is harder.

This is where L.E.T. goes further than any prioritization feed: every CVE and vendor page exposes dynamic, subscribable IP datasets. Point your firewall, WAF, CDN, or cloud security layer at the blocklist for a specific CVE — or an entire vendor — and the IPs actively hunting that vulnerability are preemptively blocked from ever reaching your workloads. The dataset updates as the campaign evolves; no manual list management.

It’s not a substitute for patching — the directive is unambiguous about that, and so are we. It’s a compensating control that buys you the 72 hours you need and materially derisks the gap between “deadline starts” and “patch deployed.” Plug the holes in the hull while you’re still in the dry dock queue.

And when the forensic triage requirement kicks in, the same data answers the other question the directive forces: pull the full attacker IP intelligence and IoC patterns for the CVE via API, run them against your logs, and you have an evidence-based answer to “were we already hit?” — within the window, not after a six-week IR engagement.

Built for automation, because three days leave no room for manual work

Everything in L.E.T. is API-first: CVE details, exploitation phase, scores, attacker IPs, IoCs. Feed it into your vulnerability management platform, your SOAR, your reporting pipeline. The directive expects agencies to automate KEV tracking and remediation reporting; our data is structured to drop straight into that machinery. A curl away:

curl -s -H "x-api-key: YOUR_API_KEY" \

  "https://admin.api.crowdsec.net/v1/cves/CVE-2025-13956"

The bottom line

BOD 26-04 codifies what defenders have known for years: patch what’s being exploited, defer what isn’t, and find out fast if you’ve already been breached. The directive supplies the framework. It assumes you have the evidence.

We have the evidence — live, global, behavioral, per-CVE and per-vendor — and the protection layer to act on it before your patch lands.

Explore Live Exploit Tracker now at tracker.crowdsec.net — browse CVEs, vendors, and live exploitation data freely. Federal agency or supporting a federal mission? Talk to our team about API access, blocklist integration, and operationalizing BOD 26-04.

If you are using the nginx (or OpenResty) remediation component, you will also need to upgrade it to its latest version to fully address CVE-2026-44982.

CVE-2026-44982: Partial CrowdSec WAF Bypass (high severity)

The AppSec datasource failed to read the request body for any request whose Content-Length was not positive.

In practice, this means HTTP/1.1 requests using Transfer-Encoding: chunked and HTTP/2 requests sent without a content-length header were evaluated against an empty body, silently bypassing any WAF rule targeting body content.

Headers-only and URI-only rules are not affected.

CVE-2026-44981: Local API Denial of Service

LAPI did not enforce a maximum decompressed body size on incoming gzip-compressed requests.

A small compressed payload could decompress into hundreds of megabytes of valid JSON, and the unauthenticated /v1/watchers and /v1/watchers/login endpoints made this reachable without credentials.

Sending enough concurrent requests causes LAPI to exhaust memory and be killed by the OS.

By default, LAPI only listens on localhost, so this is not remotely exploitable.

In a distributed setup, any attacker who can reach LAPI can exploit it. Until you upgrade, restrict LAPI access to trusted IPs at the network or reverse proxy layer.

The impact is limited to the availability of new decisions: bouncers continue to enforce existing decisions, but new alerts cannot be processed, and new decisions cannot be distributed while LAPI is down.

–

Edge systems (VPN gateways, firewalls, WAFs, reverse proxies, load balancers, IAM appliances, and remote access portals) are inherently exposed. They sit in front of identity, internal apps, and admin surfaces. They are also difficult to manage, and most organizations have more of them than they realize. Subsidiaries have their own stacks. Teams spin up temporary machines in cloud accounts. Old stuff lingers because “we’ll clean that up later.”

Attackers love “later”.

Every time an edge CVE goes public, teams fall into the same loop. Read the advisory, argue about CVSS, wait for a catalog update, and then decide whether the change window is worth it. That is understandable. Emergency changes can break production. But it is also risky. By the time you have a consensus, exploitation may already be underway.

The better approach is simple. Start with reality, then move to exposure, then mitigate, then patch. You can do this without drama if your workflow is clear.

Why do edge vulnerabilities become incidents?

Edge issues quickly become major incidents because they create a direct path to valuable outcomes:

• Remote code execution on an internet-facing system often leads to internal access.
• Auth bypass can turn into an admin takeover.
• SSRF on a gateway can expose cloud metadata, internal APIs, or secrets.
• Weaknesses in edge products are often chainable. One bug is enough to get a foothold, then another gets privilege.

There is also a timing problem. Attackers move faster than most change processes. Within hours of a PoC being public, you can expect scanning at scale. Within days, you can expect mass exploitation attempts that are more reliable and more automated. Sometimes it is even faster than that.

Scanning is constant, exploitation is specific

Your logs will fill with noise after a CVE drops. That does not mean you are compromised. It means you are on a target list.

The distinction matters because it drives decisions. If you treat every scan spike like an incident, you will burn out your team and break production more often than you should. If you dismiss scans as noise, you may miss the point at which scanning becomes a compromise.

Scanning tends to look like:

• Quick version checks
• Broad requests across many paths
• High volume from distributed sources
• Low “intent” in payloads

Exploitation tends to look like:

• Repeated requests to a small set of paths tied to vulnerability
• Payloads that attempt code execution, file writes, or auth bypass
• Follow-on behavior, like attempts to log in, create sessions, or pull configs
• Patterns that align with known indicators for a given exploit family

For a SOC, your goal is not perfection. It is to be fast and correct enough to prioritize action.

Start with the question that cuts through the noise

When an edge CVE hits, ask two questions in this order:

1. Is exploitation observed in the wild?
2. Are we exposed?

If exploitation is observed and you are exposed, you act immediately. You reduce exposure and add friction, even before you patch, because you need to buy time.

If exploitation is not observed, you still do the exposure work and patch planning, but you avoid panic changes.

CrowdSec Live Exploit Tracker is mandatory here because it provides a reality check. It is not a replacement for advisories or catalog entries. It is a way to answer “Is this happening now?” without guessing.

The 60-minute response pattern

Here is a practical way to run the first hour. This works for both CISO-level decision making and SOC-level execution.

Minutes 0 to 10: confirm reality

• Confirm whether exploitation is observed in the wild.
• If exploitation is observed, decide to mitigate now and patch as soon as feasible.
• If exploitation is not observed, proceed with exposure assessment and prepare mitigations, but avoid disruptive changes until you have a reason.

This is where many teams lose time. They debate the severity instead of determining whether the attacker’s activity is real.

Minutes 10 to 25: determine exposure

Do not rely on one inventory source. Use multiple angles:

• public IP and DNS review
• cloud security posture data
• network scans of ingress points
• configuration management records for edge products

Make sure you include:

• HA pairs and standby nodes
• systems in regional sites
• test systems that accidentally became public
• legacy devices that were “temporary.”

Then answer:

• Is the vulnerable interface reachable from the internet?
• Is it reachable from partner networks?
• Is it reachable from user segments?

Exposure drives urgency. You can have a severe bug with low exposure. You can also have a moderate bug with high exposure that becomes your biggest risk.

Minutes 25 to 45: reduce exposure and add friction

If exploitation is observed and you have exposure, focus on making quick, safe changes that reduce risk.

Start with exposure reduction:

• Restrict management interfaces to allowlists. Do it now.
• Move admin access behind a VPN or a jump host.
• Remove direct internet access where possible.

Then add friction:

• Apply WAF rules or reverse-proxy filtering if traffic passes through them.
• Add IPS signatures or firewall blocklists where available.
• Rate limit endpoints that attackers hammer during exploitation.
• Tighten ACLs around the edge service and its management plane.

CrowdSec provides both WAF virtual patching rules and real-time-updated blocklists to address the latest vulnerabilities. These mitigation assets could be pulled automatically by your edge devices to respond instantly.

Minutes 45 to 60: verify and watch

Mitigation without verification is just hope.

• Confirm that logging is enabled and that it is shipped to your SIEM.
• Create targeted detections for the known exploit paths and payload patterns.
• Watch for post-exploitation indicators:
  • New admin sessions
  • New users or API tokens
  • Config changes
  • Unusual outbound connections from the appliance
  • Unexpected access to internal services

This last step matters because some exploit chains succeed quickly and quietly. Your mitigations might be late for one asset but still protect the rest.

How to communicate without drama

CISOs get pulled into edge events because the risk is easy to explain and the consequences are high.

A good update to leadership avoids raw CVE lists and vague reassurance. It includes:

• Exploitation status: observed or not observed
• Exposure status: which assets are internet-facing and vulnerable
• Mitigations deployed: what changed in the last hour
• Patch plan: when and how, including constraints
• Evidence: what the SOC sees after mitigation

This keeps the conversation grounded. It also helps you defend emergency actions later if you need to explain why a change freeze was overridden.

Key takeaways

• Edge systems are high value because they are exposed and privileged.
• Scanning is expected. Exploitation is what changes your response.
• Start with “is exploitation observed” and “are we exposed.”
• Reduce exposure first, then add filtering, then patch.
• Report progress on exposure and controls, not on CV

ButanGas operates in the energy sector, specializing in liquified petroleum gas (LPG) storage and distribution. Its main mission is to guarantee a safe, reliable, and continuous supply throughout Italy. As part of the Dragan Group, a multinational energy organization active in seven countries, ButanGas maintains a strong national presence with more than 20 offices and 9 LPG storage and bottling depots.

Behind these operations lies a complex and extended digital infrastructure. Supporting over 700 users across multiple countries, ButanGas manages IT and cybersecurity centrally for Italy and additional legal entities abroad. They require consistent protection, centralized visibility, and scalable security controls across geographies.

At the helm of this strategy is the organization’s CIO and CISO, Riccardo Morandotti. He is responsible for IT strategy, cybersecurity governance, risk management, and digital transformation initiatives across the company. 

The challenge: Too much noise, not enough insight

Like many companies in the energy sector, ButanGas faced a constant stream of malicious activity targeting its network perimeter.

Hundreds of suspicious connections were hitting their firewalls every day, generating significant noise but little actionable intelligence. While Sophos firewalls were already in place, the team lacked clear visibility into what was actually happening within their logs.

They needed more than just protection; they needed clarity. The volume of alerts made it difficult to distinguish meaningful threats from background noise, and the lack of enriched data limited their ability to take informed action. At the same time, ButanGas had a clear strategic priority: adopting European cybersecurity solutions without compromising on the quality of threat intelligence. 

Why CrowdSec: European roots, global intelligence

After evaluating several threat intelligence providers, Riccardo identified CrowdSec as the right fit. He explains, “What stood out was that CrowdSec is a European-based company, which aligned perfectly with our strategic goal of using European security tools whenever possible. At the same time, CrowdSec collects data globally and provides insights that few other vendors can match.”  

Equally important was the ease of deployment. Within just one hour, CrowdSec was integrated into their existing environment, and results followed almost immediately. From day one, hundreds of malicious connections were blocked daily, with a threefold increase in detected suspicious traffic. At the same time, false positives remained extremely low, below 1%, ensuring legitimate traffic was never disrupted.

CrowdSec is simple to deploy, operate, and integrate, letting our team focus on response rather than tool management. Its reliable threat intelligence and accurate detections give us high‑confidence security decisions with minimal noise, making it a truly dependable part of our security architecture.

– Riccardo Morandotti, CIO and CISO of ButanGas

A smarter, more proactive firewall

ButanGas initially deployed CrowdSec on its most critical firewall, with plans to extend coverage to ten more. Even this first step delivered a significant impact.

All malicious traffic is now blocked before reaching the network, drastically reducing exposure. Firewall logs have also become far more readable and actionable, with a clear distinction between legitimate and malicious traffic, eliminating the confusion that previously slowed down analysis.

The real transformation, however, goes beyond inbound protection.

Through the integration between CrowdSec, Sophos Firewall, and their MDR service, ButanGas now benefits from proactive outbound control as well. Internal endpoints are prevented from establishing connections with known malicious IPs, and any suspicious outbound attempt is immediately blocked. In more critical cases, compromised machines can be automatically isolated, helping contain threats before they spread or escalate.

This capability has proven essential in limiting lateral movement and preventing potential data exfiltration, turning the firewall into an active enforcement point rather than a passive filter.

From blocking threats to understanding them

While automated blocking significantly improved their security posture, the most meaningful shift came from enhanced visibility.

With CrowdSec’s IP enrichment capabilities, ButanGas now gains contextual intelligence on every threat, ranging from geographic origin to behavior patterns and risk scoring. This allows their team to understand not just that an IP is malicious, but why.

For a European organization, this is particularly valuable. They benefit from strong visibility into threats impacting European countries, while still leveraging globally collected intelligence to stay ahead of emerging risks.

Building a scalable security model

With CrowdSec in place, ButanGas has transformed its firewall into a proactive, intelligence-driven security layer.

Malicious traffic is stopped before it becomes a risk, visibility has improved dramatically, and the operational burden on the IT team has been reduced. All of this has been achieved without disrupting legitimate business activity.

As deployments grow across more firewalls, ButanGas is creating a scalable, unified security model. It protects a complex, multinational infrastructure while supporting the company’s mission to deliver safe, reliable energy.

That’s where the OWASP Core Rule Set (CRS) comes in. CrowdSec supports CRS natively through the Coraza WAF engine, giving you broad attack pattern detection alongside your existing virtual patching setup.

In this post, we’ll walk through what CRS offers, how to deploy it, and how to tune it for your applications.

What is OWASP Core Rule Set (CRS)?

The OWASP Core Rule Set is among the most widely deployed sets of WAF rules worldwide. Actively maintained by the OWASP community, it provides generic attack detection against:

• SQL injection
• Cross-site scripting
• Command injection
• Path traversal
• And more

Unlike virtual patching, which targets specific known CVEs, the CRS uses a more generic approach to detect exploitation of still-unknown vulnerabilities.

This comes at a cost: a higher chance of false positives depending on the application.

Using both CRS and virtual patching rules is complementary: virtual patching rules for precise targeting of known vulnerabilities without the need for any configuration, and CRS to catch everything else.

Using the CRS with CrowdSec

CrowdSec offers two deployment modes for CRS: out-of-band or in-band.

Out-of-band (non-blocking)

In this mode, CRS rules analyze your traffic asynchronously. No request is ever blocked by a single rule match. Instead, events are generated and fed into CrowdSec’s scenario engine. If an IP triggers too many different rule violations in a short timespan, it gets banned.

This is the recommended starting point because it lets you:

• See what CRS detects in your traffic without disrupting legitimate users
• Identify false positives and tune the CRS accordingly

In-band (blocking)

In blocking mode, requests that reach the CRS threshold for blocking are dropped immediately. Alerts are generated by default, giving you visibility into what is blocked.

Getting Started: Installation

Prerequisites

You need a working CrowdSec setup with a WAF-capable remediation component. This includes the Nginx/OpenResty bouncer, Traefik bouncer, HAProxy bouncer, or any other bouncer (also known as Remediation Component) that supports the AppSec protocol.

Step 1: Install the CRS collection

For non-blocking mode:

cscli collections install crowdsecurity/appsec-crs

This installs:

• crowdsecurity/crs: the configuration that loads CRS rules in out-of-band mode
• crowdsecurity/crowdsec-appsec-outofband: a scenario that bans IPs after 5+ out-of-band rule violations to offer a base level of protection, even if the rules themselves do not block anything directly.

Step 2: Configure the acquisition

Add the CRS config to your acquisition file (e.g., /etc/crowdsec/acquis.d/waf.yaml):

source: appsec
appsec-configs:
  - crowdsecurity/crs
labels:
  type: appsec

If you already have an acquisition file for AppSec with other configs (like virtual patching), simply add crowdsecurity/crs to the existing appsec-configs list.

Step 3: Enable per-match alerting

By default, non-blocking mode doesn’t generate an alert for every individual rule match. If you want visibility into each match (useful during the tuning phase), create /etc/crowdsec/appsec-configs/crs-alerting.yaml:

name: custom/crs-alerting
on_match:
  - filter: IsOutBand == true
    apply:
      - SendAlert()
      - CancelEvent()

The CancelEvent() directive is optional: if set, no event is generated for the scenario engine, meaning CrowdSec won’t take automated decisions based on these matches. This is useful if you want alerts for monitoring but don’t want any automated bans yet.

Then add it to your acquisition:

source: appsec
appsec-configs:
  - crowdsecurity/crs
  - custom/crs-alerting
labels:
  type: appsec

Even though an alert is generated, because the rules are loaded out-of-band, nothing will be blocked, but you will still know exactly what is matching.

Step 4: Restart CrowdSec

sudo systemctl restart crowdsec

Step 5: Confirm it’s working

Now, we can see if everything is working as it should. Let’s exploit a (fake) SQL injection:

$ curl "localhost/?a='+OR+'1'='1" -i
HTTP/1.1 200 OK
...

Our request was not blocked: it’s expected as the CRS is configured in non-blocking mode.

If we look at the list of alerts in crowdsec with cscli alerts list and cscli alerts inspectd -d, We can indeed see the request was detected by the CRS:

root@instance-20240401-2335:~# cscli alerts inspect -d 105901

################################################################################################

 - ID           : 105901
 - Date         : 2026-03-12T09:44:32Z
 - Machine      : 717704f5186c4314928c2060bf5169f32E1tgFLtep049JcD
 - Simulation   : false
 - Remediation  : false
 - Reason       : anomaly score out-of-band: sql_injection: 10, anomaly: 10,
 - Events Count : 4
 - Scope:Value  : Ip:127.0.0.1
 - Country      :
 - AS           :
 - Begin        : 2026-03-12T09:44:32Z
 - End          : 2026-03-12T09:44:32Z
 - UUID         : 8cf71673-81d7-4ba0-b211-0d415a0f51fd


 - Context  :
╭───────────────┬─────────────────────────────────────────────────────╮
│      Key      │                        Value                        │
├───────────────┼─────────────────────────────────────────────────────┤
│ ja4h          │ ge11nn020000_cf69e1861692_000000000000_000000000000 │
│ matched_zones │ ARGS.a                                              │
│ method        │ GET                                                 │
│ msg           │ SQL Injection Attack Detected via libinjection      │
│ name          │ native_rule:942100                                  │
│ target_uri    │ /?a='+OR+'1'='1                                     │
│ user_agent    │ curl/7.81.0                                         │
╰───────────────┴─────────────────────────────────────────────────────╯

 - Events  :

- Date: 2026-03-12 09:44:32 +0000 UTC
╭───────────────┬──────────────────────────╮
│      Key      │           Value          │
├───────────────┼──────────────────────────┤
│ data          │                          │
│ matched_zones │ REQBODY_PROCESSOR        │
│ message       │ Enabling body inspection │
│ rule_name     │ native_rule:901340       │
│ target_fqdn   │ localhost                │
│ uri           │ /?a='+OR+'1'='1          │
╰───────────────┴──────────────────────────╯

- Date: 2026-03-12 09:44:32 +0000 UTC
╭───────────────┬──────────────────────────────────────────────────────╮
│      Key      │                         Value                        │
├───────────────┼──────────────────────────────────────────────────────┤
│ data          │ Matched Data: s&sos found within ARGS:a: ' OR '1'='1 │
│ matched_zones │ ARGS.a,ARGS.a                                        │
│ message       │ SQL Injection Attack Detected via libinjection       │
│ rule_name     │ native_rule:942100                                   │
│ target_fqdn   │ localhost                                            │
│ uri           │ /?a='+OR+'1'='1                                      │
╰───────────────┴──────────────────────────────────────────────────────╯

- Date: 2026-03-12 09:44:32 +0000 UTC
╭───────────────┬──────────────────────────────────────────────────╮
│      Key      │                       Value                      │
├───────────────┼──────────────────────────────────────────────────┤
│ data          │                                                  │
│ matched_zones │ TX.blocking_inbound_anomaly_score                │
│ message       │ Inbound Anomaly Score Exceeded (Total Score: 10) │
│ rule_name     │ native_rule:949110                               │
│ target_fqdn   │ localhost                                        │
│ uri           │ /?a='+OR+'1'='1                                  │
╰───────────────┴──────────────────────────────────────────────────╯

- Date: 2026-03-12 09:44:32 +0000 UTC
╭───────────────┬──────────────────────────────────────────────────────────────╮
│      Key      │                             Value                            │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ data          │                                                              │
│ matched_zones │ UNKNOWN                                                      │
│ message       │ Anomaly Scores: (Inbound Scores: blocking=10, detection=10,  │
│               │ per_pl=10-0-0-0, threshold=5) - (Outbound Scores:            │
│               │ blocking=0, detection=0, per_pl=0-0-0-0, threshold=4) -      │
│               │ (SQLI=10, XSS=0, RFI=0, LFI=0, RCE=0, PHPI=0, HTTP=0,        │
│               │ SESS=0, COMBINED_SCORE=10)                                   │
│ rule_name     │ native_rule:980170                                           │
│ target_fqdn   │ localhost                                                    │
│ uri           │ /?a='+OR+'1'='1                                              │
╰───────────────┴──────────────────────────────────────────────────────────────╯

A note about the reason given for the block: CRS works with a threshold system. Each rule that matches on the request will increase by some value a global score, and if the global score exceeds a preconfigured threshold (5 by default), the request will be blocked.

This is why the reason appears as anomaly score out-of-band: sql_injection: 10, anomaly: 10,.

Crowdsec automatically extracts the scoring information from the CRS to give you, at first glance, details about what was wrong with the request.

Switching to blocking mode

Once you’re confident in your CRS tuning, switch to blocking mode:

cscli collections install crowdsecurity/appsec-crs-inband

Update your acquisition:

source: appsec
appsec-configs:
  - crowdsecurity/crs-inband
labels:
  type: appsec

In this mode, any request that reaches the default CRS threshold is dropped, and alerts are generated automatically.

Let’s retry the same request as previously:

$ curl "localhost/?a='+OR+'1'='1" -i
HTTP/1.1 403 Forbidden
...

This time, the request actually got blocked!

Again, we can inspect the alert:

root@instance-20240401-2335:~# cscli alerts inspect -d 105902

################################################################################################

 - ID           : 105902
 - Date         : 2026-03-12T09:49:04Z
 - Machine      : 717704f5186c4314928c2060bf5169f32E1tgFLtep049JcD
 - Simulation   : false
 - Remediation  : false
 - Reason       : anomaly score block: sql_injection: 10, anomaly: 10,
 - Events Count : 4
 - Scope:Value  : Ip:127.0.0.1
 - Country      :
 - AS           :
 - Begin        : 2026-03-12T09:49:03Z
 - End          : 2026-03-12T09:49:03Z
 - UUID         : 7ef38529-5e7e-4d2e-9e21-24ec7a89a1ee


 - Context  :
╭───────────────┬─────────────────────────────────────────────────────╮
│      Key      │                        Value                        │
├───────────────┼─────────────────────────────────────────────────────┤
│ ja4h          │ ge11nn020000_cf69e1861692_000000000000_000000000000 │
│ matched_zones │ ARGS.a                                              │
│ method        │ GET                                                 │
│ msg           │ SQL Injection Attack Detected via libinjection      │
│ name          │ native_rule:942100                                  │
│ target_uri    │ /?a='+OR+'1'='1                                     │
│ user_agent    │ curl/7.81.0                                         │
╰───────────────┴─────────────────────────────────────────────────────╯

 - Events  :

- Date: 2026-03-12 09:49:03 +0000 UTC
╭───────────────┬──────────────────────────╮
│      Key      │           Value          │
├───────────────┼──────────────────────────┤
│ data          │                          │
│ matched_zones │ REQBODY_PROCESSOR        │
│ message       │ Enabling body inspection │
│ rule_name     │ native_rule:901340       │
│ target_fqdn   │ localhost                │
│ uri           │ /?a='+OR+'1'='1          │
╰───────────────┴──────────────────────────╯

- Date: 2026-03-12 09:49:03 +0000 UTC
╭───────────────┬──────────────────────────────────────────────────────╮
│      Key      │                         Value                        │
├───────────────┼──────────────────────────────────────────────────────┤
│ data          │ Matched Data: s&sos found within ARGS:a: ' OR '1'='1 │
│ matched_zones │ ARGS.a,ARGS.a                                        │
│ message       │ SQL Injection Attack Detected via libinjection       │
│ rule_name     │ native_rule:942100                                   │
│ target_fqdn   │ localhost                                            │
│ uri           │ /?a='+OR+'1'='1                                      │
╰───────────────┴──────────────────────────────────────────────────────╯

- Date: 2026-03-12 09:49:03 +0000 UTC
╭───────────────┬──────────────────────────────────────────────────╮
│      Key      │                       Value                      │
├───────────────┼──────────────────────────────────────────────────┤
│ data          │                                                  │
│ matched_zones │ TX.blocking_inbound_anomaly_score                │
│ message       │ Inbound Anomaly Score Exceeded (Total Score: 10) │
│ rule_name     │ native_rule:949110                               │
│ target_fqdn   │ localhost                                        │
│ uri           │ /?a='+OR+'1'='1                                  │
╰───────────────┴──────────────────────────────────────────────────╯

- Date: 2026-03-12 09:49:03 +0000 UTC
╭───────────────┬──────────────────────────────────────────────────────────────╮
│      Key      │                             Value                            │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ data          │                                                              │
│ matched_zones │ UNKNOWN                                                      │
│ message       │ Anomaly Scores: (Inbound Scores: blocking=10, detection=10,  │
│               │ per_pl=10-0-0-0, threshold=5) - (Outbound Scores:            │
│               │ blocking=0, detection=0, per_pl=0-0-0-0, threshold=4) -      │
│               │ (SQLI=10, XSS=0, RFI=0, LFI=0, RCE=0, PHPI=0, HTTP=0,        │
│               │ SESS=0, COMBINED_SCORE=10)                                   │
│ rule_name     │ native_rule:980170                                           │
│ target_fqdn   │ localhost                                                    │
│ uri           │ /?a='+OR+'1'='1                                              │
╰───────────────┴──────────────────────────────────────────────────────────────╯

It’s almost the same, except for the reason: anomaly score block: sql_injection: 10, anomaly: 10,.

The presence of block means the request was actually blocked and never reached the target application.

Customizing CRS for Your Applications

Out of the box, CRS is tuned for broad coverage. For any moderately complex application, you’ll likely need some customization to eliminate false positives. CrowdSec uses the CRS plugin system for all customizations, keeping your changes separate from the CRS rules themselves.

CRS Plugins for Popular Applications

The CRS community maintains exclusion plugins for popular web applications. These plugins contain pre-built rule exclusions that prevent common false positives for each application.

The following plugins are available directly from the CrowdSec Hub:

• WordPress
• NextCloud
• PHPMyAdmin
• CPanel
• Drupal
• PHPBB
• DokuWiki
• Xenforo

Installing a plugin

cscli collections install crowdsecurity/appsec-crs-exclusion-plugin-

For example, to install the WordPress plugin:

cscli collections install crowdsecurity/appsec-crs-exclusion-plugin-wordpress

Once installed, the plugin loads automatically after a CrowdSec restart.

The plugins are updated automatically, like any other Hub items, so you will receive upstream changes automatically.

You can also manually deploy custom plugins; refer to our documentation.

Putting It All Together: Defense in Depth

Here’s how a complete AppSec configuration might look, combining virtual patching and CRS:

# /etc/crowdsec/acquis.d/waf.yaml
source: appsec
appsec-configs:
  - crowdsecurity/appsec-default # Virtual patching (in-band)
  - crowdsecurity/crs # OWASP CRS (out-of-band)
labels:
  type: appsec

With this setup:

1. Virtual patching rules run in-band, immediately blocking requests that match known CVE patterns
2. CRS rules run out-of-band, detecting broad attack patterns and feeding events into CrowdSec’s scenario engine
3. IPs that trigger multiple CRS violations get banned automatically through the scenario system
4. CrowdSec’s threat intelligence adds another layer, sharing decisions across the community

Once you’ve tuned CRS and are confident in your configuration, you can switch to the in-band CRS collection for immediate blocking with the following configuration:

# /etc/crowdsec/acquis.d/waf.yaml
source: appsec
appsec-configs:
  - crowdsecurity/appsec-default # Virtual patching (in-band)
  - crowdsecurity/crs-inband # OWASP CRS (in-band)
labels:
  type: appsec

Next Steps

Now that you have deployed CRS with CrowdSec, here are some more resources and tools you can use to better protect your web applications:  

• Browse the CRS documentation for detailed reference
• Search the CrowdSec Hub for available CRS plugins
• Check out the CrowdSec WAF quickstart guides if you haven’t set up the AppSec component yet
• Join the CrowdSec community to share your CRS tuning experiences