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.

At CrowdSec, we’re excited about the public launch of db.gcve.eu, a new open vulnerability advisory database built to aggregate, normalize, and correlate vulnerability information across multiple publishers while remaining compatible with existing CVE workflows.

What is db.gcve.eu?

db.gcve.eu provides a unified view of vulnerabilities by continuously collecting and correlating advisories from a wide range of public sources, including 25+ sources for now.

Under the hood, it is powered by Vulnerability-Lookup, an open source project aligned with GCVE’s best current practices for collection and publication. It also ships with open access, a public API, and data dumps for bulk/offline use. It is precisely what defenders need to build automated workflows and repeatable processes.

Why this matters for European defenders

Security teams don’t just need more data. They need trusted, sovereign, and resilient access to it.

db.gcve.eu is hosted and operated by CIRCL in Luxembourg, and the project is co-funded by CIRCL and the European Union (ECCC) under the FETTA project. That combination of open-source and European-operated infrastructure is a meaningful step for digital sovereignty and operational continuity.

Just as importantly, this is not about “replacing” the global ecosystem. It’s about strengthening it.

Why “multiple sources” wins in vulnerability intelligence

Anyone running vuln management at scale knows the pain:

• One source updates first, another lags
• One vendor advisory has the best technical detail
• Another database has the best cross-references
• Exploit and “known exploited” assertions show up in different places

db.gcve.eu’s value is in doing the unglamorous but essential work: aggregation, correlation, and normalization across identifiers and databases, so defenders can spend less time reconciling records and more time acting.

This “multi-source first” stance is not a luxury. It’s how you reduce blind spots.

Real-time attacker reality, grounded in production

Vulnerability databases increasingly do more than list “what could be exploited.” Initiatives like GCVE / db.gcve.eu also incorporate community feedback and exploitation signals (including from major public telemetry providers such as Shadowserver) to help validate what’s happening in the wild.

That’s exactly the direction the ecosystem should go, and it’s where CrowdSec adds a different kind of signal: high-fidelity production telemetry.

Where many “exploitation proofs” come from honeypots, CrowdSec’s Live Exploit Tracker is built on real attacks seen across real production systems. 

That’s where CrowdSec naturally connects db.gcve.eu’s enriched advisory view with CrowdSec’s Live Exploit Tracker, which focuses on:

• CVEs actually observed being exploited in operational environments
• Time-to-exploitation and ongoing exploitation trends as they unfold
• Concrete attacker information (IPs, IoCs, exploitation behavior), usable for rapid mitigation and threat hunting
  

Put simply:

• db.gcve.eu helps you correlate and contextualize vulnerabilities across sources.
• CrowdSec enables you to prioritize with real-world exploitation evidence from production telemetry.

Practical workflows defenders can build today

Here are a few high-impact ways teams can combine these approaches:

Closing thoughts

We welcome db.gcve.eu as a concrete, open, European-operated contribution to a more resilient vulnerability intelligence ecosystem, one that values interoperability, multi-source correlation, and open access.

And we’ll keep pushing the complementary idea that defenders deserve more than static scores: they deserve real-time, accurate information about attackers so they can prioritize, mitigate, and stay ahead.

Finally, visit db.gcve.eu to learn more.

A CVE can be published in the morning and weaponized by lunch. Meanwhile, your backlog grows, your teams argue over prioritization, and critical starts to mean everything.

Live Exploit Trackeris built for that moment.

Live Exploit Tracker shows which vulnerabilities are being actively exploited in the wild, the IPs behind the exploitation, and the indicators of compromise (IoCs) associated with real-world attack attempts, based on live activity observed across hundreds of thousands of production systems worldwide.

This is not another list to monitor. It is a way to make faster, calmer decisions.

Live Exploit Tracker helps you prioritize the right CVEs, respond faster when exploitation spikes, and immediately operationalize defenses using IP feeds and IoCs.

What teams get out of Live Exploit Tracker

1. Clear prioritization when everything looks urgent

Live Exploit Tracker provides intelligence built from observed exploitation signals, including profile (opportunistic vs targeted), scale, timeline, and intensity, as well as top targeted countries.

In practice, this helps you answer:

• Is this CVE being exploited right now?
• Is it growing or fading?
• Is it a short spike or a sustained campaign?

So your patching plan becomes evidence-based rather than headline-based.

2. Faster mitigation when patching is not immediate

For each CVE, Live Exploit Tracker provides visibility with IoCs such as IPs and more, sourced from live exploitation attempts.

You can use it as:

• A helper for higher-confidence detection rules with IoCs
• A raw threat intel feed to enrich your SOAR or SIEM
• An edge-consumable blocklist format for common enforcement points like your firewall, CDN, and more

This is the practical win: you can cut exposure quickly while patching and speed up triage during incident response.

3. Earlier warning on what attackers are lining up next

Live Exploit Tracker also includes Pre-CVE Scouting. It shows IPs probing a vendor or technology over roughly the last 36 hours, including campaigns hunting for unknown vulnerabilities.

If you run internet-exposed infrastructure, this gives you a head start to harden and monitor before the disclosure catches up.

Why Live Exploit Tracker signals are operational, not noisy

Live Exploit Tracker is fueled by production telemetry. That matters because production systems are real targets: VPN gateways, APIs, login pages, business apps. This is where attackers try to win.

Production telemetry also surfaces higher-quality indicators. Attackers reveal more when they think they are on a real system and not a decoy.

You can enforce Live Exploit Tracker signals because they reflect the real state of exploitation, not algorithm-based extrapolations.

How Live Exploit Tracker fits your workflow

Live Exploit Tracker is designed to be actionable. Query exploitation intelligence via an API and feed your existing tools to enrich alerts and trigger playbooks. Drive mitigations based on what’s currently being exploited.

• Enrich your vulnerability backlog with an active exploitation context so the top of your priority list reflects reality, not just severity
• Flag changes in trend. When exploitation spikes, Live Exploit Tracker helps you spot it early and re-rank work without waiting for downstream advisories
• Create a “Patch Now” view for internet-facing assets and critical services, with clear justification for stakeholders

To wrap it up

CVE, CVSS, EPSS, and KEV still matter. They give structure.

Live Exploit Tracker adds the missing piece: what attackers are actually doing, plus the IPs and IoCs that let defenders respond quickly and confidently.

Attackers thrive on these misconceptions. They exploit gaps from false confidence, fragmented tools, delayed patching, and decisions made without context. Knowing where these beliefs fail is key to reducing real-world risk.

This article covers five common security myths, why they persist, and what really matters for defending modern environments.

Myth 1: “We’re too small to be a target.”

Dataversity reports that Ransomware-as-a-Service surged by 60% in 2025, dramatically lowering the barrier to entry for cybercriminals. As a result, launching an attack no longer requires advanced skills or significant resources. But who is most at risk? Contrary to common assumptions, it’s not large enterprises. Businesses with fewer than 1,000 employees accounted for 46% of all cyber breaches.

Smaller organizations are frequent targets because they often lack dedicated IT teams, enterprise-grade tools, and up-to-date systems. Limited budgets and a false sense of security lead to weak controls, outdated software, and unpatched vulnerabilities.

Attackers go after the same valuable data as in larger firms: customer info like names, emails, and financial details, as well as internal records that can be monetized or used in follow-on attacks.

The financial impact of these incidents can be devastating. As noted in a TechXplore article by Roxana Popescu, 37% of companies lost more than $500,000 per incident last year. Another quarter lost up to $250,000, while an additional 25% suffered losses between $250,000 and $500,000. To recover, businesses were forced to dip into cash reserves, seek funding from investors, cut jobs, or rely on credit or cyber insurance. And, in 38% of cases, pass the costs on to customers.

These attacks may not always make headlines, but their consequences are very real. Thousands of small businesses quietly struggle, or fail outright, after a cyber incident. One such example is Efficient Escrow of California, which was forced to shut down and lay off its entire staff after cybercriminals siphoned $1.5 million from its bank account using Trojan malware.

✨Takeaway: Small businesses are prime targets not due to low value, but because limited security makes them vulnerable. Accessible attack tools and valuable data mean stronger defenses, and timely patching is essential, regardless of size.

Myth 2: Low-severity vulnerabilities don’t matter

The term low-severity vulnerability often creates a false sense of safety. In security scoring systems, “low severity” typically means that a flaw has limited impact on its own, is difficult to exploit in isolation, or does not immediately expose sensitive data. It does not mean the vulnerability is harmless, irrelevant, or safe to ignore.

Severity ratings are designed to evaluate individual issues in isolation. In the real world, however, attackers don’t operate that way. They look for paths, not single weaknesses. A low-severity issue can provide just enough information or access to help an attacker move closer to their objective (often called a chain).

An example of a low‑severity vulnerability that was highly exploited was Atlassian Jira CVE‑2021‑26086. When CVE‑2021‑26086 was first disclosed, it was classified as a path traversal vulnerability with limited impact. On its own, the issue allowed unauthenticated attackers to read internal files from vulnerable Jira Server and Data Center instances, without enabling direct code execution. Because it was primarily an information disclosure flaw, it was generally considered low to medium severity, not an immediate critical threat.

However, attackers quickly showed how this “minor” issue could still be valuable:

• The path traversal enabled access to internal configuration files and metadata, providing insight into the Jira environment.
  
• Exposed information helped attackers map deployments, identify software versions, and spot additional weaknesses.
  
• The vulnerability required no authentication and affected internet‑facing Jira instances, making it easy to automate and scan at scale.
  

Within a short time, CVE‑2021‑26086 was:

• Widely scanned and exploited across the internet
  
• Used as a reconnaissance and foothold vulnerability
  
• Leveraged to support follow‑on attacks when chained with other flaws

✨Takeaway: Low-severity vulnerabilities matter because attackers can chain them into high-impact exploits. Fixing them alongside more serious issues reduces the attack surface and prevents small weaknesses from being leveraged together.

Myth 3: More tools mean fewer vulnerabilities

There’s a common belief that layering more security tools automatically reduces risk. In practice, adding tools without a clear strategy often increases complexity instead of improving security.

Security tools don’t protect systems on their own. Without proper configuration, tools may miss threats or generate excessive noise. Poor integration between tools can create blind spots, and without skilled analysis, important alerts may be ignored or misunderstood, leaving gaps in your defenses.

In many organizations, breaches don’t happen because tools are missing, but because complexity and poor integration leave gaps that attackers can exploit. A recent industry analysis describes how “security tool sprawl” creates blind spots, inconsistent alerting, and fragmented visibility that directly increase security risk. According to the survey, 41% of IT and security teams link poor integrations directly to increased risk, with disconnected tools making it harder to see threats thoroughly or automate responses. Attackers increasingly target these integration seams because fragmented stacks slow detection and response. 

When tools don’t share context or correlate alerts across environments, critical signals can be scattered across dashboards, delaying investigation and allowing attackers to operate longer without being noticed. Integrated systems and shared context are what allow security teams to connect the dots; without them, the presence of more tools can increase the attack surface instead of reducing it.

Frameworks like the NIST Cybersecurity Framework (CSF) and the MITRE ATT&CK knowledge base both emphasize process, integration, and human expertise rather than adding more tools. Similarly, ENISA highlights that effective cybersecurity requires a risk-aware, structured approach where tools are used thoughtfully, in context, and integrated into well-defined processes. 

What you can do instead:

• Configure security tools carefully and review settings regularly. 
• Integrate tools so alerts share context and reduce blind spots and noise.
• Define clear ownership and processes for investigating and responding to alerts.
• Invest in people and training.

✨Takeaway: Security isn’t about the number of tools you deploy. Effective security comes from using the right tools, integrated into clear processes, and backed by human expertise.

Myth 4: Patching is easy if you care about security

Many people believe patching is simple: apply the fix, and you’re protected. In reality, patching can be complicated. Fixes can bring compatibility issues, disrupt applications, or require extensive planning and testing before deployment. Some environments, like healthcare or financial institutions, can’t be patched immediately without careful validation to avoid affecting operational impact. 

Even security-conscious organizations sometimes delay patches. Not because they don’t care, but because teams may need time to test patches in staging environments, schedule downtime, and coordinate across dependencies to ensure continuity of service. Rushing a patch without proper preparation can create as many problems as it prevents.

A dramatic example occurred on 19 July 2024, when a routine configuration update for CrowdStrike’s Falcon endpoint security software caused systems worldwide running Microsoft Windows to crash, enter boot loops, or fail to restart properly. Roughly 8.5 million Windows devices were affected as the flawed update triggered blue screens of death and disrupted operations across airlines, hospitals, emergency services, banking systems, and government services. This was not a malicious attack, but a faulty patch that had passed automated validation before deployment, illustrating how even well-intended software updates can cause global outages when not properly tested for real-world environments. 

Best practices for effective patching:

• Keep a clear inventory of all assets.
• Prioritize patches based on risk and criticality, not just severity.
• Test patches in staging environments before deploying to production.
• Use vulnerability management tools to identify known vulnerabilities and missing patches across your systems continuously.
• Automate routine patches but keep human oversight for critical systems.
• Maintain regular patch schedule and track compliance.

✨Takeaway: Patching isn’t just about applying fixes. It requires continuous vulnerability management, planning, testing, and balancing security with operational needs.

Myth 5: CVSS scores tell the whole story

The Common Vulnerability Scoring System (CVSS) provides a standardized way to rate vulnerability severity. Many organizations rely on CVSS scores alone to prioritize fixes, which can be misleading. CVSS indicates potential impact in general terms, not the actual risk to your specific environment. 

A high CVSS score doesn’t automatically mean a vulnerability is fully understood or that your organization knows exactly where it exists. Context matters; the criticality of affected assets, network exposure, and whether active exploits exist all influence real risk. Ignoring these factors can leave serious gaps, even for vulnerabilities rated as “critical”.

An example is Log4Shell (CVE-2021-44228). It received a CVSS score of 10, the highest possible rating. Despite this, many organizations struggled to identify which systems and applications were affected because Log4j is a library that often exists deep in software dependency chains or embedded in third-party products. Teams without complete visibility or software inventory faced delays in assessing risk, even though the vulnerability itself was theoretically critical. Attackers quickly began exploiting exposed instances, demonstrating that a high CVSS score alone is not enough. Organizations must understand where and how the vulnerability exists in their environment. 

What you can do:

• Use CVSS as a starting point, not a decision on its own.
• Evaluate vulnerabilities based on your environment, asset criticality, and threat landscape.
• Use risk-based prioritization to focus remediation efforts.
• Combine CVSS with threat intelligence and visibility into your systems to guide decisions.

✨Takeaway: CVSS scores are helpful, but context is key. Understanding how vulnerabilities exist in your environment and prioritizing based on actual risk is far more important than relying solely on the number.

To sum it up

Cybersecurity fails less from ignorance than from oversimplification. Myths like “small means safe,” “scores tell the whole story,” or “more tools = better protection” create false comfort. Attackers exploit complexity, context gaps, and blind spots.

Reducing risk requires seeing what’s really happening: which vulnerabilities are exploited, how attacks unfold, and where exposure lies. Real-time exploit intelligence helps teams prioritize, respond faster, and stay ahead of emerging threats.

A big part of the problem is this: not all threat intelligence is collected the same way. Two familiar sources are honeypots and production telemetry. They can both be useful. But they do not tell you the same story.

Honeypots are great at one thing: internet weather

A honeypot is a decoy. It is meant to be found and tested. That makes it good at capturing the constant noise of the internet.

Using honeypots, you will see scans, lots of them. You will see commodity bots. You will see known CVE opportunistic exploitation attempts. This helps you understand what is trending.

If your goal is visibility into broad activity, honeypots deliver.

But there is a catch.

Honeypots can be identified and dodged

Many honeypots live on ranges that look like “lab infrastructure.” Datacenter IPs, consistent patterns, similar stacks, similar behaviors. Over time, attackers learn what these systems look like.

Even low to mid-level tooling can do basic fingerprinting. Some attackers keep lists. Others simply deprioritize anything that smells like a trap. In any case, when attackers possess valuable exploits, they use them on their targets and not indiscriminately on unknown IPs.

That creates bias. Using honeypots, you mainly observe what attackers are willing to touch blindly. You do not reliably observe what they do when money is on the line.

Another key aspect of Honeypots is that automation is essential for scaling them. Your go-to infrastructure will likely be with major cloud providers, allowing you to automate the deployment of your containers (or VMs). In this case, the distribution and variety of your honeypot network are limited to some well-known ranges of IP addresses. For the very same reason, this limits CDNs’ ability to catch threats ahead of the curve (who would use a new technique or 0-day on an exceedingly careful target?), sitting on a bunch of known ranges gives you an incomplete picture of the real world.

Production telemetry captures intent because it sits on real targets

Production workloads are the opposite of decoys. They are the objective: login pages, VPN gateways, APIs, mail servers, business apps. This is where attackers try to win.

That is why telemetry from production environments is so valuable. It captures behavior aimed at real outcomes: account takeover, fraud, API abuse, layer 7 denial-of-service, and targeted exploitation of stacks that actually run revenue.

Production telemetry is where you reliably capture valuable Indicators of Compromise (IoCs), because attackers must engage with a real service. You see real patterns, like targeted URLs, exploitation payloads, and credentials. That precious information is disclosed only when attackers know they have reached a valuable target and not wasted in a honeypot environment.

This is the core difference for a CISO: honeypots show you what exists on the internet. Production telemetry shows you what is being used against real businesses.

What “production telemetry” means with CrowdSec, in plain terms

CrowdSec’s approach is to detect malicious behavior in logs and web traffic in real time on internet-exposed workloads. The Security Engine reads, normalizes, and enriches logs from many sources, including cloud services and standard log pipelines.

Detection is contextual. It does not treat every system the same. With a VPN, it detects brute-force and credential-stuffing attempts. An e-commerce site can detect catalog theft, scalping, credit card stuffing, and Layer 7 DDoS attacks.

This is why the CrowdSec signal tends to be more “honest.” Attackers have to interact with something tangible.

Context matters more than volume

Most feeds compete on quantity. More IPs. More alerts. More “Top Attackers.”

CISOs would rather have clearer decisions and actionable insights.

The strongest signals come from context. What was attacked? How? How often? On which type of service? Whom by? Was it a new IP, a known one? Did it attempt to knock my servers using other techniques before? Was it a brute force attempt? Was it credential stuffing or injections? Was it scanning that led to exploitation? Are authentications coming from those IP addresses known to be impossible travelers?

This is where production-based detection wins. It is tied to real logs and real services. That context is what turns observations into enforceable policies, while reducing false positives to zero.

The SOC angle: richer alerts, less guesswork

SOC teams care about the “why,” not just the “what.” CrowdSec can enrich alerts with details such as username attempts, targeted URLs, scanned ports, verticals, or countries.

It also positions itself as a companion to the SIEM, and an actionable “pre-filter.” The idea is simple: triage in-stream, suppress noise, and avoid paying to store and investigate junk at scale.

Honeypots still have a role

Honeypots are not useless. They are just not sufficient on their own.

They are suitable for early warning and trend spotting. They are good for research. They help you understand the background threat landscape.

But if your goal is prevention at scale, you want intelligence that reflects real attacks against real targets. That is what production telemetry gives you. And that is the foundation CrowdSec uses. CrowdSec explicitly positions itself as different from a honeypot network for this reason: it protects real workloads from real customers that attackers actually want to monetize.

Closing thought

Honeypots tell you who is knocking on doors.

Production telemetry tells you who is trying to get in, where they are pushing hardest, and what they are trying to achieve, their “Why”.

For CISOs, that is the difference between interesting threat intel and tactical threat intel you can turn into enforcement.

On December 3rd, 2025, the React team disclosed CVE-2025-55182, dubbed React2Shell, a critical Remote Code Execution (RCE) vulnerability affecting React Server Components (RSC). With a CVSS score of 10.0 and an exploitation rate approaching 100% on default configurations, this flaw poses a severe threat to modern infrastructures that rely on React 19 and Next.js.

CrowdSec, the open source security ecosystem, reacted swiftly. Within hours of the disclosure, it released a dedicated virtual patching detection rule, once again demonstrating how collaborative defense can drastically reduce exposure time.  

Technical Analysis of React2Shell

Vulnerability Overview

CVE-2025-55182 is caused by unsafe deserialization in the Flight protocol used by React Server Components. The server-side code processes HTTP payloads without sufficient validation, allowing attackers to inject crafted objects that result in arbitrary code execution.

Affected packages (versions 19.0.0 → 19.2.0):

• react-server-dom-webpack
• react-server-dom-turbopack
• react-server-dom-parcel

Impacted frameworks:

• Next.js 15.0.4 → 16.0.6 (including canaries 14.3.0-canary.77+)
• React Router (RSC mode)
• Waku, Vite RSC, Parcel RSC
• RedwoodSDK

⚠️ Critical point: A freshly created Next.js application using create-next-appis vulnerable by default. No special configuration is required; simply enabling Server Components is enough.

Attack Scenarios

An attacker can:

• Send a malicious HTTP POST request to any endpoint
• Abuse the vulnerable deserialization logic
• Execute arbitrary server-side code
• Gain full server access
• Exfiltrate data, deploy backdoors, and pivot laterally within the infrastructure  

CrowdSec’s Response to React2Shell

A Fast, Community-Driven Reaction

One of the major strengths of open source security is its reaction speed. Just hours after public disclosure, CrowdSec released a dedicated detection rule: vpatch-CVE-2025-55182

How the Detection Rule Works

The vpatch-CVE-2025-55182 rule focuses on identifying real-world exploitation attempts of React2Shell by correlating multiple strong signals, significantly reducing false positives:

• HTTP POST method -> Exploitation relies on server-side form submissions.
• Presence of React Server Action headers (next-action, rsc-action-id) -> strong indicators of RSC/Next.js flows.
• Tampering with internal Flight parameters (status, resolved_model) -> sensitive fields involved in the vulnerable deserialization logic.
• Suspicious $@ payload pattern -> Known signature associated with React2Shell injection techniques.

By correlating these indicators, CrowdSec detects exploitation attempts even in the absence of a publicly available working exploit, making this rule an effective preventive virtual patch.

Installing the CrowdSec Virtual Patch

If you already run CrowdSec with the AppSec (WAF) component, enabling protection against React2Shell is straightforward:

cscli appsec-rules install crowdsecurity/vpatch-CVE-2025-55182 

Within seconds, the AppSec engine begins detecting and mitigating exploitation attempts targeting CVE-2025-55182.

Adding the React2Shell CrowdSec Blocklist

In addition to application-layer detection, CrowdSec also provides a dedicated React2Shell IP blocklist, built from real-world exploitation attempts observed across the community. This blocklist aggregates source IPs actively exploiting CVE-2025-55182 and allows defenders to block attackers at the network or firewall level, before requests even reach the application.

Benefits of using the blocklist:

• Blocks known React2Shell attackers globally
• Reduces load on the application and WAF
• Complements AppSec virtual patching with network-level enforcement
• Automatically updated through CrowdSec’s threat intelligence

The React2Shell blocklist is available here: 👉 https://app.crowdsec.net/blocklists/6936fb6f5f136d434bcbd4af

Important: Patch Your Dependencies

While CrowdSec provides immediate protection, virtual patching does not replace vendor fixes.

To fully remediate React2Shell, ensure you update:

• React 19.x -> patched release
• Next.js -> official security release published by Vercel

Applying these updates removes the vulnerability at its source and should be done even if CrowdSec is already deployed.  

Conclusion

CVE-2025-55182 (React2Shell) is a maximum-severity vulnerability with widespread impact across the modern React ecosystem. However, it also highlights the effectiveness of *collaborative open-source security.

👉 CrowdSec delivered a detection rule within hours, enabling organizations to defend themselves immediately through virtual patching.

Recommended actions for all organizations using React Server Components:

1. Apply official patches as soon as possible
2. Deploy CrowdSec AppSec with the virtual patching collections
3. Monitor exploitation attempts targeting RSC endpoints
4. Continuously test detection and response (Purple Team approach)

React2Shell is a clear reminder that fast detection, shared intelligence, and community-driven defense are essential to securing modern web stacks.

Additional Resources

• Detecting React2Shell: The maximum-severity RCE Vulnerability affecting React Server Components and Next.js
• Security Advisory: CVE-2025-66478
• React2Shell (CVE-2025-55182)