Overview
Tunnelling protocols are an essential part of the Internet and form much of the backbone that modern network infrastructure relies on today. One limitation of these protocols is that they do not authenticate and/or encrypt traffic. Though this limitation exists, IPsec can be implemented to help prevent attacks. However, implementation of these protocols have been executed poorly in some areas.
For the latest security findings from the researchers at the DistriNet-KU Leuven research group, please refer to: https://papers.mathyvanhoef.com/usenix2025-tunnels.pdf
Description
Researchers at the DistriNet-KU Leuven research group have discovered millions of vulnerable Internet systems that accept unauthenticated IPIP, GRE, 4in6, or 6in4 traffic. This can be considered a generalization of the vulnerability in VU#636397 : IP-in-IP protocol routes arbitrary traffic by default (CVE-2020-10136). The exposed systems can be abused as one-way proxies, enable an adversary to spoof the source address of packets (CWE-290 Authentication Bypass by Spoofing), or permit access to an organization’s private network. Vulnerable systems can also facilitate Denial-of-Service (DoS) attacks.
Two types of DoS attacks exploiting this vulnerability can amplify traffic: one concentrates traffic in time (“Tunneled-Temporal Lensing”), and the other can loop packets between vulnerable systems, resulting in an amplification factor of at least 13- and 75-fold, respectively. Additionally, the researchers discovered an Economic Denial of Sustainability (EDoS), where the outgoing bandwidth of a vulnerable system is drained, raising the cost of operations if hosted by a third-party cloud service provider.
Impact
An adversary can abuse these security vulnerabilities to create one-way proxies and spoof source IPv4/6 addresses. Vulnerable systems may also allow access to an organization’s private network or be abused to perform DDoS attacks.
Solution
See the “Defences” section in the researcher’s publication https://papers.mathyvanhoef.com/usenix2025-tunnels.pdf
Acknowledgements
Thanks to the researchers Mathy Vanhoef and Angelos Beitis of the DistriNet-KU Leuven research group for the initial discovery and research. This document was written by Ben Koo.
CVE-2024-7595
GRE and GRE6 Protocols (RFC2784) do not validate or verify the source of a network packet, allowing an attacker to route arbitrary traffic via an exposed network interface that can lead to spoofing, access control bypass, and other unexpected network behaviors. This can be considered similar to CVE-2020-10136.
CVE-2024-7596
Proposed Generic UDP Encapsulation (GUE) (IETF draft-ietf-intarea-gue*) does not validate or verify the source of a network packet, allowing an attacker to route arbitrary traffic via an exposed network interface that can lead to spoofing, access control bypass, and other unexpected network behaviors. This can be considered similar to CVE-2020-10136.
*Note: GUE Draft is expired and no longer canonical.
CVE-2025-23018
The IPv4-in-IPv6 and IPv6-in-IPv6 protocols (RFC2473) do not require the validation or verification of the source of a network packet, allowing an attacker to route arbitrary traffic via an exposed network interface that can lead to spoofing, access control bypass, and other unexpected network behaviors. This can be considered similar to CVE-2020-10136.
CVE-2025-23019
The IPv6-in-IPv4 protocol (RFC4213) does not require authentication of incoming packets, allowing an attacker to route traffic via an exposed network interface that can lead to spoofing, access control bypass, and other unexpected network behaviors.
Note: CVE-2024-7595, CVE-2024-7596, and CVE-2025-23018 are considered similar to CVE-2020-10136 in that they highlight the inherent weakness that these protocols do not validate or verify the source of a network packet. These distinct CVEs are meant to specify the different protocols in question that are vulnerable.
For reference: (CVE-2020-10136) Multiple products that implement the IP Encapsulation within IP (IPIP) standard (RFC 2003, STD 1) decapsulate and route IP-in-IP traffic without any validation, which could allow an unauthenticated remote attacker to route arbitrary traffic via an exposed network interface and lead to spoofing, access control bypass, and other unexpected network behaviors.

Overview
Rsync, a versatile file-synchronizing tool, contains six vulnerabilities present within versions 3.3.0 and below. Rsync can be used to sync files between remote and local computers, as well as storage devices. The discovered vulnerabilities include heap-buffer overflow, information leak, file leak, external directory file-write,–safe-links bypass, and symbolic-link race condition.
Description
Many backup programs, such as Rclone, DeltaCopy, and ChronoSync use Rsync as backend software for file synchronization. Rsync can also be used in Daemon mode and is widely used in in public mirrors to synchronize and distribute files efficiently across multiple servers.
Following are the discovered vulnerabilities:
CVE-2024-12084 A heap-buffer-overflow vulnerability in the Rsync daemon results in improper handling of attacker-controlled checksum lengths (s2length). When the MAX_DIGEST_LEN exceeds the fixed SUM_LENGTH (16 bytes), an attacker can write out-of-bounds in the sum2 buffer.
CVE-2024-12085 When Rsync compares file checksums, a vulnerability in the Rsync daemon can be triggered. An attacker could manipulate the checksum length (s2length) to force a comparison between the checksum and uninitialized memory and leak one byte of uninitialized stack data at a time.
CVE-2024-12086 A vulnerability in the Rsync daemon could cause a server to leak the contents of arbitrary files from clients’ machines. This happens when files are copied from client to server. During the process, a malicious Rsync server can generate invalid communication tokens and checksums from data the attacker compares. The comparison will trigger the client to ask the server to resend data, which the server can use to guess a checksum. The server could then reprocess data, byte to byte, to determine the contents of the target file.
CVE-2024-12087 A path traversal vulnerability in the Rsync daemon affects the –inc-recursive option, a default-enabled option for many flags that can be enabled by the server even if not explicitly enabled by the client. When using this option, a lack of proper symlink verification coupled with de-duplication checks occurring on a per-file-list basis could allow a server to write files outside of the client’s intended destination directory. A malicious server could remotely trigger this activity by exploiting symbolic links named after valid client directories/paths.
CVE-2024-12088 A –safe-links option vulnerability results in Rsync failing to properly verify whether the symbolic link destination contains another symbolic link within it. This results in a path traversal vulnerability, which may lead to arbitrary files being written outside of the desired directory.
CVE-2024-12747 Rsync is vulnerable to a symbolic-link race condition, which may lead to privilege escalation. A user could gain access to privileged files on affected servers.
Impact
When combined, the first two vulnerabilities (heap buffer overflow and information leak) allow a client to execute arbitrary code on a device that has an Rsync server running. The client requires only anonymous read-access to the server, such as public mirrors.
Additionally, attackers can take control of a malicious server and read/write arbitrary files of any connected client. Sensitive data, such as SSH keys, can be extracted, and malicious code can be executed by overwriting files such as ~/.bashrc or ~/.popt.
Solution
Apply the latest patches available at https://github.com/RsyncProject/rsync and https://download.samba.org/pub/rsync/src/. Users should run updates on their software as soon as possible. As Rsync can be distributed bundled, ensure any software that provides such updates is also kept current to address these vulnerabilities.
Acknowledgements
Thanks to Simon Scannell, Pedro Gallegos, and Jasiel Spelman at Google Cloud Vulnerability Research for discovering the first five vulnerabilities; thanks to Aleksei Gorban for discovering the symbolic-link race condition. Finally, thanks to Andrew Tridgell for reporting all of them.
This document was written by Dr. Elke Drennan, CISSP.

Overview
The Howyar UEFI Application “Reloader” (32-bit and 64-bit), distributed as part of SysReturn prior to version 10.2.02320240919, is vulnerable to the execution of arbitrary software from a hard-coded path. An attacker who successfully exploits this vulnerability can bypass the UEFI Secure Boot feature and execute unsigned code during the boot process in the UEFI context.
Description
The Unified Extensible Firmware Interface (UEFI) is a specification for firmware architecture that facilitates interaction between a computing platform’s hardware and operating system during the early boot phase. When a UEFI-compliant computer is powered on, the UEFI implementation (including multiple UEFI applications) is the first software to run, preceding the operating system. UEFI applications are typically digitally signed, often by the Microsoft UEFI Certificate Authority (CA), ensuring their trusted execution under UEFI Secure Boot. UEFI bootloaders, a type of UEFI application, provide early boot management, loading OS files into protected memory areas for execution. These bootloaders can execute additional software and load drivers as part of their startup processes.
The Howyar Reloader UEFI application, an UEFI bootloader available in both 32-bit and 64-bit versions, has been found to contain an arbitrary code execution vulnerability. Researchers at ESET discovered that the application allows execution of UEFI software from a hard-coded path without verifying its signature. This occurs because the Reloader does not use UEFI’s standard BootServices LoadImage() API for safe application execution. Consequently, any unsigned third-party software can be executed during the early boot phase with high privileges in the UEFI context. Since the Reloader application is signed by the trusted Microsoft UEFI CA, it can be installed on any UEFI-compliant system. Furthermore, as it is bundled and distributed as part of supply-chain software, it may also be present in other UEFI implementations provided by software suppliers or OEMs.
An attacker with the ability to update the UEFI bootloader can exploit this vulnerability to run arbitrary code, bypassing UEFI Secure Boot. On systems where a vulnerable version of the Reloader application is present, an attacker only needs to install a malicious unsigned UEFI application in a hard-coded path to achieve Secure Boot bypass and execute code in the UEFI context.
To mitigate this vulnerability, updated Reloader should be installed on the affected systesm. It is also essential that all UEFI compliant computers also update their Secure Boot Forbidden Signature Database (DBX or Revocation List), supplied by the UEFI Forum. This update should be applied to the special SPI flash memory on the motherboard, which stores firmware data. Maintaining the integrity of the UEFI Secure Boot ecosystem requires the timely application of these updates.
Impact
An attacker can bypass Secure Boot at system startup and execute arbitrary code before the operating system (OS) loads. Code executed in this early boot phase can persist on the system, potentially loading malicious kernel extensions that survive both reboots and OS reinstallation. Additionally, it may evade detection by OS-based and endpoint detection and response (EDR) security measures.
Solution
Apply a Patch
Howyar Technologies and their partners have released updated software to address this vulnerability. Please follow their guidance to install the updated version of the software. Additionally, Microsoft has indicated that they intend to provide an updated DBX (Revocation List) file around January 14, 2025. These updates may also be delivered by your OEM or OS vendor to ensure the Secure Boot Forbidden Signature Database (DBX) is up to date. Microsoft Windows users can follow instructions in Check-UEFISecureBootVariables on verifying the latest SecureBoot updates were applied and also find out if it is safe to apply these updates. For Linux users, seeBlog fwupd-2.0.4 which provides you with instructions on changes to fwupd to support this update.
Recommendations for Enterprises and Developers
As changes to the DBX(Forbidden Signature Database) file can lead to system instability, vendors are urged to thoroughly test the updates to ensure they do not render systems unusable. Note: Update the DB (Signature Database) before applying the DBX, this means you should update the trusted list of boot applications first, before updating the list of revoked boot application. Enterprises and cloud providers managing large numbers of systems should prioritize applying these updates and ensure the DBX file changes are implemented reliably to prevent loading of unsigned binaries in the virtual machine boot process. Microsoft has provided a secureboot_objects GitHub repository with the DBX files and additional tools. Enterprises that use installable boot media such as CDROM or Network Media (PXE or HTTP) should ensure all the media files are updated as well that were previously signed by now blocked digital certificate Microsoft Windows Production PCA (Product Certificate Authority) 2011.
Acknowledgements
Thanks to Martin Smolar of ESET for his responsible disclosure of this vulnerability to Howyar Technologies and other affected vendors. Thanks also to Howyar Technologies that closely worked with the researcher and CERT/CC to resolve this vulnerability. This document was written by Vijay Sarvepalli.