[Security] Everything.exe double-click on crafted filename "demo." executes sibling "demo.cmd" via cmd.exe (target confu

[hamm]

Title:
[Security] Everything.exe double-click on crafted filename "demo." executes sibling "demo.cmd" via cmd.exe (target confusion -> command execution)

Body:
Hello Everything developers,

I would like to report a potential security vulnerability in Everything (Everything.exe). When a crafted filename is used (a dot at the end of the name), double-clicking a file that visually appears to be a harmless 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):
- Everything 1.4.1.1030 for Windows:
- Everything-1.4.1.1030.x86-Setup.exe
- Everything-1.4.1.1030.x64-Setup.exe
- Everything-1.4.1.1030.x86.Lite-Setup.exe
- Everything-1.4.1.1030.x64.Lite-Setup.exe
- Everything-1.4.1.1030.x86.msi
- Everything-1.4.1.1030.x64.msi
- Everything-1.4.1.1030.x86.Lite.msi
- Everything-1.4.1.1030.x64.Lite.msi
- Everything-1.4.1.1030.x86.en-US-Setup.exe
- Everything-1.4.1.1030.x64.en-US-Setup.exe
- Everything-1.4.1.1030.x86.zip
- Everything-1.4.1.1030.x64.zip
- Everything-1.4.1.1030.x86.Lite.zip
- Everything-1.4.1.1030.x64.Lite.zip
- Everything-1.4.1.1030.ARM.zip
- Everything-1.4.1.1030.ARM64.zip
- Everything-1.4.1.1030.x86.en-US.zip
- Everything-1.4.1.1030.x64.en-US.zip
- Everything-1.4.1.1030.ARM.en-US.zip
- Everything-1.4.1.1030.ARM64.en-US.zip
- Windows 10 and Windows 11 (both confirmed)

Component:
- Everything (Everything.exe)

Summary:
Double-clicking the file:
C:\Users\potat\Desktop\demo\demo.
(note: the filename contains a trailing dot)
causes Everything.exe to execute:
C:\Users\potat\Desktop\demo\demo.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 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 dot in the name):
cmd /c 'type nul > "\\?\%CD%\demo."'
3) Create a sibling script file in the same folder:
cmd /c 'echo start calc> "\\?\%CD%\demo.cmd"'
4) Open the folder in Everything (Everything.exe).
5) Double-click "demo.".
6) Observe:
- calc.exe is launched.

Expected result:
Double-clicking "demo." should open that file with the associated viewer/editor (or prompt to choose an app). It must not execute a different sibling file such as "demo.cmd".

Actual result:
Everything.exe starts cmd.exe and executes "demo.cmd".

Control tests:
- If "demo.cmd" is removed/renamed, double-clicking "demo." no longer executes any commands; instead Windows shows “Choose an app to open demo.”.
- 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: Everything.exe
- Everything.exe -> Process Create -> cmd.exe
- Command line contains:
cmd.exe /c ""C:\Users\potat\Desktop\demo\demo.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 dots/spaces 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.[dot]", but Everything spawns cmd.exe and executes the sibling "demo.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 Everything’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.[dot]") results in Everything launching cmd.exe to execute a different sibling script ("...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.

[void]

It's an issue with the Shell.
Specifically, ShellExecute.

Start -> Run has the same issue.

I will look into a work around.
Thanks for the issue report.

[Phlashman]

This is the normal expected Windows behavior....

If you do a google search with "windows start run defaults to .cmd extension"

the AI overview gives an explanation as to why it is executing the .cmd file

[hamm]

Thanks for the quick confirmation.

I agree the root cause is in Windows ShellExecute / shell resolution (Start->Run reproduces it as well). However, from a security perspective the issue still matters in Everything because Everything’s UI double-click is the trigger that turns a user’s selection (“demo.”) into execution of a different sibling script (“demo.cmd”).

Expected behavior for a file manager/search tool is: double-click should open the literal selected object, or show “Choose an app / no association”. It should not silently execute a different file due to shell/PATHEXT-style resolution.

So even if this is a Windows shell quirk, Everything can still mitigate it (e.g., refuse/warn when the selected name contains trailing dots/spaces or when resolution would change the effective target type), which would prevent the click-to-execute scenario in Everything.

I’m happy to provide ProcMon traces and an “Explorer vs Everything” comparison note to support a robust fix/workaround.

[hamm]

Based on the three ProcMon screenshots, this is not something that can be dismissed as “just Windows behavior” without acknowledging the product-side security impact in Everything. In Everything’s UI I double-click the decoy file **"demo.txt␠"** (note the trailing space), but the actual outcome is execution of the sibling script **"demo.txt␠.cmd"**. This is a classic **target confusion / UI-to-execution mismatch**: the user-selected target A results in executing a different target B.

The evidence is a closed chain:

- In the filtered ProcMon trace, the **parent process is Everything.exe**, not explorer.exe and not a user-launched cmd.exe. Screenshot #2 shows a **Process Create** event where **Everything.exe** creates **C:\Windows\System32\cmd.exe** with the command line:
`cmd.exe /c "C:\Users\potat\Desktop\demo\demo.txt .cmd"`
This proves the execution is triggered from Everything’s double-click/open flow.

- Screenshot #3 (stack trace) shows the call path goes through **windows.storage.dll!RealShellExecuteExA** (ShellExecute semantics) and then into the CreateProcess chain. This may explain the underlying mechanism (ShellExecute resolution/association), but it also confirms that **Everything is the component initiating and delegating the “open” action** in a way that leads to script execution.

- Screenshot #1 shows Everything.exe performing file operations against the script path during the same interaction, which is consistent with Everything’s open logic touching the .cmd target as part of this workflow.

Importantly, the expected UX for double-clicking the selected file **"demo.txt␠"** should be either:
- open the literal selected object, or
- show “No association / Choose an app (Open with…)”
but it should never silently execute a different sibling script due to normalization/PATHEXT-style resolution.

Therefore, even if the root cause involves Windows ShellExecute behavior, this remains a security issue in Everything because it manifests through Everything’s UI and can be mitigated on the application side (e.g., refuse/warn/force Open With when trailing spaces/dots are present or when resolution would change the effective target, and ensure the opened/exec’d target is strictly the literal selected path). This prevents the click-to-execute scenario inside Everything.

[void]

Everything executing the wrong file is a security issue and I will have a workaround in the next update.

The real issue is the shell failing to create a normal PIDL for a file ending with a dot (.)
Everything will fall back to shell execute if a normal PIDL cannot be created.

[therube]

Windows 10 and Windows 11 (both confirmed)

Appears Win7 is not affected by this.
.
Screenshot here, viewtopic.php?p=79810#p79810.

[void]

This issue also applies to Windows 7.

[void]

Everything-1.4.1.1032 will no longer execute

demo.cmd

when launching

demo.

[therube]

Oh, so Everything 1.4 IS affected - even in Windows 7.


(I had only tested Everything 1.5.)
So is it so that Everything 1.5 was never affected?


(I'll also note that Everything 1.4 does not "see" the (.) file's size/date
- Everything 1.5 does.)

[void]

The issue applies to Everything 1.5.0.1404a and earlier.
The issue will be fixed in Everything 1.5.0.1405a.

[void]

Everything 1.5.0.1405a will no longer execute

demo.cmd

when launching

demo.