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.

Unit 42 reveals how multi-agent AI systems can autonomously attack cloud environments. Learn critical insights and vital lessons for proactive security.

The post Can AI Attack the Cloud? Lessons From Building an Autonomous Cloud Offensive Multi-Agent System appeared first on Unit 42.

Unit 42 research reveals AirSnitch attacks bypass WPA2/3 Wi-Fi encryption and client isolation, exposing critical infrastructure vulnerabilities.

The post When Wi-Fi Encryption Fails: Protecting Your Enterprise from AirSnitch Attacks appeared first on Unit 42.

CVE-2023-33538 allows for command injection in TP-Link routers. We discuss exploitation attempts with payloads characteristic of Mirai botnet malware.

The post A Deep Dive Into Attempted Exploitation of CVE-2023-33538 appeared first on Unit 42.

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.

Unit 42 reveals "Agent God Mode" in Amazon Bedrock AgentCore. Broad IAM permissions lead to privilege escalation and data exfiltration risks.

The post Cracks in the Bedrock: Agent God Mode appeared first on Unit 42.

Unit 42 uncovers critical vulnerabilities in Amazon Bedrock AgentCore's sandbox, demonstrating DNS tunneling and credential exposure.

The post Cracks in the Bedrock: Escaping the AWS AgentCore Sandbox appeared first on Unit 42.

Unit 42 uncovers escalating Kubernetes attacks, detailing how threat actors exploit identities and critical vulnerabilities to compromise cloud environments.

The post Understanding Current Threats to Kubernetes Environments appeared first on Unit 42.

Unit 42 research on multi-agent AI systems on Amazon Bedrock reveals new attack surfaces and prompt injection risks. Learn how to secure your AI applications.

The post When an Attacker Meets a Group of Agents: Navigating Amazon Bedrock's Multi-Agent Applications appeared first on Unit 42.

Unit 42 uncovers a "double agent" flaw in Google Cloud's Vertex AI, demonstrating how overprivileged AI agents can compromise cloud environments.

The post Double Agents: Exposing Security Blind Spots in GCP Vertex AI appeared first on Unit 42.

Unit 42 identifies a recruitment phishing campaign targeting senior professionals via impersonation and fraudulent resume fees.

The post Threat Brief: Recruiting Scheme Impersonating Palo Alto Networks Talent Acquisition Team appeared first on Unit 42.

Explore Google’s synced passkey architecture. Unit 42 details its mechanisms, key management, and secure communication in passwordless systems."

The post Google Cloud Authenticator: The Hidden Mechanisms of Passwordless Authentication appeared first on Unit 42.

An espionage operation demonstrated strategic operational patience against targets in Southeast Asia, deploying custom backdoors.

The post Suspected China-Based Espionage Operation Against Military Targets in Southeast Asia appeared first on Unit 42.

Unit 42 research reveals AI judges are vulnerable to stealthy prompt injection. Benign formatting symbols can bypass security controls.

The post Auditing the Gatekeepers: Fuzzing "AI Judges" to Bypass Security Controls appeared first on Unit 42.

In-depth analysis of threat activity we call CL-UNK-1068. We discuss their toolset, including tunneling, reconnaissance and credential theft.

The post An Investigation Into Years of Undetected Operations Targeting High-Value Sectors appeared first on Unit 42.

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.

Uncover real-world indirect prompt injection attacks and learn how adversaries weaponize hidden web content to exploit LLMs for high-impact fraud.

The post Fooling AI Agents: Web-Based Indirect Prompt Injection Observed in the Wild appeared first on Unit 42.

A high-severity CVE-2026-0628 in Chrome's Gemini allowed local file access and privacy invasion. Google quickly patched the flaw.

The post Taming Agentic Browsers: Vulnerability in Chrome Allowed Extensions to Hijack New Gemini Panel appeared first on Unit 42.

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.