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

Supporting Ingress-NGINX during its final lifecycle

CrowdSec currently integrates with Ingress-NGINX through a dedicated image that embeds CrowdSec remediation capabilities. This integration will remain available for the last supported versions of Ingress-NGINX.

First, we need to underline that CrowdSec requires a dedicated image. CrowdSec remediation in Ingress-NGINX relies on Lua to execute the blocking logic. Lua support was removed from the official Ingress-NGINX image, which means CrowdSec cannot run on the upstream image anymore. As a result, the CrowdSec integration requires an alternate image that restores the Lua capability needed by the remediation engine. This extended support should be viewed as a transitional measure, providing ample time for a smooth migration to more future-proof and robust architectures.

For users evaluating alternatives today, it is also worth noting that CrowdSec already supports Traefik and HAProxy as ingress controllers.

While third parties sometimes provide support for this in an open-source capacity, we remain fully committed to the CrowdSec components and features, ensuring their continued support and the introduction of new functionality over time. We also maintain and develop documentation for the tools used by the community.

The shift from Ingress-NGINX to Gateway API in Kubernetes

The Kubernetes shift toward Gateway API beyond the lifecycle of Ingress-NGINX, Kubernetes itself is signalling a broader shift in how north-south traffic should be handled.

The Kubernetes ecosystem is increasingly converging around the Gateway API specification. This specification introduces the Gateway API as a more flexible and extensible way to manage traffic entering a cluster.

Several implementations of the Gateway API specification already exist, and a number of them are built on technologies that already support CrowdSec remediation mechanisms. Because of this, we see the Gateway API ecosystem as a natural evolution path for CrowdSec users running Kubernetes clusters. Today, solutions such as Traefik, HAProxy, and Envoy can already operate with CrowdSec remediation, meaning that when they are used as Gateway API implementations. They can immediately benefit from CrowdSec to help secure infrastructure.

We are committed to supporting both established and emerging API gateway solutions with meaningful adoption. Traefik and HAProxy are strong examples of this today, and multiple Envoy-based community implementations are also evolving in this space. We closely monitor these projects as they mature toward production readiness, so that CrowdSec users can rely on them with confidence.

Next Steps for Kubernetes: Transitioning to Gateway API with CrowdSec

Our goal is to help users navigate this transition as smoothly as possible.

Several Gateway API integrations already exist, many of them developed by the community. When the underlying technology supports CrowdSec remediation, as is the case with Traefik, integration is straightforward. Our focus is now on validating these solutions and providing the necessary testing and documentation so they can be easily adopted and reliably used by the community.

In parallel, we are committed to producing documentation that will guide users through the transition from traditional ingress controllers to API Gateway-based architectures.

This will include practical migration guidance, configuration examples, and recommendations on which Gateway implementations work well with CrowdSec. 

Looking forward

Ingress controllers played a key role in the Kubernetes ecosystem for many years, but the landscape is evolving. As Kubernetes provides a new Gateway API, users can run CrowdSec alongside it.

In the meantime, users relying on Ingress-NGINX can continue using CrowdSec remediation with the latest supported versions. However, teams planning new deployments or long-term architectures are encouraged to start considering alternatives, such as adopting the Gateway API or using another supported ingress controller, since Ingress-NGINX is the only controller being gradually phased out.

We are closely monitoring the Gateway API ecosystem and its evolution. Our goal is to support solutions with a strong, growing user base, ensuring that CrowdSec integrates where it can deliver the most value. 

This article breaks down what each term actually means, how vulnerabilities move through their lifecycle, and what that means for you as a developer or maintainer.

What even is a vulnerability?

At its core, a vulnerability is a weakness in a system that someone could exploit. It doesn’t have to be a dramatic zero-day in a cryptography library. It can be something simply mundane, like a forgotten admin endpoint with default credentials, or a dependency that hasn’t been updated in two years.

Vulnerabilities tend to fall into a few buckets:

• Software bugs: Logic errors, memory issues, improper input handling, the kinds of things that slip through code review and only reveal themselves under the right (wrong) conditions.
• Misconfiguration: Open ports that shouldn’t be open, overly permissive IAM roles, debug endpoints left on in production. Config issues are responsible for a huge proportion of real-world breaches.
• Human factors: Weak passwords, phishing susceptibility, and the developer who commits an API key because they were in a hurry. This category is frustratingly durable.

The key thing to understand: a vulnerability sitting quietly in your codebase isn’t actively hurting anyone. It only becomes a problem when someone finds it and does something with it.

Vulnerability vs. threat vs. risk

These three concepts form a chain, and understanding the chain is what lets you make sensible decisions about where to spend your time.

• Vulnerability is the weakness (an unpatched library, a misconfigured firewall rule).
• A threat is the actor or mechanism that could exploit it (an attacker, an automated scanner sweeping the internet).
• Risk is what you’re actually trying to manage: the likelihood that the threat exploits the vulnerability, multiplied by the impact if it does.

A concrete example: say your app has an admin panel exposed to the internet with default credentials still set. That’s your vulnerability. The threat is anyone running credential-stuffing tools against it, and there are plenty of those running 24/7. The risk is high because both the likelihood and the potential impact (full admin access) are significant.

Contrast that with a theoretical XSS in an internal tool used by two people on your team. Still a vulnerability, much lower risk. This framing is how you avoid treating every CVE as an alarm fire.

The vulnerability lifecycle

Vulnerabilities don’t just appear and disappear. They go through a lifecycle, and where you are in that lifecycle dramatically affects how much danger you’re in.

Discovery

Someone finds the vulnerability: a security researcher, a developer doing a code review, a bug bounty hunter, or an attacker. The discoverer’s intentions shape everything that happens next.

Disclosure

How the vulnerability gets reported matters a lot. There are three main patterns in the wild:

• Responsible disclosure: The researcher contacts the vendor privately and gives them time to fix it before going public.
• Coordinated disclosure: A deadline is set, typically 90 days, after which the details go public regardless of whether a patch exists. This is now the dominant approach, popularized by Google Project Zero and CERT/CC. It puts real pressure on vendors to actually ship fixes rather than quietly hoping nobody notices.
• Full disclosure: Everything goes public immediately. Controversial, but the argument is that it forces faster action and gives defenders the information they need without waiting on vendor timelines.

The exploitation window

This is where things get uncomfortable. Between when a vulnerability is discovered (or disclosed) and when it’s actually patched across affected systems, there’s a window of exposure. For zero-days, vulnerabilities being actively exploited before any patch exists, that window starts the moment the attacker finds it.

The exploitation window is why patch speed matters so much. It’s not theoretical. Once a CVE drops with a working proof-of-concept attached, mass exploitation often starts within hours.

Patch and remediation

The vendor ships a fix. In the open source world, this usually means a PR gets merged, a new version gets tagged, and a CVE gets assigned with a CVSS score that tells you how severe the issue is considered to be. CVSS isn’t perfect; it doesn’t account for your specific environment, but it’s a useful first filter for prioritization.

Resolution and monitoring

Applying the patch is not the end of the story. You need to verify it’s actually deployed everywhere it needs to be, and keep watching for signs that exploitation happened before you patched. Logs, alerts, anomaly detection, and the operational work that actually catches incidents.

How vulnerabilities get found

In practice, most vulnerabilities surface through one of these channels:

• Security audits and code review: Organizations proactively scan their own systems and codebases for weaknesses.
• Bug bounty programs: External researchers are incentivized to find and responsibly report vulnerabilities.
• Accidental discovery: Users or developers notice unexpected behavior that points to a weakness.
• Malicious discovery: Attackers actively probe systems to find exploitable vulnerabilities.

When a vulnerability becomes an incident

Most vulnerabilities never turn into incidents. The ones that do tend to share a common thread: they were known, there was a fix available, and nobody got around to applying it.

An incident happens when a vulnerability gets actively exploited and causes real harm, data exfiltration, services taken down, and credentials compromised. At that point, you’re no longer in vulnerability management territory; you’re in incident response, which is a different and much more stressful.

Staying on the right side of that line comes down to a few practical habits: patch quickly (especially anything with a high CVSS score or active exploitation reports), monitor for anomalous behavior, and treat your CVE feed as something worth actually reading.

Why does this matter if you’re building or maintaining software

If you’re a developer, the decisions you make, which dependencies you pull in, how you configure your deployment, and whether you have a process for responding to vulnerability disclosures in your own project, have downstream consequences for everyone using your software.

Open source maintainers carry a particular version of this responsibility. When a vulnerability is found in a widely-used package, the blast radius can be enormous. Having a clear disclosure policy, staying reachable, and shipping fixes promptly are part of what makes open source software trustworthy.

Security doesn’t have a finish line. Understanding how vulnerabilities work, how they get discovered, and how they move from disclosure to exploitation is the foundation for making better decisions across the whole chain, from the code you write to the alerts you triage at midnight.

First of all, an MCP (Model Context Protocol) is an open-standard specification that enables Large Language Models to securely and consistently connect to external data sources and local tools, essentially acting as a “USB port” for AI to interact with your files, databases, and APIs.

This extract from our internal tooling has drastically improved our ability to create virtual patching rules for the WAF and internal detection rules for our data lake. In our context, the CrowdSec MCP allows a user to simply instruct their favourite LLM, like ChatGPT, Claude, Gemini, and others, and say, “Hey, look up this blog post and create a WAF rule for it”, and end up with a highly accurate result.

In the era of rapidly progressing LLMs, this might sound like a normal Monday morning. But achieving consistent, production-ready WAF rules takes a few tricks; let’s not forget, there is no magic. Here is a walk-through of the process that brought us here and the lessons we learned along the way.

Why Automate WAF Rules with AI?

Let’s cut to the chase: writing WAF rules is tedious, and life is too short to write YAML. At CrowdSec, we track about 100 new vulnerabilities every month, which means writing just as many YAML WAF rules with accompanying tests, often with convoluted syntax. The initial need was clear: we wanted to increase our ability to produce reliable WAF rules while reducing as much as possible the human bandwidth spent writing WAF rules or scenarios.

We already leveraged LLMs to industrialise those processes and increase their velocity, but the way MCP interacts with LLM allowed us to take it one step further.

Why We Built a Model Context Protocol (MCP) for CrowdSec?

In our first iterations, we exploited OpenAI APIs directly with some custom prompts, including examples, instructions, etc. However, even if you can set the temperature of the LLM when using the API, the results aren’t consistent, as you might know. As a result, the generated rules are sometimes correct and sometimes incorrect.

When things went right, everybody was happy, but when things went wrong (hallucinations, misunderstandings from the LLM), the human had to take over and start over. This was both a source of frustration and a waste of time, with every iteration providing results of varying quality. We quickly identified that a feedback loop was needed.

Last but not least, previously developed tooling had strong adherence to some input formats – such as nuclei templates – and we wanted natural language understanding to achieve the same result from less structured sources, such as blog posts or write-ups.

Both these reasons make a good case for experimenting with MCPs.

Overcoming LLM Limitations in WAF Rule Generation

On tasks that sound rather simple, an LLM might fail spectacularly, especially if it involves a lot of small steps to follow meticulously. Providing the LLM with tools (such as linting, syntax validation, etc.) is a great way to introduce feedback loops, giving it a chance to identify its mistakes and correct itself, and that’s what makes MCP attractive in this use case.

Feedback Loop is Key

In the context of an MCP, given that you provide enough tools, it will correct itself over time when it starts hallucinating. As a concrete example, the first steps of the MCP usage by the LLM to generate a WAF rule look like:

1. Get “WAF rules syntax” prompt from MCP: it covers the syntax of the WAF rules, with some do’s and don’ts.
2. Submit the generated WAF rule to the “syntax validation” tool: it will validate the generated YAML based on our public YAML schemas.

Simply introducing this 2nd step allows the LLM to understand that it generated an incorrect YAML document, go back to the 1st step, make another attempt, and go back to the 2nd step until it gets proper validation. Providing the LLM with specific steps to follow enables iterative refinement, significantly improving the overall quality of generated results.

In the example above, we see self-correction via a feedback loop: upon getting the prompt “WAF rule challenge” that aims at identifying common mistakes or suboptimal patterns, the LLM corrects itself: 

> Actually, since the guidelines say only use OR or AND (not both), and the paths differ, but the injection pattern is the same, I’ll create a single rule using a URI regex to match both paths with the AND condition on the injection:

Let’s not forget about consistency

Another key advantage of MCP integration is consistency. As one might know, while LLMs excel at a lot of things, consistency isn’t their forte. By exposing the right tools and prompts to the LLM, we can strongly mitigate the issue:

• Sometimes, a few lines of code will succeed where a smarter LLM might erratically fail. Identifying those choke points and exposing the tools at the right time allows us to get around the LLM’s inconsistencies.
• Exposing clear steps to the LLM with various subprompts helps ensure that validation steps aren’t skipped (which might otherwise happen). Typically, forcing the LLM to analyse previously generated data with a different prompt enables it to perform self-correction and pushes consistency one step further.

Thus, MCPs sometimes allow for filling gaps in the LLM’s ability. In the example below, the LLM generated a syntaxically correct rule, but upon testing the WAF rule against an actual exploit, it realizes its own mistake:

More tools for better results

However, to obtain a correct WAF rule, it isn’t enough to produce a syntaxically correct document, as there are many pitfalls:

• The rule might be too broad or too narrow.
• The rule might simply not match the exploit.
• The rule isn’t following best practices.
• The rule needs to include a proper test case for regression and false-positive detection.

To achieve all this, we provide the MCP with more than 20 tools that will help it at the various steps of the process, so that the overall workflow looks like:

Identified limitations

While we’re overall very satisfied with the current results produced by the LLM and how it drastically allowed us to reduce production time of rules while increasing the consistency of the results, there are a few key points that need to be kept in mind when designing such systems:

• LLMs get overwhelmed when there is too much data: On other features that implied interacting with verbose APIs, we repeatedly observed the LLMs getting confused or lost when dealing with MCP outputs. You often need to find bypasses or shortcuts to avoid exposing the LLM to significant volumes of data, or risk inconsistent results – most likely due to context size.
• LLMs lack consistency: sometimes, we had to expose or provide tools that might seem overly basic, simply because the LLM repeatedly failed on steps that seemed trivial. It was specifically true when you step away from creative tasks, and instead ask LLM to verify a document against a yaml/JSON schema.
• Prompt engineering: while it might sound really stupid, we observed very different output quality depending on how the prompt was formatted, rather than what was inside.