Navigating the Noise: Separating Security Reality from Hype

Introduction

In the cybersecurity landscape, sensational headlines and alarming vulnerability disclosures are commonplace. Recent events have been a whirlwind, with claims of massive data breaches and widespread vulnerabilities affecting critical infrastructure. From the overstated impact of Next.js middleware vulnerabilities to the exaggerated reach of Nginx ingress issues, it's clear that the cybersecurity community needs a reality check.

Vulnerability researchers at Bitsight understand the importance of accurate, contextualized information. In this blog, we'll address the trend of over-hyped vulnerabilities, the potential for CVSS score inflation, and how Bitsight's robust triage and prioritization engine helps CISOs and security teams cut through the noise to focus on what truly matters.

Next.js middleware: Reality vs. hype

Following the discovery of CVE-2025-29927 in Next.js middleware, initial claims suggested that over 500,000 instances were potentially vulnerable. However, our research indicated that the actual number was significantly lower—by an order of magnitude. 

This vulnerability was disclosed by Rachid Allam, who did a very good analysis on it, and ever since it was released, we’ve also been investigating it in order to determine if it was possible to create a detection capability for it. The vulnerability specifically affects the middleware functionality in Next.js, which, according to the documentation:

“Middleware allows you to run code before a request is completed. Then, based on the incoming request, you can modify the response by rewriting, redirecting, modifying the request or response headers, or responding directly.”

The fact that it only affects the middleware functionality in Next.js is a small detail that has a big impact on the total number of instances that may be exposed. Detecting whether or not middleware is running is not hard, and we just need to look for a response header that contains any of the following: x-nextjs-redirect, x-middleware-rewrite, or x-nextjs-rewrite.

Using this technique, we were able to get a clear picture of the vulnerable landscape using our own scanner, which showed that from a total of ~307k Next.js instances, less than 15k were running Middleware, or 4.88%.

We then focused on the vulnerability itself. Looking at the vulnerable code that is also available in the original disclosure, we can see that it occurs when the header x-middleware-subrequest is used and it originates from a design flaw in how Next.js processes this header. 

const subreq = params.request.headers["x-middleware-subrequest"];
const subrequests = 
  typeof subreq === "string"
    ? subreq.split(":")
    : [];
if (subrequests.includes(middlewareInfo.name)) {
  result = {
    response: NextResponse.next(),
    waitUntil: Promise.resolve()
  };
  continue;
}

This header is used to determine if the middleware should be applied or not. The header value is split to create a list using the column character “:” as a separator, and then checks if this list contains the middlewareInfo.name value. This means that by adding the x-middleware-subrequest header with the correct value to a request, an attacker can completely bypass any middleware-based protection mechanism.

A couple of x-middleware-subrequest header values were initially released that depended on the version that was running.

For versions before 12.2

• x-middleware-subrequest: pages/_middleware
• x-middleware-subrequest: pages/dashboard/_middleware

For 12.2 and later

• x-middleware-subrequest: middleware
• x-middleware-subrequest: src/middleware

For 13.2.0 and later

• x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware
• x-middleware-subrequest: src/src/middleware:src/middleware:src/middleware:src/middleware:src/middleware

An interesting analysis from assetnote discovered that all of the headers above could be replaced by one that would work no matter what version of Next.js was running. During our testing, we were already combining multiple header values to decrease the number of requests needed to detect vulnerable instances, but this allowed us to be much more efficient.

• x-middleware-subrequest: src/middleware:nowaf:src/middleware:src/middleware:src/middleware:src/ middleware:middleware:middleware:nowaf:middleware:middleware:middleware:pages/_middleware

Because this is an authorization bypass, we found 2 common resources that are usually protected - /dashboard/admin and /admin/login, and to detect this vulnerability and avoid false positives, the following workflow was used:

• We first start by detecting all Next.js instances, and of those, the ones running Middleware. 
• After that, we perform a request to /dashboard/admin to confirm we have a 404 Not Found status code, and if so, we repeat the same request, but this time using the vulnerable x-middleware-subrequest header, bypassing any authorization mechanism in place. If we get a 200 OK status code, we can safely determine it is, in fact, a vulnerable instance. 
• This process may be repeated for the endpoint /admin/login if it fails to determine vulnerability status using /dashboard/admin.

After creating the new detection capability for this CVE, we ran another scan, and the results showed that only a very small number of instances running Middleware were actually vulnerable to CVE-2025-29927.

From a total of 14974 instances we found running Middleware, only 343 were vulnerable, a number significantly lower than the original estimates of 500,000.

Although the original estimates were exaggerated, it is worth noting that the CVSS remains at 9.1 and the EPSS at 0.85, even though certain pre-requisites need to be met for an instance to be considered vulnerable, let alone exploitable. It is also interesting to note that CVE-2025-29927 was not added to the CISA Known Exploited Vulnerabilities List (at the time of this writing).

Ingress NGINX IngressNightmare: Separating signal from noise

Initial reports of an Ingress nginx kubernetes vulnerability warned of a widespread security flaw CVE-2025-1974 in ingress-nginx admission controllers, suggesting that 43% of cloud setups and about 6,500 Kubernetes clusters were vulnerable to remote code execution (RCE) and potential full cluster control from an unauthenticated attacker. This vulnerability came alongside several specific injection points to reach the vulnerable functionality in CVE-2025-1097, CVE-2025-1098, CVE-2025-24513, and CVE-2025-24514. Again, our research indicated that the actual number of vulnerable systems was significantly lower.

From its description, “ingress-nginx is an Ingress controller for Kubernetes using NGINX as a reverse proxy and load balancer.” It is essentially an NGINX instance wrapped in a Kubernetes pod. However, it also exposes an admission controller designed to validate potential ingress configurations.

Notably, after validating some of the parameters, the admission controller will fill in a template to generate an actual NGINX configuration file, and then validate it using the nginx -c <filename> -t test command.

The original Wiz advisory does a great job of explaining exactly how this can be abused to achieve Remote Code Execution. As long as attackers can:

1. Inject arbitrary inputs into the temporary file and
2. Get the system to run it through nginx -t, they are well on their way to success.

We noticed that the patch addresses this issue by

1. Validating the inputs and sanitizing the outputs of more of the input annotations to prevent attackers from injecting arbitrary content
2. At least temporarily commenting out the call to testTemplate to disable the nginx -t usage

We quickly realized that the simplest way to test for the presence of this vulnerability would be to inject something invalid into the temporary configuration file to induce a known syntax error when validated through nginx -t.

This did come with one potential issue: notice that the temporary file will not be deleted if there is an error returned on line 665 above. We were concerned that testing for this vulnerability would leave behind invalid configuration files that could use up limited storage space and cause harm to the affected hosts. However, we were able to put this concern to rest and prove that all temporary configuration files should be deleted approximately every 5 minutes, giving us reasonable leeway and reinforcing that this is the intended application behavior.

Our task then became to choose a good request that we could use to probe for syntax errors. ProjectDiscovery published a great writeup containing an example nuclei template to probe for vulnerable instances (see here and search for “Vulnerable Exposed Admission Controller Template”).

However, one issue with this template is that it makes use of CVE-2025-24514 to inject content into the configuration file, specifically the “auth-url” annotation parameter. As noted by the Kubernetes advisory, this particular CVE has an additional mitigation and different vulnerable versions from the other CVEs in the family. There is nothing wrong with using this particular type of request to probe for CVE-2025-24514, however it will lead to false-negatives if used to probe for the other CVEs in certain cases.

Therefore, we needed to figure out how to use one of the other injection CVEs to our advantage. In the end, we settled on CVE-2025-1098, making use of the “mirror-target” and “mirror-host” annotations.

Here is the relevant “metadata” for our probe request, given in the form of a Python dictionary with a randomized hostname value (we noticed after our first scan that there were misleading results if the instance had already configured a service with the given hostname, so we aimed to avoid this). The mirror-target itself just needs to be any valid value. This type of value was taken directly from the documentation. The uid is the true target, since it will be injected verbatim with no sanitization into the configuration file. In this case, we inject a single semicolon to mess with the balance of curly braces in the file.

This will be the corresponding section of the config file. Notice the extra curly brace present on the first line:

If the system injects this block into the file and runs it through nginx -t, we should expect to see an error message complaining about the imbalanced braces:

In short, we identified vulnerable instances by examining their TLS certificates (looking for subject organization "nil2" and issuer organization "nil1" along with an “nginx” Subject Alternative Name, following the suggested nuclei template). We then confirmed the vulnerability by injecting a deliberately incorrect configuration that caused a diagnostic error output complaining about imbalanced curly braces.

Our investigation using active scanning techniques showed a different picture than the initial article suggested. We scanned roughly 500,000 Kubernetes instances globally and found only 3,236 confirmed vulnerable instances out of 4,032 where ingress-nginx was detected. This number aligns more closely with the 6,500 cluster estimate cited in the blog, when considering limitations in complete network visibility. The claim that "43% of cloud environments are vulnerable to RCE" appears to be a significant overestimation based on our findings. Importantly, the number of exposed instances we detected decreased from 4,272 to 4,032 after one week, indicating that users are actively taking steps to address this issue.

Exploiting CVE-2025-1974 requires network access to the ingress-nginx admission controller endpoint, which is usually exposed on TCP port 8443. While ingress-nginx is present in about 40% of Kubernetes environments, successful unauthenticated exploitation needs direct network access to this specific service. Our analysis reveals several factors that limit the exploitability of this vulnerability:

• Customized annotation prefixes: Organizations use non-standard prefixes for ingress annotations.
• Read-only filesystem mounts: The admission controller might be running with a read-only filesystem, preventing the creation of malicious configuration files.
• Insufficient disk space: Limited space could prevent the writing of malicious configuration files.
• Network policy implementations: Network policies might restrict incoming traffic to the admission controller endpoint.

Contrary to the initial broad warnings, our data indicates that less than 1% of the environments we scanned show exploitable conditions (3,236 / 500,000). Again, it is interesting to note that CVE-2025-1974 was also not added to the CISA Known Exploited Vulnerabilities List (at the time of this writing).

The problem of CVSS bias: Inflation and deflation

One of the factors contributing to this hype is the manipulation of CVSS (Common Vulnerability Scoring System) scores, which manifests in both inflation and deflation patterns.

CVSS inflation

CVSS inflation refers to the systematic overestimation of vulnerability severity scores, leading to a distorted view of actual security risks. While CVSS provides a standardized way to assess vulnerability severity, it can sometimes be misused or misinterpreted. Researchers may inadvertently or intentionally inflate scores to draw attention to their findings, driven by factors such as:

• Desire for research visibility and recognition
• Competition for limited security resources and attention
• Media coverage that favors higher-severity vulnerabilities
• The pursuit of speaking engagements or professional advancement
• Pressure to demonstrate the value of security research

CVSS deflation

Conversely, CVSS deflation occurs when vendors attempt to minimize the perceived severity of vulnerabilities in their own products. This phenomenon is equally problematic and often manifests through:

• Strategic application of environmental and temporal metrics to reduce overall scores
• Downplaying exploitability factors by citing deployment configurations that may not reflect real-world usage
• Emphasizing mitigating factors that exist only in theory or require perfect implementation
• Lobbying NVD and other vulnerability databases for score revisions
• Delaying disclosure until patches are available, then factoring the existence of patches into scoring

The inherent ambiguity of CVSS

The CVSS framework itself contributes to these issues. Despite detailed scoring rubricks there are  inherent ambiguities in the scoring process:

• Subjective interpretation of metrics like "attack complexity" and "privileges required"
• Inconsistent application of scoring guidelines across different organizations
• The gap between Base, Temporal, and Environmental scores, with most public discourse focusing only on Base scores
• Limited accommodation for application context and business impact
• Difficulty in accounting for vulnerability chains or compound vulnerabilities
• The one-dimensional nature of a numerical score attempting to represent multi-dimensional risk

This manipulation—both inflation and deflation—can lead to alert fatigue, resource misallocation, and decreased credibility in vulnerability reporting. Security teams may chase down overhyped vulnerabilities while missing genuinely critical issues that have been downplayed. The result is a vulnerability management landscape where the signal-to-noise ratio becomes increasingly problematic.

CVSS scores in a vacuum

CVSS scores are deliberately context-agnostic. They don't know that your "medium" 5.5 vulnerability sits on your crown jewel database, while that "critical" 9.8 affects a system buried behind three layers of network isolation. The scores won't tell you that yesterday's "high" vulnerability just appeared in a ransomware group's toolkit, dramatically increasing its real-world risk overnight.

Consider Log4Shell—yes, it deserved its perfect 10.0 score, but did every instance deserve the same urgent response? Organizations that prioritized internet-facing applications first demonstrated understanding beyond the score. Meanwhile, security teams treating all CVSS 9+ vulnerabilities equally often find themselves drowning in patches while missing contextually critical issues that might score lower but represent their organization's actual attack paths.

Effective vulnerability management requires looking beyond the numbers. Overlay asset criticality, threat intelligence about active exploitation, existing security controls, and business impact to transform those abstract scores into meaningful prioritization. Your adversaries aren't selecting targets based on CVSS scores—they're looking for the path of least resistance to your most valuable assets.

Bitsight's approach: Accurate triage and prioritization 

At Bitsight, we understand that security teams are overwhelmed with vulnerability data. That's why we've developed a sophisticated triage and prioritization engine that goes beyond simple CVSS scores.

• Dynamic Vulnerability Exploit (DVE) scores: Our proprietary DVE score delivers immediate, AI-cultivated CVE risk assessments within hours of publication. By complementing traditional static scoring systems like CVSS with real-time threat intelligence and underground cybercriminal activity, security teams can focus on the vulnerabilities that pose the greatest risk to their organization.
• Contextual analysis: Our engine analyzes vulnerabilities in the context of real-world deployments, considering factors such as exploitability, asset criticality, and environmental factors.  
• Continuous scanning: We continuously scan our customers' attack surface to identify and validate vulnerabilities, providing up-to-date and accurate information.
• Actionable intelligence: We deliver actionable intelligence that helps security teams prioritize remediation efforts based on actual risk, not just theoretical severity.  
• Proven results: As demonstrated with the Next.js and Nginx vulnerabilities, our engine cuts through the hype to provide a realistic assessment of risk. We identified that the actual number of vulnerable systems was orders of magnitude lower than initial reports, allowing our customers to focus on real threats.

Why this matters to you

• Reduced alert fatigue: By providing accurate risk assessments, Bitsight helps security teams focus on the most critical vulnerabilities, reducing alert fatigue.
• Improved resource allocation: Our prioritization engine ensures that resources are allocated effectively, maximizing the impact of security efforts.
• Enhanced decision-making: CISOs and security leaders can make informed decisions based on reliable data, rather than relying on sensational headlines.

Looking ahead

The cybersecurity landscape will continue to be filled with noise and hype. However, by relying on trusted sources of information and robust risk assessment tools like Bitsight, organizations can effectively manage their security risks.

Conclusion

In a world filled with security alarms, Bitsight stands as a beacon of clarity. We empower our customers with the accurate, actionable intelligence they need to protect their organizations and navigate the complexities of modern cybersecurity.