Security] XYplorer.exe double-click on crafted filename "demo.txt " executes sibling "demo.txt .cmd" via cmd.exe (target
Posted: 18 Jan 2026 06:14
Title:
[Security] XYplorer.exe double-click on crafted filename "demo.txt " executes sibling "demo.txt .cmd" via cmd.exe (target confusion -> command execution)
Body:
Hello XYplorer developers,
I would like to report a potential security vulnerability in XYplorer (XYplorer.exe). When a crafted filename is used (a trailing space and a space before the apparent extension), double-clicking a file that visually appears to be a .txt file may execute a sibling .cmd script with the same name prefix, resulting in command execution as the current user.
Please treat this ticket as PRIVATE (Mark as Private is enabled).
Affected versions / platforms (confirmed):
- XYplorer 27.20.0900 (2026-01-07) for Windows (6.3 MB)
Compatible with 32-bit and 64-bit Windows XP, Vista, 7, 8, 8.1, 10, 11
- XYplorer 28.10.0400 (2026-01-14) for Windows (10.2 MB)
Compatible with 64-bit Windows XP, Vista, 7, 8, 8.1, 10, 11
- Windows 10 and Windows 11 (both confirmed)
Component:
- XYplorer (XYplorer.exe)
Summary:
Double-clicking the file:
C:\Users\potat\Desktop\demo\demo.txt
(note: the filename contains a trailing space after "txt")
causes XYplorer.exe to execute:
C:\Users\potat\Desktop\demo\demo.txt .cmd
(note: the filename contains a space before ".cmd")
via cmd.exe (/c), which allows an attacker-controlled script to run.
Impact:
An attacker who can place both files in the same directory (e.g., via an extracted archive, shared folder, or downloaded bundle) can trick a user into double-clicking a seemingly harmless text file, but the sibling .cmd is executed. This leads to arbitrary command execution as the current user.
Reproduction steps (PoC):
1) Create a folder, e.g.:
C:\Users\potat\Desktop\demo\
2) Create an empty file with a crafted name (trailing space in the name):
cmd /c 'type nul > "\\?\%CD%\demo.txt "'
3) Create a sibling script file in the same folder:
cmd /c 'echo start calc> "\\?\%CD%\demo.txt .cmd"'
4) Open the folder in XYplorer (XYplorer.exe).
5) Double-click "demo.txt ".
6) Observe:
- calc.exe is launched.
Expected result:
Double-clicking "demo.txt " should open that file with the associated text viewer/editor (or prompt to choose an app). It must not execute a different sibling file such as "demo.txt .cmd".
Actual result:
XYplorer.exe starts cmd.exe and executes "demo.txt .cmd".
Control tests:
- If "demo.txt .cmd" is removed/renamed, double-clicking "demo.txt " no longer executes any commands; instead Windows shows “Choose an app to open demo.txt ”.
- With normal filenames ("demo3.txt" and sibling "demo3.txt.cmd"), double-clicking "demo3.txt" does NOT execute the .cmd payload.
Evidence:
I attached ProcMon screenshots that show:
- Parent process: XYplorer.exe
- XYplorer.exe -> Process Create -> cmd.exe
- Command line contains:
cmd.exe /c ""C:\Users\potat\Desktop\demo\demo.txt .cmd""
- cmd.exe then creates calc.exe (PoC payload execution)
Suggested fix / direction:
Please ensure the double-click/open action operates strictly on the literal selected file path and does not resolve/normalize it into a different sibling executable/script (such as *.cmd). The issue appears related to filename parsing/normalization around trailing spaces/dots and extension handling.
Thank you for your time. I can retest any proposed fix on Windows 10/11 and provide ProcMon .PML logs if needed.
Additional note (why this is security-relevant and not just “Windows behavior”):
The user double-clicks the literal selected file "demo.txt[space]", but XYplorer spawns cmd.exe and executes the sibling "demo.txt[space].cmd". If the .cmd is removed, the same double-click only shows “Choose an app to open”, and with normal names ("demo3.txt" + "demo3.txt.cmd") no execution occurs. This indicates XYplorer’s open path is resolving/redirecting the target to a different executable when a sibling .cmd exists, which is a target confusion issue.
This is not about Windows refusing such filenames; both files exist and are accessible on NTFS. The security issue is that a UI double-click on the selected non-executable entry ("demo.txt[space]") results in XYplorer launching cmd.exe to execute a different sibling script ("...txt[space].cmd"). A file manager should never switch targets from the selected file to a different executable based on name normalization or PATHEXT-style resolution. thanks.
[Security] XYplorer.exe double-click on crafted filename "demo.txt " executes sibling "demo.txt .cmd" via cmd.exe (target confusion -> command execution)
Body:
Hello XYplorer developers,
I would like to report a potential security vulnerability in XYplorer (XYplorer.exe). When a crafted filename is used (a trailing space and a space before the apparent extension), double-clicking a file that visually appears to be a .txt file may execute a sibling .cmd script with the same name prefix, resulting in command execution as the current user.
Please treat this ticket as PRIVATE (Mark as Private is enabled).
Affected versions / platforms (confirmed):
- XYplorer 27.20.0900 (2026-01-07) for Windows (6.3 MB)
Compatible with 32-bit and 64-bit Windows XP, Vista, 7, 8, 8.1, 10, 11
- XYplorer 28.10.0400 (2026-01-14) for Windows (10.2 MB)
Compatible with 64-bit Windows XP, Vista, 7, 8, 8.1, 10, 11
- Windows 10 and Windows 11 (both confirmed)
Component:
- XYplorer (XYplorer.exe)
Summary:
Double-clicking the file:
C:\Users\potat\Desktop\demo\demo.txt
(note: the filename contains a trailing space after "txt")
causes XYplorer.exe to execute:
C:\Users\potat\Desktop\demo\demo.txt .cmd
(note: the filename contains a space before ".cmd")
via cmd.exe (/c), which allows an attacker-controlled script to run.
Impact:
An attacker who can place both files in the same directory (e.g., via an extracted archive, shared folder, or downloaded bundle) can trick a user into double-clicking a seemingly harmless text file, but the sibling .cmd is executed. This leads to arbitrary command execution as the current user.
Reproduction steps (PoC):
1) Create a folder, e.g.:
C:\Users\potat\Desktop\demo\
2) Create an empty file with a crafted name (trailing space in the name):
cmd /c 'type nul > "\\?\%CD%\demo.txt "'
3) Create a sibling script file in the same folder:
cmd /c 'echo start calc> "\\?\%CD%\demo.txt .cmd"'
4) Open the folder in XYplorer (XYplorer.exe).
5) Double-click "demo.txt ".
6) Observe:
- calc.exe is launched.
Expected result:
Double-clicking "demo.txt " should open that file with the associated text viewer/editor (or prompt to choose an app). It must not execute a different sibling file such as "demo.txt .cmd".
Actual result:
XYplorer.exe starts cmd.exe and executes "demo.txt .cmd".
Control tests:
- If "demo.txt .cmd" is removed/renamed, double-clicking "demo.txt " no longer executes any commands; instead Windows shows “Choose an app to open demo.txt ”.
- With normal filenames ("demo3.txt" and sibling "demo3.txt.cmd"), double-clicking "demo3.txt" does NOT execute the .cmd payload.
Evidence:
I attached ProcMon screenshots that show:
- Parent process: XYplorer.exe
- XYplorer.exe -> Process Create -> cmd.exe
- Command line contains:
cmd.exe /c ""C:\Users\potat\Desktop\demo\demo.txt .cmd""
- cmd.exe then creates calc.exe (PoC payload execution)
Suggested fix / direction:
Please ensure the double-click/open action operates strictly on the literal selected file path and does not resolve/normalize it into a different sibling executable/script (such as *.cmd). The issue appears related to filename parsing/normalization around trailing spaces/dots and extension handling.
Thank you for your time. I can retest any proposed fix on Windows 10/11 and provide ProcMon .PML logs if needed.
Additional note (why this is security-relevant and not just “Windows behavior”):
The user double-clicks the literal selected file "demo.txt[space]", but XYplorer spawns cmd.exe and executes the sibling "demo.txt[space].cmd". If the .cmd is removed, the same double-click only shows “Choose an app to open”, and with normal names ("demo3.txt" + "demo3.txt.cmd") no execution occurs. This indicates XYplorer’s open path is resolving/redirecting the target to a different executable when a sibling .cmd exists, which is a target confusion issue.
This is not about Windows refusing such filenames; both files exist and are accessible on NTFS. The security issue is that a UI double-click on the selected non-executable entry ("demo.txt[space]") results in XYplorer launching cmd.exe to execute a different sibling script ("...txt[space].cmd"). A file manager should never switch targets from the selected file to a different executable based on name normalization or PATHEXT-style resolution. thanks.
