A Critical Remote Code Execution (RCE) vulnerability, identified as CVE-2025-55182, has been discovered in Next.js applications utilizing React Server Components (RSC) and Server Actions. This vulnerability stems from insecure deserialization within the underlying “Flight” protocol used by React. Unauthenticated remote attackers can exploit this flaw to execute arbitrary code on the server, potentially leading to a complete compromise of the application and underlying system.

Given the widespread adoption of Next.js and the critical severity of the flaw (CVSS 10.0), immediate action is required.

Affected Products

The vulnerability affects the React Server Components ecosystem, which is heavily integrated into modern frameworks like Next.js. Specifically, it impacts the react-server-dom-parcel, react-server-dom-turbopack, and react-server-dom-webpack packages.

Affected Versions:

• React Server Components: Versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0.
• Next.js: Applications using App Router (Next.js 15.x, 16.x) or experimental Server Actions are likely affected by default.

Vulnerability Details

CVE-2025-55182 is an insecure deserialization vulnerability that occurs at “Server Function endpoints.”

The flaw exists because the server-side handler for the React “Flight” protocol unsafely deserializes payloads from HTTP requests. The server fails to properly validate serialized input before processing it. An attacker can trigger this vulnerability by sending a specially crafted POST request to the root path containing:

1. Specific Next-Action headers.
2. Malformed multipart data payloads.

When processed, this malformed payload triggers the insecure deserialization, allowing the attacker to inject and execute malicious code remotely.

Detection

Detectify customers can now test whether their applications are exposed to this RCE.

The vulnerability assessment released by Detectify checks for the presence of the insecure deserialization flaw by sending a specially crafted POST request to the root path with Next-Action headers and malformed multipart data. The test safely identifies the vulnerability by observing specific error responses from the server that confirm the deserialization failure, without executing malicious code.

Mitigation

Upgrade Immediately: The most effective mitigation is to upgrade the affected packages to their patched versions.

• React Server Components: Upgrade react-server-dom-* packages to versions 19.0.1, 19.1.2, or 19.2.1 (or later).
• Next.js: Upgrade to the latest patch release for your major version (e.g., Next.js 15.0.5+, 16.0.7+).

If immediate patching is not feasible: You may be able to mitigate the risk by applying Web Application Firewall (WAF) rules to block requests containing suspicious Next-Action headers or malformed multipart bodies, though this is not a substitute for patching.

Patch availability

The vulnerability is fixed in the following versions:

• React Server Components: 19.0.1, 19.1.2, and 19.2.1.
• Next.js: Various patch releases (check the official Next.js release log for your specific version branch).

Users are strongly advised to update to these versions.

Customers can always find updates in the “What’s New at Detectify” product log. Any questions can be directed to Customer Success representatives or Support. If you’re not already a customer, click here to sign up for a demo or a free trial and immediately start scanning. Go hack yourself!

References
Vendor Advisory 

The post Security Update: Critical RCE in React Server Components & Next.js (CVE-2025-55182) appeared first on Blog Detectify.

At ManagedMethods, we’re always listening and thinking about how we can make our cybersecurity, student safety, and classroom management products simpler and more effective for educators and IT leaders.  This Fall, we’re excited to share several new updates across both Classroom Manager and Cloud Monitor, designed to help districts improve student engagement, streamline digital class ...

The post What’s New in Cloud Monitor & Classroom Manager: Smarter Tools for K–12 Classrooms appeared first on ManagedMethods Cybersecurity, Safety & Compliance for K-12.

The post What’s New in Cloud Monitor & Classroom Manager: Smarter Tools for K–12 Classrooms appeared first on Security Boulevard.

Six months after launch, Alfred, the AI Agent that autonomously builds security tests, has revolutionized our workflow. Alfred has delivered over 450 validated tests against high-priority threats (average CVSS 8.5) with 70% requiring zero manual adjustment, allowing our human security researchers to concentrate on more complex, high-impact issues. 

Now, we’re elevating Alfred’s capabilities by integrating real-world threat actor intelligence directly into its core system. This significant enhancement ensures that Alfred immediately prioritizes and generates tests for the most alarming, actively weaponized CVEs, dramatically increasing the speed and relevance of protection for all Detectify customers.

A deeper focus on threat actors

When we first built the vulnerability catalog that Alfred uses to source its assessments, the initial focus was identifying which CVEs were being utilized by Advanced Persistent Threats (APTs) and other active threat actors. Up until now, the system has primarily sourced raw vulnerability data (CVEs, along with their exploitability likelihood). However, in the spirit of our original intent, we’ve overhauled the pipeline to directly integrate active threat intelligence. 

This means that the vulnerability catalog used to feed the Alfred pipeline now sources two critical elements: vulnerabilities AND threat actors.

This change allows Alfred to place immediate and explicit emphasis on the CVEs that are being actively exploited by malicious actors in the wild. Alfred ensures that the most dangerous, actively weaponized CVEs are prioritized first for test generation and deployment onto the Detectify platform by adding up-to-the-minute threat actor behavior into our prioritization model.

Capturing even more relevant hits

In addition to this enhanced threat intelligence sourcing, we have also optimized Alfred’s processing pipeline. This alteration is designed to capture an even broader scope of relevant CVEs: specifically, those with a high likelihood of translating into actionable security tests that will help our customers find vulnerabilities in their assets.

We’re excited to deliver continuous and even higher-value security research by combining the power of the Detectify Crowdsource community with our AI Researcher Alfred.

The post Detectify AI-Researcher Alfred gets smarter with threat actor intelligence appeared first on Blog Detectify.

Our API scanner can test for dozens of vulnerability types like prompt injections and misconfigurations. We’re excited to share today that we’re releasing vulnerability tests for OAuth API authorization for organizations that use JWT tokens. These JWT, or JSON Web Tokens, are meant to prove that you have access to whatever it is you are accessing. One of the most critical JWT vulnerabilities is algorithm confusion. This occurs when an attacker tricks the server into verifying the token’s signature using a different, less secure algorithm than intended. There are plenty of other issues that can go wrong with managing JWT, which is why having a test to catch these misconfigurations is so useful. 

Our API scanner can now detect a variety of misconfigurations that occur with JWT, like timestamp confusion or even manipulating the header with ‘none.’  This will help mitigate the risk of misconfigurations that come up when things like managing complex infrastructure is a daily part of an AppSec team’s scope. 

So, how are we able to release new types of vulnerability tests that are outside of the OWASP API Top Ten or publicly available CVEs? 

When we set out to build our API scanning engine, we faced a fundamental choice: wrap an existing open-source tool like ZAP, or build something from the ground up. Unlike other vendors, we chose the latter. While open-source tools are invaluable to the security community, we believe our customers deserve more than repackaged checks and noisy results. To deliver on that, we engineered a proprietary engine guided by three core principles:

1. Dynamic Payloads. Traditional API scanners run the same tests, and if your API hasn’t changed, you get the same results. This can create a false sense of security. We’ve taken a different approach. Our engine uses dynamic payloads that are randomized and rotated with every scan. This means that each scan is a unique event, a novel attempt to find vulnerabilities that static checks would miss. Even in an unchanged API, our scanner offers a continuous opportunity for discovery.
   
2. Massive Scale, Reproducible Results. Our dynamic approach doesn’t come at the cost of consistency. It allows for a massive scale of test variations. For certain tests, like prompt injection, the number of potential payload permutations is theoretically over 922 quintillion. For command injections, we draw from a library of over 330,000 payloads. This isn’t chaos; it’s controlled and predictable randomization. We use a “seed” for each scan, much like a seed in Minecraft generates a specific world. This allows us to precisely reproduce the exact payload that identified a vulnerability, ensuring our findings are always verifiable and actionable for your developers. 
3. Research-Led, High-Fidelity Findings. Our engine is the product of our internal security research team—the same team that powers the rest of Detectify. We prioritize exploitability, meaning we attempt to actually exploit a vulnerability rather than simply flagging a potential issue. This, combined with our proprietary fuzzing technology with a history of finding zero-days, results in high-accuracy findings you can trust. This drastically reduces the time you would otherwise waste on triaging false positives, allowing you to focus on what matters.

Research-led vulnerability testing means that our engines don’t rely on publicly available information.

Detectify builds and maintains its scanning engines in-house to tailor them specifically for modern application architectures. This approach is designed to yield more accurate results for custom applications by better understanding complex logic and API-driven front-ends. In contrast, general-purpose open-source engines can struggle with the nuances of modern apps and APIs.

Why does this matter to AppSec teams? Simply put, reduced noise. Many security vendors today rely heavily on open-source tooling, meaning no steps are taken by the tool to reduce noise. By building its own engines, Detectify can implement methodologies like testing for OAuth authorization, which helps curb the time users spend validating vulnerabilities.

This means that our API Scanner is not only dynamic in how it tests for vulnerabilities, but also not limited by what is possible at the moment 

One piece of feedback we’ve regularly received from our customers is that they find the breadth of coverage really useful. Not only can we discover high and critical vulnerabilities, but we can also find issues like misconfigured JWT tokens and missing security headers, something that isn’t commonly available in API scanners.

We can deliver this kind of experience to our users because our engines are built with the AppSec team in mind, meaning that we consider the use cases that our users need.  

Detectify’s research-led approach and proprietary fuzzing engine deliver high-fidelity, actionable results that empower AppSec teams to secure their APIs with confidence – try our API scanner to experience the difference.

The post New API testing category now available  appeared first on Blog Detectify.

We know the importance of staying ahead of threats. At Detectify, we’re committed to providing you with the tools you need to secure your applications effectively. This update covers our new Dynamic API Scanning feature, updates over the last few months, and the latest additions to our vulnerability testing capabilities. 

What have we shipped to customers over the last few months?

Introducing Dynamic API Scanning

We’re excited to announce the launch of Dynamic API Scanning, now integrated into the Detectify platform. As APIs become increasingly critical to modern applications, they also present a growing attack surface. Our new API Scanning engine is designed to provide you with unified visibility and research-led testing for your APIs.

Key capabilities include:

• Comprehensive Vulnerability Coverage: We test for a broad range of vulnerabilities, including the OWASP API Top 10, to ensure your APIs are protected against the most critical threats.
• Unified Platform: By integrating API scanning into the Detectify platform, we provide a single pane of glass for managing the security of your entire attack surface.

This new feature will help you tackle challenges such as incomplete API inventories and the use of disparate testing solutions. The new API Scanner uses an advanced dynamic approach where the payloads used for testing are randomized and rotated with every single scan, meaning that every scan that we run against customer API is going to be unique; something that we never scanned before. Read more about Dynamic Payloads here.

Get started with Detectify API Scanning with this guide.

Not sure what to scan? We do. 

Prioritizing deep application scanning across hundreds of assets is a significant challenge. To solve this, our new Scan Recommendations feature helps you move from guessing to certainty. It analyzes your attack surface to identify complex, interactive web apps and recommends them for deeper scanning, ensuring your most critical assets are always covered.

Detectify now presents asset classification in a single view

To decide what to test, you first need to know what each asset does. Our new Asset Classification feature automates this by analyzing and categorizing your web assets (e.g., rich web apps, APIs). This gives you the insight needed to prioritize security testing and ensure your attack surface is covered.

We’ve also made major improvements to how Detectify performs

New improved subdomain discovery with 3x wordlist

We’ve enhanced active subdomain discovery. It now runs recursively to find deeply nested subdomains and uses a wordlist that is three times larger. This expanded wordlist is explored over time to uncover obscure assets with minimal impact. To support these improvements, passive subdomain discovery must be enabled to run active discovery.

Filter Vulnerabilities based on a modification timestamp via API

We’ve improved vulnerability filtering in the API. The vulnerabilities endpoint now returns a <modified_at> timestamp that updates on any change, including manual actions. This allows for more granular queries using the new <modified_before> and <modified_after> filters.

We released a lot of new tests thanks to Alfred, Crowsource, and our internal Security Research team.

This product update would be very, very long if we listed all of the new vulnerabilities we implemented thanks to our Alfred, our AI Security Researcher, Crowdsource, and our incredible team of Security Researchers. So, you can check out all of our new tests here.

The post Product update: Dynamic API Scanning, Recommendations & Classifications, and more appeared first on Blog Detectify.

What if we told you that our newly released API Scanner has 922 quintillion payloads for a single type of vulnerability test? A quintillion is a billion billion – an immense number that highlights the limitations of traditional API security testing. Old methods like relying on signatures, vulnerability-specific payloads, or a fixed set of fuzzing inputs just aren’t enough anymore, especially when dealing with custom-built software and unique API endpoints.

A fixed set of payloads can’t find new and unknown vulnerabilities. The future (now present) of API security testing requires a new approach that can generate a nearly infinite set of payloads to keep pace with new and evolving threats, such as Prompt Injection. 

In security testing, a payload is a specific string of text or data designed to interact with an application in an unintended way. For instance, a payload for an SQL Injection attack might be ‘ OR 1=1–, while a Cross-Site Scripting (XSS) payload could be <script>alert(‘XSS’)</script>. A payload for a Prompt Injection vulnerability could look like this:

Traditional API security scanners use static word lists, which are files containing a finite number of known payloads. Traditional scanners limit the volume of payloads they test for. If they were to attempt to test a massive array of payloads, it would be slow and costly for the vendor to execute. This brute-force approach is fundamentally limited because it can only find what it knows to look for.

A more advanced approach to API fuzzing (a security testing technique that involves feeding malformed or unexpected data into an application to see how it responds) relies on a basically “infinite” body of payloads. Instead of relying on a finite list, the security tool can generate a virtually limitless number of unique payloads on the fly. But with a list this large, how does a tester or a security scanner manage what to test? The answer lies in the seed number.

What is the “seed number” concept?

Much like a seed in the game Minecraft generates a unique and expansive world, a seed number for API fuzzing deterministically generates a specific subset of payloads from an “infinite” list. This ensures that the same seed will always produce the same payloads, which allows for reproducible and manageable scans without the need to store a massive word list. The new API scanner can generate a nearly infinite set of payloads, with over 922 quintillion for prompt injection alone, which allows it to try new things with every scan while still running all the standard tests.

How can machine learning make scanning smarter?

The true power of the seed number approach is leveraged when combined with machine learning principles. The system can learn from past scans and prioritize the most effective seeds. In the visual example above, for example, if seed 5684 consistently finds Prompt Injection vulnerabilities across various APIs, the security tool can “learn” that this seed is highly effective and prioritize using it for future scans on similar targets.

• String Manipulation: Appending or prepending special characters like !@#$, <>.
• Data Type Fuzzing: Replacing an integer with a string, or a boolean with a number.
• Format String Attacks: Injecting format specifiers like %n, %s, or %x to test for format string vulnerabilities.

This dynamic approach can find novel vulnerabilities that a static word list could never anticipate by generating payloads in real time based on the application’s responses. 

How does API vulnerability detection work?

Let’s look at <seed 5684> with corresponding <payload B!>. The API Scanner sees the target API as a “black box”. It doesn’t need to understand the underlying logic of the API. It sends a series of requests (some with clean data, and some with the mutated, seeded payloads) and it analyzes the responses from the server, looking for anomalies.

The key to detection is response comparison. A clean request should yield a predictable response, while a malicious or fuzzed request might trigger an unexpected change. This could manifest as:

• A 500 Internal Server Error: A common indicator that an injected payload has caused an unhandled exception on the server.
• A 403 Forbidden or 401 Unauthorized: If an API returns one of these status codes for a request, it indicates that a user lacks the necessary permissions. The goal is to then send a specific payload that “flips” this response to a 200 OK. If successful, there is proof of a filter, authentication, or authorization bypass, confirming a broken access control vulnerability.
• Unexpected changes in response content: For example, an injected payload might cause the server to return database error messages or system file contents, or something as subtle as a deviating content length or longer response times.

The system flags these changes and presents them. This simple, response-based logic allows the tool to be highly effective and accurate without needing a deep understanding of the API’s internal workings. The engine takes this a step further by attempting to actually exploit the vulnerability, which reduces false positives and provides high-fidelity, actionable findings.

Conclusion

API security is moving away from static, reactive methods and towards a proactive, intelligent, and scalable model. Concepts like the seed number and mutation-based fuzzing, which can generate a virtually limitless attack surface to test against, help ensure that a security posture is as dynamic as the threats that organizations face. 

We can’t afford to only test for what is considered the norm. A truly effective security tool must go out of its way to find hidden parameters, unconventional routes, and unexpected states that would otherwise go unnoticed by most scanners. 

Try out our new API Scanner with dynamic fuzzing to see it in action. Book a demo here. 

FAQ

Q: What is the main problem with traditional API security scanners? A: One of the main problems is their reliance on static, finite word lists of known payloads, which makes them ineffective against new, mutated payloads that attackers are constantly developing.

Q: How does a seed number help with API fuzzing? A: A seed number deterministically generates a specific, reproducible unique set of payloads from a much smaller list, allowing for manageable and repeatable scans without needing to store a massive word list. This is why the new API scanner is able to achieve massive scale while ensuring reproducible results.

Q: What does Detectify look for to detect a vulnerability? A: It looks for anomalies in the server’s response after a fuzzed request, such as a 500 Internal Server Error, a 403 Forbidden status, or unexpected changes in the response content, compared to a clean request.

The post Infinite payloads? The future of API Testing with dynamic fuzzing appeared first on Blog Detectify.

Application environments are more complex than ever, with APIs forming the critical connective tissue. But this proliferation has created a vast, often invisible, attack surface. Security teams are caught in a difficult position: compliance frameworks like PCI and SOC 2 demand API scanning, but offer little guidance. Meanwhile, you’re grappling with incomplete API inventories, and the market is a confusing mix of expensive, hard-to-instrument niche tools.

You need a way to see everything on your attack surface from web apps to APIs, test what matters most, and do it all without derailing your existing workflows.

We are excited to introduce advanced API Scanning, fully integrated into the Detectify platform.

A new approach to a growing problem

We built our API scanner to address the specific challenges we heard from security teams. You told us you needed to:

• Gain a complete API inventory without wrestling with poor documentation.
• Confidently fulfill compliance needs with a clear, defensible testing process.
• Consolidate tools and manage API testing within your existing AppSec program.

Our new capabilities are designed to do exactly that in combination with our intelligent scan recommendations and asset classification, providing unified visibility and research-led testing across your entire attack surface.

What makes the Detectify API scanner engine unique?

When we decided to build API scanning, we made an active choice not to simply wrap an existing open-source tool like ZAP. We believe our customers deserve better than repackaged checks and noisy results. Instead, we built our own proprietary engine from the ground up, focused on three key principles:

1. Dynamic Payloads: Every Scan is Unique

Static API scanners run the same checks time and time again. If your API hasn’t changed, you get the same results, creating a false sense of security. Our engine is different.

We use a dynamic approach where the payloads used for testing are randomized and rotated with every single scan. This means, as one of our engineers put it,

“every scan that we run against the customer’s API is going to be unique – something that we never scanned before”.

This creates a continuous opportunity to find new vulnerabilities that static checks would miss, even in an unchanged API.

2. Massive scale, reproducible results

Our dynamic approach allows for a massive scale of test variations. For certain tests like prompt injection, the number of potential payload permutations is theoretically over 9.2 quintillion. For command injections, we utilize a library of over 330,000 payloads.

But this isn’t chaos. The randomization is predictable. Using a “seed” – much like how a seed in Minecraft creates a specific world – we can precisely reproduce the exact payload that found a vulnerability, ensuring our findings are always verifiable and actionable for your developers.

3. Research-led, high-fidelity findings

Our engine is built by the same internal security research team that powers the rest of Detectify. We focus on exploitability, meaning we try to actually exploit the vulnerability rather than just flagging a potential issue. This approach, combined with our proprietary fuzzing technology that has a history of finding zero-days, results in high-accuracy findings you can trust, drastically reducing the time you waste on triaging false positives.

What does Detectify API scanning mean for you?

• Unified API Visibility: With Surface Monitoring, we map out your attack surface and classify the assets into categories like APIs and Web apps. You combine discovered API endpoints with the ones you upload, providing a unified inventory so you can prioritize scanning across your entire attack surface, not just the parts you already know about.
• Broad Vulnerability Coverage: We go deep on injection tests and also cover a wide range of other categories, including Broken Authentication and Security Misconfigurations in OWASP API Top 10.
• Compliance Confidence: Our platform provides a clear and defensible process to meet API security compliance requirements recently added to PCI and SOC2. By systematically scanning your web apps and APIs for a broad range of vulnerabilities, you can confidently demonstrate a robust testing methodology to auditors.
• Consolidated Workflows: By integrating API scanning into our platform, you can consolidate your AppSec testing with a single vendor, streamlining workflows and gaining a comprehensive view of your security posture without several standalone tools.

Ready to see your full API attack surface? Talk to our experts or start a 2-week free trial.

If you are a Detectify customer already, don’t miss the What’s New page for the latest product updates and new security tests added to the platform.

The post Introducing Dynamic API Scanning appeared first on Blog Detectify.

The average organization is missing testing 9 out of 10 of their complex web apps that are attacker-attractive targets.  To address this, we’re launching new capabilities to help AppSec teams know what else, beyond core applications, likely requires in-depth testing. Asset Classification and Scan Recommendations automatically classify discovered web assets based on attacker reconnaissance techniques and deliver recommendations on where to run DAST, bridging the gap between broad and deep testing across the entire attack surface.

We know that security teams face a constant challenge: they know they need to test their main applications thoroughly, but what about everything else? Which of the dozens or hundreds of other web assets that they discover with Detectify actually need deep testing?

It’s a common struggle. In fact, our data shows that on average, organizations are missing 9 out of 10 of their complex, valuable web apps when it comes to testing. Alarmingly, over half of organizations miss all their complex apps when getting started with scanning, reflecting their uncertainty about where to deploy scans and missing valuable targets. This isn’t just about oversight; it’s also about the difficulty of scaling testing effectively as the attack surface expands. 

Attackers love this uncertainty. They look for the gaps between what you think you’re exposing and what’s actually out there.

Why prioritize and recommend scans?

This difficulty in effectively scaling testing leads to crucial questions: what exactly constitutes a web application suitable for in-depth testing, and why is prioritizing where to deploy tests so important?

Generally, a web application is something interacted with via a browser. It is often built using HTML within a client-server architecture. Crucially, it offers interactive elements like forms, dynamic pages, and potentially database connections.

In AppSec, particularly DAST, the goal is to find vulnerabilities in these assets. This involves first exploring the application (crawling) and then interacting with its elements (fuzzing). This approach is most valuable when there’s something substantial to crawl and interact with, significantly more than just a single page of static HTML. If an asset lacks these interactive elements, the fuzzer has little to do, and running a deep scan results in wasted resources and CPU cycles. Therefore, recommending which assets to scan deeply is essential for efficiency.

See the forest and the trees 

To address this challenge and eliminate the guesswork, we’re excited to introduce new capabilities designed to help you focus your testing where it matters most: Asset Classification and Scan Recommendations.

How can you decide what to test if you don’t know what an asset actually does? Our new Asset Classification capability automatically analyzes and categorizes web assets discovered across your attack surface.

How can you decide what to test if you don’t know what an asset actually does? Asset Classification automatically analyzes and categorizes web assets discovered across your attack surface. Identify rich web apps, basic web apps, APIs, server and client errors, etc.

The process begins by identifying potential web applications. We look at basic response data to determine if a web application is being served, checking for the following basic characteristics:

• Content-Type: text/html (Other types like XML might indicate non-crawlable APIs)
• Status Code: 200 OK
• Body Length: Sufficiently large (> 100 characters) to suggest more than a minimal response.

Once a potential web application is identified, the next step is to classify its nature and complexity to determine if it’s a “complex” application likely warranting deeper testing. Using techniques that mimic hacker reconnaissance, it analyzes attributes combined into a scoring algorithm. Currently, this includes:

• Technology detection: What specific libraries, frameworks, or technologies are present, and how many?
• Header analysis: Presence and configuration of certain headers (e.g., Content Security Policy – CSP).
• Interaction points: Presence of login forms or other input fields.
• Body length: The overall size of the response body.

This classification helps teams quickly understand the potential purpose, complexity, and interactivity of each discovered asset, even those that pop up without a team’s direct knowledge, so they can prioritize them effectively.

Intelligent Scan Recommendations to know where to point your DAST

Building on Asset Classification, our new Scan Recommendations feature delivers intelligent suggestions based on an asset’s classification (the technical characteristics mentioned above) and its likely attractiveness to attackers. This helps determine which of the web apps require comprehensive DAST through deep crawling and fuzzing, leveraging vulnerability research from the Detectify Crowdsource community and AI-built assessments from Detectify Alfred. 

We know it is hard to ensure all essential web apps are covered with Application Scanning. Which of your dozens or hundreds of web apps actually need deep testing? Which are processing user data or even have many components that hackers would target?

Breaking the illusion of coverage

The new capabilities bridge the gap between broad and deep testing across the entire attack surface, enabling AppSec teams to allocate resources confidently on the assets that matter most: Surface Monitoring gives a comprehensive attack surface view and tests for vulnerabilities. Application Scanning goes deeper where it matters with advanced crawling and fuzzing. The days of blindly deploying DAST and chasing shadows from irrelevant targets are over. It’s time to break the illusion of coverage. 

Scan Recommendations and Asset Classification are now available to Detectify customers. Sign up for a trial or book a demo to start scanning.

The post Redefining AppSec Testing with Intelligent Scan Recommendations and Asset Classification appeared first on Blog Detectify.

A series of vulnerabilities, known as IngressNightmare (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-1974), have been identified in ingress-nginx, a widely used Kubernetes ingress controller. When exploited together, these vulnerabilities allow for configuration injection through the Validating Admission Controller. Unauthenticated remote attackers on the Pod network could exploit this vulnerability to gain unauthorized access to sensitive data, including Kubernetes Secrets, and even perform a complete takeover of the cluster.

Affected Products

The Kubernetes Ingress NGINX Controller is a widely used component that routes external traffic to cluster services. It includes an admission controller that validates incoming ingress objects by reviewing configurations and ensuring they are correct before approval. This controller operates with significant privileges, as it requires access to resources across the cluster.

All versions of ingress-nginx are potentially vulnerable. The issue is fixed in versions 1.12.1 and 1.11.5.

Vulnerability Details

CVE-2025-1974 arises from configuration injection vulnerabilities within ingress-nginx’s Validating Admission Controller. Combined with other vulnerabilities (CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098),  attackers on the Pod network can gain unauthorized access to Kubernetes Secrets and potentially take over the entire cluster. 

Detection

Detectify Surface Monitoring customers can test whether they have exposed ingress NGINX admission, which enables the exploit chain. 

The vulnerability assessment released by Detectify identifies exposed Ingress NGINX admission controllers by analyzing TLS certificates. This assessment is highly reliable as Kubernetes run with self-signed certificates and the assessment looks for certificates with issuer "O=nil1", subject "O=nil2" and SAN containing "ingress-nginx-controller-admission".

Mitigation

• Upgrade to ingress-nginx versions 1.12.1 or 1.11.5.
• If immediate patching is not feasible, disable the Validating Admission Controller:
  • For Helm installations: Set controller.admissionWebhooks.enabled=false.
  • For manual installations: Delete the ValidatingWebhookconfiguration named ingress-nginx-admission and remove –validating-webhook from the ingress-nginx-controller Deployment or DaemonSet arguments.
  • Remember to re-enable the Validating Admission Controller after upgrading.

Patch availability

The vulnerability is fixed in ingress-nginx versions 1.12.1 and 1.11.5. Users are strongly advised to update to these versions or apply the provided mitigation.

Customers can always find updates in the “What’s New at Detectify” product log. Any questions can be directed to Customer Success representatives or Support. If you’re not already a customer, click here to sign up for a demo or a free trial and immediately start scanning. Go hack yourself!

References:

Original Research: Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog
Admission Control in Kubernetes

The post Security Update: Publicly Exposed Ingress NGINX Admission appeared first on Blog Detectify.

We are excited to announce Detectify Alfred, a revolutionary system that uses AI to completely autonomously collect and prioritize threat intelligence and generate high-fidelity security tests for the CVEs that are most likely to be exploited in the wild. This innovation allows us to dynamically deliver always-on security research to AppSec teams with unprecedented speed and coverage, combining the power of human ingenuity from the Detectify Crowdsource community of ethical hackers with the powerful capabilities of AI.

With more than 100 new CVEs published daily and a growing number of vulnerabilities not covered by the CVE system, security teams are increasingly overwhelmed. They must ensure they are testing for the latest issues and identifying and prioritizing the threats that pose actual risks to their systems. Traditional automated scanners often worsen this issue by adding new security tests relying on slow manual searches for publicly available CVE tests; generating excessive noise through signature-based testing rather than actual exploitability, and missing CVE-less vulnerabilities, such as misconfigurations.

Meet the security researcher that never sleeps

Alfred serves as a powerful additional source of security research, complementing the insights from our Crowdsource community of ethical hackers and internal security research experts. By fully automating the identification and creation process of CVE-based assessments, our security research forces can dedicate more resources to address advanced and novel threats, including those hiding beyond CVEs, delivering greater value to our customers.

Detectify Alfred under the hood

Alfred utilizes large language models (LLMs) to autonomously process details of CVEs as they are disclosed. We prioritize these vulnerabilities based on their likelihood of being exploited using the Exploit Prediction Scoring System (EPSS) framework. Next, the system scrapes the web for publicly available proofs-of-concept for each CVE, generating a payload-based exploit that is added as a security test to our Detectify platform only after a quality assurance check is performed by a researcher. We only build tests for relevant CVEs that can be validated with our proven payload-based approach, which emulates real-world exploits and dramatically reduces false positives.

Let’s take a closer look at how Alfred operates: 

1. Threat intelligence. With over 100 CVEs published every day, the system pulls vulnerability data from a wide range of trusted security intelligence sources. The raw vulnerability data is then enriched by gathering related information from diverse sources, including technical blogs and research labs, building a comprehensive knowledge base.
2. Filtering and ranking relevant CVEs. This system takes into account the exploitability likelihood for each vulnerability, based on the EPSS framework. Additionally, it filters for CVEs relevant to Detectify customers, specifically those that can be automated in our scanning engines and those that are not prone to false positives.
3. Generating payload-based security tests. Based on the analyzed information, the system attempts to automatically generate a testing procedure designed to replicate the vulnerability. Automated checks are run to ensure the generated test aligns with the specific requirements of our testing infrastructure.
4. Integrating tests into the Detectify engines. The generated test undergoes automated refinement, including error correction and optimization, to ensure accuracy and efficiency. As soon as the final quality check is performed, the refined security test is integrated into our platform.
5. Filtered-out CVEs are continuously re-evaluated in case new information about them is made available.

Thanks, Alfred!

Thanks to the release of Alfred, Detectify customers can now benefit from dramatically faster and broader access to test for relevant CVEs. An always-on sleepless agent continuously on the lookout for new vulnerabilities. 

Alfred’s AI-built assessments are now being rolled out to all Surface Monitoring and Application Scanning customers, making Detectify the only AppSec tool that combines its own community of ethical hackers with AI research. Read more about Alfred here. 

Are you interested in learning more about Detectify and seeing Alfred in action? Start a 2-week free trial or talk to our experts.

If you are a Detectify customer already, don’t miss the What’s New page for the latest product updates and new security tests added to the platform. 

The post Introducing Alfred for fully autonomous AI-built vulnerability assessments appeared first on Blog Detectify.

The post Major improvement to web crawling, more customization, and new tests appeared first on Detectify Blog.

The post Now possible to group assets, from domains to technologies appeared first on Detectify Blog.

The post See technologies on the attack surface plus updates to Attack Surface Custom Policies and API keys appeared first on Detectify Blog.

The post More improvements to Attack Surface Custom Policies appeared first on Detectify Blog.

The post How to set up Attack Surface Custom Policies appeared first on Detectify Blog.

The post Proactively reduce risks with Attack Surface Custom Policies appeared first on Detectify Blog.

The post 3x more subdomain takeovers now discovered appeared first on Detectify Blog.

The post How to scan your attack surface appeared first on Detectify Blog.

The post Quickly access insights about apex domains on the attack surface appeared first on Detectify Blog.

The post One click to your attack surface: New simplified navigation appeared first on Detectify Blog.