A new command injection vulnerability in OpenSSH, tracked as CVE-2025-61984, has been disclosed, which could allow an attacker to achieve remote code execution on a victim’s machine.

The vulnerability is a bypass of a previous fix for a similar issue (CVE-2023-51385) and exploits how the ProxyCommand feature interacts with the underlying system shell when handling specially crafted usernames.

The core of the vulnerability lies in OpenSSH’s failure to properly sanitize control characters, such as newlines, within usernames. An attacker can create a username that includes a newline character followed by a malicious command.

This username is then passed to the shell via SSH’s ProxyCommand. While OpenSSH filters many dangerous shell metacharacters, it does not filter characters that could force a syntax error in certain shells.

When a shell like Bash, Fish, or csh processes the ProxyCommand, the crafted syntax error on the first line, the command fails, but the shell does not exit.

Instead, it proceeds to execute the command on the next line, which is the malicious payload supplied by the attacker. This behavior effectively bypasses security measures intended to prevent command execution, opening the door for an RCE.

The Git Submodule Attack Vector

The most practical exploitation scenario for CVE-2025-61984 involves a malicious Git repository. An attacker can configure a submodule within their repository to use a URL containing the malicious, multi-line username.

If a victim clones this repository recursively (git clone --recursive), Git will attempt to connect via SSH to fetch the submodule. This triggers the vulnerability ProxyCommand if the user has a specific configuration.

The exploit requires two conditions on the victim’s machine: a shell that continues execution after a syntax error (like Bash) and an SSH configuration file (~/.ssh/config) with a ProxyCommand that uses the %r token to include the remote username.

Notably, the secure shell Zsh is not vulnerable to this technique as it terminates upon encountering such errors. Tools like Teleport have been found to generate SSH configurations that use this vulnerable pattern, potentially increasing the attack surface.

Mitigations

The OpenSSH project has released a patch in version 10.1 that fully addresses this vulnerability by disallowing control characters in usernames. All users are strongly urged to upgrade to this version or newer.

For systems that cannot be immediately updated, several mitigations can be implemented.

Users can edit their SSH configurations to enclose the %r token in single quotes ('%r') within any ProxyCommand directive, which prevents the shell from interpreting the special characters.

Another effective defense-in-depth measure is to configure Git to restrict the automatic use of SSH for submodules.

This vulnerability serves as a critical reminder of the complex security risks that can emerge from the interactions between trusted developer tools.

Follow us on Google News, LinkedIn, and X for daily cybersecurity updates. Contact us to feature your stories.

The post OpenSSH Vulnerability Exploited Via ProxyCommand to Execute Remote Code – PoC Released appeared first on Cyber Security News.

A 13-year-old critical remote code execution (RCE) vulnerability in Redis, dubbed RediShell, allows attackers to gain full access to the underlying host system.

The flaw, tracked as CVE-2025-49844, was discovered by Wiz Research and has been assigned the highest possible CVSS severity score of 10.0, a rating reserved for the most severe security issues.

The vulnerability is a Use-After-Free (UAF) memory corruption bug that has existed in the Redis source code for approximately 13 years. A post-authentication attacker can exploit this flaw by sending a specially crafted Lua script.

Because Lua scripting is a default feature, the attacker can escape the Lua sandbox environment to achieve arbitrary code execution on the Redis host.

This level of access grants an attacker complete control, enabling them to steal, delete, or encrypt data, hijack system resources for activities like crypto mining, and move laterally across the network.

The potential impact is magnified by Redis’s ubiquity. An estimated 75% of cloud environments utilize the in-memory data store for caching, session management, and messaging.

The combination of this critical flaw with common deployment practices that often lack proper security hardening creates a significant risk multiplier for organizations globally.

Redis Instances Exposed to the Internet

Analysis by Wiz Research revealed an extensive attack surface, with approximately 330,000 Redis instances exposed to the internet. Alarmingly, about 60,000 of these instances have no authentication configured.

The official Redis container image, which accounts for 57% of cloud installations, does not require authentication by default.

This configuration is highly dangerous, as it allows any unauthenticated attacker to send malicious Lua scripts and execute code within the environment.

Even instances exposed only to internal networks are at high risk, as an attacker with an initial foothold could exploit the vulnerability for lateral movement to more sensitive systems.

The attack flow begins with the attacker sending a malicious Lua script to the vulnerable Redis instance. After successfully exploiting the UAF bug to escape the sandbox, the attacker can establish a reverse shell for persistent access.

From there, they can compromise the entire host by stealing credentials like SSH keys and IAM tokens, installing malware, and exfiltrating sensitive data from both Redis and the host machine.

On October 3, 2025, Redis released a security advisory and patched versions to address CVE-2025-49844. All Redis users are strongly urged to upgrade their instances immediately, prioritizing those that are internet-exposed or lack authentication.

In addition to patching, organizations should implement security hardening best practices.

These measures include enabling strong authentication, disabling Lua scripting if it is not required, running Redis with a non-root user account with minimal privileges, and implementing network-level access controls like firewalls and Virtual Private Clouds (VPCs) to restrict access to authorized networks only.

Follow us on Google News, LinkedIn, and X for daily cybersecurity updates. Contact us to feature your stories.

The post 13-year-old Critical Redis RCE Vulnerability Let Attackers Gain Full Access to Host System appeared first on Cyber Security News.