Executive Summary

We identified a couple of vulnerabilities in AI automation platform Dify resulting in cross-tenant sensitive information disclosure and one-click account takeover. These findings reinforce the pattern we documented in our previous n8n blogpost: even though AI automation platforms are increasingly becoming integration hubs for complex workflows, their security posture still lags behind their rapid evolution and operational importance. 

Introduction

Dify is an open-source platform for building LLM-powered applications: agents, chatbots, and automated workflows. With over 134,000 GitHub stars and over 10 million docker pulls, it has rapidly become one of the most popular tools in the AI application space, offering both self-hosted and managed cloud deployments. 

Our research into Dify uncovered two distinct vulnerabilities that illustrate this risk: 

1. A file handling flaw that enables one-click account takeover through a single malicious link (detailed below). 
2. An insufficient tenant isolation issue in shared environments that exposes other users’ application source code.  

Both findings point to the same structural challenge: platforms that centralize trust must also centralize rigor in how they isolate users and handle untrusted input. 

The first issue was addressed in Dify 1.13.1. The second was fixed in the sandbox layer by moving from a shared identity to per-execution UIDs, then shipped to Dify users through the newer sandbox image bundled with 1.13.3. 

Dify did not respond to any of our disclosure messages and chose to patch silently.  

One Click to Account Takeover

The flaw lies in how Dify handles file uploads through workflow tool nodes, such as Image Downloader or Image Toolbox. 

SVG is an XML-based image format that can natively embed JavaScript, via <script> tags or event handlers on SVG elements. When a browser renders an SVG file served from a trusted origin, any embedded script executes with full access to that origin’s session context, including cookies, local storage, and API calls. 

Dify uses two subdomains: 

• upload.dify.ai: where user-uploaded files are stored and served 

• cloud.dify.ai: the main application domain, where users authenticate and manage their workflows 

Critically, upload.dify.ai and cloud.dify.ai are configured as DNS aliases. From the browser’s perspective, both subdomains resolve to the same origin. This collapses the intended security boundary: a file that should have been confined to a static asset domain is instead rendered with the full privileges of the application domain. 

A malicious SVG uploaded to upload.dify.ai could simply be accessed via cloud.dify.ai, and the browser would execute its JavaScript payload as if it were part of the application itself. 

But this design wouldn’t be dangerous if access control was enforced on uploaded files. Each uploaded file receives a unique ID and is stored at a predictable path: 

https://upload.dify[.]ai/files/tools/<unique-id>/filename.svg 

However, these files are publicly accessible with no authentication and no per-user scoping (a.k.a Insecure Direct Object Reference). Anyone who knows the URL can retrieve the file. And that ID is not necessarily secret: it could leak through Referer headers or surface in shared workspace contexts. 

Therefore, in this case, the exploitation scenario was straightforward:  

• The threat actor generates a malicious link leading to a resource in his account 

• The resource link is shared to another user, and one click leads to account takeover. 

Eventually, Dify team fixed this first issue by overwriting the content-type of the HTTP response to “application/octet-stream”, independently from the nature of the file, represented with the args.as_attachment flag version 1.13.1.
This value triggers download instead of rendering. 

Cross-Tenant Source Disclosure in the Python Sandbox

This bug lived deeper in the stack, inside dify-sandbox, the service Dify uses to execute untrusted code. 

The failure here was particularly interesting, as it required a chain to fully leak other users’ source code on the Dify platform. 

1. Sandboxed Python executions shared a filesystem location. 
2. Those executions shared the same runtime identity. 
3. The leaked artifact contained encrypted code, not plaintext. 
4. But the “encryption” was repeating-key XOR, so ciphertext alone was often enough. 

Where the Leak Came From 

Fig. 1: Dify cross-tenant source disclosure 

The Dify monorepo only pins the sandbox image. At tag 1.13.1, Dify still shipped langgenius/dify-sandbox:0.2.12 in its compose files: 

• Dify 1.13.1 sandbox pin: https://github.com/langgenius/dify/blob/1.13.1/docker/docker-compose-template.yaml#L246-L249 

Inside that sandbox version, the Python runner used a fixed sandbox root: 

• sandbox root definition: https://github.com/langgenius/dify-sandbox/blob/0.2.12/internal/core/runner/python/setup.go#L23-L26 

• chroot behavior described in FAQ: https://github.com/langgenius/dify-sandbox/blob/0.2.12/FAQ.md#L3-L13 

The important detail is what happened during execution. The runner generated a temporary script under ${LIB_PATH}/tmp/<uuid>.py, which became /tmp/<uuid>.py from the Python process’s perspective after chroot. The same runner stamped every wrapper script with a single hard-coded sandbox UID: 

• vulnerable runner: https://github.com/langgenius/dify-sandbox/blob/0.2.12/internal/core/runner/python/python.go#L89-L164 

• static sandbox UID: https://github.com/langgenius/dify-sandbox/blob/0.2.12/internal/static/user.go#L1-L6 

Three lines tell the story: 

• Identity was fixed through static.SANDBOX_USER_UID. 

• The wrapper script was written with os.WriteFile(…, 0755). 

• The file lived under the shared sandbox tmp directory. 

Separate tenants executing inside the same sandbox root, under the same effective identity, with readable code artifacts left in a shared /tmp. That is the entire isolation bug. 

Our proof of concept simply sampled /tmp during execution and collected newly created files. In a shared cloud deployment, that exposed wrapper scripts belonging to other tenants running on the same sandbox host. 

The attacker-side workflow looked like this: 

What the Attacker Actually Stole

The leaked file was not the raw user script. 

Dify generated a Python wrapper that loaded a native seccomp helper, decoded a Base64 blob, decrypted it, and exec’d the result. 

The decryptor lived in the embedded prescript: 

• prescript decryptor: https://github.com/langgenius/dify-sandbox/blob/0.2.12/internal/core/runner/python/prescript.py#L22-L47 

The critical line: 

On the Go side, the matching encryption logic was just as direct: 

This looks like “encryption,” but it is really a byte-wise Vigenere cipher with a 64-byte repeating key. 

Something like that: 

Why the Encryption Broke

If Dify had used a modern authenticated cipher and never exposed the key, reading /tmp/<uuid>.py would still have been bad, but it would not immediately reveal source code. Instead, the runner: 

• generated a random 64-byte key 

• XORed every plaintext byte with key[i mod 64] 

• Base64-encoded the result 

• embedded the ciphertext in the wrapper script 

Repeating-key XOR leaks structure across every byte position modulo the key length. Once the key length is known, recovery collapses into a set of small single-byte XOR problems,  not a modern cryptanalytic challenge. 

Our PoC used exactly that property. The attack strategy: 

1. Lock onto the real key size of 64 bytes. 
2. Score candidate plaintext bytes for “Python-likeness.” 
3. Slide common cribs, import , from , def main( — across the ciphertext. 
4. Reward outputs that decode as UTF-8, contain Python tokens, and successfully parse with ast.parse. 

Workflow code is highly structured plaintext: full of repeated syntax, imports, identifiers, indentation, JSON handling, and predictable scaffolding. Even when the exact business logic is unknown, the shape of Python source gives the attacker enough signal to recover key bytes and reconstruct the rest. 

The sandbox did not need to leak the key. The ciphertext was enough.

A reduced version of the recovery logic:

The real PoC is more careful, including crib dragging, UTF-8 heuristics, Python-token scoring, AST validation, and more. 

Why This Was Recoverable in Practice

Three properties made the attack reliable. 

Fixed key size. The vulnerable runner hard-coded key_len := 64, so the PoC did not have to discover a moving target. 

Strong plaintext priors. Python source naturally contains ASCII-heavy text, repeated keywords, common import patterns, indentation and punctuation, and valid UTF-8. 

Machine-verifiable output. The PoC did not stop at “looks readable.” It strongly preferred candidates that parsed as real Python, turning recovery into a search problem with a sharp scoring function. 

How Dify Fixed It

The fix landed in dify-sandbox 0.2.13: 

• fix: tenant isolation use uid: https://github.com/langgenius/dify-sandbox/commit/6b3577c7779c4afc9f26645df5a4660a7282a566 

The patched runner changed the trust boundary in the right place: 

• fixed runner: https://github.com/langgenius/dify-sandbox/blob/0.2.13/internal/core/runner/python/python.go#L30-L176 

• UID pool: https://github.com/langgenius/dify-sandbox/blob/0.2.13/internal/core/runner/python/uid_pool.go#L9-L67 

The important changes: 

• uid, err := AcquireUID(ctx) 

• The wrapper was written with os.WriteFile(…, 0600). 

• The file was reassigned with syscall.Chown(…, uid, …). 

• The embedded prescript stopped using the single global sandbox UID and used the per-run UID instead. 

This matters more than any cryptographic tweak. Before the fix, every execution looked like the same sandbox user. After the fix, each execution got its own identity and its own readable artifact set. 

Dify did not “fix the encryption.” It fixed the isolation boundary. 

The Impact

• One-click account takeover: The attacker acts as the victim: modifying workflows, changing settings, inviting collaborators. 

• Workflow theft: Private workflows (often encoding proprietary business logic, integration architecture, and prompt engineering) become fully accessible. 

• Credential exfiltration: API keys, OAuth tokens, and model configurations stored in Dify can be extracted, enabling lateral movement into every connected external service. 

• Full instance compromise: If the victim is an administrator, the attacker gains control of the entire Dify deployment and every integration it orchestrates. 

Conclusion

Both vulnerabilities we found in Dify stem from the same oversight: security controls that weren’t designed to keep pace with the platform’s feature growth. As these tools add collaboration, file sharing, and multi-tenant environments, each new surface needs to be hardened with the same rigor as the core application. 

What makes this particularly relevant for security teams is the open-source model: Dify is widely self-hosted, meaning unpatched instances may persist long after fixes are released. Organizations running Dify (in any configuration) should verify they are on v1.13.1 or later. 

Timeline

• January 14, 2026: initial disclosure sent 

• March 17, 2026: Dify 1.13.1 released, addressing the first issue 

• March 19, 2026: dify-sandbox 0.2.13 released with UID-based tenant isolation 

• March 20, 2026: follow-up sandbox patch stabilizes the UID-based design inside the chroot 

• March 25, 2026: Dify 1.13.3 released, bundling the fixed sandbox at 0.2.14 

The post Dify: When Your AI Platform Becomes the Attack Surface appeared first on Blog.

TL;DR: Researchers recently disclosed CVE-2026-42945, a critical heap-based buffer overflow vulnerability affecting both NGINX Open Source and NGINX Plus. The flaw exists within the ngx_http_rewrite_module component and can allow unauthenticated attackers to trigger denial-of-service conditions and potentially achieve remote code execution (RCE) using specially crafted HTTP requests.

Imperva Threat Research Group analyzed the vulnerability and associated exploitation techniques. Imperva customers using Cloud WAF or On-Prem WAF are protected against attack attempts targeting this issue.

The Vulnerability

CVE-2026-42945 is a heap-based buffer overflow vulnerability in the ngx_http_rewrite_module component of NGINX Open Source and NGINX Plus. The issue, nicknamed NGINX Rift, occurs when specific rewrite-rule patterns are processed using unnamed Perl-Compatible Regular Expression (PCRE) capture groups such as $1 or $2, combined with replacement strings containing a question mark (?) and followed by additional rewrite, if, or set directives.

Under vulnerable conditions, specially crafted HTTP requests can trigger heap corruption within the NGINX worker process. Public research indicates this can reliably cause worker crashes and denial-of-service conditions, while some researchers also demonstrated potential paths toward remote code execution under favorable memory-layout conditions.

The vulnerability was discovered through autonomous analysis of the NGINX codebase and reportedly remained dormant for nearly two decades. Researchers described the issue as arising from a state mismatch in rewrite processing logic that ultimately results in unsafe memory handling during URI rewriting operations.

In practical terms, an attacker sends a crafted HTTP request designed to reach a vulnerable rewrite rule. During processing, attacker-controlled URI data can overflow allocated heap memory inside the worker process. Depending on the target environment and mitigations such as ASLR, exploitation may result in:

• Worker process crashes
• Repeated restart loops
• Application-layer denial of service
• Potential remote code execution within the NGINX worker context

The flaw affects:

• NGINX Open Source versions 0.6.27 through 1.30.0
• NGINX Plus R32 through R36

Patched releases include:

• NGINX Open Source 1.30.1 and 1.31.0+
• NGINX Plus R32 P6 and R36 P4

Because rewrite directives are extremely common in real-world NGINX deployments, particularly in reverse proxies, API gateways, load balancers, authentication flows, and URL routing logic, exposure may extend across a substantial portion of internet-facing infrastructure. NGINX was the most widely deployed web server on the internet as of 2025, supporting 32.4% of all websites with known web servers, so the exposure surface is extremely broad across enterprise, cloud, SaaS, and e-commerce environments.

Some of the techniques associated with exploitation include:

• Crafted HTTP requests targeting vulnerable rewrite rules
• Abuse of unnamed PCRE capture groups ($1, $2)
• Heap corruption via malformed URI rewriting operations
• Application-layer denial of service through worker crashes
• Potential memory manipulation leading to remote code execution
• Automated internet-wide scanning for exposed NGINX deployments

Unlike traditional volumetric DDoS attacks, exploitation of CVE-2026-42945 targets the application processing layer directly, allowing attackers to disrupt services using relatively small numbers of malicious requests.

Bottom Line

CVE-2026-42945 demonstrates how long-lived vulnerabilities in foundational internet infrastructure can remain undiscovered for years while silently exposing a massive attack surface. By abusing rewrite-processing logic inside ngx_http_rewrite_module, attackers can trigger heap corruption using crafted HTTP requests, leading to denial-of-service conditions and potentially remote code execution.

Because NGINX is deeply embedded within modern web infrastructure, including reverse proxies, API gateways, SaaS applications, and cloud environments, organizations should prioritize patching affected systems immediately and review rewrite-rule configurations for vulnerable patterns involving unnamed PCRE captures.

Imperva Cloud WAF and On-Prem WAF customers are protected against related attack activity.

The post CVE-2026-42945: Imperva Customers Protected Against Critical NGINX Rewrite Module Vulnerability appeared first on Blog.

Many developers today are using Claude Code, with a growing portion running it through Amazon Bedrock. For enterprise teams, Bedrock offers major advantages: keeping data inside a VPC, leveraging AWS credits, and integrating with existing IAM controls, monitoring, and security policies. Bedrock adoption also grows significantly among larger organizations and enterprise environments – but this setup can also introduce security risks or unintended configuration mistakes in real-world usage. 

If you’re running Claude Code with AWS Bedrock, there’s something you need to know: the AWS credentials you configure for Bedrock don’t stay confined to Bedrock. They might be shared with every shell command, every MCP server, and every subprocess that Claude Code spawns. And depending on how those credentials are scoped, that could mean full access to your entire AWS account. 

The Problem in a Nutshell 

When you set up Claude Code for Bedrock, you store your AWS credentials in ~/.claude/settings.json: 

{ 
   "env": { 
     "AWS_ACCESS_KEY_ID": "...", 
     "AWS_SECRET_ACCESS_KEY": "...", 
     "AWS_DEFAULT_REGION": "us-east-1", 
     "CLAUDE_CODE_USE_BEDROCK": "1" 
   } 
} 

These environment variables get loaded into the Claude Code process. So far, so normal. The issue is that Unix processes inherit environment variables from their parent. Every time Claude Code runs a shell command, spawns an MCP server, or launches any subprocess, those child processes get your AWS credentials too. 

That means any AWS CLI command executed through Claude Code authenticates as your IAM principal. Not just for Bedrock, but for everything that principal has permissions to do. 

How This Goes Wrong in Practice 

The security boundary here is entirely on the IAM policy side, Claude Code itself applies no restriction. If your IAM user only has `AmazonBedrockLimitedAccess`, the blast radius is minimal. But in practice, credentials often have broader permissions than intended. None of the scenarios below require an attacker or a sophisticated exploit, they’re everyday mistakes that happen when AWS credentials are broader than they need to be. 

1. Reusing your everyday IAM user

You already have an IAM user you use for daily development, like deploying lambdas, reading S3, or managing EC2 instances. Instead of creating a dedicated user for Claude Code, you drop those same credentials into settings.json because it’s faster. Now Claude Code has access to everything you do: production databases, customer data in S3, IAM itself. You meant to give it Bedrock access, but you actually gave it your entire AWS footprint. 

2. Operating on the wrong environment

You’re working on a staging project, but the credentials in settings.json belong to your production account. You ask Claude Code to “delete the old test data from S3” or “terminate the idle instances.” Claude Code generates the right AWS CLI commands for the task, but runs them against production. There’s no visual indicator in Claude Code telling you which AWS account or environment is active. The approval prompt shows aws s3 rm, and you click accept because the command looks correct for what you asked. 

3. Permissions drifting over time

You start with a tightly scoped IAM user for Bedrock only. Months later, someone on your team attaches AmazonS3ReadOnlyAccess for a one-off migration script and forgets to remove it. Then PowerUserAccess gets added during an incident for quick debugging. The Claude Code credentials silently gain more power over time, and nobody audits what it can actually do because “it’s just the Bedrock user.” 

4. Shared credentials across a team

A team lead sets up an IAM user for Claude Code and shares the credentials in a wiki or Slack channel for the team to use. Now multiple developers are running Claude Code with the same identity. There’s no way to distinguish who did what in CloudTrail logs. If one developer’s session is compromised through prompt injection, the blast radius covers everyone using those credentials, and attribution is impossible. 

The Attack Scenarios 

This isn’t just a theoretical concern. There are several realistic ways this can go wrong: 

Accidental over-provisioning is the most likely scenario. A developer uses Claude Code normally, unaware that a “clean up old files” prompt could generate AWS CLI commands touching production S3 buckets or EC2 instances. 

Prompt injection is more targeted. An attacker plants malicious instructions in a repository file: a README, a config file, a code comment. When Claude Code reads the file, the injected instruction can influence it to generate AWS CLI commands that exfiltrate data or create backdoor access keys. The user sees an approval prompt but might not catch the malicious intent among legitimate-looking operations. 

Compromised MCP servers inherit the full environment as subprocesses. A malicious or supply-chain-compromised MCP server can silently make AWS API calls using your credentials. 

What You Should Do 

Scope your credentials tightly. The IAM user or role you configure for Claude Code should have the absolute minimum permissions needed, ideally only bedrock:InvokeModel* and related Bedrock actions. Audit what’s attached right now. You might be surprised. 

Consider using Bedrock API keys instead of IAM credentials. Claude Code supports AWS_BEARER_TOKEN_BEDROCK, which is inherently scoped to Bedrock operations. API keys can’t be used by the AWS CLI for non-Bedrock operations. This is the most effective mitigation available today and requires no infrastructure changes. 

Use temporary credentials. If you must use IAM credentials, prefer STS temporary credentials or SSO-based authentication over long-lived access keys. They at least limit the exposure window. 

Pay attention to shell command approval prompts. When Claude Code asks permission to run a command –  read it. Look for aws CLI commands that access services beyond what you’d expect. If you see aws s3, aws ec2, aws iam, or similar, think about whether that’s something you intended to allow. 

Audit your settings.json. Run aws sts get-caller-identity with the configured credentials and check what policies are attached to that principal. If the answer is anything broader than Bedrock access, tighten it. 

The Bigger Picture 

This is a classic example of the principle of least privilege being violated through environment inheritance, a well-understood Unix behavior that becomes a security issue when credentials meant for one purpose are implicitly available for all purposes. 

Claude Code’s shell command approval prompt provides some protection, but it’s a thin layer. Users lack context about which AWS credentials are active and what permissions they grant. Approval fatigue, the tendency to reflexively accept prompts after seeing enough of them, further erodes this safeguard. 

The ideal fix would be credential isolation: Bedrock credentials should be internal to Claude Code and never exposed to shell subprocesses through environment variables. Until that happens, and according to Anthropic, the responsibility falls on you to ensure your credentials are scoped as narrowly as possible. 

The post Using Bedrock with Claude Code? Your AWS Credentials Are Shared With Every Subprocess appeared first on Blog.

AI agents are not a future concern. They are already changing how enterprise systems are accessed, automated, and abused.

And the security implication is clear: the more autonomous systems rely on APIs, the more important it becomes to know exactly which APIs exist, how they are being used, and whether they are being misused.

If your organization cannot answer those questions, you have a visibility problem. And in an environment where AI can accelerate both legitimate automation and malicious abuse, visibility is the first step to control.

Risk accelerating

APIs have always been a target because they expose data and business logic. What has changed is pace.

AI can now help attackers discover endpoints faster, test more abuse paths, and automate attacks that once took much more effort. Meanwhile, AI agents inside the enterprise are generating more API traffic, often with broader privileges than anyone intended.

That means security teams are facing a harder problem: not just more traffic, but more uncertainty and adversaries with improved tools.

What CISOs should be worried about

The biggest risks are not always the loudest ones.

Whether it’s an over-permissioned agent, a forgotten or shadow API, or a “legitimate” request abused to enumerate data or chain unauthorized actions, the risk is real. It’s often compounded by API tokens with broad access and long expiration times.

These are the kinds of issues that can lead to evasive data exfiltration, unauthorized payments, compliance violations, and operational surprises that go undetected far too long.

If your API security program cannot spot abnormal behavior early, the business is exposed.

×

May 21 Upcoming Webinar

Findings from the 2026 Bad Bot Report

Register Now

What good looks like

CISOs need a practical model, not more noise.

That model should:

• Continuously discover APIs across the environment.
• Classify which ones are sensitive.
• Establish baselines for normal behavior.
• Detect abnormal or suspicious API activity.
• Support least-privilege access for AI agents.
• Help revoke risky permissions quickly.

This is how security leaders turn AI agent activity from a blind spot into something measurable and governable.

The board conversation has changed

This is no longer just a technical issue for engineering or operations.

Boards care about risk, control, and business impact. They need to know how many AI agent-facing APIs are being monitored, how many anomalous calls have been detected, and how quickly the business can respond when something looks wrong.

That is the real opportunity for CISOs: to move API security into the center of the AI risk conversation.

Download the guide now

For CISOs, security leaders, and executives, this guide explains the new API security realities emerging with AI agents. We created A CISO’s Guide to API Security in the Age of AI Agents to help you navigate the shift with clarity and confidence.

Inside, you will learn:

• Why AI agents are increasing API risk rather than replacing it.
• How to connect API security to business and board-level concerns.
• What to look for in a practical CISO playbook for discovery, visibility, and control.
• How to govern agent-driven access before it becomes business exposure.

AI agents may change how work gets done. But the organizations that understand their APIs first will be the ones best positioned to stay in control.

Download the CISO guide now

The post Why AI Agents Make API Security a CISO Priority appeared first on Blog.

TL;DR: A newly disclosed denial-of-service vulnerability, CVE-2026-23870, impacts React Server Components and dependent frameworks, including Next.js App Router deployments. The flaw enables unauthenticated attackers to send specially crafted HTTP requests that trigger excessive CPU consumption during request deserialization, leading to potential service degradation or total unavailability. Imperva Threat Research Group has analyzed the vulnerability and associated attack patterns. Imperva Cloud WAF and On-Prem WAF customers are already protected against exploitation attempts targeting this issue.

The Vulnerability

Researchers recently disclosed CVE-2026-23870, a high-severity denial-of-service vulnerability affecting React Server Components and downstream frameworks such as Next.js. The issue exists in how vulnerable React Server Component implementations deserialize attacker-controlled request payloads sent to Server Function endpoints.

The vulnerability stems from improper handling of cyclic or recursively referenced data structures during request processing. Specifically, vulnerable deserialization logic within the React Flight protocol can repeatedly consume maliciously crafted models before properly marking them as processed, resulting in excessive resource consumption.

In practical terms, an attacker can send a specially crafted HTTP request to exposed Server Function endpoints in applications using React Server Components. When the payload is processed, the server enters a high-CPU execution state that can persist for extended periods before eventually throwing an error. Because the error is catchable and the attack requires no authentication, attackers can repeatedly issue malicious requests to sustain denial-of-service conditions.

The issue primarily impacts:

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

Affected versions include:

• 0.0 through 19.0.4
• 1.0 through 19.1.5
• 2.0 through 19.2.4

Patched releases are available in:

• 0.5
• 1.6
• 2.5

Because React Server Components are heavily used in modern application architectures, particularly high-traffic ecommerce, SaaS, and API-driven environments, exploitation can have significant operational impact. Applications leveraging Next.js App Router deployments are especially exposed due to the widespread use of Server Function endpoints.

Some of the techniques observed or associated with exploitation include:

• Crafted cyclic model payloads designed to trigger recursive deserialization behavior
• Repeated requests to Server Function endpoints to sustain CPU exhaustion
• Abuse of React Flight protocol request parsing logic
• Application-layer denial-of-service attacks targeting availability rather than data theft
• Automated scanning of exposed React and Next.js deployments for vulnerable endpoints

Unlike traditional volumetric DDoS attacks, CVE-2026-23870 enables low-bandwidth, application-layer denial of service by forcing disproportionate server-side computation. This makes the attack particularly attractive because relatively small numbers of malicious requests can create significant backend resource exhaustion.

Bottom Line

CVE-2026-23870 highlights the growing security risks associated with modern server-side rendering frameworks and component-driven architectures. By abusing request deserialization logic in React Server Components, attackers can trigger disproportionate backend resource consumption using relatively low-effort HTTP requests.

Since this vulnerability requires no authentication and targets exposed Server Function endpoints directly, exploitation is straightforward in unpatched environments. Organizations using React Server Components, Next.js App Router, or related server-side rendering frameworks should immediately upgrade affected packages and review exposed application endpoints.

Imperva Cloud WAF and On-Prem WAF customers are protected against related attack activity.

The post CVE-2026-23870: Imperva Customers Protected Against Critical React Server Components DoS Vulnerability appeared first on Blog.

Introduction

There’s an automated attack circulating right now that breaks into unprotected Redis servers, takes over the underlying machine, and then carefully puts everything back the way it found it. It restores the database filename. It deletes the tools it used. It detaches from the connections it opened. When it’s done, the server looks healthy. Logs look normal. Nothing appears to be wrong.

Except there’s a new line in /root/.ssh/authorized_keys that wasn’t there before.

We discovered this attack recently targeting a single Redis honeypot. Attacks came from 10 distinct source IPs across six countries, and over 1,200 attack attempts were recorded in a single month. Our data-driven, AI-based honeypot enabled us to detect and analyze this activity in detail.

The Attack

Redis was never designed to face the internet directly. But people expose it: a misconfigured security group, a container with the wrong port mapping, a developer who needs it reachable for a quick test. The default configuration has no password. Port 6379, open to the world.

When our Redis honeypot instance was exposed, the first visitors arrived within minutes. They connected, ran INFO, read the version string, and disconnected. That’s it. They aren’t trying to break in. They’re taking a census- cataloging what’s out there, how old it is, whether it’s protected. Thousands of these scans happen every day across the internet, quiet and mechanical.

Then a second wave showed up. These bots tried something: config set dbfilename backup.db. It’s a test. If Redis accepts the command, it means the server will let you write files to arbitrary paths on the host machine’s disk. The bot doesn’t exploit this. It just records the address and leaves. It’s building a list for someone else.

The real attack came as a single connection that tried five different methods of compromise in rapid sequence. The whole thing took a few seconds. It opened with FLUSHDB to wipe the database and clear the slate, and then worked through the following tricks:

Cron injection: redirect Redis’s save directory to /var/spool/cron/, write a key whose value is a cron entry. Now the host downloads and runs a binary from a C2 server every minute, with a randomly generated filename to dodge signature detection.

Lua sandbox escape: a Debian/Ubuntu packaging decision dynamically linked Redis’s Lua interpreter against the system library, breaking the sandbox. One EVAL command loads io.popen, leading to full RCE. CVE-2022-0543 is four years old, yet still working.

SSH key planting: same file-writing trick, pointed at /root/.ssh/authorized_keys. One line, and the operator has root access forever.

Replication hijacking: SLAVEOF tells Redis to sync from the attacker’s server, which serves a malicious shared object disguised as a database dump. MODULE LOAD turns it into a Redis extension exposing system.exec. This trick leads to full RCE through Redis’s own replication protocol.

Direct execution: use that module to download and run the binary through the shell.

Five methods, one connection, a few seconds- but attackers don’t need all five to work. They just need one.

Then the connection did something unexpected. It started cleaning up.

SLAVEOF NO ONE
 system.exec "rm -rf /tmp/exp.so"
 MODULE UNLOAD system
 config set dbfilename dump.rdb

It detached from the rogue replication server. It deleted the malicious shared library from the disk. It unloaded the module from Redis. It restored the original database filename. Redis is often used for ephemeral data, like sessions, queues, and rate limits, so a cleared database might not even raise an alarm. It just looks like a restart.

The attack was optimized for staying hidden after breaking in. Every forensic trace is reversed. The only artifact left behind is an SSH public key, one line in a file that most administrators never read, indistinguishable from a legitimate entry. Even if you find the malware, kill the process, and delete the cron entry, the key is still there. Root access, on demand, forever. Or until someone manually audits authorized_keys, which is rare.

The Botnets

The SSH Key Operator: A sophisticated, single-operator attack that targets unprotected Redis servers. It attempts five different RCE methods. Over a single month, our single Redis honeypot recorded over 1,200 attack attempts from 10 distinct source IPs across six countries. The majority included RCE attempts: Lua sandbox exploits and replication hijacking aimed at arbitrary command execution on the host. Different C2 servers, different binary names, but the same sequence, the same Lua payload, the same SSH public key. One operator, rotating sources and randomizing filenames. The key is the only constant.

The traffic came in distinct waves. Baseline was roughly 15 to 20 attempts per day from two or three sources. Then, without warning, a wave would hit, with a single IP connecting hundreds of times in an afternoon, once every 69 seconds- in total, over 300 attempts in a few hours. We saw three to four waves per month, each lasting two to six hours, each from a different source IP. Then silence until the next wave.

MGLNDD Botnet: A separate operation that periodically connects to exposed Redis servers, sending a single command format (MGLNDD_54.147.241.42_6379) to perform a “roll call” – checking whether the Redis server is already part of their botnet. It operates from Azure VMs using AWS IP addresses, never repeating the same source twice.

The SSH key operator and the MGLNDD botnet share the same hunting ground but ignore each other completely. Two separate operations are working in the same territory. An exposed Redis port isn’t just targeted by an attacker, it’s targeted by an ecosystem.

Takeaway

The attack is silent. The window between “I’ll fix that config later” and the machine is silently compromised isn’t days or hours-it’s seconds. Everything looks fine afterward: the server is up, the application works, the dashboards are green. The only artifact is an SSH key, patient and persistent, waiting to be used.

What You Must Do:

• Never expose Redis to the internet. Restrict access via security groups, firewalls, or VPCs.
• Set a strong Redis password. The default has none.
• Regularly audit /root/.ssh/authorized_keys for unfamiliar keys-attackers hide persistence here.
• Keep Redis patched. CVE-2022-0543 still works after 4 years.
• Monitor for suspicious commands: CONFIG SET, MODULE LOAD, FLUSHDB, SLAVEOF.
• Use file integrity monitoring on /root/.ssh/authorized_keys to detect tampering.
• Don’t trust green dashboards. Assume you’ve been breached until verified otherwise.

Imperva Data Security solutions provide comprehensive protection for your data against a wide range of threats. These offerings enable security teams to identify the location of sensitive information, monitor access patterns, and detect misuse promptly to facilitate timely response.

The post Your Redis Server Looks Fine. That’s the Problem. appeared first on Blog.

A five-level operating model for turning API security visibility into measurable risk reduction, faster remediation, and confident digital growth — without slowing development.

What is API security operationalization?

API security operationalization is the process of converting API discovery and visibility into continuous, measurable risk reduction across discovery, vulnerability identification, prioritization, mitigation, and scaling. It moves API security from a one-time assessment to a repeatable, outcome-driven program, with KPIs such as mean time to remediation (MTTR), high-risk API count, and exposed endpoint reduction.

Operationalization matters because APIs are the fastest-growing attack surface — and most organizations now have visibility into their APIs but cannot act on it consistently. Without operationalization, discovery becomes a catalog instead of a control.

 Why most API security programs stall after discovery

Most organizations aren’t struggling to see their APIs anymore. They’re struggling to turn API security visibility into consistent, measurable outcomes. According to the OWASP API Security Top 10, the most damaging API risks — broken object-level authorization (BOLA), broken authentication, and unrestricted resource consumption — all exploit gaps that exist after discovery, not before it.

APIs are the fastest growing attack surface — Imperva research shows API-directed attacks now account for a meaningful share of the application threat landscape (see the 2025 Imperva Bad Bot Report for current bot-driven API abuse data). Yet many security programs stall after discovery: risks are identified but not prioritized. Findings are reported but not operationalized. Controls exist, but don’t scale.

Imperva API Security closes that gap.

It enables organizations to move beyond insight and into action, so API security becomes a repeatable, outcome-driven capability that reduces real risk, improves efficiency, and supports faster innovation.

Here’s how to operationalize it for impact.

Figure 1: The Imperva API Security operational maturity model — five levels from Discover to Optimize. 

Level 1: API discovery and classification

Building a complete, continuously updated inventory of every API

API discovery is the continuous process of identifying every API endpoint — managed, unmanaged, shadow, and deprecated — across cloud, on-premises, and hybrid environments, then classifying each one by data sensitivity and business criticality.

You can’t secure what you don’t fully understand, and classifying APIs by data sensitivity helps reduce the scope to a more manageable set. In dynamic environments, APIs are constantly changing, new ones spin up, old ones linger, and many remain undocumented.

Operationalization starts with continuous, accurate discovery and classification:

• Identify every API across cloud, on-premises, and hybrid environments — including REST, GraphQL, gRPC, and SOAP endpoints
• Uncover shadow APIs, unmanaged endpoints, and deprecated/zombie APIs that bypass change-management controls
• Classify APIs by data sensitivity (PII, PHI, PCI, financial), business criticality, and external exposure
• Map authentication posture — which endpoints require auth, which use long-lived tokens, which are publicly accessible without auth

How Imperva delivers:

Imperva API Security provides deep, continuous visibility into your API ecosystem, helping you uncover hidden APIs and automatically build a risk-aware inventory. This gives you not just a list of APIs, but the context needed to act on them.

Outcome: Reduced API attack surface, an inventory you trust, and the foundation every later level depends on. Without trustworthy discovery, prioritization is guesswork.

×

May 21 Upcoming Webinar

Findings from the 2026 Bad Bot Report

Register Now

Level 2: Identifying API vulnerabilities and business-logic abuse

Expose real-world risk, not just theoretical issues

Modern API attacks don’t rely on obvious exploits. They leverage legitimate access in unintended ways — abusing business logic, over-permissioned tokens, and weak authorization. The OWASP API Security Top 10 ranks broken object-level authorization (BOLA) as the #1 API risk: an authenticated user manipulates an object identifier (user ID, account ID, document ID) to access another user’s data the API never intended to expose. Unlike SQL injection, BOLA produces no malformed payloads — every request looks legitimate.

To operationalize security, you need to detect:

• Broken object-level authorization (BOLA, OWASP API1:2023) and access-control gaps that grant cross-tenant data access
• Broken authentication (OWASP API2:2023) — weak tokens, credential stuffing, missing MFA on sensitive flows
• Unrestricted resource consumption (OWASP API4:2023) — missing rate limits, no quota enforcement
• Excessive data exposure (OWASP API3:2023) — endpoints returning more fields than the client needs
• Anomalous usage patterns and behavioral risks (account-takeover, scraping, slow-rate enumeration)
• Business-logic abuse — checkout, refund, and gift-card workflows weaponized by legitimate-looking calls
• Risky tokens — long-lived credentials, over-permissioned API keys, leaked secrets in client code

How Imperva delivers:

Imperva analyzes API traffic and behavior to surface context-rich risk signals, so you can see not just what’s vulnerable, but how it can be exploited in practice.

Outcome: Shift from static findings to actionable intelligence aligned with real attack paths.

Level 3: Risk-based API prioritization (cutting through alert noise)

Focus on what actually matters to the business

Not all API risks are equal and treating them that way slows teams down.

Operational maturity comes from risk-based prioritization:

• Which APIs are business-critical? — handle revenue-generating workflows, customer authentication, or core data
• Which expose sensitive data? — return PII, PHI, payment data, or trade secrets
• Which are externally accessible? — reachable from the public internet, partner networks, or third-party integrations
• What is the real-world impact if exploited? — regulatory penalty, customer trust loss, downtime cost, blast radius

How Imperva delivers:

Imperva brings together visibility, behavioral insight, and business context to help teams focus on the highest-impact risks first, cutting through noise and enabling faster, smarter decisions.

Outcome: Align security effort with business risk, not alert volume.

Level 4: API risk mitigation and measurable outcomes (KPIs that matter)

Turn insight into action, and prove it’s working

Security only delivers value when risk is actively reduced, and that reduction is measurable.

Mitigation should be paired with clear KPIs:

• High-risk API count — number of APIs flagged as critical-severity, month over month (direct measure of attack-surface reduction)
• Mean time to remediate (MTTR) — days from detection of an API risk to closure (proxy for security engineering velocity)
• Exposed/unmanaged endpoint count — public APIs without owner, doc, or auth control (catches drift between deploys)
• Protection coverage — % of high-risk APIs with active mitigation policies (shows control density across the surface)
• Inline-action rate — % of detected abuse stopped at session level (vs. IP block); differentiator vs. coarse-grained tools

How Imperva delivers:

Imperva enables teams to detect and respond to malicious or risky API activity with precision, using inline actions at the client session level to stop abuse in real time, far more effective than coarse IP-based blocking. This turns API security into a measurable, outcome-driven function.

Outcome: Demonstrate real risk reduction and tangible ROI.

Level 5: Scaling API security through automation and DevOps integration

Embed API security into how your business operates

Manual processes don’t scale in modern API environments. Optimization is about making API security continuous, automated, and integrated.

This means:

• Automating API discovery and risk assessment so every new endpoint is inventoried within minutes of deployment
• Embedding API security into CI/CD pipelines — schema validation, OWASP-scoped tests, and policy-as-code at PR time
• Integrating with the broader stack — SIEM, SOAR, ticketing, IAM, and the Imperva Web Application and API Protection (WAAP) platform
• Repeatable remediation playbooks mapped to API risk class (BOLA, broken auth, excessive data exposure, business-logic abuse)

How Imperva delivers:

Imperva helps operationalize API security at scale, reducing manual effort while improving consistency and coverage. It enables security teams to keep pace with development without becoming a bottleneck.

Outcome: Scale protection without scaling complexity.

The right + left operating model: balancing protection and enablement

Sustainable API security is not just about stronger controls. It’s about balance.

• Right (Protection): Visibility, detection, and enforcement to reduce risk
• Left (Enablement): Automation, scalability, and efficiency to support speed

Too much focus on protection slows the business. Too much focus on speed increases exposure.

Imperva API Security brings both together.

Right + Left = Optimum—where security doesn’t compete with the business; it accelerates it.

Figure 2: Building a Sustainable Strategy – Right + Left = Optimum

Conclusion: Make API Security a Business Enabler

The difference between having API security and operationalizing it is the difference between insight and impact.

With Imperva API Security, organizations can:

• Continuously discover and understand their API landscape
• Identify and contextualize real-world risks
• Prioritize based on business impact
• Mitigate and measure outcomes
• Scale security through automation and integration

The result is not just better security.

It’s faster innovation, stronger resilience, and confident digital growth.

If your API security program is stuck at visibility, it’s time to take the next step.

Operationalize it. Measure it. Scale it.

See how Imperva API Security can help you turn API security into a strategic advantage,

and start driving real business value from day one.

Want to see how Imperva API Security can be operationalized at scale? Watch the detailed expert webinar for practical guidance and real-world insights. 

Frequently asked questions about API security operationalization

What’s the difference between API security and API security operationalization?
API security is the set of controls that protect APIs from abuse. API security operationalization is the practice of running those controls as a continuous, measurable program — with discovery, prioritization, KPIs, and automation rather than one-time scans.

What are the most common API vulnerabilities?
The OWASP API Security Top 10 (2023 edition) ranks broken object-level authorization (BOLA), broken authentication, broken object-property-level authorization, unrestricted resource consumption, and broken function-level authorization as the highest-impact API risks. Most modern attacks combine two or more of these.

How is API discovery different from API documentation?
API documentation describes what an API is supposed to do. API discovery finds every API that actually exists in your environment — including shadow, deprecated, and undocumented endpoints that documentation misses. Operationalized programs treat discovery as continuous, not one-time.

How do you measure API security effectiveness?
Track high-risk API count, mean time to remediate (MTTR), exposed/unmanaged endpoint count, protection coverage, and inline-action rate. KPI movement over time is the proof that the program — not just the toolset — is working.

Does Imperva API Security work with my existing WAF or WAAP?
Yes. Imperva API Security is part of the Imperva Web Application and API Protection (WAAP) platform and integrates with Imperva WAF, the Imperva CDN, and third-party SIEM/SOAR tooling. The same operational model spans web app and API protection.

→ Explore the Imperva API Security platform: https://www.imperva.com/products/api-security/ 

The post API Security Operations: How to Move from Visibility to Measurable Risk Reduction appeared first on Blog.

What is CVE-2026-41940?

CVE-2026-41940 is a critical authentication bypass vulnerability affecting cPanel & WHM, including DNSOnly, in versions after 11.40. The flaw, discovered by WatchTowr Labs, exists in the login flow and allows unauthenticated remote attackers to gain unauthorized access to the control panel. The vulnerability carries a CVSS 3.1 score of 9.8 and is classified under CWE-306: Missing Authentication for Critical Function.

cPanel & WHM is widely used to manage web hosting environments. WHM provides administrative access to hosting infrastructure, while cPanel gives individual account holders control over their hosted sites. Because this vulnerability affects the authentication layer of a management interface, successful exploitation could give attackers access to high-value administrative functions across hosting environments. The issue affects all currently supported versions of cPanel & WHM, and the flaw is tied to session loading and saving behavior.

cPanel has released patched versions and recommends immediate updates. Administrators should update a fixed version, verify the cPanel build, and restart the cPanel service. For environments that cannot immediately patch, cPanel recommends blocking inbound traffic on ports 2083, 2087, 2095, and 2096 or temporarily stopping affected services.

Imperva customers are protected out-of-the-box against CVE-2026-41940.

Observations from Our Data

Since the release of CVE-2026-41940, Imperva has observed nearly 4,000 attack requests targeting customer environments.

Our data shows:

• Attacks targeting sites across 15 distinct industries and 17 countries, indicating broad scanning and opportunistic exploitation rather than activity concentrated against a single vertical or geography.
• US-based sites accounted for almost 70% of observed attacks, followed by Barbados and Israel. The heavy concentration against US sites suggests attackers are prioritizing regions with large hosting and web infrastructure footprints, while the presence of smaller geographies indicates automated discovery across exposed internet-facing assets.

• The most frequently targeted industries were Business, Society, and Education. This distribution reflects the broad deployment of hosting control panels across organizations that maintain public-facing websites, portals, and distributed web infrastructure.

While observed volume remains limited compared to mass exploitation campaigns, the spread across industries and countries shows active probing for exposed cPanel and WHM instances. Given the vulnerability’s unauthenticated nature and impact on administrative access, even moderate request volumes warrant urgent attention, and attack volumes will likely grow.

Mitigation and Protection

The definitive remediation for CVE-2026-41940 is to update cPanel & WHM to a patched version immediately. Organizations should also review cPanel’s detection guidance, inspect session files for indicators of compromise, and audit WHM access logs for unauthorized activity. cPanel’s advisory specifically recommends purging affected sessions, forcing password resets for root and WHM users, and checking for persistence mechanisms if indicators of compromise are found.

Imperva customers using Cloud WAF and WAF Gateway are protected against exploitation techniques associated with CVE-2026-41940. Imperva’s web application firewall inspects HTTP traffic for malicious patterns, helping block attempts to abuse authentication workflows and session-handling behavior before they reach vulnerable systems.

For customers with Cloud WAF, protection is automatically applied. Customers with WAF Gateway should refer to the manual mitigation guide sent by Imperva support teams and provided in the Imperva Community Guide.

Conclusion

CVE-2026-41940 represents a critical risk for organizations running exposed cPanel & WHM infrastructure. Its combination of unauthenticated access, low attack complexity, and potential administrative impact makes it a high-priority vulnerability for patching, monitoring, and incident review.

Imperva customers are protected against exploitation attempts associated with this vulnerability through Imperva’s web application firewall protections and HTTP traffic inspection capabilities. Organizations running cPanel & WHM should still apply vendor patches immediately, validate their deployed versions, and review available logs and session artifacts for signs of compromise.

The post Imperva Customers Protected Against CVE-2026-41940 in cPanel & WHM appeared first on Blog.

For decades, companies have operated on a simple assumption that most internet traffic came from people. That assumption no longer holds.

The latest 2026 Bad Bot Report: Bad Bots in the Agentic Age reinforces a shift that is now impossible to ignore. Automated traffic continues to outpace human activity online, accounting for more than 53% of all web traffic in 2025, up from 51% the year before. Human activity has declined to just 47% and continues to fall.

This is not a short-term spike driven by a specific attack cycle or technology trend. It reflects a structural change in how the internet operates. Increasingly, businesses are not serving customers alone. They are serving machines.

Key Findings From the 2026 Bad Bot Report

• Bots now drive 53% of web traffic. Automated activity has officially overtaken humans online, up from 51% in 2024.
• 27% of bot attacks target APIs. Attackers are bypassing user interfaces entirely to operate directly at machine speed.
• Financial services bear the brunt. The sector accounted for 24% of all bot attacks and 46% of account takeover incidents.
• AI agents are a new category of internet participant. They no longer just scan websites; they retrieve data, execute workflows, and act on behalf of users.

AI Agents and Bots Are Becoming the Default Internet User

Automation has always existed on the internet in the form of search engine crawlers, scripts, and background processes. What has changed is the scale, sophistication, and purpose of that automation.

AI is accelerating this shift. AI-driven bots have surged dramatically, but more importantly, AI agents are now emerging as a new category of internet participant. These systems don’t just scan websites; they interact with them, retrieve data, execute workflows, and increasingly act on behalf of users.

In practice, this means that what looks like a customer interaction may not be a customer at all. It may be an AI system querying pricing data, completing a transaction, or testing application behavior. For businesses, this blurs a fundamental line. The distinction between legitimate and malicious traffic is becoming harder to define, because both now operate through the same systems, use the same interfaces, and follow the same logic.

×

May 21 Upcoming Webinar

Findings from the 2026 Bad Bot Report

Register Now

The Rise of Uncontrolled Automation

The real risk is not the presence of bots, but that much of this automation is unmanaged. In earlier phases of the internet, bot activity was episodic and often easier to identify. Today, automation is persistent. It operates continuously across digital services, often indistinguishable from legitimate use. This creates a new category of risk that many organizations are not yet equipped to handle. Uncontrolled automation can distort business metrics, inflate infrastructure costs, degrade performance, and expose sensitive workflows.

For example, bots can continuously query pricing or availability systems, creating artificial demand signals. They can interact with promotional systems at scale, exploiting business logic in ways that traditional security controls are not designed to detect. Even benign automation, when left unmanaged, can place sustained load on systems that were designed for human behavior.

The result is that companies are increasingly sharing their digital infrastructure with automated agents that they neither fully understand nor control.

APIs and Identity Systems Sit at the Center of Modern Risk

As automation evolves, so do attacker strategies. The traditional model of targeting websites at the surface level is giving way to a more direct approach.

Bots are increasingly interacting with the same APIs that power core business functions, including authentication, payments, search, and inventory systems. In 2025, 27% of bot attacks targeted API endpoints, allowing attackers to bypass user interfaces entirely and operate at machine speed. These interactions often appear legitimate, with well-formed requests and successful authentication, but the difference lies in intent and scale.

This is particularly visible in sectors where digital transactions are tightly linked to revenue. Financial services, for example, accounted for 24% of all bot attacks and 46% of account takeover incidents. The goal is not disruption for its own sake, but direct monetization.

In this environment, identity systems are no longer just a security layer. They are a primary point of exposure.

How AI Agents Are Quietly Rewriting Business Models

The shift toward machine-driven interaction is not only a security issue. It is beginning to reshape how businesses operate.

If a growing share of traffic is automated, then traditional metrics such as user engagement, conversion rates, and demand signals become harder to interpret. A spike in traffic may not indicate customer interest. A drop in performance may not be caused by user behavior.

At the same time, AI-driven systems are creating new forms of demand. Companies are beginning to consider how and whether to allow AI agents to access their services, and under what conditions. This raises questions about access control, pricing, and even monetization.

Some organizations are exploring models where AI-driven access is authenticated, measured, and potentially governed as a distinct channel. While still early, this points to a future in which businesses must actively manage not just who accesses their systems, but what.

From Bot Detection to Automation Control

For years, cybersecurity strategies have focused on detecting and blocking malicious activity. That approach is increasingly insufficient in a world where automation is both pervasive and often legitimate. The more important question is no longer whether traffic is automated, but whether it aligns with business intent.

This shift, from blocking bad bots to governing all automation based on intent, requires a new approach. Organizations must move from viewing bots as anomalies to viewing automation as a fundamental part of their operating environment. That means implementing controls that can distinguish between acceptable and harmful automation, applying governance to how systems are accessed, and designing defenses that can adapt as behavior changes.

In effect, the challenge is becoming one of control rather than detection.

A Machine-Driven Internet

The internet is entering a new phase that’s defined less by human interaction and more by machine-to-machine activity. Automation is no longer a layer on top of digital infrastructure but embedded within it, with significant implications for businesses. Trust, performance, and revenue are increasingly shaped by how well organizations manage automated interaction.

Companies that continue to operate under the assumption that users are human risk misreading their own systems. Those that adapt by understanding, governing, and controlling automation will be better positioned to compete in an internet where machines are not just participants, but the majority.

The shift is already underway. The question for businesses is not whether it will happen, but how they will respond.

Download the Full 2026 Bad Bot Report

Get the complete data, sector breakdowns, and defense recommendations in Imperva’s 2026 Bad Bot Report: Bad Bots in the Agentic Age.

Frequently Asked Questions

What is the Imperva Bad Bot Report?

The Imperva Bad Bot Report is an annual industry research report analyzing global automated bot traffic, attack trends, and the impact of malicious bots on websites, APIs, and applications. The 2026 edition focuses on the rise of AI agents and agentic automation.

How much of internet traffic is bots in 2025?

According to Imperva’s 2026 Bad Bot Report, automated bot traffic accounted for more than 53% of all web traffic in 2025, up from 51% the year before. Human traffic has fallen to 47% and continues to decline.

Why are AI agents a cybersecurity concern?

AI agents act on behalf of users, retrieving data, executing workflows, and completing transactions through the same interfaces as humans. This blurs the line between legitimate and malicious traffic, makes traditional bot detection insufficient, and exposes APIs and identity systems to automation that organizations cannot easily distinguish from real users.

Which industries are most affected by bot attacks?

Financial services experience the highest impact, accounting for 24% of all bot attacks and 46% of account takeover incidents in 2025. APIs are the dominant attack surface, with 27% of bot attacks targeting API endpoints across all industries.

The post Bad Bot Report 2026: The Internet Is No Longer Human and It’s Changing How Business Works appeared first on Blog.

When evaluating cloud security platforms, one question comes up again and again:

“How many Points of Presence do you have?”

At first glance, the logic seems sound. More locations should mean lower latency, faster response times, and better protection. The assumption is simple: if security is delivered at the edge, then more edge locations must automatically translate into stronger application security.

That assumption, however, is largely inherited from the content delivery world — and it does not hold up when applied to real‑time application and API protection.

The Common Assumption: More PoPs Means Better Security

In content delivery networks (CDNs), PoP count is a meaningful metric. Static content benefits directly from being cached as close as possible to end users. The more locations you have, the more likely content can be served locally, reducing latency and improving page load times.

Application security operates under a very different set of constraints.

Web Application and API Protection (WAAP) platforms are not simply delivering content. They must inspect every request, enforce security policies, analyze behavior, detect abuse, and mitigate attacks in real time — all while maintaining visibility across global traffic flows.

In this context, proximity alone is not the primary driver of security effectiveness.

Not All PoPs Are Created Equal

A Point of Presence is a physical location where traffic is processed — but PoPs vary widely in capability.

Some platforms emphasize deploying a very large number of small, highly distributed PoPs optimized for caching and proximity. Others prioritize fewer, high‑capacity PoPs placed at major internet exchange points and backbone hubs.

These high‑connectivity locations sit directly on global networks, allowing traffic to reach them efficiently from broad geographic regions. In practice, users are often only a few milliseconds away from a well‑connected PoP, even if it is not located in the same city or country.

For security workloads, network connectivity, inspection depth, and capacity matter far more than raw geographic density.

Anycast Routing Changes the Equation

Modern security platforms rely on Anycast routing, which automatically directs traffic to the optimal PoP based on real‑time network conditions rather than simple physical distance.

With Anycast routing:

• Traffic follows the most efficient network path
• Performance remains consistent even during outages
• Failover happens automatically without user intervention

A well‑architected Anycast network can deliver predictable performance and resilience without requiring a PoP in every location where users reside.

Security Is Not the Same as Content Delivery

The most important distinction to understand is this:

CDNs scale by distributing copies of static content.
Security platforms scale by performing stateful inspection and coordinated decision‑making on live traffic.

Security inspection is computationally intensive and context‑dependent. Every request must be evaluated against behavioral models, threat intelligence, and policy logic. This work is fundamentally different from serving cached files.

As PoP counts increase, security platforms must make architectural trade‑offs around:

• How much inspection can be performed locally
• How much capacity is available per location
• How security intelligence is synchronized globally
• How attacks spanning regions are detected and mitigated

These trade‑offs define security outcomes far more than the number of locations alone.

What “Security in Every PoP” Really Means

Some modern platforms advertise that they run security services in every PoP, enabling them to deliver cached content and secure application traffic in the same location.

This approach offers clear advantages for latency‑sensitive use cases and environments where performance and security must be tightly coupled at the edge.

However, delivering security everywhere requires security capabilities to be highly distributed and lightweight by design. As PoP counts grow into the hundreds or thousands, platforms must balance:

• Inspection depth versus per‑location footprint
• Local decision‑making versus global coordination
• Uniformity of protection versus operational complexity

In practice, “security in every PoP” often prioritizes speed and proximity over inspection depth, per‑location capacity, and attack absorption strength. While this model performs well under normal traffic conditions, it does not inherently guarantee stronger protection during large, sustained, or highly coordinated attacks.

Concentrated Capacity vs. Distributed Presence

Highly distributed security architectures excel at minimizing latency and handling everyday traffic efficiently.

Security‑first architectures, by contrast, are designed to concentrate capacity, intelligence, and mitigation power at strategically connected locations.

This concentration enables:

• Immediate absorption of large volumetric attacks without traffic redirection
• Deep, stateful inspection even under extreme load
• Faster detection of coordinated attack patterns
• Predictable performance during worst‑case scenarios

For application and API security, the most critical moments are not normal operations, but peak attack conditions. It is during these moments that per‑PoP capacity and global visibility matter more than sheer geographic density.

When PoP Density Does Matter

PoP count does play an important role in specific scenarios:

• Global delivery of static content
• Ultra‑low‑latency applications such as gaming or live streaming
• Environments heavily reliant on edge caching

Many enterprises address this by separating concerns — using one platform optimized for content delivery and another purpose‑built for inline application and API security.

Architecture Over Optics

PoP count makes for an impressive slide, but it does not tell the full story.

The true measure of an application security platform lies in its network design, routing intelligence, inspection depth, per‑location capacity, and ability to perform under attack — not in how many dots appear on a map.

Some platforms optimize for being everywhere.
Others optimize for being strong where it matters most.

PoP count measures proximity.
Security performance measures resilience.

In application security, architecture — not optics — determines outcomes.

The post Why PoP Count Isn’t the Real Measure of Application Security Performance appeared first on Blog.

When Anthropic unveiled Mythos and Project Glasswing, the reaction was immediate and polarized. Some dismissed it as fear-driven marketing, while others treated it as a credible shift in the threat landscape.

Like with many things, the truth is probably somewhere in the middle. I wanted to test that for myself, and since I recently got access to OpenAI’s Trusted Access for Cyber program, I decided to take it for a spin.

GPT-5.4 identified the bugs and helped assemble a working exploit chain, but it wasn’t a simple “build me an exploit” prompt. Guiding it required domain knowledge, iterative probing, and knowing which paths were actually exploitable.

On modern browsers like Safari, exploitation is less about finding bugs and more about finding bugs that still matter after multiple layers of defense.

The bug I’m going to talk about today sits in a more interesting category. The bug itself looked contained, and in many ways it was. It did not provide a path to RCE or a sandbox escape. What it did instead was cross a different boundary entirely: it broke the Same-Origin Policy.

If you visited a malicious page from any Apple device, it could read authenticated cross-origin data from other sites you use, including access tokens and other sensitive data, making account takeover trivial.

The video below shows the PoC we sent Apple, demonstrating leakage of sensitive data from both Apple Connect and iCloud / Apple ID endpoints. Although this demo focuses on Apple services, the issue affects all websites. This means that by visiting a malicious website, sensitive data from other domains is at risk of being leaked.

The Sandbox Russian Doll

Browser exploitation in 2026 is a lot like being trapped in a Russian doll.

You start in the smallest doll, and every time you escape one layer you discover you are still trapped inside another one.

Finding a low-level memory bug is not the same thing as finding an exploit. Most of these bugs die in the gap between “memory corruption happened” and “something meaningful crossed a security boundary.”

On the outside you have the browser process model. Even if renderer code goes wrong, the browser is trying very hard to keep that damage inside the web content process.

Inside that you have the web security model: Same-Origin Policy, CORS, opaque responses, cookie scoping, and credential modes. Even if a page can trigger a cross-origin request, the renderer, and especially the Gigacage, should not be able to access the response bytes. Right?…

The Bug

The original bug lives in the refresh logic for non-shared resizable WebAssembly memory.

When a non-shared WebAssembly.Memory grows in BoundsChecking mode, JavaScriptCore can replace the underlying memory handle. That part is not the bug. The bug is what happens after that to the JS-visible resizable buffer returned by memory.toResizableBuffer().

The bug is simple enough that once I saw it, it was hard to unsee it. Safari’s grow path effectively does this:

And the refresh step effectively does this:

After memory.grow(), WebKit updates the buffer metadata, but leaves m_data pointing at the old freed allocation.

So after a grow, JavaScript can hold a buffer whose reported size is new, whose handle is new, but whose actual data pointer still references the old freed Primitive Gigacage allocation.

That turns into a stale typed-array window over freed memory.

On its own, this is already a real bug. But we’re still stuck inside the JavaScriptCore gigacage, effectively sandboxed. Without a second bug to break out into the renderer, it doesn’t chain into anything meaningful. What we have is a solid first-stage primitive, but no real security impact on its own.

Why it did not look exploitable at first

The stale window is confined to the Primitive Gigacage, which immediately limits what you can do with it. Many typical targets either never land there, lack useful structure, or fail to produce any cross-boundary effect.

So early on, it had all the hallmarks of a bug that looks promising but rarely goes the distance:

• easy source-level root cause
• visible stale memory behavior
• real reclaim
• no clean escape path

This is where a lot of low-level browser bugs die.

What changed the problem was a very different framing: maybe I did not need to escape the cage at all.

Maybe I just needed the browser to place something valuable inside it.

The Pivot

Instead of asking “how do I get from my stale WASM view to some protected browser state?” I started asking a better question:

“What browser code takes data that JavaScript is not allowed to read, but still copies that data into normal renderer memory?”

Because that is all I need.

I don’t need to break the abstraction.

I just need the browser to break it for me.

That naturally narrows the search space to subsystems that:

• handle sensitive cross-origin data, and
• still allocate ArrayBuffer-backed memory as part of their internal pipeline

That points straight at Fetch. The Fetch API clearly indicates that the response is opaque, meaning that its headers and body are not available to JavaScript.

Opaque Responses Are Supposed to Be Opaque

At the API level, the Fetch model here is straightforward.

If I do a cross-origin request with:

fetch(url, { mode: “no-cors”, credentials: “include” });

The browser may send the request, including cookies depending on context, but JavaScript receives an opaque response.

That means:

• I can hold the Response object
• but I cannot read the body bytes

And WebKit enforces that in the obvious place:

FetchBodyOwner::readableStream() blocks opaque bodies via isBodyNullOrOpaque().

So at first glance, everything looks fine. The body is hidden. The policy is enforced. Same-Origin Policy survives another day.

Except it does not.

The Fetch Behavior that Broke the Modal

The surprising part is Response.clone().

If FetchResponse::clone() is called while the response is still loading, WebKit will internally create a readable stream so it can tee the body between the original response and the clone.

That internal path does not apply the same opaque-body check first.

And once that happens, hidden response bytes start becoming very real renderer objects.

This is the part that made me stop and stare at the source, because the mismatch is right there.

The normal body path blocks opaque responses:

But FetchResponse::clone() does this while the response is still loading:

That is why it works.

The visible accessor path says “opaque bodies do not get a stream.” The clone path says “if it is still loading, create a stream so both clones can tee it.”

That second path is exactly what I needed.

The data flows through normal ArrayBuffer creation paths:

• buffered chunks go through tryCreateArrayBuffer()
• later chunks go through takeAsArrayBuffer()
• shared buffer data gets copied into ordinary ArrayBuffer allocations inside the renderer

So the policy ends up split in two:

• the public Fetch API says the body is opaque
• the renderer still materializes the opaque body into readable byte arrays during clone-time streaming

Combined with the stale WASM window, it becomes a SOP break.

The Chain

At a high level, the exploit became:

1. Force the target WASM memory into the BoundsChecking path.
2. Call memory.toResizableBuffer().
3. Grow the memory.
4. Keep the stale resizable buffer whose pointer still targets freed Primitive Gigacage pages.
5. Trigger a cross-origin fetch(…, { mode: “no-cors”, credentials: “include” }).
6. Call response.clone() while the response is still loading.
7. Let Fetch internals materialize the hidden body bytes into ordinary renderer ArrayBuffers.
8. Reclaim the stale WASM-covered pages with those allocations.
9. Read the cross-origin bytes through the stale view.

That is the entire trick.

I never needed response.text(). I never needed response.arrayBuffer(). I never needed the public API to hand me the body.

The browser copied the body into memory for its own internal bookkeeping, and the stale WASM view read it directly.

That is why this bug stopped being “some weird WASM UAF” and became “this completely breaks the Same-Origin Policy.”

The file:// Detour

One of the weirdest parts of the research was that the request side behaved differently depending on where I launched it from.

In my testing, cross-origin requests were much easier to get moving from file:// than from a normal https attacker page.

That sounds backwards until you look at WebKit’s handling of local origins.

Document.cpp has explicit special-casing around local documents and settings like:

• allowUniversalAccessFromFileURLs
• allowFileAccessFromFileURLs

MiniBrowser exposes those knobs too, which made file:// very useful as a research environment. It let me focus on the memory side and confirm the leak path before I had a clean web-facing story.

But I did not want a local-file party trick.

I wanted a real web exploit.

And from a normal https page, the same request pattern was not giving me the reliability I wanted.

That is where about:blank saved me.

Why about:blank saved the final POC

The final PoC opens an about:blank popup and performs the fetches from there:

This ended up mattering a lot.

At first I thought this was just an origin-inheritance trick. That part is real:

So about:blank does inherit the opener’s origin.

But that alone does not explain why the popup path behaved differently.

What actually seems to matter is Safari’s cookie / first-party bookkeeping. Fetch subresource requests copy document->firstPartyForCookies() into the request:

And WebKit’s cookie blocking logic bails out immediately if that first-party domain is empty:

That is a very different path from a normal attacker-controlled https page. From a regular https://attacker.example origin, the first party is the attacker site, so a request to the victim site looks third-party and Safari’s tracking-prevention logic can suppress cookies.

From the about:blank popup path, the security origin still comes from the opener, but the popup’s top-level URL / first-party context is no longer a normal registrable https site in the same way. In practice, that was enough to make credentials: “include” requests behave differently and get me the authenticated traffic pattern I needed.

So the important point is not “about:blank disabled CORS.” It did not. The important point is:

• the popup kept the opener’s origin
• the request still went through normal Fetch/CORS code
• Safari’s first-party cookie logic treated that popup context differently

That was the difference between “cross-origin request happens but is useless” and “cross-origin request comes back with authenticated bytes worth stealing.”

Why this was fun

This is my favorite kind of browser bug.

Not because the root cause was complicated. It was not. The WASM bug was almost embarrassingly direct.

And not because the final chain was huge. It was not.

It was fun because it is exactly the kind of bug modern browser architecture is supposed to suppress.

A stale pointer inside a cage is supposed to stay a stale pointer inside a cage.

An opaque response is supposed to stay opaque.

Those are both reasonable assumptions.

The exploit works because both assumptions were true only locally.

JavaScriptCore gave me a stale view that looked hard to use. WebCore Fetch gave me sensitive bytes that looked impossible to read.

Put them together and Safari’s Same-Origin Policy fell apart.

Disclosure

We reported our findings to Apple. Shortly after, a fix shipped, suggesting the issue was already known internally.

The vulnerability (CVE-2026-20664) is addressed in iOS 26.4 and iPadOS 26.4 (23E6254 and later), and macOS Tahoe 26.4 (25E253 and later). Make sure your systems are up to date.

Closing Thoughts

The biggest thing on my mind after working with these models is the leverage they provide, and what that means for N-days. A security patch in popular software used to hide the underlying exploit behind time, effort, and expertise. Now that you can scale tokens instead of effort, that barrier is mostly gone.

This doesn’t turn exploitation into a trivial task. You still need someone who understands what they are looking at, can filter noise, and can steer the process when it stalls. But AI changes the unit of work. Instead of deep, sequential effort, you get parallel exploration and rapid iteration. The constraint shifts from raw effort to how effectively an operator can guide multiple lines of inquiry at once.
`

The post Hacking Safari with GPT 5.4  appeared first on Blog.

In today’s dynamic digital environment, the pressure to innovate has never been greater. Development teams are pushing for native cloud tools to maximize performance and cost-efficiency, while security teams require best-of-breed, enterprise-grade protection to defend against an ever-evolving threat landscape. This often creates a point of friction, forcing organizations into a difficult trade-off: sacrifice performance for security, or accept weaker protections for the sake of speed.

To resolve this challenge, Thales Imperva is collaborating with Google Cloud to deliver a solution that helps bridge this gap. We are proud to introduce Imperva for Google Cloud (IGC), an integrated security solution that offers the best of both worlds: enterprise-grade application security with the cloud-native performance you expect from Google Cloud.

Imperva for Google Cloud: A Holistic, Integrated Solution

Imperva for Google Cloud is not just another security layer; it is a fully managed, best-in-class Web Application and API Protection (WAAP) solution built directly into the fabric of Google Cloud. This integration, available now on Google Cloud Marketplace,   provides robust protection without disrupting your existing infrastructure or workflows.

• Cloud-Native Performance Without Compromise: Imperva for Google Cloud uses Google Cloud’s native Service Extension and Private Service Connect to inspect traffic within the Google Cloud network. This means all traffic analysis happens without your data ever leaving Google Cloud infrastructure, preserving optimal latency, performance, and data residency.
• Quick Deployment: Forget complex re-architecture. Imperva for Google Cloud can be deployed quickly using familiar tools like Terraform, Google Cloud CLI (gCloud CLI), or the Google Cloud console UI. There are no disruptive DNS, SSL, or network routing changes required, allowing you to achieve production-ready protection almost immediately.
• Enterprise-Grade Protection Out of the Box: Imperva for Google Cloud is powered by Imperva’s industry-leading security engine, delivering comprehensive WAF, advanced API Security, and Account Bot Protection. Backed by 24/7 threat research, the Imperva solution provides near-zero false positives, with 97% of customers successfully using default policies and 95% running in blocking mode from day one. This dramatically reduces the operational overhead of constant rule tuning.

Real-World Impact: Securely Accelerating Your Business

By eliminating the trade-offs between security and performance, Imperva for Google Cloud helps organizations achieve key business outcomes:

• Accelerate Lift-and-Shift Migrations: Migrate workloads to Google Cloud confidently with security that adapts to your applications, not the other way around. Eliminate migration delays caused by complex security re-architecture.
• Unleash DevOps-Friendly Security: Empower development teams to innovate at speed. IGC closes the security gaps in built-in tools without slowing down deployment velocity or requiring developers to become security experts.
• Protect Modern Cloud-Native Applications: Secure your Kubernetes and microservices architectures with best-in-class defenses optimized for low-latency environments.
• Achieve Unified Multi-Cloud Governance: Manage security for all your Imperva-protected environments from a single, unified dashboard, providing consistent policy management and visibility across your entire multi-cloud estate.

“Bringing Thales Imperva to Google Cloud Marketplace will help customers quickly deploy, manage, and grow the company’s integrated security solution on Google Cloud’s trusted, global infrastructure,” said Dai Vu, Managing Director, Marketplace & ISV GTM Programs at Google Cloud. “Thales can now securely scale and support organizations that want to use its Imperva for Google Cloud solution to increase protection for their cloud-native applications, APIs, microservices and more.”

×

May 21 Upcoming Webinar

Findings from the 2026 Bad Bot report

Register Now

Join Us on the Journey to More Seamless Cloud Security

As we approach key industry events like our exclusive Executive Briefing Center (EBC) meeting in late March and Google Cloud Next 2026 in April, the conversation around integrated  security has never been more relevant. The launch of Imperva for Google Cloud marks a pivotal moment in our relationship with Google, providing a clear path for customers to secure their digital assets without compromise.

Ready to secure your cloud-native applications?

• Request a demo: Experience IGC in action at Imperva for Google Cloud
• Start your evaluation: Available now on Google Cloud Marketplace

The post Enterprise-Grade Application Security, Cloud-Native Speed: Introducing Imperva for Google Cloud appeared first on Blog.

The recent buzz around Anthropic’s Mythos model has been intense, and for good reason. Early reports suggest a model that significantly advances automated reasoning over large codebases, vulnerability discovery, and exploit generation. Some are already calling it a “game changer” for offensive security. 

But like most breakthroughs in AI, the reality is more nuanced. 

Let’s unpack what Mythos is, why it’s getting so much attention, and where the real impact will (and won’t) be. 

What Is Mythos, and Why It Matters 

At its core, Mythos is designed to operate deeply within software systems: 

• It can reason across entire codebases, not just snippets  

• It demonstrates strong capabilities in multi-step vulnerability discovery  

• It can potentially chain findings into realistic exploit paths  

This is what sets it apart from earlier models. Traditional LLMs often struggled with: 

• Context fragmentation (limited memory of large systems)  

• Superficial pattern matching (vs. true reasoning)  

• Weakness in multi-stage attack logic  

Mythos appears to push beyond that, closer to what human security researchers do when analyzing complex systems. 

That’s the hype. Now let’s put it into perspective.

1. Closed Systems Still Have a Natural Advantage

One of the most important constraints, often overlooked, is access. 

Organizations running: 

• Licensed binaries  

• Closed-source products  

• SaaS platforms  

are inherently less exposed to this class of AI-driven analysis. 

Why? Because Mythos appears to be most effective when it has full visibility into the source code. Without that: 

• Reverse engineering binaries is still hard and lossy  

• SaaS environments expose only interfaces, not logic  

This creates a natural barrier for attackers. 

Although “security through obscurity” isn’t a solution, in practice: 

• Open-source projects and exposed codebases will feel the impact first  

• Closed vendors still need to worry, but they’re not suddenly transparent overnight 

2. The Real Pressure Point: Time-to-Mitigation

AI doesn’t just change what attackers can do, it changes how fast everything happens.  

And this is where security vendors feel the most pressure. The challenge isn’t whether vulnerabilities exist, it’s how fast vendors can respond once they’re discovered. 

The new race: 

• AI/ human finds vulnerability →  

• AI Exploit is generated quickly →  

• Attack traffic emerges earlier →  

• Defenses must adapt in near real-time.

This shifts the competitive advantage to vendors that can: 

• Automate security workflows to 

• Rapidly understand new attack patterns  

• Generate mitigations  

• Deploy protections before mass exploitation 

3. The Budget Reality: AI Red-Teaming Isn’t Cheap 

One of the least discussed aspects of Mythos is cost. 

Running such a model at scale involves: 

• High compute costs  

• Expensive infrastructure  

• For example, Anthropic admitted that “Across a thousand runs through our scaffold, the total cost was under $20,000” for finding vulnerabilities in OpenBSD.

• Significant human validation effort 

And that last part is critical. 

Every finding still requires: 

• Verification (is it real?)  

• Reproduction  

• Impact assessment  

Which means more security engineers per finding, not less.

Organizations will need to start budgeting for: 

• AI-assisted red teaming  

• Dedicated pipelines to process findings  

• Integration into SDLC workflows  

This mirrors what we’ve already seen with GitHub Copilot-style assistants and AI-based code analysis tools.

Implication for attackers: 

These “doomsday” capabilities are not evenly distributed. 

• Well-funded actors (nation-states, top-tier cybercrime groups) → likely adopters  

• Opportunistic attackers → much slower to benefit  

So the threat landscape widens at the top, not uniformly across all attackers.

4. Bug Bounty Programs Will Feel the Noise First

One immediate and very practical impact: bug bounty platforms are about to get noisy. 

Expect a surge of: 

• AI-generated vulnerability reports  

• Poorly validated findings  

• Duplicates and false positives  

This creates a scaling problem for security teams. 

Organizations will need to adapt: 

• Stronger triage filtering mechanisms (likely AI-driven)  

• Reputation systems for researchers  

• Penalties for repeated false positives  

• Potential adjustments in bounty pricing  

Otherwise, teams risk wasting cycles on low-quality reports and missing real vulnerabilities buried in noise. Ironically, AI will be needed to defend against AI-generated reports.

5. Not All Vulnerabilities Are Equal

Another important nuance:  

Finding a vulnerability ≠ exploiting it at scale. 

Even with Mythos: 

• Many findings will be low impact  

• Exploitation may require environment specific conditions  

• Real-world constraints (auth, rate limits, monitoring) still apply  

This is where traditional security layers still matter: 

• WAF, API protection, Bot protection 

• Identity protection 

• Data protection 

• Threat reputation 

Mythos increases discovery capability, but doesn’t eliminate defense in depth. 

Final Thoughts 

The Mythos model presents a meaningful step forward. It brings AI closer to acting like a real security researcher, capable of deep reasoning and complex analysis. 

But it’s not a universal “break everything” button. 

• Closed systems still provide friction  

• Costs limit widespread misuse  

• Defensive technologies remain highly relevant  

• Operational processes (triage, mitigation) become the real bottleneck  

The hype focuses on capability. The reality is about constraints and execution. 

And as always in cybersecurity, the winners won’t be those with the best tools, but those who can operationalize speed, from detection to mitigation, at scale. 

The post Anthropic Mythos: Separating Signal from Hype appeared first on Blog.

Executive Summary

In this article, we disclose a new high severity unauthenticated remote denial‑of‑service vulnerability we identified and reported in React Server Components that we’ve dubbed “React2DoS”.  In this blog, we’ll analyze its impact and place it in the broader context of recently found Flight protocol vulnerabilities, especially CVE‑2026‑23864.

Introduction

We are in a phase of the web where performance and developer experience are no longer trade-offs, they’re expectations. Modern frameworks compete to ship less JavaScript, reduce client-side complexity, and move logic back to the server.

React, as one of the dominant forces in frontend development, has been at the forefront of this evolution. With the introduction of React Server Components (RSC), the ecosystem embraced a new model: components that execute exclusively on the server, access databases and secrets directly, and stream a serialized UI representation to the client.

This architecture promises smaller bundles, cleaner separation of concerns, and more efficient rendering. Instead of hydrating everything on the client, Server Components emit a structured stream that the browser reconstructs locally.

At the heart of this mechanism lies a custom streaming protocol known as Flight. Through Flight, React can serialize complex structures, like arrays, maps, object references, even promises and async boundaries, allowing the server to describe rich UI trees in a compact format.

This is powerful.

But history has shown that when we introduce custom serialization formats and complex parsers, we also introduce risk. The server must deserialize and reconstruct object graphs from client-controlled input. And complex parsing logic has long been fertile ground for vulnerabilities.

In our research we discovered a denial-of-service vulnerability that allows an attacker to impose disproportionate computation to the remote server.

React2Shell and subsequent DoS vulnerabilities

Earlier this year, the disclosure of React2Shell caught much of the community off guard, triggering emergency patches and intense scrutiny of the React Server Components architecture, amplified by waves of low-quality AI-generated analysis that blurred the line between verified facts and speculation. This episode also prompted deeper investigations into and led to new discoveries related to the security of the Flight protocol and related parsing mechanisms.

CVE‑2026‑23864 (CVSS 3.1 of 7.5), stood out as a notable example and serves as a useful reference for understanding the mechanics behind the issue we explore in this research.

Among other vectors, this vulnerability concerned the BigInt deserialization path in Flight:

• $n markers denote BigInt values
• No limit was enforced on digit length

Therefore, sending a million‑digit BigInt could cause a significant computation cost, and CPU exhaustion. An example payload could look like this:

0:"$n9999999999...[repeated 1 million times]"

In our setup, a single query like this could delay the server’s execution by several seconds if the inbound payload reaches the maximum allowed size (1MB with Node.js runtime, 10MB with Edge runtime).

This was the starting point of our research, and we tried to find payload that would trigger a similar, or superior cost to the server. This is exactly what we found, actually more computationally-intensive  by several orders of magnitude.

React2DoS

React relies on a mechanism known as the React Flight Protocol to serialize values that are sent to Server Functions.

On the client side, data is transmitted to the server as small pieces (or “chunks”), for example through form submissions:

payload = {
  "0": (None, '["$1"]'),
  "1": (None, '{"category":"vehicle","model":"$2:modelName"}'),
  "2": (None, '{"modelName":"tesla"}'),
}

As illustrated above, these chunks can reference one another.

After deserialization on the server, the reconstructed object looks like this:

{ "category": "vehicle", "model": "tesla" }

At first, we tried to measure the cost of execution of every type of reference supported by the Flight protocol. Among them, we looked at two promising ones: $Q and $W, respectively instantiating new Maps and Sets from the client request payload.

The first observation we made was that it was possible to reference the root element in the root element itself (!), which paved the way to recursive expressions:

“0” : [“$Q0”]

This, would cause the execution of the following JavaScript expression:

New Map([null])

Which makes perfect sense, because at the time of resolution of $Q0, $0 is not known yet.

However, what surprised us, was the fact that the following expression:

“0” : [“$Q0”, “$Q0” ..., “$Q0”] (x n)

did trigger the execution of the Map constructor n times!

Indeed, the ReactFlightReplyServer uses a `consumed` attribute to prevent multiple computations of the same reference and prevent abuse. But this mechanism only enters in action when the reference is successfully resolved (see Fig 1).

Fig. 1: Exception doesn’t prevent recomputation of the same faulty Map 

Because the `new Map` expression failed (new Map([null]) is not a valid JavaScript expression), this outcome was not stored anywhere. But surprisingly, the deserialization is not interrupted by this exception! 

The execution of the expression `new Map ([null])` is pretty cheap, it takes our server around 0.03ms. Virtually instant. But this is neglecting the fact that  a threat actor can insert more than 100,000 instances in a 1MB payload, leading to the cost of several seconds, comparable to the CPU exhaustion issue behind CVE‑2026‑23864 and described above. 

Considering this, we submitted a first report to Meta, sharing this POC and demonstrating the impact. 

But soon after, we realized there was a way more impactful payload we could generate by exploiting our original idea.  

Instead of sending a series of “$Q0” that would immediately trigger the exception, we decided to introduce a series of valid map entries at the start of the root entry, to force the Map constructor to iterate over them before triggering the expected exception (see Fig. 2). 

Fig. 2: Internal recursive resolution of “$0” 

By doing so, we achieved a quadratic complexity, and a much more expensive payload ! The optimal number setting is n/2 valid maps and n/2 map references to the 0 object (“$Q0”). 

CVE‑2026‑23864 (CPU exhaustion) vs React2DoS (CVE-2026-23869) 

With our new attack vector, the computation could easily last several minutes. Therefore, with only small payloads of tens of kilobytes, it was possible to initiate impactful DoS attacks. 

To give ourselves an idea of the impact of this attack vector, we computed a chart showing the comparison between CVE‑2026‑23864 (CPU exhaustion) and React2DoS. The result showed that after only a few kilobytes, React2DoS starts to stand out, and when the payload size reaches hundreds of kilobytes, it is already more powerful by several orders of magnitude (see Fig. 3). 

Fig. 3: Comparison React2DoS – CVE‑2026‑23864 

Therefore, with a single request, a threat actor can trigger a computation that will take minutes to handle. By repeating this, complete denial of service can be achieved. 

Mitigation 

The React team fixed this issue via setting the consumed flag before any map/set constructor was called.

The issue affects React Server Components version 19.2.4 and below. We recommend that you update to the latest available version that patches this vulnerability as soon as possible.  

If your application already sits behind an Imperva proxy, it is automatically protected against this attack. 

Conclusion 

This case highlights an important reality: the path to innovation inevitably introduces complexity, and therefore risk. As ecosystems evolve rapidly, staying up to date and remaining aware of newly discovered security issues is essential. 

In a more personal way, it was a pleasure for me to delve into one of the most used framework in the world and discover a finding with meaningful impact. This wouldn’t have been possible if researchers before didn’t pave the way with their investigations and their recent findings (React2Shell,  CVE‑2026‑23864…).  

Disclosure Timeline 

Feb 3 2026 – Report including first payload 

Feb 5 2026 – Second payload reported 

April 8 2029 – Vulnerability fixed in 19.2.5 (patch backported to versions 19.0.5, 19.1.6)

The post React2DoS (CVE-2026-23869): When the Flight Protocol Crashes at Takeoff appeared first on Blog.

AI-driven automation is no longer emerging. It is already integrated and accepted as internet traffic. From AI assistants and crawlers to enterprise automation tools, websites are now routinely accessed by non-human actors operating at scale.  Vulnerabilities or weaknesses in your application infrastructure, including risky APIs, are no longer difficult to find, as agentic AI tools, paired with automation, can observe and test endpoints and access points faster than any human.

AI-aware bot protection is a security approach that detects, classifies, and controls automated traffic generated by AI agents, LLM-powered assistants, and autonomous tools — then applies granular policies based on each bot’s identity, intent, and behavior.

Key Takeaways:

• AI-powered bots now represent a significant and growing share of internet traffic, blending seamlessly into legitimate user sessions.
• Traditional bot detection cannot reliably distinguish between beneficial AI assistants and malicious AI-driven agents.
• Unmanaged AI bots create measurable business risks: analytics distortion, inventory manipulation, API abuse, account takeover, and content scraping.
• Imperva Advanced Bot Protection provides granular visibility and control over AI-driven traffic by tool type, category, behavior, and business function.
• Effective AI bot management in 2026 requires multilayered detection with real-time, policy-based response capabilities.

The challenge for security teams is no longer understanding why automation is increasing, but gaining clear visibility and control over what that automation is doing.

The result is a growing grey zone where distinguishing among human users, legitimate AI agents, and malicious bots becomes significantly more challenging, and where traditional security controls often lack the visibility needed to reliably distinguish among them.

According to Imperva’s 2025 Bad Bot Report, bad bots accounted for 32% of all internet traffic — a 2% increase year-over-year. With AI-powered tools accelerating automation, this figure is expected to grow significantly in 2026, making bot detection and bot management a critical priority for every organization.

How Do AI Bots Blend Into Legitimate Web Traffic?

AI agents and automated tools are improving how people interact with the internet, dramatically enhancing productivity and convenience. For example:

• AI assistants like ChatGPT, Perplexity AI, and Google Gemini retrieve real-time answers from multiple websites to summarise content or compare products
• Travel platforms continuously check flight prices, seat availability, and hotel inventory
• E-commerce monitoring tools track pricing, stock levels, and competitor offers across retailers
• AI-powered shopping assistants help users find deals or complete purchases faster
• Enterprise AI tools query SaaS platforms and APIs to automate workflows like reporting, customer support, and data enrichment
• Search and indexing bots extract and index web content to power AI-driven search experiences

However, the same technological advancements that enable these positive experiences are also empowering cybercriminals. Automation at scale lowers the barrier for malicious activity, putting malicious bots at a significant advantage when automated traffic is the expected baseline. They can blend seamlessly into legitimate traffic patterns, making detection significantly more challenging.

What Are the Business Risks of Unmanaged AI Bot Traffic?

Many organizations still view bot protection as optional. However, with AI agents such as crawler bots and fetch bots, now an accepted part of internet traffic and automation accelerating at scale, bot protection has become a core security requirement. Failing to treat it as such exposes organizations to serious business risks:

How Does Imperva Deliver AI Bot Detection and Control?

The ability to control which parts of your application functionality are accessible to AI tools is critical to your AI Security Strategy.

How Does Imperva Provide Visibility Into AI Bot Traffic?

Imperva Advanced Bot Protection (ABP) offers granular visibility into AI tools, agents, and crawlers, providing a detailed, real-time view of which AI tools are accessing your websites, applications, and API endpoints.

With ABP, security teams can clearly see which AI tools are hitting their environment, which applications and URLs are being accessed, the volume and frequency of requests, and whether those requests are being allowed, blocked, or challenged

This level of visibility ensures organizations know exactly what is interacting with their digital services and helps identify unintended policy outcomes, such as blocking AI tools they want to allow, or allowing tools they should restrict.

The AI Tools dashboard provides a centralized view of AI-driven traffic, enabling faster investigation and more informed decision-making.

How Can You Control AI Bots by Tool Type, Category, and Behavior?

Beyond visibility, Imperva enables precise control over how AI tools interact with your applications.

With ABP, security teams can easily:

• Allow, block, or rate-limit specific AI tools
• Apply policies based on categories such as AI crawlers, AI agents, and AI fetch bots
• Quickly adapt policies as new AI tools emerge

This allows organizations to move from reactive blocking to intentional control of automated access.

How Does Imperva Protect Critical Business Functions from AI Bots?

Imperva ABP also provides granular control at the application and business function levels, allowing organizations to define exactly which parts of their applications AI tools are allowed to access. This ensures that:

• Approved tools can only reach intended endpoints
• Sensitive paths, APIs, or business logic remain protected
• Access policies align with business and data governance requirements

This ensures AI tools interact with applications in a controlled, predictable, and secure way.

Why Is Imperva ABP a Leading Bot Management Solution?

ABP protection against AI builds on an already strong foundation of Advanced Bot Protection, combining multilayered detection, intelligent risk scoring, and real-time controls to accurately distinguish between human, legitimate automation, and malicious bots. With deep visibility, rapid decisioning, and expert support, ABP is already a proven solution for managing sophisticated bot threats. It is now further strengthened by the ability to monitor and control AI-driven traffic precisely.

Frequently Asked Questions About AI Bot Protection

Q: What is AI-aware bot protection?

A: AI-aware bot protection is a security approach that detects, classifies, and controls automated traffic from AI agents, LLM-powered assistants, and autonomous tools. Unlike traditional bot detection that relies on static signatures, AI-aware protection uses behavioral analysis and AI tool fingerprinting to distinguish between beneficial AI assistants, legitimate automation, and malicious bots.

Q: What is the difference between traditional bot detection and AI-aware bot management?

A: Traditional bot detection identifies bots using predefined signatures and rules, treating most automated traffic as either good or bad. AI-aware bot management goes further by classifying AI tools by type, category, and behavior — enabling organizations to allow helpful AI agents while blocking or rate-limiting harmful ones with granular policies.

Q: How do AI agents bypass conventional bot defenses?

A: AI agents can mimic human browsing behavior, rotate IP addresses, solve CAPTCHA, and generate realistic session patterns. Because they operate as legitimate AI tools (such as AI assistants and search crawlers), they often pass through conventional defenses that only look for known malicious signatures.

Q: What business risks do AI bots create?

A: Unmanaged AI bots can distort marketing analytics, hoard inventory, abuse API business logic, perform credential stuffing for account takeover, scrape proprietary data and competitive intelligence, and degrade customer experience through increased site latency.

Q: Can businesses allow some AI bots while blocking others?

A: Yes. Solutions like Imperva Advanced Bot Protection enable granular control, allowing organizations to allow specific AI tools (such as approved search crawlers), rate-limit others (such as AI assistants accessing content), and block malicious AI agents — all at the individual tool, category, or endpoint level.

Q: What is agentic AI, and why does it matter for application security?

A: Agentic AI refers to autonomous AI systems that can independently browse the web, interact with APIs, and complete multi-step tasks without human oversight. These agents can probe for vulnerabilities, test endpoints, and access business functions faster than any human, making agentic AI security a critical concern for organizations.

Monitor, Control, and Prevent AI-Driven Bot Threats

Automation is now a permanent and growing part of how the internet operates. The critical challenge is no longer detecting bots alone but understanding and controlling AI-driven interactions at scale.

Organizations need to know exactly which AI tools are accessing their environments, what they are doing, and how to control that access with precision.

Imperva Advanced Bot Protection delivers the visibility, control, and adaptive protection required to operate securely in this new environment.

By enabling organizations to monitor AI agents, control their access at a granular level, and prevent malicious automation from hiding within legitimate traffic, Imperva helps businesses confidently embrace the future of AI-driven digital experiences.

Learn how Imperva Advanced Bot Protection delivers AI-aware bot management for your applications. Explore our bot protection solutions or download the latest Imperva Bad Bot Report for the most current data on AI-driven bot threats.

The post Why AI Bot Protection and Control Are Essential for Application Security appeared first on Blog.

For years, a lot of risky APIs survived simply because they were hard to find. They weren’t documented. Only a handful of engineers knew the endpoints. And if an attacker wanted to abuse them, they had to spend real time reverse‑engineering traffic and guessing how things worked.

That “security by obscurity” was never a security strategy, but it did create friction.

AI removes that friction.

Today, coding assistants and agentic tools can observe patterns in traffic, infer undocumented endpoints, generate proof‑of‑concept exploits, and test thousands of permutations faster than any human. We’ve already seen what happens when exposed APIs meet automation at scale: a hobbyist was able to gain control of thousands of robot vacuums due to exposed APIs and an over‑privileged token, something that simply wouldn’t have scaled without automation on the attacker side.

The takeaway is straightforward: if you don’t know where your APIs are, what they expose, and who can talk to them, AI will find those gaps for you, either in the hands of your developers or your attackers.

Why has API security become critical in the age of AI agents?

API security is the foundation of protecting applications against automated, AI-driven threats. In the past, attackers relied on manual reverse-engineering to discover undocumented API endpoints. Today, AI agents and coding assistants can autonomously map traffic patterns, infer hidden endpoints, and test thousands of exploit permutations in seconds. Furthermore, AI agents can bypass traditional web application firewalls (WAFs) by executing perfectly formatted, syntactically correct requests that abuse business logic—such as chaining legitimate calls to perform a Broken Object Level Authorization (BOLA) attack.

Because AI agents use APIs as their primary control plane, securing these interfaces is no longer just about preventing data breaches; it is about establishing the necessary guardrails to ensure AI tools operate safely and within their intended scope.

How AI Agents Change the Threat Model

AI doesn’t just make attackers faster. It changes what “attack” looks like, because agents can behave like normal users while still doing abnormal things.

1) Business Logic is the New Frontline

Traditional API protections – gateways, WAFs, basic input validation, are good at stopping obviously bad traffic: missing tokens, malformed payloads, suspicious content types.

But agents don’t have to look suspicious. They can follow every syntactic rule and still abuse your business logic.

Imagine an agent that:

• Uses a valid user token and calmly walks the edges of a pricing API until it discovers discount combinations you never intended to allow.
• Chains perfectly legitimate calls to pivot from one customer data to another customer’s data. This effectively executes a Broken Object Level Authorization (BOLA) attack – a critical vulnerability highlighted in the OWASP API Security Top 10 – without brute‑forcing raw IDs.

Nothing in those requests’ screams “attack.” The danger is in the sequence, the intent, and the scale, the exact things many baseline controls don’t reason about.

2) Agent-Specific Protocols Expand the Attack Surface

Agents aren’t only calling the same APIs as your mobile app calls. They’re increasingly using agent‑first toolchains and protocols that wrap platforms behind “tool” interfaces, making discovery and invocation easier than ever.

Look at what’s happening across major SaaS ecosystems: new CLIs and frameworks are designed so an agent can discover capabilities, understand schemas, and call dozens of APIs through a single control surface. Under the hood it’s still JSON over HTTP but packaged in protocols and workflows many security tools don’t meaningfully parse or recognize.

If your security stack doesn’t understand what it’s looking at, it can’t apply real policy. It just sees “some JSON” and hopes for the best.

The Thales Vision: API Security as the AI Agents’ Control Plane

At Thales, we see API Security evolving into the control plane for AI agents: the place where you get a coherent view of what agents are doing, which APIs they’re touching, and how to govern that behavior, consistently and at scale.

1) Start with ruthless visibility

You can’t protect what you can’t see, and AI moves too fast for spreadsheets and tribal knowledge.

We’re focused on:

• Finding every API: Discovering shadow, zombie, and newly created APIs across clouds and data centers, then mapping the data they expose and the business functions they support.
• Making agent traffic visible: Identifying traffic that comes from agents and agent toolchains, tying it back to the human or system they’re acting for, and surfacing suspicious patterns early.

The goal: when your CISO asks, “Which agents can touch customer PII today?” you can answer with confidence instead of guesswork.

2) Speak the same language as AI agents

We’re extending the API Security engine, so it doesn’t just see “JSON over HTTP ” but understands the agent protocols layered on top, things like MCP (Model Context Protocol) style streams and backend API calls from an agent-oriented CLI.

Once we can parse and normalize that traffic, we can:

• Apply the same validation and anomaly detection we already use for REST and GraphQL.
• Correlate what an agent is doing across back‑end services, rather than treating every request as an isolated event.

In practice, that means the security brain becomes protocol‑aware. Whether an action comes from a mobile app, a browser, or an AI agent using a modern toolchain, the same set of eyes is watching.

3) Put real guardrails around tokens and delegation

Agents run on delegation. They act on behalf of users and services using tokens, keys, and temporary credentials. When those credentials are over‑privileged or long‑lived, you get “quiet catastrophe” scenarios, like a single token shared among thousands of agents.

We’re building on our existing token visibility to:

• Score token risk: Evaluate scope, lifetime, usage patterns, and anomalies like sudden geography changes or volume spikes.
• Create policies specifically for agent delegation: For example, “This support agent’s token can only read billing data for the current customer, up to N requests per hour, and never export full datasets.”
• Catch replay and abuse: Detect when tokens are cloned, reused from odd locations, or used by unexpected agent identities.

If an AI agent starts stretching beyond the intent of its access, querying too broadly, too often, or in the wrong context, the platform should be able to flag, throttle, or cut it off in real time.

4) Defend the messy middle: business logic and BOLA

Agents follow natural‑language prompts, not carefully designed UI flows. That makes them unusually good at stumbling into the “negative space” of your application: edge paths nobody documented, but your back end still accepts.

Our approach anchors security in behavior and intent:

• Model sequences of calls as workflows and look for patterns that don’t match real user behavior, for example, moving from one customer account to another without a corresponding permission to change.
• Treat BOLA as more than “did you increment an ID,” and start reasoning about what resource the agent is effectively asking for when it requests “all internal reports” or “all projects in the system.”

The endgame is business‑level guardrails you can express clearly, and enforce across all agents, regardless of how clever the prompts are.

Meeting you where you already are

None of this works if it requires an exotic, parallel deployment just for AI. That’s why we’re embedding agent controls into the places customers already rely on Imperva today:

• Imperva Cloud WAF for internet-facing API
• Imperva WAF Gateway for on-prem and hybrid environment
• Imperva eWAF for cloud-native and microservices workloads

In each case, it’s the same security engine doing heavy lifting, discovering APIs, understanding protocols, analyzing behavior, and enforcing policy inline on every agent’s call.

Where we’re heading

AI agents are already inside organizations, helping engineers, answering customers, and automating operations. The real question is whether they’re operating inside guardrails you actually understand.

Our view is simple:

• You don’t secure AI by bolting something onto the model.
• You secure AI by controlling the APIs and data the model can reach.

By turning API Security into the shared control plane for AI agents, across discovery, protocol understanding, token governance, and business‑logic protection, we want to help teams say “yes” to AI without crossing their fingers behind their back.

If you can see every agent, every call, and every token, you can turn AI from a wild card into an engineered advantage. That’s the future we’re building toward.

The post API Security for AI Agents: Why Protection Has Never Been More Important. appeared first on Blog.

Application development has changed dramatically. Enterprises now release software faster, operate more digital services, and deploy applications across a mix of public cloud, private cloud, APIs, containers, and on-premises infrastructure.

As application delivery has accelerated and architectures have become more distributed, a disconnect has emerged between the teams building applications and those responsible for protecting them.

This tension is often described as the Wall of Confusion between DevOps and IT Security.

But the challenge does not stop there.

Over time, organizations have also introduced multiple security tools to protect different parts of the application stack. Each tool is managed separately, often by different teams, through different platforms, policies, and workflows.

The result is an additional layer of complexity. Security teams must navigate multiple vendors and fragmented controls, while DevOps teams experience delays as security becomes harder to integrate into fast-moving development cycles.

Understanding how to break down both the organizational and operational layers of this confusion is essential for organizations that want to maintain innovation while ensuring consistent, scalable security.

Applications Now Run Across Hybrid Environments

Today, around forty percent of enterprise applications run in the public cloud, and that number is expected to rise significantly to 62% over the next two years.

Source: Vanson Bourne Survey, “DevOps vs Security: Breaking Down the Wall of Confusion in Modern Application Delivery”

Yet the shift to cloud does not mean applications live in one place. Most organizations now operate across hybrid and multi-cloud environments where applications run across public cloud platforms, private cloud infrastructure, on-premises systems, Kubernetes clusters, and an expanding network of APIs.

Cloud-agnostic strategies are also becoming more common as organizations seek flexibility and avoid dependence on a single provider. At the same time, many enterprises continue to operate legacy systems alongside modern cloud-native services.

The result is a highly distributed application landscape. Applications now run across multiple environments simultaneously, and security must be able to protect them wherever they operate.

Source: Vanson Bourne Survey, “DevOps vs Security: Breaking Down the Wall of Confusion in Modern Application Delivery”

DevOps and Security Want the Same Outcome

Despite the perception of conflict, DevOps and IT Security teams are largely aligned on the goals of modern application security. Both groups ultimately want the same outcome: applications that are secure, reliable, and able to scale with business demand.

Research conducted with Vanson Bourne reinforces this alignment. 96% of DevOps and 95% of IT Security professionals agree that modern environments require security that is flexible across any architecture.

This global study of 1,500 professionals across the US, Europe, and APAC highlights an important point. Modern application security is not just a technology problem. It is a workflow and collaboration challenge.

Security and DevOps want the same outcome, but they experience different frustrations. These gaps can create delays, bottlenecks, false positives, and friction that undermine the cloud-native innovation organizations are working to achieve.

The Wall of Confusion: Conflicting Priorities, Fragmented Security and Tool Sprawl

The Wall of Confusion is not just about DevOps and Security working in silos. It is also about how security is delivered. Over time, organizations have added more and more security tools. One for web applications, another for APIs, another for cloud, another for containers. Each tool solves a specific problem, but together they create complexity instead of clarity.

Security teams are left navigating multiple vendors, switching between management platforms, and maintaining different policies across environments. This makes it difficult to keep controls aligned and increases operational overhead.

At the same time, gaps begin to appear. As applications move across environments, it is not always clear if they are fully protected. Policies become inconsistent because what is set in one environment does not automatically apply to another.

In fact, based on a 2026 survey of Imperva Application Security customers, 77% of security professionals say operational complexity is their biggest challenge.

For DevOps teams, this complexity shows up as delay. Security becomes a bottleneck not because it is unnecessary, but because it is too difficult to operationalize.

That is the wall and it is what needs to come down.

Why Traditional Security Models Fall Short

When applications operate across multiple environments, security approaches designed for fixed infrastructure quickly become difficult to manage.

Many organizations rely on a mixture of embedded protections, centralized security services, and environment-specific tools to protect different parts of their application landscape. While each solution may address a particular need, together they can create fragmented security architectures. This fragmentation leads to inconsistent policies, duplicated alerts, limited visibility, and increased manual effort.

Security teams must manage multiple tools and workflows, while development teams experience delays when security is applied inconsistently or too late in the process. Both teams are constrained by the same underlying issue: security models that were not designed for modern, distributed application environments.

Security Must Move with the Application

Modern applications are no longer tied to a single infrastructure model. They are composed of microservices and APIs, deployed through automated pipelines, and distributed across multiple environments.

Security therefore cannot remain a centralized checkpoint that appears late in the development process. Instead, protection needs to move with the application and operate consistently wherever that application runs.

This means security controls must function across public cloud environments, private infrastructure, hybrid deployments, Kubernetes clusters, APIs, and the traditional systems that many organizations still rely on.

DevOps and IT Security teams increasingly recognize this shift. They are not asking for less security. They are asking for security that works the way modern applications work.

Securing Applications Anywhere with Thales

As application architectures continue to evolve, organizations are no longer dealing with a single security challenge, but with the need to protect applications consistently across every environment they operate in.

The issue is not just distribution. It is how to secure that distribution without adding more tools, more complexity, or more operational overhead.

Security strategies built around isolated environments or disconnected tools are no longer sufficient. What is needed is a unified approach that delivers consistent protection, visibility, and control across the entire application landscape.

Now, the question becomes how to deliver that in practice.

Many vendors talk about flexibility but still require organizations to choose a single deployment model or manage multiple disconnected solutions. Imperva takes a fundamentally different approach. It meets organizations where they are, supporting multiple deployment models while maintaining a single, unified security experience.

This includes protection for internet-facing applications and APIs through Imperva Cloud, native integration for public cloud environments (Imperva for Google Cloud), container-based deployment for Kubernetes and microservices, and gateway deployment for on-premises, hybrid, and air-gapped environments.

The key is that all of these deployment options are powered by the same Imperva Security Engine.

This means one management console, consistent policies across every environment, and unified visibility across the entire application portfolio, regardless of where applications are deployed. Security teams do not need to manage multiple tools or vendors, and DevOps teams do not need to change how they build and deploy applications.

That is what securing applications anywhere really means.

Download the whitepaper: DevOps vs Security: Breaking Down the Wall of Confusion in Modern Application Delivery

The post Securing Applications Anywhere: Breaking Down the Wall of Confusion appeared first on Blog.

Most organisations assume DDoS (Distributed denial of service) protection is a box they’ve already ticked. If traffic spikes or an attack starts, the thinking goes, their provider will absorb it and move on.

But in the real world it can be a different story. Many incidents aren’t caused by the scale of an attack alone, they happen because their protection isn’t designed to act fast enough, distinguish legitimate traffic or stay active without disruption for normal traffic. Or slows the legitimate traffic down, degrading performance when under an attack.

In this blog, we look at why DDoS resilience is really about continuity, not just mitigation, and what teams often miss when they assume they’re already protected.

The DDoS Protection Gap: Why Performance Breaks Under Pressure.

Modern DDoS attacks rarely look like blunt floods now; they utilize multi-vector strategies targeting the application layer (Layer 7) to blend in. They overwhelm specific application paths or quietly degrade performance until frustrated users give up.

In 2025, Imperva Threat Research team observed an application-layer DDoS attack that peaked at 15 million requests per second against a financial services API, a clear sign that attackers now combine scale with stealth tactics.

When protection isn’t built to handle this kind of attack, organisations often see:

• Delays between detection and mitigation
• Legitimate users are blocked or challenged during peak moments
• Performance degradation that’s dismissed as ‘normal slowing’
• Downtime that occurs despite having DDoS controls in place

The result is widespread impact, disrupting not just infrastructure, but revenue, brand reputation and most importantly, trust.

Why Modern DDoS Protection is a Business Continuity Challenge

Effective  DDoS protection isn’t about surviving the largest possible attack on paper. It’s about ensuring users can continue to access applications, complete transactions and rely on important services, even when an attack is ongoing.

To do that organisations need protection that is:

• Not dependent on manual activation
• Fast, with mitigation measured in seconds, not minutes or hours
• Accurate, so legitimate users aren’t caught in the crossfire
• Edge-based mitigation using a global Anycast network, stopping attacks before they put internal systems under pressure

Without these characteristics, DDoS defences can become part of the problem rather than the solution.

The Oversight: What Security Teams Miss About Resilience

Many organisations unknowingly accept risk because they:

• Assume any DDoS protection will do the job
• Focus on volumetric capacity but overlook detection accuracy, time to mitigate, mitigation efficacy and stealth attacks to the application layer
• Rely on reactive or hybrid approaches that leave a mitigation gap
• Accept user friction as an acceptable side effect of defence activity
• Accept operational complexity as “the nature of the beast”

Often, these gaps only become visible during critical moments such as launches, seasonal peaks or high-traffic events, when resilience matters most.

The Solution: Supporting Continuity with Always-On Mitigation

Thales’s Imperva DDoS Protection is designed to preserve availability and user experience, even during sustained or sophisticated attacks.

Behind the scenes, this means:

• Continuous and detailed profiling of peace-time traffic for fast identification of anomalies and potential DDoS attacks.
• Always- on mitigation at the edge, eliminating delays in response with an industry-leading 3–     second time-to-mitigation SLA for network-layer attacks.
• Versatile set of techniques for minimising disruption to legitimate users, including signatures, behavioural patterns and challenges.
• Attack isolation for avoiding potential collateral damage.
• Global scale and distribution, absorbing attacks close to the source.

The Impact: Why True Resilience Matters for Revenue

DDoS attacks don’t just test security controls; they test business resilience. When protection fails, the impact is immediate, abandoned sessions, lost transactions, frustrated customers and operational pressure at exactly the wrong moment.

DDoS resilience isn’t defined by how large an attack you can withstand, but by how consistently your services remain available while it’s happening.

By aligning always-on mitigation, rapid response and accurate traffic, classification, organisations can reduce risk without compromising user experience and ensure that availability isn’t dependent on perfect timing or manual intervention.

Because the true test of DDoS protection is whether services remain available.

To discuss DDoS protection with a member of the team, get in touch.

The post Why Most DDoS Protection Fails: Solving for Continuity and Resilience appeared first on Blog.

Since the headline-grabbing outages of 2021, we’ve had recurring conversations with large enterprises asking some version of the same question.

Do we really want our CDN, security, and routing control to live in the same place?

This issue of control has become more urgent after a series of well‑publicized, multi‑hour outages across major cloud‑based DDoS protection and security platforms. These incidents are rare but appear to be increasing in frequency. And when they happen, they expose architectural decisions many organisations haven’t revisited in years. The fact is that architectures assumed providers would never fail. Reality proved them wrong.

The concern isn’t whether cloud DDoS mitigation works. At scale, it does. The issue is control: whether customers retain the ability to reroute traffic independently if the provider itself goes down.

Many DDoS protection services simplify onboarding by originating customer prefixes and returning traffic via static paths. Under normal conditions, this works. During a provider outage, especially one affecting routing or orchestration, customers may lose the ability to reroute traffic
independently. Recovery depends on provider‑side changes at the worst possible moment.

That’s when a DDoS mitigation service can become a single point of failure.

Protection and control are different problems

One thing we consistently hear from network and security teams is that DDoS attack mitigation and traffic control are often treated as the same problem. They aren’t.

Resilient architectures separate them:

The Internet already provides a mechanism to enforce this separation: the Border Gateway Protocol (BGP). This is the Internet’s routing protocol; it determines how traffic is directed between the networks.

So, the real question isn’t whether to use cloud‑based DDoS protection. It’s whether that protection operates with your routing policy, or instead of it.

Resilient architectures treat attack mitigation and traffic control as separate concerns. Providers absorb DDoS attacks. Customers retain routing authority using BGP, enabling them to decide how traffic flows during failures.

When customers control BGP, outages take on a different character. They become routing events, not service outages. Traffic can be redirected faster, the blast radius is reduced, and network teams respond using familiar controls instead of escalation paths.

Designing for the inevitable

No provider is immune to failure. CDNs, hyperscalers, and DDoS mitigation services all operate complex, global control planes.

Resilience doesn’t come from assuming outages won’t happen. It comes from designing so that when they do, customers still control the outcome.

That’s why more organizations are adopting architectures where:

• DDoS protection is cloud‑delivered
• Routing authority remains customer‑owned
• BGP is the final decision layer for traffic steering

This approach preserves the benefits of cloud‑scale mitigation while avoiding the creation of new single points of failure.

A practical next step

If you’re rethinking your DDoS architecture, your best starting point isn’t a product demo; it’s an architectural review. Here are some questions to ask yourself:

• Who originates your prefixes today?
• How quickly can you reroute traffic if a provider is unavailable?
• What dependencies exist between mitigation availability and network availability?

Those answers usually reveal more than any outage postmortem.

On the Internet, control of routing is control of availability, and we think that control should always remain in customer’s hands.

Want to discuss what customer‑controlled DDoS protection looks like in practice? Get in touch with Thales to review your architecture.

The post When your DDoS mitigation provider goes down: Why traffic control can’t be outsourced appeared first on Blog.

Executive Summary

We identified a security weakness in n8n’s credential management layer that could have completely compromised the application’s security. This finding highlights the core risks of centralized authentication in workflow automation platforms.

As n8n serves as the central hub connecting critical systems and orchestrating business processes across teams, any gap in credential handling can potentially cascade across connected systems, disrupting operations, compromising data flows, and credentials.

While this issue was fixed in v2.6.4, it reminds us about the unique security challenges of AI automation platforms.

Introduction

We are in a moment where AI and automation platforms are rapidly becoming embedded in everyday operations, allowing teams to connect models, APIs, SaaS tools, and internal systems with minimal friction.

Platforms like n8n promise powerful automation through visual workflows and reusable credentials, lowering the barrier to orchestrating complex tasks across services. But this convenience comes with structural risk: these tools centralize highly sensitive tokens, OAuth flows, and API keys, effectively concentrating trust in a single automation layer.

When that layer fails to enforce basic security controls, the impact is not limited to one workflow, it can extend across every connected system. In this research, we examine how a Stored XSS vulnerability in n8n’s OAuth credential handling can lead to account takeover and broader instance compromise.

The Vulnerability

The vulnerability lies in how n8n handles the “Authorization URL” within the OAuth credential setup. OAuth (Open Authorization) is an authorization framework that allows an application to access a user’s data on another service without exposing the user’s password.

In a standard workflow, users configure OAuth credentials to authenticate n8n with an external provider. When a user clicks “Connect my account,” n8n opens a popup window pointing to the service’s authorization page.

However, we discovered that the frontend function responsible for opening this window did not validate the protocol of the provided URL (see below). This allowed an attacker to bypass the expected scheme and inject JavaScript code.

The Attack Flow

Because n8n allows credentials to be shared between users in the same instance (collaborative features), a threat actor can weaponize this weakness, see Fig 1.

Fig. 1: High level view of the attack flow

The steps are the following:

1. Preparation: The attacker creates a new credential using the “OAuth2 API” type.
2. Injection: In the “Authorization URL” field, instead of a valid URL, the attacker inserts a malicious JavaScript payload.
3. Trap: The attacker shares this credential with the victim (e.g., an administrator or a user with higher privileges).
4. Execution: The victim, seeing a shared credential, opens it and clicks “Connect my account.” The browser immediately executes the injected JavaScript in the context of the victim’s session instead of navigating to the remote authorization URL.

Demonstration Video

The following video demonstrates the exploitation chain: sharing the malicious credential with a victim account and triggering the XSS payload.

Root Cause

During the OAuth flow, the browser initiates a top-level navigation to the authorization URL in the oAuthCredentialAuthorize function of the credential service. However, this segment of the program missed sanitation of the Authorization URL.

Fig. 2: Vulnerable source code

Impact: Application Compromise

This is a stored XSS, meaning the payload is saved permanently in the database and served to any user who interacts with the credential. The impact of executing arbitrary JavaScript in the context of an n8n session is significant:

1. Account Takeover: The attacker can impersonate the victim’s in his session and force actions on their behalf, effectively taking over the account.
2. Credential Exfiltration: The attacker can then use the XSS to query the internal n8n API and retrieve other credentials stored in the instance.
3. Instance Control: With admin access gained via the XSS, the attacker can access more credentials, escalate privileges, and gain full control of the n8n instance.

Conclusion

Workflow automation tools like n8n are becoming the backbone of modern IT infrastructure. While they offer immense power and speed, they also centralize trust. A vulnerability in this layer can often be more damaging than a vulnerability in a single isolated application.

We recommend organizations treat their automation platforms as Tier-0 assets, enforce strict access controls, and ensure they are patched promptly.

Timeline

• Jan 29 : Disclosure of the issue
• Feb 6 : Issue fixed in v2.6.4

The post N8N: Shared Credentials and Account Takeover appeared first on Blog.