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.

Applications have long evolved from monolithic structures to complex, cloud-native architectures. This means that the tried-and-true methods we rely on are becoming dangerously outdated. For AppSec to keep pace, we must look beyond current tooling and revisit the very fundamentals of DAST – the automated discipline of black box testing.

The basics of black box security testing

Before diving into modern challenges, let’s revisit the three pillars of any successful black box security test: a foundation that remains constant even as technology shifts:

1. State: The application must be put into a specific condition that exposes potential vulnerabilities.
2. Payloads: A relevant attack string must be sent to trigger the vulnerability. Payloads must be crafted to match the underlying technologies and the desired aggression (e.g., a simple SLEEP vs. a data-altering DELETE).
3. Assertions: You need a reliable way to determine if the payload was successful. This can be as simple as a script alert(1) or as complex as measuring response time changes for a Blind SQL injection.

These fundamentals are always constrained by two major resources:

• Server load: Can the system (especially a production system) handle the load of testing? Testing production is often ideal because it holds all business-critical data and is never truly equal to staging.
• Scanning time & cost: Resources are finite. A scan running in a fast build pipeline needs a different time budget than one in a QA environment. Furthermore, computational costs for rendering, traffic, and even AI tokens must be factored in.

Why the old methods are breaking

The black box fundamentals are stable, but the applications we test have been completely revolutionized.

Monolithic legacy architecture (The “good old days”)
In the traditional LAMP stack world, things were simpler:

• URL = State: Each state of the application was directly accessible via a URL.
• Visible technology: The underlying tech stack was relatively easy to determine, and the alternatives were few.
• Direct payload response: Payloads directly triggered the application you were testing, with minimal movement through system components.

Modern Application Architecture

Today, the architecture is complex and layered, breaking all the old assumptions:

• URL ≠ State: Application state is now driven by actions (like clicking a button to add a product to a cart), not just URLs. Modern URLs often use fragments (#) and may change client-side via the JavaScript history API without triggering HTTP requests.
• Hidden technology stack: Applications now consist of CDNs, cloud storage, container groups, message queues (like Kafka), and schedulers. The underlying tech is hidden and protected behind many layers.
• Payloads trigger across components: A single payload might travel through a Kafka message bus and trigger in a separate system, potentially due to serialization/deserialization differences between coding languages, or even in a third-party service (e.g., a logging tool).

With architecture fundamentally changed, it is no wonder many black box tools, often based on decades-old underlying projects, are struggling to keep up.

The (very much) required shifts in black box methodology

To meet the challenges of modern apps, black box tools must evolve their approach to state, payloads, and assertions.

1. Generating State

• Graph, not a tree: URL trees are obsolete. A modern web app must be modeled as a graph, where a node is a state and an edge is an educated guess of an action that modifies the state. This requires modeling both client-side and server-side state.
• Recreation of state: You can no longer reliably recreate a state with just a URL or a HAR archive. Tools must replay the sequence of actions taken to reach a specific state.
• Short-lived states: States are increasingly short-lived (e.g., JWTs with short TTLs), making it difficult for traditional crawlers to test them effectively later on.

2. Crafting payloads

• Context-aware payloads: Since the full stack is hidden, payloads must be designed to work in multiple contexts. A single string must survive serialization/deserialization across different programming languages as it propagates through the system and potentially triggers in a different software stack.

3. Making Assertions

• Delayed and out-of-band triggers: Payloads may now trigger much later, possibly after being queued for processing or returning from a different view. The Log4j vulnerability was a clear example of payloads triggering deep within the architecture, requiring out-of-band methods and network pingbacks.
  
• Noisier Systems: Measuring system behaviors, like using response time for Blind SQL injection, is nearly impossible in an architecture based on message queues and load balancing.

The path forward 

The key is not to “just AI everything,” but to strategically use advanced methods to optimize decision-making. We at Detectify have already begun rolling out a couple of next-generation assessment updates to address this, with Dynamic Payload Rotation as a prime example for our API Scanner, and many more are planned for early next year.

This feature utilizes a near-infinite pool of payloads, mixing constant checks with experimental variations. If an experimental payload succeeds, it is immediately reused in future tests for that tech stack. This form of unsupervised machine learning allows the scanner to gain a permanent testing edge, ensuring that the fundamentals of state, payload, and assertion evolve as fast as the applications they protect.

The post Why traditional black box testing is failing modern AppSec teams appeared first on Blog Detectify.

This comparison focuses on how Holm Security and Detectify address the core challenges faced by AppSec teams: gaining visibility and context, testing their web applications and APIs, and how quickly users can get value from these tools. Holm Security offers broad, unified coverage across the entire IT estate (internal, external, and cloud) and relies on a proprietary unified risk score for strategic prioritization, making it a good consolidated risk reporting and management tool. Detectify, by contrast, is a specialized EASM and DAST solution focused on external applications. Detectify utilizes its Asset Classification to provide explicit scanning recommendations and employs 100% payload-based testing to ensure a high-fidelity signal, directly reducing friction and the time spent validating findings.

Detectify vs. Holm Security: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients and past Holm Security users who decided to evaluate Detectify as its alternative, but also based on the following sources:

• Holm Security’s official website & resources
• Holm Security’s documentation
• Holm Security’s publicly accessible demos

The post Product comparison: Detectify vs. Holm Security appeared first on Blog Detectify.

Welcome to The researcher’s desk  – a content series where the Detectify security research team conducts a technical autopsy on vulnerabilities that are particularly interesting, complex, or persistent. For this issue, we look at CVE-2025-64446, a critical authentication bypass that has been actively exploited in the wild, targeting Fortinet’s Web Application Firewall (WAF) product, FortiWeb.

The Case File: Unauthenticated control

What’s the root cause of CVE-2025-64446?

The core issue is a complex Unauthenticated Authentication Bypass flaw. It involves an improper handling mechanism within the FortiWeb appliance that is related to user impersonation functionality.

Essentially, the vulnerability allows an attacker to manipulate the way the system validates user identity, tricking the appliance into granting administrative privileges. The flaw is rooted in how a function intended to handle user context is improperly exposed or protected, enabling its misuse for unauthorized access.

What’s the mechanism behind CVE-2025-64446?

The mechanism involves bypassing the standard login procedure to gain full administrative privileges on the FortiWeb appliance.

• Bypass the gate: The attacker first leverages a mechanism (reported as a Relative Path Traversal combined with a logic flaw) to reach a restricted executable or API endpoint on the FortiWeb device.
• Impersonation: Once the endpoint is reached, the attacker sends specially crafted input (often within an HTTP header) containing fields designed to impersonate the built-in admin account.
• Complete compromise: The appliance’s authentication function processes this untrusted input and grants the attacker an administrative context. This allows the attacker to execute administrative commands, often leading to the creation of a new, persistent administrator account with known credentials, which grants complete control over the WAF.

This flaw is interesting because it showcases the danger of authentication logic errors and how seemingly internal, administrative functions (like impersonation) can be weaponized when not properly secured. The flaw was exploited in attacks before a public patch was available, confirming its zero-day status.

Defensive takeaways

• Patching: Fortinet issued updates to resolve this vulnerability. Users must apply the security patch immediately to all affected FortiWeb versions.
• Management Access: Review the administrative user list for any new, unknown, or unauthorized accounts created since the beginning of October 2025 on the VPN appliance as a sign of compromise.
• The Detectify Approach: Detectify customers are running payload-based tests to check for the specific combination of path manipulation and header injection required to trigger this unauthenticated authentication bypass, providing early warning for vulnerable assets.

Questions? We’re happy to hear from you via support@detectify or book a demo to learn more about Detectify.

References

• https://nvd.nist.gov/vuln/detail/cve-2025-64446
• https://www.bleepingcomputer.com/news/security/fortinet-confirms-silent-patch-for-fortiweb-zero-day-exploited-in-attacks/
• https://labs.watchtowr.com/when-the-impersonation-function-gets-used-to-impersonate-users-fortinet-fortiweb-auth-bypass/
• https://blog.qualys.com/vulnerabilities-threat-research/2025/11/14/unauthenticated-authentication-bypass-in-fortinet-fortiweb-cve-2025-64446-exploited-in-the-wild

The post The researcher’s desk: FortiWeb Authentication Bypass (CVE-2025-64446) appeared first on Blog Detectify.

Welcome to The researcher’s desk  – a content series where the Detectify security research team conducts a technical autopsy on vulnerabilities that are particularly interesting, complex, or persistent. The goal here is not to report the latest research (for which you can refer to the Detectify release log); it is to take a closer look at certain vulnerabilities, regardless of their disclosure date, that still offer critical lessons.

For this issue, we analyze CVE-2025-59287, a critical remote code execution (RCE) flaw in Microsoft Windows Server Update Services (WSUS) that targets the core patch management infrastructure of the enterprise.

The Case File: WSUS Unauthenticated RCE

What’s the root cause of CVE-2025-59287?

The access flaw, CVE-2025-59287, is due to unsafe deserialization of untrusted data in the WSUS reporting/web services.

This means the service accepts data sent by an external source and fails to validate its structure or content safely before processing it. This fundamental failure allows an attacker to inject arbitrary code instructions into the data stream that the service then executes.

What’s the mechanism behind CVE-2025-59287?

The mechanism enables a high-impact attack due to its low requirements and high privileges.

• Unauthenticated Access: Attackers can send specially crafted events to unauthenticated endpoints of the WSUS service.
• Arbitrary Code Execution: The unsafe deserialization flaw allows the attacker to execute arbitrary code remotely.
• Privilege: This code executes with SYSTEM privileges on the target server, providing the highest level of control.

This flaw is interesting because it is actively exploited in the wild and targets core update management infrastructure in enterprises. It has been used to deploy infostealers and pre-ransomware payloads, which compromises sensitive data in regulated environments. The existence of public PoC exploits also accelerates the threat landscape.

Defensive takeaways

• Patching: Apply vendor updates to mitigate this vulnerability.
• The Detectify Approach: Detectify customers are running payload-based assessments to test for this vulnerability.

Questions? We’re happy to hear from you via support@detectify or book a demo to learn more about Detectify.

The post The researcher’s desk: CVE-2025-59287 appeared first on Blog Detectify.

This review provides a direct comparison between two external security platforms, Halo Security and Detectify. The analysis will focus on three core areas critical to Application Security engineers: Visibility and Context, which examines how each platform discovers and classifies assets; Assessment, which compares their technical methodologies for finding vulnerabilities; and Usability, which evaluates the day-to-day workflow and operational efficiency of each tool.

Detectify vs. Halo Security: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients and past Halo Security users who decided to evaluate Detectify as its alternative, but also based on the following sources:

• Halo Security’s official website & resources
• Halo Security’s documentation
• Halo Security’s publicly accessible demos

The post Product comparison: Detectify vs. Halo Security appeared first on Blog Detectify.

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.

For Application Security leaders and engineers, the choice between Rapid7 and Detectify is a decision between two fundamentally different philosophies: a broad, SOC-centric platform versus a purpose-built, practitioner-focused tool. Rapid7 presents a unified solution that correlates application flaws with holistic infrastructure risk, while Detectify is engineered exclusively for the external AppSec workflow. This analysis has compared both platforms through the three core use cases that matter to an AppSec team: their approach to visibility and attack surface discovery, the technical methodology and effectiveness of their assessment engines, and the practical usability of each tool in a modern, fast-paced remediation pipeline.

Detectify vs. Rapid7: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients and past Rapid7 users who decided to evaluate Detectify as its alternative, but also based on the following sources:

• Rapid7’s official website & resources
• Rapid7’s documentation
• Rapid7’s publicly accessible demos

The post Product comparison: Detectify vs. Rapid7 appeared first on Blog Detectify.

This comparison reviews two security platforms, Detectify and Invicti, both engineered to provide vulnerability assessment and attack surface management. While both platforms compete, Detectify is built on a forward-looking philosophy, leveraging its proprietary, payload-based scanning engine and a multi-source intelligence model. This approach is powered by a private community of elite ethical hackers (Detectify Crowdsource), an AI researcher, and an internal team, enabling it to find the novel, non-CVE vulnerabilities that other tools miss. In contrast, Invicti’s value is rooted in its “Proof-Based Scanning” engine, an approach focused on confirming publicly known vulnerabilities, which requires a significant upfront time investment for configuration and cannot scan for emerging, 0-day threats. This core difference in assessment philosophy steers the platforms’ respective value, usability, and the day-to-day workflow for an AppSec team.

Detectify vs. Invicti: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients of Invicti who decided to evaluate Detectify as its alternative, but also based on the following sources:

• Invicti’s official website & resources
• Invicti’s documentation
• Invicti’s publicly accessible demos

The post Product comparison: Detectify vs. Invicti appeared first on Blog Detectify.

Welcome to The researcher’s desk – a content series where the Detectify security research team will conduct a technical autopsy on vulnerabilities that are particularly interesting, complex, or persistent. The goal here is not to report the latest research (for which you can refer to the Detectify release log); it is to take a closer look at certain vulnerabilities, regardless of their disclosure date, that still offer critical lessons. 

For our first case file, we examine the exploit chain targeting Cisco ASA and FTD firewalls, beginning with the unauthenticated access flaw, CVE-2025-20362.

The case file

• Disclosure Date: September 25, 2025
• Bypass Flaw: CVE-2025-20362 with CVSS 6.5
• Execution Flaw: CVE-2025-20333 with CVSS 9.9
• Vulnerable Component: VPN Web Server on Cisco ASA/FTD
• Final Impact: Unauthenticated Remote Code Execution (RCE)
• Observations: Flaws were actively exploited as zero-days before patches were available

What’s the root cause of CVE-2025-20362? 

The access flaw, CVE-2025-20362 (Missing Authorization, CWE-862), is essentially a failure in user input validation, typically manifesting as a Path Traversal/Normalization issue.

When an attacker sends a carefully crafted HTTP request containing specific directory traversal sequences, the VPN web server’s logic fails to correctly identify the request as unauthenticated. Instead, the server’s authorization component is bypassed, treating the request as if a session already exists. This grants the remote attacker access to critical, restricted URL endpoints—endpoints that are not designed for public interaction.

What’s the mechanism behind CVE-2025-20362? 

The primary lesson of this case is chainability. While CVE-2025-20362 alone carries a moderate score, its true severity is realized when it is used to nullify the only defense protecting the second vulnerability, CVE-2025-20333 (a Buffer Overflow).

1. Latch Opened. The attacker uses a crafted request to exploit the input validation flaw CVE-2025-20362, bypassing the need for a login. 
2. Execution Delivered. The attacker then targets the now-exposed critical endpoint with the payload designed to trigger the Buffer Overflow CVE-2025-20333. (CVE-2025-20333 alone requires valid VPN credentials)
3. Result: The chain achieves Unauthenticated Remote Code Execution with privileges on the firewall: a complete takeover of the network perimeter.

Our team chose this flaw because it is an excellent example of a modern, high-stakes attack. The entire chain has been leveraged by sophisticated, state-sponsored campaigns, demonstrating that attackers prioritize the easiest way in, often starting with a moderate-severity bypass to unlock a critical vulnerability. It proves that defenders must identify and fix every link in a potential chain, not just the high-score vulnerabilities. 

Defensive takeaways

• Patching: Immediately upgrade to the latest, fixed Cisco releases.
• Segment and Isolate: If possible, restrict administrative and VPN web server access to only trusted IPs via upstream ACLs.
• The Detectify Approach: Detectify customers are running payload-based testing to check for the precise input normalization failure of CVE-2025-20362. 

Questions? We’re happy to hear from you via support@detectify or book a demo to learn more about Detectify.

The post The researcher’s desk: CVE-2025-20362 appeared first on Blog Detectify.

This comparison reviews two modern security platforms, ProjectDiscovery and Detectify, both engineered to provide high-signal, low-noise vulnerability assessment and attack surface management. While both are effective, they are built on fundamentally different philosophies. ProjectDiscovery is a platform where its value is rooted in its powerful open-source tools, like the Nuclei engine, which offer self-serve customization for newly disclosed public CVEs. In contrast, Detectify’s value lies in its proprietary, payload-based scanning engine , which is uniquely powered by a private community of elite ethical hackers (Detectify Crowdsource) to find novel, non-CVE vulnerabilities. This core difference in approach steers their respective strengths in assessment, usability, and the day-to-day workflow for an AppSec team.

Detectify vs. ProjectDiscovery: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients of ProjectDiscovery who decided to evaluate Detectify as its alternative, but also based on the following sources:

• ProjectDiscovery’s official website & resources.
• ProjectDiscovery’s documentation.
• ProjectDiscovery’s publicly accessible demos.

The post Product comparison: Detectify vs. ProjectDiscovery 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.

Choosing the right tool is a critical decision that depends on a team’s specific goals, resources, and technical focus. This review provides an in-depth comparison of two leading platforms, Escape and Detectify, to help you make an informed choice. We will explore how each tool approaches three core pillars of any effective AppSec program: Visibility (discovering and understanding your attack surface), Assessment (accurately finding vulnerabilities), and Usability (ensuring the tool is efficient and enjoyable to use). By the end of this comparison, you will have a clear understanding of each platform’s strengths and weaknesses, enabling you to determine which solution is the better fit for your team’s unique operational style—whether you need a tool built for deep, customizable analysis or one optimized for speed and decisive, guided action.

Detectify vs. Escape: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients and past Escape users who decided to evaluate Detectify as its alternative, but also based on the following sources:

• Escape’s official website & resources
• Escape’s documentation
• Escape’s publicly accessible demos

TL;DR

The post Product comparison: Detectify vs. Escape appeared first on Blog Detectify.

The difference between Detectify and Tenable lies in their core scope and the use cases they support. Detectify is a specialized, attacker-centric platform designed for the application security practitioner. Its focus is exclusively on the external, internet-facing attack surface with Dynamic Application Security Testing (DAST) to find exploitable vulnerabilities in web applications and APIs. In contrast, Tenable is a comprehensive exposure management platform built for the entire security and risk organization. It provides a holistic view of risk across the entire IT estate—from internal servers and cloud infrastructure to identity systems and the external perimeter—positioning itself as the central nervous system for enterprise-wide vulnerability and risk management.

Their differing scope dictates their strengths. Detectify’s primary advantage for an AppSec team is the high-fidelity, low-noise nature of its findings. Its unique reliance on payload-based testing, powered by a crowdsourced network of elite ethical hackers, delivers results that prove exploitability and are immediately actionable. This builds credibility with development teams and streamlines the remediation workflow, which is a significant usability win. Tenable’s strength lies in its unmatched breadth of coverage and its powerful risk contextualization through the Vulnerability Priority Rating (VPR) and Attack Path Analysis. It excels at showing how an application fits into an org’s risk profile, making it an indispensable tool for compliance and enterprise risk management.

Detectify vs. Tenable: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients and past Qualys users who decided to evaluate Detectify as its alternative, but also based on the following sources:

• Tenable’s official website & resources
• Tenable’s documentation
• Tenable’s publicly accessible demos

TL;DR

The post Product comparison: Detectify vs. Tenable appeared first on Blog Detectify.

Your responsibilities cover the full spectrum of risk—from the applications your teams build and the products you ship to the overarching compliance mandates you must meet. The core challenge is achieving this with a lean team where every hour of engineering time is critical. Choosing the right tooling is not just a technical decision; it’s a strategic one that directly impacts your team’s efficiency and your organization’s security posture.

This review provides an in-depth, practical comparison of Qualys and Detectify across three critical dimensions for a security leader:

• Visibility and Context: How well does it discover your complete attack surface and help you understand what’s important?
• Vulnerability Assessment: How effective is it at finding truly exploitable vulnerabilities versus creating triage overhead?
• Usability: Does the tool act as a force multiplier for your team or an operational burden?

Detectify vs. Qualys: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients and past Qualys users who decided to evaluate Detectify as it alternative, but also based on the following sources:

• Qualys’ official website & resources
• Qualys’ documentation
• Qualys’ publicly accessible demos

TL;DR

The post Product comparison: Detectify vs. Qualys appeared first on Blog Detectify.

Choosing the right DAST tool is a critical decision that shapes the effectiveness of their entire program. Detectify and Burp Suite Enterprise, exemplify the innovation happening in this space. While both are powerful assessment tools, they are engineered to solve different core problems, stemming from fundamentally different approaches to visibility, vulnerability assessment, and usability. Understanding these differences is key to selecting the platform that aligns with your team’s specific needs, maturity, and security goals.

This comparison breaks down the core philosophies of each tool. Detectify operates on an “outside-in” model, starting with the crucial question: “What is my complete external attack surface?” It combines attack surface discovery with payload-based testing sourced from elite ethical hackers, the AI agent Alfred, and its internal security research team to provide immediate visibility and high-confidence, actionable findings. In contrast, Burp Suite Enterprise follows an “inside-out” model, built to answer: “Is this specific application I already know about secure?” It provides a powerful, highly customizable DAST scanner for mature security teams to perform deep, exhaustive scans on a known set of assets, prioritizing granular control and comprehensive coverage over automated discovery and ease of use.

Detectify vs. Burp Enterprise: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients and past Burp Enterprise users who decided to evaluate Detectify as its alternative, but also based on the following sources:

• Burp’s official website & resources
• Burp’s documentation
• Burp’s publicly accessible demos

TL;DR

The post Product comparison: Detectify vs. Burp Enterprise 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.

This guide will explore the key distinctions between Nessus and Detectify, two products built to solve different problems. We’ll compare their core visibility, assessment methodologies, and approaches to modern web apps and API security.

The primary difference between the two products lies in their core focus. Nessus focuses on infrastructure vulnerability scanning, where they have prioritized  performing deep, authenticated scans on internal assets like servers and workstations. Nessus’ strength is its massive plugin library, which is ideal for patch management and compliance auditing. However, its web application scanning is a newer, less specialized feature, and its external scans are signature-based, which can create a high volume of false positives and triage work for an Application Security team.

Detectify, in contrast, starts with giving users both the visibility and context about their attack surface, making it possible to test each and every asset, like modern web applications and APIs. Its key technical differentiator is its payload-based testing methodology, API scanner, and classification and recommendation system. By confirming exploitability with every finding, it reduces false positives and curbs the triage load. Detectify’s assessment capabilities are further enhanced by sourcing vulnerabilities from a private community of ethical hackers and an AI agent, allowing it to find novel and non-CVE issues.

Detectify vs. Nessus: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients and past Nessus users who decided to evaluate Detectify as its alternative, but also based on the following sources:

• Nessus’ official website & resources
• Nessus’ documentation
• Nessus’ publicly accessible demos

TL;DR

The post Product comparison: Detectify vs. Nessus 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.

Intruder is a cloud-based vulnerability scanner that provides an automated overview of an organization’s attack surface. Its primary function is to proactively identify weaknesses across internet-facing infrastructure and applications before they are exploited. The platform’s scanning engine runs a set of checks for both infrastructure-level misconfigurations and application-layer vulnerabilities, like those in the OWASP Top 10. It leverages open-source engines like ZAP to execute its checks. 

For an application security team, Intruder offers a tradeoff between ease of use and granular control. The platform is user-friendly, but its options for fine-tuning scan configurations are limited. Furthermore, its continuous attack surface monitoring and testing capabilities, which are critical for securing externally-facing assets, are limited and primarily available only in its highest pricing tiers.

This document provides a direct comparison of Intruder and Detectify. The objective is to break down the key technical differentiators to help users make an informed decision.

Detectify vs. Intruder: A Quick Comparison

We’ve built this comparison mainly based on the feedback from dialogues with prospective clients and past Intruder users who decided to evaluate Detectify as its alternative, but also based on the following sources:

• Intruder’s official website & resources
• Intruder’s documentation
• Intruder’s publicly accessible demos

The post Product comparison: Detectify vs. Intruder appeared first on Blog Detectify.