← Back to all sparks
C

CrowdSec

INFRA · APIS
Velocity6.3

Collaborative behaviour-based intrusion prevention engine

CrowdSec's bot-detection candidate hardens through rc2 while the WAF becomes the product's centre.

wafbot-detectionkubernetessecurityrelease-candidatefingerprinting
Current state
The 1.8 release candidate is where CrowdSec's attention sits. rc1 introduced WAF bot detection — a challenge and fingerprinting page evaluated against configured rules — plus a Kubernetes datasource reading straight from the apiserver and HTTP helpers for the expression language. rc2 does not change that feature set; it tunes it, adding a challenge threshold, detecting disabled cookies, unifying bot-detection scores, raising proof-of-work difficulty, and fixing a goroutine leak in the pre-warmer. The releases before this line were mostly internal refactoring of the acquisition and leaky-bucket packages.
Where it's heading
CrowdSec is moving from a log-analysis engine that emits IP decisions toward an inline enforcement layer that inspects and challenges live traffic. The WAF has taken the last several feature releases — OpenAPI schema validation in 1.7.8, flexible rule conditions and RE2 by default in 1.7.7, now bot detection — while the surrounding work is plumbing to support it. The Kubernetes datasource extends the same reach into cluster audit logs rather than host files.
Prediction
Expect a 1.8.0 final once the challenge tuning settles, with bot fingerprinting the headline. Whether fingerprint signal joins the shared community blocklist the way IP decisions do is not answered anywhere in these entries.

Recent moves

  1. 21d ago

    1.8 rc2 tunes the bot-detection challenge and hardens acquisition limits

    A second candidate restating rc1's feature notes with the bot-detection flow refined: configurable challenge thresholds, an explicit error when cookies are disabled, unified scoring, harder proof-of-work, and a fixed pre-warmer goroutine leak. It also caps body sizes on k8s-audit and HTTP acquisition and revamps cscli console status, which reads as the pre-GA tightening pass rather than new capability.

    View source ↗
  2. 1mo ago

    CrowdSec 1.8 RC adds WAF bot detection and a Kubernetes datasource

    ⚡ SPARK

    The origin of the 1.8 line and the point where CrowdSec's WAF stopped being a rule engine and started challenging clients directly. Everything in rc2 refines what this candidate introduced.

    View source ↗
  3. 4mo ago

    1.7.8 RC: OpenAPI schema validation in the WAF

    Adds OpenAPI schema validation so the WAF can reject requests that violate a declared API contract, alongside body size limits and chunked decision streaming by default. Part of the steady build-out that made the WAF the centre of gravity ahead of 1.8.

    View source ↗
  4. 5mo ago

    1.7.7 RC: flexible WAF rule conditions and RE2 by default

    Lets WAF rules mix AND and OR conditions arbitrarily, enables RE2 by default on Linux, and exposes more Coraza transformations. Expressiveness work that made the later challenge-rule model practical.

    View source ↗
  5. 8mo ago

    1.7.5 RC: acquisition and leaky-bucket refactoring

    Almost entirely internal restructuring — dependency injection in the leaky bucket, acquisition config validation, removal of global state. Nothing users observe, but it precedes the datasource work that arrives in 1.8.

    View source ↗
  6. 9mo ago

    1.7.4 RC2: acquisition module split and lint cleanup

    Splits each acquisition datasource into its own file and runs a broad lint pass. Groundwork visible only in how quickly new datasources shipped afterwards.

    View source ↗