LiveWallPaper 2.6.8.0: Unauthenticated Code Execution

Summary

GiantappMan’s LiveWallPaper (巨应壁纸) version 2.6.8.0 for Windows exposes an ASP.NET Core Kestrel and SignalR management service on TCP port 5001. In the tested configuration, the service listened on 0.0.0.0:5001 and accepted requests from another host on the local network without authentication.

An unauthenticated client can obtain a writable wallpaper draft directory, upload an executable through UploadFile, and ask the SignalR hub’s ShowWallpaper method to start that file. The resulting process runs in the logged-on desktop user’s context. This is a remote code execution issue when the management port is reachable; no privilege elevation was demonstrated.

The execution is end-to-end remote code execution rather than the launch of a program the attacker does not control, because the file that is executed is the file the attacker uploaded. In testing, the uploaded program started Windows’ own cmd.exe with a command line of the attacker’s choosing, which is general command execution; there is no fixed program or allow-list involved.

Item	Finding
Vendor	GiantappMan / Giant App Studio
Product	LiveWallPaper (巨应壁纸), Windows application
Confirmed affected version	2.6.8.0, Microsoft Store build
Test environment	Windows 11 x64; an unauthenticated client on a separate host in the test network
Primary weakness	CWE-306: Missing Authentication for Critical Function
Contributing weakness	CWE-434: Unrestricted Upload of File with Dangerous Type
Impact	Unauthenticated remote code execution as the desktop user when TCP 5001 is reachable — the attacker’s own binary is executed, so arbitrary commands can be issued through it
Proposed CVSS v3.1 base score	9.8 (Critical) — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVE	CVE-2026-116110 — assigned, VulDB is the CNA
Other versions	Not independently tested

Technical basis

The vendor’s v2.x source at commit aa9bb36 declares version 2.6.8.0, which matches the version returned by the tested application’s GetClientVersion hub method.

1. ServerWrapper.cs configures the local server with http://*:{port}/, so the listener is not restricted to loopback.
2. Startup.cs maps the /livewallpaper SignalR hub. The relevant LiveWallpaperHub.cs methods do not require authentication. GetDraftDir returns a writable wallpaper directory and ShowWallpaper forwards a caller-supplied path to the engine.
3. LiveWallpaperController.cs accepts a file upload without authenticating the caller or restricting the file extension. Its destination directory check uses a string containment test against the wallpaper directory.
4. The engine accepts the supplied path in WallpaperApi.cs; ExternalProcessRender.cs passes an executable path to Process.Start.

Verification

On the tested 2.6.8.0 build, an unauthenticated network client received a SignalR connection token and the version response. The same client uploaded a benign x64 proof program, then invoked ShowWallpaper with its returned path. A distinct console window opened on the affected desktop and showed the running user, host name, and working directory. As a control, invoking the same method with the existing Windows Calculator executable opened Calculator on the affected desktop.

In a separate 2.6.8.0 test VM, a first Calculator request produced no visible window, while a later fresh request did open Calculator. The same remote method also visibly started Windows Notepad. The engine can skip a repeat request when the same wallpaper path is already recorded for a screen. It may also embed an application’s window in the desktop wallpaper layer, where it has no normal taskbar button. Visual confirmation should therefore use a fresh request and observation on the affected desktop.

The engine chooses a renderer by file extension: the .exe proof reached the process launcher, while an uploaded .bat file did not execute. A hub response or a GetRunningWallpapers entry by itself is not proof of process creation; the visible windows were the confirming observation.

Two details matter when reproducing this. The hub method signature is ShowWallpaper(path, screen), and the screen argument is required: a call that omits it is answered normally but starts no process, which is easy to misread as “the chain does not work”. Use a concrete screen name such as Display0. The renderer also only routes .exe to the process launcher, so a .bat upload will not execute even though the upload itself succeeds.

Because the window in the uploaded-program case was opened by cmd.exe carrying the attacker’s own command line, the chain provides command execution and not merely a fixed program launch. No further step is needed to turn it into a general-purpose remote command channel; only the content of the uploaded executable determines what runs.

From code execution to a reverse shell

A reverse shell does not require any additional primitive. The uploaded file is arbitrary attacker code, so the same chain accommodates a payload that opens an outbound TCP connection and attaches cmd.exe to it. That variant was exercised during testing: a small no-CRT x64 binary (importing only KERNEL32 and WS2_32, so it does not depend on a matching UCRT on the target) was uploaded through UploadFile, started through ShowWallpaper, connected back to the tester, and returned an interactive command channel running as the logged-on desktop user. The proof-of-concept script accompanying this report builds and uses exactly that payload.

Nothing in the vulnerable service constrains what the uploaded executable does after it is started: it inherits the user’s token and network access, and the service only tracks the process so that it can be stopped when the wallpaper changes.

The uploaded program ran with the logged-on user’s privileges. The evidence does not establish administrator access, exploitation of other product versions, or exploitation over the public Internet. A sanitized request/response transcript and the benign proof program have been prepared for private review by the vendor and vulnerability coordinator.

Severity assessment

The proposed CVSS v3.1 base score is 9.8 (Critical): CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The management service uses HTTP and WebSocket over TCP and was observed listening on 0.0.0.0:5001; its protocol does not require the attacker to be on the same subnet, which supports AV:N under the FIRST CVSS v3.1 Attack Vector guidance. This does not imply that the service was exposed to the public Internet. The observed chain requires no credentials or user interaction. Code runs with the existing desktop user’s authority, so Scope is Unchanged. Arbitrary code execution supports High confidentiality, integrity, and availability impact. This is a reporter-proposed score; the vulnerability coordinator may revise it.

On the impact metrics. Confidentiality, Integrity and Availability are each High because the impact is measured against the impacted component — the logged-on user’s Windows session — and the demonstrated capability is arbitrary code execution with that user’s complete token, not merely a file landing on disk. The uploaded program was started by ShowWallpaper and opened a console window on the affected desktop reporting whoami, hostname and the working directory; a control run with C:\Windows\System32\calc.exe opened Calculator on the same desktop. Code running at that privilege reads every document, the browser profile, cloud-sync directories, user-scope credential stores and SSH/API keys reachable by that account (C:H), can rewrite or delete them and tamper with the product’s own configuration (I:H), and can terminate arbitrary user processes, including the service itself (A:H). Under the specification’s definition, C:H applies when “all resources within the impacted component” are divulged, which is what unlimited code execution in that session yields.

Why Scope stays Unchanged while impact stays High. With S:U, the vulnerable component and the impacted component are managed by the same security authority, i.e. the user’s own access-control context. The payload does not cross into a different authority, so S:U is correct — and precisely because it stays inside that authority, everything within it is exposed. If the impact were argued to be confined to the wallpaper service itself, then running code on the OS would lie outside that component and would require S:C, which raises the score rather than lowering it.

On “user-level rather than SYSTEM”. That observation is an Environmental (Modified) consideration, not a Base one. The specification states that the Base score “assumes the reasonable worst case impact across different deployed environments” (§1.1), and §4.2 gives this exact case: a service that normally runs with administrator privileges but “might be running with reduced privileges” in a given environment — for which the Modified Confidentiality, Integrity and Availability are set to Low. The Base vector should therefore remain C:H/I:H/A:H; a deployment-specific reduction belongs in MC/MI/MA. For comparison, CVE-2023-23397 (Outlook, where the attacker gains the user’s identity rather than SYSTEM) is scored AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8) by Microsoft, and CVE-2022-22965 and CVE-2019-0708 carry the same S:U/C:H/I:H/A:H pattern (9.8).

Suggested remediation

• Require authentication and authorization for the SignalR hub and upload endpoint.
• Bind the management service to loopback by default. If remote control is needed, make network exposure an explicit setting and restrict allowed clients.
• Restrict uploads to expected wallpaper asset types and validate the canonical destination path server-side.
• Do not pass a client-supplied path to a process launcher. Resolve permitted players or wallpaper IDs on the server.

Until a fix is available, users can prevent untrusted hosts from reaching TCP 5001 with host or network firewall rules.

Disclosure

The vendor was contacted on 2026-09-27 through GiantappMan/livewallpaper issue #185 to request a private reporting channel. This page is a public summary. The detailed reproduction package should be shared with the vendor and VulDB through appropriate reporting channels. Vendor response, fix status, and any assigned CVE can be added here when confirmed.