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.

As APIs power the majority of modern web applications, implementing robust API security is no longer optional – it’s a critical necessity for data protection. This guide explores how to seamlessly integrate API gateway security into your Imperva on-premises environment to mitigate OWASP Top 10 threats, ensuring both web application and business logic threats are effectively managed.

The Need for API Security Integration

APIs not only enable communication between systems but also expose vulnerabilities that can be exploited by attackers. A strong API security solution safeguards your applications against threats ranging from SQL injections and cross-site scripting to more nuanced business logic attacks. With Imperva’s security capabilities integrated into your gateway, you benefit from:

• Comprehensive API Protection: Defend against the OWASP API Top 10 risks, including BOLA and Broken Authentication, by stopping malicious traffic at the gateway.
• Operational Simplicity: Leverages the powerful capabilities of the Imperva gateway without adding unnecessary complexity.
• Flexibility and Scalability: Supports on-premises, cloud-native, and Kubernetes environments, adapting to your organization’s evolving needs.

Key Technical Aspects of the Integration

Dynamic Profiling and Application Insight

Imperva’s patented Dynamic Profiling technology is at the core of this integration. It automatically learns the structure and usage of your web applications by monitoring every URL, parameter, cookie, and HTTP method. This continuous learning process helps to:

• Automatically Adjust Security Profiles: Minimal manual tuning is required as the system adapts to your application’s normal behavior.
• Detect Anomalies: By comparing real-time data against expected usage models, the solution quickly identifies suspicious activities that could indicate an attack.

Protocol Validation and Attack Signatures

The integration offers a dual-layer defense strategy:

• Protocol Validation: Every API request is checked to ensure compliance with HTTP protocol standards, filtering out malformed or malicious requests.
• Attack Signatures: With a comprehensive database of over 6,500 attack signatures that are regularly updated by expert teams, the WAF GW swiftly identifies and blocks known threats.

Diagram: Imperva Security Layer Architecture – This diagram illustrates the layered approach of Imperva’s security, showing how protocol validation, signature matching, and dynamic profiling work together to secure API traffic.

Application Profiling and the Correlation Engine

Understanding your application’s normal behavior is key to spotting potential threats. By profiling real-time usage and employing a sophisticated correlation engine, the solution:

• Detects Business Logic Attacks: Identifies vulnerabilities such as Broken Object Level Authorization (BOLA) and Broken Function Level Authorization (BFLA).
• Enhances Threat Verification: Integrates data analysis with vertical integration to validate and remediate suspicious activities effectively.

Seamless Integration with Leading API Management Tools

Imperva’s API-Anywhere solution provides a gateway-agnostic approach, integrating leading tools like Kong API Gateway via a dedicated plugin. This gateway-agnostic approach ensures:

• Selective Traffic Handling: Only validated, non-malicious traffic is forwarded to the API controller, maintaining optimal performance.
• Automated API Discovery: The system continuously identifies, classifies, and monitors API endpoints, including deprecated and unauthenticated ones, reducing manual effort and accelerating the development cycle.

×

Apr 9 Upcoming Webinar

Stronger Together: Advanced Bot Protection + API Security = Superior Protection Against Automated API Abuse

Register Now

Deployment and Installation: A Step-by-Step Guide

Flexibility in deployment is a key benefit of the Imperva API security solution. Whether your infrastructure is based on cloud-native technologies like Kubernetes or traditional hypervisors like VMware, integration is straightforward.

1. Generate the Installation Package:
   Use the provided HELM chart to generate configuration files and prepare the console.
   • Impv-a-console-x.x.x.tgz (This Package includes the Helm Chart of the Console)
   • Values.yaml (This file contains the configuration)
2. Deploy the Console:
   Install the console in your environment. This can be managed either via the Imperva Cloud Console or a local self-managed option.helm install impv-apisec-console -f values.yaml -n impv-anywhere –create-namespace
3. Enable the API-Security Policy on Your Gateways:
   With the console active, enable the API security policy on your gateways. The gateway begins populating data to the Imperva Unified Management Console (UMC) either in the cloud or on premises, based on your configuration.
   
4. Ongoing API Discovery and Verification:
   Continuous API discovery and Swagger file verification ensure that all endpoints are monitored, classified, and secured, significantly reducing the risk of overlooked vulnerabilities.

Benefits and Added Value

Integrating API security with the Imperva gateway delivers tangible benefits:

• Streamlined Security Operations: Automated profiling and centralized management reduce the operational burden on your security teams.
• Enhanced Developer Productivity: Automated API discovery and inventory management expedite the development cycle.
• Robust Protection Across Environments: Whether your APIs are public-facing or internal, legacy or cloud-native, the solution offers comprehensive security without compromising performance.
• Actionable Insights and Compliance: Gain granular visibility into traffic to support GDPR, PCI DSS, and HIPAA data governance and protect sensitive PII.

Conclusion

A robust API security strategy must be flexible, comprehensive, and easy to deploy. Imperva’s API-Anywhere solution integrated with your gateway environment meets these requirements by offering:

• A Gateway Agnostic Security Solution: Seamlessly integrates with multiple API management tools.
• Automated API Inventory and Protection: Continuously monitors and updates API endpoints, uncovering any shadow or deprecated APIs.
• Dual-Level Threat Mitigation: Protects against both application-level and business logic attacks through dynamic profiling, protocol validation, and advanced correlation engines.

By integrating this solution, organizations can protect critical assets, streamline operations, and maintain high levels of security and compliance, all while enabling a faster, more agile development process.

The post Integrating Advanced API Security with Imperva Gateway Environment appeared first on Blog.

We’re excited to announce the launch of Upload Scan and Control, an essential new feature for Imperva Cloud WAF. This add-on tackles one of the most critical vulnerabilities facing web applications today—insecure file uploads—offering protection with scalability, simplicity, and enterprise-grade control.

Why Secure File Upload Protection Is Critical for Modern Web Applications

File upload functionality is now a staple in web applications; from job portals accepting résumés to customer support platforms collecting documents.

Unfortunately, attackers exploit this functionality to inject malware, ransomware, and other malicious payloads into systems. This also can become the main source for remote code executions.

With Upload Scan and Control integrated into your Web Application Firewall (WAF), you’ll soon be able to enforce file size and type restrictions, blocking unauthorized or suspicious files before they enter your environment, ensuring your upload capabilities remain safe and compliant.

According to the OWASP Top Ten, insecure file uploads remain one of the most exploited web application vulnerabilities worldwide.

The Growing Risk of Malicious File Uploads

Across the Cloud WAF user base, we process over 20 million file uploads daily, with more than 800 customers across industries like finance, healthcare, retail, and government.

Cyber attackers are becoming more sophisticated and often target file uploads as an initial entry point. The earlier you can block malicious content, before it hits an endpoint or server, the greater your chances of preventing a breach entirely.

×

Apr 9 Upcoming Webinar

Stronger Together: Advanced Bot Protection + API Security = Superior Protection Against Automated API Abuse

Register Now

Why Network-Layer File Upload Security Beats Endpoint-Only Protection

Endpoint antivirus and EDR tools play a critical role in detection, but they typically act after malicious files land on your system. At this stage, it may already be too late. Investigations take longer, the damage may already be done, and attackers may have gained a foothold.

Upload Scan and Control stops threats at the edge, before files are saved or executed, enabling true prevention over delayed remediation before they even reach your network layer.

Advantages of Imperva Upload Scan and Control for Cloud WAF

Our new feature delivers several enterprise-grade benefits:

1. Full visibility across all upload points: Identify which applications allow file uploads and monitor activity from a single dashboard.
2. Instant, one-click activation: Protect all current and future apps automatically, eliminating developer integration work.
3. Scalable security for large enterprises: No additional requirements for app owners or developers to introduce additional integrations significantly reducing operational overheads.

Peace of Mind for Security Leaders and Compliance Teams

With Upload Scan and Control, enterprises can:

• Block threats at the edge before they reach your network.
• Trace file origins and identify the responsible user or IP.
• Maintain audit-ready compliance records (such as GDPR, CCPA, and HIPAA) without adding complexity to existing security stacks.

As cloud-native adoption accelerates and threat actors adapt, features like this are becoming essential to maintaining a secure, compliant perimeter.

Get Ready to Enable Upload Scan and Control

If you’re already using Imperva Cloud WAF today, check your Imperva console to see which apps you currently allow file uploads against and start protecting them today. Get in touch so you can activate Upload Scan and Control within your Cloud WAF environment or to schedule a demo, contact your Imperva account team.

The post Cloud Based WAF Upload Scan and Control: The New Standard for File Upload Security appeared first on Blog.

React Server Components (RSC) have introduced a hybrid execution model that expands application capabilities while increasing the potential attack surface.

Following earlier disclosures and fixes related to React DoS vulnerabilities, an additional analysis of RSC internals was conducted to assess whether similar denial-of-service risks remained.

This analysis identified a new denial-of-service (DoS) condition that, under specific circumstances, can render a React server unreachable.

Context

Previous reports showed that malformed requests could trigger excessive server-side computation during RSC rendering and serialization. While patches addressed the known attack patterns, it remained unclear whether these issues were isolated or indicative of broader weaknesses.

Technical Overview

The analysis focused on the following RSC code paths:

• Server Component request parsing
• Recursive resolution and payload generation

By evaluating server behavior when processing unexpected but syntactically valid inputs, an alternative execution path was identified in which server resources could be exhausted. This behavior is not covered by existing mitigations and could be abused to sustain a denial-of-service condition.

The issue was reported to the React security team. Due to the potential impact, exploitation details are not disclosed here.

Mitigation

While framework-level fixes are under review:

• Imperva customers are protected against this issue.
• Imperva’s Application Security solutions detect and block malicious request patterns that trigger abnormal server-side processing before vulnerable paths are reached.

Conclusion

This work highlights the importance of ongoing security evaluation of modern application architectures and the role of layered protections in mitigating denial-of-service conditions.

The post A New Denial-of-Service Vector in React Server Components appeared first on Blog.

What Is CVE-2026-21962?

CVE-2026-21962 is a critical (CVSS 10.0) vulnerability in the Oracle HTTP Server and the WebLogic Server Proxy Plug-in for Apache HTTP Server and Microsoft IIS. An unauthenticated attacker with HTTP access can exploit this flaw by sending crafted requests to the affected proxy components and bypass security controls. Successful exploitation can result in unauthorized creation, deletion, or modification of critical data, or full compromise of all data accessible through the affected servers.

The vulnerability affects multiple supported versions, including:

• Oracle HTTP Server and WebLogic Server Proxy Plug-in (Apache): 12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0
• WebLogic Server Proxy Plug-in for IIS: 12.2.1.4.0

Key aspects of the vulnerability include:

• Unauthenticated network access: Exploitation does not require credentials or user interaction.
• Low attack complexity: Attackers can exploit the issue with standard HTTP traffic.
• Maximum severity: With a CVSS score of 10.0, this is a top-tier risk for confidentiality and integrity impact.

Observations from Our Data

Since this CVE’s release, we’ve seen:

• Over 140,000 attack attempts, targeting 21 countries globally. Almost 75% of attacks target US-based sites, followed by Poland.

• Attacks from 9 source countries.

• Attacks targeting sites across 18 industries, primarily Computing and IT.

Mitigation and Protection

The definitive remediation for CVE-2026-21962 is applying Oracle’s January 2026 Critical Patch Update for all affected versions. Administrators should prioritize this patch given the severity of the issue.

Imperva customers using both CWAF and WAF Gateway are protected out-of-the-box.

Conclusion

CVE-2026-21962 represents a critical perimeter security risk for organizations running Oracle HTTP Server and WebLogic Proxy Plug-in components. Its combination of unauthenticated access, low attack complexity, and maximum CVSS rating makes it a high-priority patching and detection concern.

Imperva customers are protected against exploitation techniques associated with this vulnerability through our web application firewall and advanced HTTP traffic inspection capabilities. For any Oracle HTTP Server and WebLogic Proxy Plug-in users still running legacy proxy deployments, we strongly advise accelerating patch deployment and reviewing exposure based on your internal telemetry.

The post Imperva Customers Protected Against CVE-2026-21962 in Oracle HTTP and WebLogic appeared first on Blog.

Holiday shopping season is in full swing, and Black Friday 2025 continued to demonstrate that consumer demand and attacker activity shows no signs of slowing. According to Adobe Analytics, U.S. consumers spent $11.8 billion online on Black Friday, setting a new record and highlighting sustained strength in online shopping. Yet behind this surge in legitimate traffic, retailers also faced a sharp rise in automated abuse, account takeover attempts, and reconnaissance across their digital storefronts.

This post breaks down what we saw across our network during the Black Friday period, including traffic trends, attack behavior, targeted geographies, and insights retailers can apply to strengthen their defenses ahead of the holiday home stretch.

What We Saw

Massive Traffic Surges Extending Past Black Friday

Retail traffic surged 37% above November averages, peaking on Black Friday but continuing into the weekend of November 29–30. Traditionally, traffic dips slightly on Saturday before building again on Cyber Monday, but this year showed a clear shift: shoppers kept buying throughout the weekend. This aligns with broader retail trends showing consumers taking advantage of longer promotional windows rather than concentrating purchases on a single day.

For retailers, this means the “peak” period is expanding- and with it, the window of exposure to cyber threats.

Bot Attacks Rose 50%, Focused on High-Value Workflows

Alongside legitimate traffic, bot attacks on retail sites spiked 50% over the November average. The timing closely tracked promotional activity, suggesting attackers were attempting to exploit increased consumer volume to blend in and avoid detection.

Broadly, these bots targeted:

• Authentication and account flows (e.g., /login)
• Inventory and product data endpoints (e.g., /datastore, /event/)
• Transaction and application paths (e.g., credit-card application flows, lottery/promotion services, and user log endpoints)

This behavior reflects typical seasonal abuse campaigns: credential stuffing to hijack accounts, automated scraping to gain pricing or inventory intelligence, and attempts to manipulate promotions or loyalty flows.

Attacks Concentrated on the US, UK, and Australia

Malicious traffic during Black Friday was heavily concentrated in three markets: the US (46%), Australia (12%), and the UK (11%). These regions represent some of the world’s most active e-commerce ecosystems, and attackers mirrored legitimate consumer behavior by focusing on markets with the highest transaction volumes and promotional activity.

The US, in particular, drew nearly half of all observed attacks, consistent with its dominant share of global Black Friday spending. Australia and the UK followed, reflecting strong regional participation in holiday sales events and an attacker strategy aimed at exploiting high-demand markets where automated activity can more easily blend in with legitimate traffic.

For retailers operating in these geographies, the data underscores the importance of region-aware threat monitoring and the need to maintain heightened vigilance throughout the extended holiday weekend.

Attack Patterns Reveal Automation, ATO Prep, and Abuse at Scale

Based on attacker activity observed over the holiday shopping weekend, several clear patterns emerged, showing a mix of high-volume automation, credential-based attacks, and spam and proxy abuse. Overall, the attack data suggests that adversaries were focused on the following behaviors:

1. Heavy Use of Known Bad Bots and Automated Browsers

A significant portion of malicious traffic came from known automated frameworks, including headless browsers and scripted tools designed to mimic real users. This type of activity typically supports:

• Large-scale login attempts
• Price, inventory, or content scraping
• Testing of checkout, promotion, and product pages for weaknesses

Attackers were industrializing their activity using automation that can rapidly adapt during peak events.

2. Preparing and Executing Account Takeover (ATO)

We observed high levels of activity associated with login reconnaissance and credential-testing behavior, indicating attempts to stage or execute ATO. Attackers were:

• Testing large volumes of username/password combinations
• Probing login endpoints to identify which attempts were blocked, challenged, or allowed
• Taking advantage of elevated holiday traffic to blend their activity into normal user patterns

This aligns with typical seasonal fraud behavior, where attackers target stored payment methods, loyalty balances, and customer identities.

3. Evading Detection Through Proxies and Client Impersonation

A large volume of traffic originated from anonymous proxies, VPNs, and other anonymization services, combined with indicators of client spoofing meant to disguise automation. Attackers were:

• Rapidly rotating IP addresses
• Using advanced bots, attempting to masquerade as legitimate browsers
• Using more simple bots, which use fingerprints or user agents that fell outside normal human patterns

In response, much of this traffic triggered JavaScript challenges or CAPTCHA enforcement, forcing suspicious clients to prove they were human.

4. Abusing Forms and Content Channels for Spam

We also observed activity consistent with comment spam, referrer manipulation, and other low-effort abuse aimed at exploiting retail sites as platforms for unwanted advertising or redirection. This typically includes:

• Submitting spam content through comment or feedback forms
• Inserting malicious or low-quality URLs via referrer fields
• Attempting to poison analytics or direct traffic elsewhere

While not as immediately damaging as ATO, these campaigns can harm site performance, customer trust, and brand analytics.

What This Means for Retailers

Black Friday 2025 reinforced several themes:

1. The peak holiday season is widening.
   High traffic persisted later into the weekend than in prior years. Retailers should consider extending peak staffing and monitoring coverage accordingly.
2. Attackers are increasingly using shopper traffic as camouflage.
   Surges in human activity closely mirror surges in automated abuse. Retailers need strong bot detection, fingerprinting, and behavioral analysis—not just rate limiting.
3. API security is now as important as web application security.
   Many of the top targeted URLs were APIs tied to data, personalization, or analytics. These endpoints often sit behind the UI and may not receive the same scrutiny as consumer-facing pages.
4. Geographic targeting is aligned with opportunity.
   The US, Australia, and UK remain prime markets for both legitimate and malicious traffic. Retailers serving these regions must expect elevated attack pressure during every promotional period.

Conclusion

This year’s Black Friday illustrated both consumer resilience and the evolving sophistication of attackers. Retailers saw new sales records, and attackers took advantage of the same moment to blend in, scale operations, and probe for weaknesses.

As the holiday season continues, retailers should ensure that defenses are calibrated for:

• Sustained high traffic (not just one peak day)
• Increased bot sophistication
• ATO protection
• Region-specific targeting aligned with revenue hotspots

By understanding the patterns we saw during Black Friday, retailers can prepare for the continued wave of holiday traffic and ensure a safer, smoother experience for their customers through the end of the year.

The post Black Friday 2025 in Review: What Retailers Need to Know About This Year’s Holiday Shopping Season appeared first on Blog.

In an era marked by escalating cyber threats and evolving risk landscapes, organisations face mounting pressure to strengthen their security posture whilst maintaining seamless user experiences. At Thales, we recognise that robust security must be foundational – embedded into products and services by design, not bolted on as an afterthought. This principle underpins our commitment to the U.S. Cybersecurity and Infrastructure Security Agency (CISA)’s Secure-by-Design pledge, which calls on software manufacturers to establish security features like multi-factor authentication (MFA) as standard across their product portfolios.

As digital transformation accelerates and attack surfaces expand, the gap between security capabilities and emerging threats continues to widen. According to the 2025 Thales Data Threat Report, organisations are grappling with unprecedented challenges: 69% regard the fast-moving ecosystem as the most concerning GenAI security risk, whilst 83% report that strong MFA is used more than 40% of the time. This indicates both progress and significant opportunity for improvement. These findings underscore a critical reality: whilst security tools and technologies have advanced, comprehensive deployment and consistent enforcement remain essential challenges that demand immediate attention.

This blog examines the pivotal role of multi-factor authentication in modern cybersecurity strategies. We explore the fundamentals of MFA, analyse the evolving threat landscape that necessitates its adoption, and provide practical guidance on implementation. Whether you are a security professional seeking to strengthen your organisation’s defences or an individual user looking to protect personal accounts, this resource offers the insights and actionable steps needed to embrace MFA with confidence and rigour.

Understanding Multi-Factor Authentication: The Basics

Multi-factor authentication verifies your identity using two different forms of identification. Typically this involves something you know (like a password) and something you have (like a code on your phone). Think of it like using an ATM: you need both your bank card and your PIN to withdraw cash.

This dual-layer approach creates a significant barrier for attackers. Even if someone steals your password, they still can’t log in without that second factor. It’s elegantly simple, yet remarkably powerful – your password alone is no longer enough to unlock the door.

The Growing Threat Landscape: Why MFA Is No Longer Optional

Cyberattacks have grown increasingly sophisticated, with stolen passwords at the heart of many breaches. According to the 2023 Verizon Data Breach Investigations Report, nearly 49% of data breaches involved the use of stolen credentials.

MFA directly addresses this vulnerability. Our own research at Thales demonstrates the critical importance of strong authentication measures. According to the 2025 Thales Data Threat Report, 83% of organisations report that strong MFA is used more than 40% of the time, yet significant challenges remain in achieving comprehensive deployment. This data underscores both the growing recognition of MFA’s importance and the continued need for organisations to strengthen their authentication posture.

Furthermore, our 2025 Digital Trust Index – Third-Party Edition reveals a concerning reality: 40% of users reset passwords once or twice a month, highlighting the inherent weakness of password-only authentication systems. These frequent password resets not only frustrate users but also create security vulnerabilities that MFA effectively mitigates.

How MFA Defeats Common Attack Methods

MFA thwarts the most prevalent attack techniques:

Brute-force and credential stuffing attacks: These automated attacks become practically futile with MFA enabled because guessing the password isn’t enough to break in.

Phishing attacks: Even if you unwittingly hand over your password to a phisher, they still can’t access your account without the one-time code or second factor that MFA requires.

It’s no surprise that CISA’s Secure-by-Design guidelines explicitly call for making MFA a built-in, default security feature. In today’s threat landscape, MFA has evolved from a nice-to-have extra to an essential safeguard.

Thales’ Commitment: Security by Design and by Default

At Thales, we build security into our products by design, baked into our products and services. Our commitment to CISA’s Secure-by-Design pledge is reflected in how we develop features like MFA.
We already implement robust MFA across our cloud services to help safeguard your accounts and data. By requiring two forms of identification to access the Thales Cloud Security Console, we add an extra layer of protection that makes it “much harder for unauthorised users to access sensitive information”. This significantly reduces the risk of breaches and builds trust.

The Principle of Shared Responsibility

Thales’ approach recognises shared responsibility. “Security by default” means we provide secure settings and features right out of the box. However, security is also a partnership – we provide the tools, whilst you play a crucial role by using them.
We’ve made MFA available and straightforward to configure, and we actively encourage customers to use advanced authentication methods. Whilst MFA might not be mandated on all accounts by default today, we strongly recommend that you activate it. By choosing to enable MFA now, you’re not only protecting yourself immediately but also aligning with best practices that Thales and the cybersecurity community advocate globally.

Getting Started: How to Set Up MFA

Enabling multi-factor authentication on your Thales account is quick and straightforward. Here’s how:

1. Log in and navigate to your user settings. Go to Account Settings or Profile, where you’ll find security settings for MFA management. You can find these options in the Thales Cloud Security Console setup checklist.
2. Locate the Multi-Factor Authentication option and click to begin setup.
3. Select your preferred MFA method: authenticator app, SMS, or email.
4. Configure the chosen method:
   • For an authenticator app, scan the displayed QR code with your app ( MobilPASS+, Google Authenticator, Microsoft Authenticator, Authy, etc.).
   • For SMS, enter your mobile number to receive a verification code.
   • For email, a code will be sent to your registered email address.
5. Save your backup codes. These are your safety net if you lose access to your MFA device. Store them in a secure location like a password manager.
6. Complete and test the setup. Once verified, MFA will be enabled. Log out and log in again to ensure everything works properly.

That’s it! You’ve added a powerful extra layer of security in just a few minutes.

Choosing Your MFA Method: A Comparison

For organisations seeking a comprehensive overview of authentication options, Thales offers an extensive portfolio of MFA tokens and authenticators. Our OneWelcome Authenticators Portfolio includes FIDO2 passkeys, hardware tokens, smart cards, and software authenticators, ensuring secure access across different environments and devices . This breadth of choice allows organisations to select the authentication method best suited to their security requirements and user needs

When setting up MFA, you have several authentication options:

Authenticator App (recommended): Generates a new 6-digit code every 30 seconds. This method is very secure, works offline, and is significantly more phishing-resistant. Pros: High security, no network dependency. Cons: Requires your phone.

Text Message (SMS): Sends a one-time code to your mobile phone. Pros: Easy to use, no app required. Cons: Slightly less secure than authenticator apps due to potential SIM-swapping attacks, but still greatly improves security over no MFA. CISA recommends SMS-based authentication only as a “last resort” when more secure options aren’t available

Email Codes: Sends verification codes to your registered email. Pros: No extra device needed. Cons: Least secure option if your email is compromised. Use only if other methods aren’t feasible, and ensure your email itself has MFA.

Hardware Security Keys: Physical devices, such as Thales FIDO Security Keys that you plug in or tap to verify login. Pros: Highest level of security, phishing-resistant. Cons: Requires purchasing a device.

Which should you choose? If possible, use an authenticator app or hardware key, as these are most secure. For most users, an authenticator app strikes an excellent balance. SMS is a solid fallback, and email can work if necessary – just be aware of the security trade-offs.

Moving Beyond Passwords: Passwordless Authentication

Whilst MFA significantly strengthens security, the most forward-thinking organisations are taking the next step: eliminating passwords altogether. Passwordless authentication removes the vulnerabilities inherent in password-based systems – no passwords to steal, phish, or reuse.

Thales’ SafeNet Trusted Access empowers organisations to build comprehensive passwordless policies using FIDO2 passkeys, biometrics, and hardware authenticators. Our Passwordless 360 approach provides a detailed framework for implementing passwordless authentication across your organisation, combining security, user experience, and regulatory compliance.

Troubleshooting and Frequently Asked Questions

Q: Do I have to enter an MFA code every single time I log in?
A: Often not every time. Many systems offer the option to “remember” a device for a certain period (e.g., 14 days). This means you won’t need to enter a code each time on that trusted device. However, use this feature only on personal devices you control, not shared or public computers.

Q: I’m not receiving the MFA code, or it says the code is wrong. What should I do?
A: Common solutions include: For SMS, check your signal and that your phone number is correct in account settings. Wait a moment and click “Resend code” if available. For authenticator apps, ensure your phone’s clock is accurate, as codes are time-based. For email, check your spam folder.

Q: What if I lose access to my phone or MFA device?
A: Use your saved backup codes to log in. If you’ve lost those as well, contact Thales support for account recovery assistance.

Q: Can we use our own IdP?
A: Yes, you can leverage external IdPs like SafeNet Trusted Access by Thales, which allows you to build adaptive authentication policies and leverage a broad range of MFA options.

Q: Can I switch MFA methods?
A: Yes. You can disable MFA and re-enable it with a new method anytime through your account settings.

Q: Is MFA required?
A: Whilst not mandatory on all accounts today, we strongly recommend enabling it. It’s one of the most effective ways to protect your account.

Understanding Digital Trust: Research from Thales

Thales’ research demonstrates the critical importance of strong identity and access management. Our 2025 Digital Trust Index – Third-Party Edition reveals that 96% of third-party users face issues logging into partner systems, wasting 48 minutes a month on average. Additionally, 40% reset passwords once or twice a month – highlighting the need for more secure, passwordless methods like MFA.

The 2025 Data Threat Report further emphasises this urgency. According to our research, 83% of organisations report that strong MFA is used more than 40% of the time, yet challenges remain. As organisations adopt AI and face evolving quantum threats, robust authentication becomes even more critical.

Thales’ comprehensive Identity and Access Management solutions provide organisations with the capabilities needed to improve user experiences whilst strengthening security. From Multi-Factor Authentication and Single Sign-On to passwordless authentication and passkeys, Thales delivers the tools to make IAM processes straightforward and dependable.

Final Thought

Cybersecurity is a shared responsibility. We design secure systems, and you make them stronger by turning on protections like MFA. Enable MFA today in your Thales account settings. It takes just a few minutes and makes a significant difference.

Secure by design starts with secure choices.

The post Security by Design: Why Multi-Factor Authentication Matters More Than Ever appeared first on Blog.

After our research on Cursor, in the context of developer-ecosystem security, we turn our attention to the Jupyter ecosystem. We expose security risks we identified in the notebook’s export functionality, in the default Windows environment, to help organizations better protect their assets and networks.

Executive Summary

We identified a new way external Jupyter notebooks could be exploited by threat actors to lure unsuspecting users and compromise their workstation.

Companies are recommended to use a centralized Jupyter server, stay up to date and strictly restrict external files susceptible to processing with Jupyter software.

Introduction

Jupyter notebook is quite an institution in the development of AI projects. Back in 2015, around 200,000 notebooks were publicly available on GitHub—by early 2021 that number had surged to nearly 10 million. Used by more than 80 % of data scientists and AI engineers worldwide, Jupyter is deeply embedded in every stage of AI workflows, from exploratory analysis and visualization to model prototyping and collaboration.

When investigating this ecosystem, our approach was to try to imagine where a threat actor could find his way through, and leverage functionalities to exploit victims’ environments. The first direction came surprisingly easily: the configuration files.

Configuration files are often considered innocuous. However, they may include obscure parameters that most users aren’t aware of. Ignoring them would be a critical mistake.

Config files have led to vulnerabilities in many other instances. For example, in VSCode’s IDE, the .vscode/settings.json config file was also a key component in multiple high severity vulnerabilities discovered (CVE‑2021‑34529 , CVE‑2025‑53773 or CVE-2025-54130).

One specificity of the Jupyter ecosystem that makes this attack vector even more interesting is the fact that configuration files are also perfectly valid Python executables- making them easier to exploit.

Jupyter Configuration Files

The most common configuration file is jupyter_notebook_config.py, typically found in the user-specific configuration directory (~/.jupyter/). It’s responsible for defining core Notebook server settings such as network bindings, authentication options, file system paths, and various security-related parameters. However, other config files may also be used depending on the component, such as jupyter_nbconvert_config.py for export settings, or jupyter_server_config.py for Jupyter Server.

Configuration files can actually exist in any directory, allowing for layered overrides. Available options cover a wide range of functionality, from UI behavior and authentication to kernel management, export formats, logging, and more. This approach gives users fine-grained control over the entire Jupyter ecosystem.

For example:

c = get_config()
c.NotebookApp.port = 8888
c.FileContentsManager.save_script = True

However, acknowledging a high severity impact, Jupyter decided in October 2022 to remove CWD from the config paths, reducing the risk presented significantly.

This was the starting point of our research. We started searching for a similar or stronger way to exploit the same idea: having a file whose name is not constrained adjacent to a jupyter notebook, assuming an unsuspecting user would trigger an innocuous operation on a perfectly legit Jupyter notebook on the official Jupyter software and inadvertently allow full system compromise.

And this is exactly what we found by investigating the official export tool of Jupyter, nbconvert.

The Vulnerability

The vulnerability we discovered allows arbitrary code execution on Windows machines when exporting a notebook to PDF. By placing a properly named, malicious script in the notebook folder location, an attacker could hijack the conversion process and execute code with the privileges of the user.

When a Jupyter notebook containing SVG output is exported via nbconvert, the svg2pdf.py preprocessor is triggered to convert SVG images via the Inkscape tool. During this process, the path to Inkscape executable is resolved using Python’s shutil.which() via the following expression:

inkscape_path = which("inkscape")

without including inkscape anywhere as a mandatory nbconvert dependency. This opened the door to unintended code execution as the following figure shows:

Fig. 1: High level flow of exploitation of the security issue

shutil.which behavior is controlled internally by the Windows API function NeedCurrentDirectoryForExePathW, which returns TRUE (include CWD) when the NoDefaultCurrentDirectoryInExePath environment variable is not set, which is the default configuration on standard Windows installations.

In Python versions earlier than 3.12, `shutil.which()` ignores the `NoDefaultCurrentDirectoryInExePath` environment variable entirely, making it impossible to prevent this unsafe search behavior through configuration.

Python 3.12 and later versions properly respect this environment variable when set, but the variable remains unset by default on Windows systems, leaving many vulnerable.

Since nbconvert officially supports Python versions starting from 3.9, it includes versions that are affected by this issue both ways.

CVE-2025-53000

This unsafe lookup behavior aligns with CWE-427: Uncontrolled Search Path Element. Therefore, we recommended disabling the searching of inkscape software from CWD and relying on fixed safe search places.

Upon receiving our report, the Jupyter team reproduced the issue, acknowledged the associated risk, and requested a CVE (see below). A discussion was then initiated regarding how to fix the issue. However, the Jupyter team eventually stopped responding to our messages and has not addressed the issue to date.

CVE-2025-53000 has been assigned to this vulnerability. At the time of publication, the Github advisory has not yet been released by the maintainers.

Because export functionality is commonly used and generally trusted, it presents an attractive target for attackers, and especially in environments where notebooks are frequently shared—such as academic research groups, data science teams, or educational institutions—the potential for exploitation increases substantially.

Eventually, following our 90-day policy, we decided to publish this advisory to help protect the community.

Demonstration Video

The following demonstration video was recorded on a Windows 10 Enterprise x64 machine with default settings, using miniconda3 and Python 3.13.9, using the latest available Jupyter software versions, including:

Jupyter Core 5.9.1, nbconvert 7.16.6, and Notebook 7.5.0

Post Exploitation

Once successfully triggered, this vulnerability gives the attacker arbitrary code-execution in the context of the user. This immediately impacts confidentiality, integrity, and availability, as the attacker can access, modify, or disrupt the user’s data and workflows. On typical Windows data-science workstations, victim accounts almost always have:

• Direct access to sensitive notebooks and datasets.
• Cached cloud credentials (AWS CLI, Azure CLI, gcloud, Databricks etc.)
• Locally installed package managers (conda, pip, winget) and DevOps pipelines that will happily run additional code.

This potentially amplifies the radius of compromise, allowing its effects to spread beyond the initial workstation.

Recommendations

Companies are recommended to rely on a centralized Jupyter server, ensure that all Jupyter-related software remains up to date, and enforce strict restrictions on external files that may be processed through Jupyter tools.

It is also recommended to enable the NoDefaultCurrentDirectoryInExePath environment variable to reduce the risk of unintentionally executing files from untrusted locations.

Conclusion

This vulnerability shows how the invisible glue of our workflows can become points of failure when not properly scrutinized.

We expect more vulnerabilities to surface in this fast-growing AI ecosystem as workflows become more automated, composable, and cloud-integrated, and we hope this report encourages teams to take a closer look at the quiet dependencies holding their environments together.

Timeline

• June 8: Disclosure report submitted.
• June 12: Issue reproduced.
• June 25: CVE reservation by Jupyter team.

The post Code Execution in Jupyter Notebook Exports appeared first on Blog.

The surge in AI-driven traffic is transforming how websites manage their content. With AI bots and agents visiting sites at unprecedented rates (often scraping without permission, payment, or attribution) content owners face a critical challenge: how to protect their intellectual property while capitalizing on legitimate AI use cases.

Today, we’re excited to announce Imperva’s integration with TollBit, a groundbreaking solution that enables our Cloud Web Application Firewall (CWAF) customers to monetize traffic from AI bots and crawlers that would otherwise scrape their content without permission or compensation.

Meeting the AI Traffic Challenge

The traditional ad-supported and subscription-based content models are being disrupted by AI. This integration provides a new economic model where value flows fairly between content creators and AI developers, transforming unauthorized scraping into a sustainable revenue stream.

How Imperva and TollBit Work Together

The integration leverages Imperva’s industry-leading Web Application Firewall capabilities alongside TollBit’s analytics and monetization platform to create a comprehensive solution:

1. Detection & Enforcement: Imperva CWAF identifies AI bot traffic at the edge, providing the critical first layer of protection.
2. Intelligent Redirection: Using Imperva’s redirect rules, requests from AI bots are automatically redirected to a TollBit subdomain (e.g., tollbit.example.com), with CWAF returning an HTTP 302 response.
3. Payment Gateway: The TollBit subdomain returns an HTTP 402 response code (payment required), prompting AI bot operators to obtain valid TollBit tokens for authorized access.
4. Analytics & Insights: Through SIEM log integration, Imperva Access and Security logs flow to TollBit’s analytics engine, providing executives with clear, AI-specific analytics that show how bots are engaging with their content and the business impact of that traffic both within Tollbit and Imperva’s UMC.

Implementation Architecture

The integration requires a straightforward setup process:

• Onboard your domain to Imperva Cloud WAF
• Create a TollBit account and verify domain ownership via DNS TXT records
• Configure a TollBit subdomain with appropriate DNS NS records
• Create redirect rules in Imperva’s management console to route AI bot traffic
• Set up AWS S3 bucket integration for log processing and analytics

To ensure compatibility with TollBit’s requirements, an AWS Lambda function prefixes dates to Imperva log file names, enabling seamless ingestion into TollBit’s analytics platform.

A Shared Vision for Fair Compensation

This partnership represents a fundamental shift in how content owners approach AI traffic. Rather than simply blocking all bots or allowing unrestricted scraping, sites now have granular control to enforce access rules and pricing on their own terms.

Content owners deserve fair compensation for how their content powers the AI ecosystem. By combining Imperva’s security capabilities with TollBit’s monetization tools, we’re enabling the transition from unauthorized scraping to sustainable, licensed transactions.

What This Means for Imperva Customers

With this integration, Imperva CWAF customers gain:

• Robust protection against unauthorized AI scraping at the application layer
• Complete visibility into AI traffic patterns and behaviors through dedicated analytics
• Flexible control to decide which AI agents can access content and under what conditions
• New revenue streams that turn scraping attempts into legitimate, paid transactions

The agent economy is here, and autonomous AI visitors are becoming a permanent fixture of web traffic. With Imperva and TollBit, you can ensure these interactions happen on your terms—fairly, transparently, and profitably.

Get Started

If you’re an Imperva Cloud WAF customer and want to activate the integration:

• Create your own Tollbit account on the TollBit platform https://app.tollbit.com/sign-up.
• Create custom rules in the Imperva Cloud WAF platform as instructed in the TollBit Docs.

TollBit is free for publishers and websites so you can be up and running in no time.

Learn more about how Imperva’s integration with TollBit can help you protect and monetize your content in the AI era.

The post Imperva Partners with TollBit to Power AI Traffic Monetization for Content Owners appeared first on Blog.

Introduction and Vulnerability Overview 

Earlier this month, Imperva published an initial advisory outlining how our customers were protected against the newly disclosed React2Shell vulnerability impacting React Server Components (RSC). That post focused on the essentials: a critical flaw arising from unsafe server-side deserialization of client-controlled RSC payloads, its potential to enable unauthenticated remote code execution, and what we do to protect against it.  

In this follow-up, we expand on that foundation by examining what makes this vulnerability so dangerous. We explore the real-world footprint of this vulnerability, look at how it has appeared in the wild across different countries and sites, examine recorded exploit attempts that use this vulnerability as an entry point in opportunistic malware campaigns, and assess how the flood of AI-generated PoCs is complicating real-world defenses. 

General Statistics 

Before diving into the technical details, let’s begin with a macro-view of its real-world impact across the globe. 

Over the past week, Imperva sensors recorded over 127 million requests related to React2Shell (CVE‑2025‑55182) probing and exploitation attempts, highlighting the scale and automation targeting this vulnerability. These attempts spanned across more than 87 thousand distinct sites, showing that opportunistic scanning far outweighs targeted, single-tenant attacks.  

Activity was observed across 128 countries, with the United States and Singapore emerging as the most heavily targeted regions, underscoring the global reach of this CVE. 

The industry reach is widespread, although Education and Financial Services sites collectively account for almost half of all attacks.

The PoC Slop

Shortly after the public disclosure of React2Shell (CVE-2025-55182), a flood of what claimed to be “proof-of-concept” exploits began circulating. As the original disclosure site warns, many of these PoCs were invalidly crafted under incorrect assumptions, such as requiring explicit exposure of dangerous server-side functionality such as child_process.exec, vm.runInThisContext, or fs.writeFile rather than exploiting the actual flaw in the RSC Flight deserialization logic.

This surge of AI-generated PoC samples has a harmful side effect: it has muddied the waters for defenders. Instead of concentrating on the real vulnerability, security teams must sift through a sea of false or irrelevant exploit attempts. Attackers and bots are now producing a vast number of convincing-looking payloads, making it much harder for defenders to tell legitimate exploits from background noise.

An example of AI POC:

Malicious campaigns

In the immediate aftermath of the React2Shell disclosure, Imperva Threat research observed a large volume of malicious campaigns leveraging the vulnerability as an entry point. The following is a summary of just a few of the campaigns we observed along with the relevant IoCs:

1. Linux Remote Access Trojan Campaign
2. XNote RAT
3. Snowlight dropper
4. ReactOnMyNuts: Botnet and Cryptominer spreader campaign
5. Runnv Cryptojacking campaign

1. Linux Remote Access Trojan Campaign

Description:

A widespread campaign, where attackers leveraged the React Server Components vulnerability to download a malicious RAT executable. Once installed, the malware contacts a C2 server and retrieves JSON-based task instructions, such as running system commands, opening a reverse shell, and uploading or downloading files.

Top Targeted Countries: United States, Indonesia Thailand, Brazil, United Kingdom

Top Targeted Industries: Telecom and ISPs, Business, Financial Services, Gambling

Malicious command:

IoCs:

2. XNote RAT

Description:

A highly targeted campaign, affecting only financial services sites in Hong Kong, utilizing the React2Shell vulnerability to deploy the Xnote Remote Access Trojan Linux malware. The Xnote malware was exposed by Russian anti-virus company Doctor Web, who believe that there is “good reason to believe that some members of the Chinese hacker group called ChinaZ took part in the development of this Trojan.”

Targeted Country: Hong Kong

Targeted Industry: Financial Services

Malicious command:

IoCs:

3. Snowlight dropper

A campaign focused on deploying the SnowLight dropper through the React2Shell vulnerability. SnowLight serves as both an initial access vector and a persistence mechanism, executing malicious scripts that retrieve and install additional, more advanced payloads, most notably the VShell Remote Access Trojan (RAT).

SnowLight is associated with Chinese state-sponsored threat actors tracked as UNC5174, a group known for targeting research and education institutions, businesses, charities, NGOs, and government organizations across Southeast Asia, the United States, and the United Kingdom.

Targeted Countries: Indonesia, Australia, United States, Kuwait

Targeted Industry: Financial Services, Telecom and ISPs, Retail

Malicious command:

IoCs:

4. ReactOnMyNuts: Botnet and Cryptominer spreader campaign

Description:

A campaign utilizing the React2Shell vulnerability to spread both Mirai and XMRig cryptojacking malware samples using shared server architecture. The attackers used the vulnerability to execute a one-liner command aimed at downloading and installing both Mirai botnet and XMRig cryptojacking malware.

Cryptojacker configuration showing wallet addresses

Top Targeted Countries: United States, Australia, United Kingdom, Argentina, Columbia

Top Targeted Industries: Healthcare, Business, Financial Services, Computing & IT

Malicious commands:

IoCs:

5. Runnv Cryptojacking campaign

Description:

A cryptojacking campaign, with indicators of Chinese origin. The attackers utilized the React2Shell vulnerability to execute a dropper bash script, which downloads several second stage files including bash scripts and gzip compressed data. These components form the code and configuration of the cryptojacking operation. From an investigation of the wallet addresses used in the campaign we can see that (at the time of investigation) the threat actors were making around 170 USD per day, or around 62,050 USD per year.

Screenshot downloader script showing Chinese characters

Crypto wallet address:

Campaign Monero Wallet Statistics

Top Targeted Countries: United States, Brazil, United Kingdom, Colombia, Canada

Top Targeted Industries: Business, Financial Services, Lifestyle, Healthcare

Malicious commands:

IoCs:

Conclusion

The React2Shell vulnerability has quickly evolved from disclosure to widespread exploitation, with over 127 million attack attempts targeting more than 87,000 sites across 128 countries observed on the Imperva network alone within the first week. The campaigns documented here, from state-sponsored RATs to cryptojacking operations demonstrate how rapidly threat actors weaponize critical vulnerabilities. Imperva Cloud WAF and On-Premises WAF customers remain fully protected against these exploitation attempts.

The post Chain Reaction: Attack Campaign Activity in the Aftermath of React Server Components Vulnerability appeared first on Blog.

The more critical APIs become, the more sensitive data they carry identities, payment details, health records, customer preferences, tokens, keys, and more.

And this is where organizations face a painful, often invisible problem:

To protect APIs, many organizations end up exposing the very data they are trying to secure.

Most API security tools still rely on raw-payload logging, traffic replay, or shipping full request bodies into external analytics systems. That means sensitive customer data:

• Leaves controlled environments
• Gets stored in multiple systems
• Crosses borders without intention
• Lands in tools not designed to hold PII
• Multiplies breach risk and regulatory pressure

This creates a direct conflict between security, privacy, and compliance, and businesses are caught in the middle.

The Real-World Impact: When Privacy Becomes a Security Liability

Across industries – financial services, retail, healthcare, travel, public sector, the story repeats:

1. Breach blast radius expands

The more systems that hold raw API payloads, the bigger the impact when any one of them is compromised.

2. Compliance becomes harder, not easier

GDPR, CCPA, HIPAA, PCI, and emerging data-sovereignty regulations penalize:

• unnecessary data retention
• cross-border data transfers
• third-party exposure
• lack of data-minimization controls

Most API security tools inadvertently violate all four.

3. Data residency rules block API security deployments

Organizations operating in multiple regions can’t centralize raw API data in a single cloud service, but many tools require doing exactly that.

4. Dev and QA environments become privacy risks

When security tests are based on production payload replays, sensitive data leaks into non-production systems.

5. Security teams lose visibility if they avoid raw logging

Many leaders try to “lock down” data flows, but that often leaves API blind spots, making it harder to detect business logic abuse, scraping, or session-based attacks.

This is the API privacy paradox:
You either weaken privacy to strengthen security or weaken security to preserve privacy.

The Industry Approach Is Broken

The traditional API security model makes three flawed assumptions:

1. You must log or store raw payloads to get visibility.
2. You must centralize traffic for analytics.
3. You must replay production data to test API security.

These assumptions create privacy exposure, compliance failure, and operational friction.

Imperva Solves This by Rethinking the Architecture

Imperva’s privacy-first, local-first platform was built around a core belief:

API security should not require exposing sensitive data, ever.

The architecture flips the traditional model:

1. Inspect at the PoP (where traffic lives)

Traffic is parsed in-memory at the Point-of-Presence closest to the application, SaaS PoP or on-prem.

Raw values never leave the PoP.

2. Convert sensitive values into privacy-safe artifacts

Classification + hashing replaces raw payloads with:

• label
• schema fragments
• one-way irreversible hashes
  This is the only data that ever moves upstream.

3. Detect and respond using metadata only

Anomaly detection uses metadata such as:

• data labels
• schema context
• session identifiers
• hashed tokens

No raw content is needed or exposed.

4. Enforce using hashes, not identities

Hash-based enforcement enables:

• per-session blocking
• token-level mitigation
• behavior-based decisions
  without seeing or sharing the sensitive value behind the hash.

5. Same privacy guarantees across all deployments

Cloud, on-prem, hybrid – the mechanics never change.

What This Means for the Business

This is where Imperva’s architecture translates directly into measurable, enterprise-wide value:

Smaller blast radius = lower breach liability

Fewer systems hold PII, drastically reducing what attackers can steal and what you must disclose.

Faster compliance alignment

Local data processing and zero raw persistence align with GDPR, HIPAA minimum-necessary, and sovereignty rules.

Real-time protection with zero added exposure

Inline, in-PoP inspection gives detection teams full visibility without raw payload retention.

Safer automation in Dev/QA

Privacy-aware test artifacts eliminate the risk of production PII leaking into pipelines.

Reduced third-party risk

Vendors never receive raw payloads, only metadata and hashes.

A future-proof privacy posture

As regulatory pressure increases, architectures like this become mandatory, not optional.

Why This Whitepaper Matters

This whitepaper breaks down exactly how Imperva delivers production-grade API protection while preserving privacy, with clear explanations and practical examples.

You’ll learn:

• How to get deep visibility without storing raw payloads
• Why in-PoP processing reduces exposure and simplifies compliance
• How hash-based enforcement protects identities while enabling precise blocking
• How to design a privacy-first architecture that works across hybrid/multi-cloud

In other words:
If you need to secure APIs and meet privacy, residency, or compliance requirements – this is essential reading.

Ready to See How Privacy-First API Security Really Works?

Download the whitepaper and learn how Imperva protects APIs without exposing sensitive data.

The post The Privacy Gap in API Security: Why Protecting APIs Shouldn’t Put Your Data at Risk appeared first on Blog.