Installer launches XYplorer with admin privileges → unintended admin sessions

[Basel Shishani]

I ran into a confusing (and potentially risky) behaviour during a fresh install.

What happened

• The installer does not request administrator rights itself; it tells you to run it as administrator.
• I ran the installer with administrator privileges.
• After install, the “Launch XYplorer” checkbox was ticked → XYplorer auto-started.
• That instance inherited the administrator privileges from the installer.

No new security prompt appears at that stage, so it’s easy to miss that XYplorer is now running with administrator rights.

Why this matters
XYplorer is a file manager and a launcher. When it runs with administrator privileges:

• anything launched from it (Command Prompt, PowerShell, scripts) inherits administrator rights
• file operations occur with full system access
• there’s no clear indication tied to the action (the elevation happened earlier)

Concrete example (custom command)
I created a simple custom command to open Command Prompt in the current folder:

Code: Select all

// Run Script
run "cmd.exe /k cd /d ""<curpath>"""

When triggered from the auto-launched XYplorer:

• Command Prompt opened already with administrator rights
• no security prompt was shown
• administrator-only operations (e.g., sc stop spooler) succeeded

From a normally launched XYplorer instance, the same command opens a non-elevated Command Prompt, as expected.

Expected behaviour (typical Windows pattern)

• Installer requests administrator rights directly (clear system prompt)
• After installation, the application launches without administrator rights, or does not auto-launch

Observed behaviour

• Installer with administrator rights → auto-launched XYplorer continues with those privileges (implicit)

Why it’s problematic

• breaks least-privilege expectations
• creates hidden elevated state
• increases risk of unintended system changes

Suggestion

• Do not auto-launch XYplorer from an elevated installer, or
• Relaunch it without administrator rights after install, or
• Clearly indicate elevated state in the interface/title

This would align with standard Windows behaviour and reduce confusion.

Edit
The script that worked for launching an admin cmd prompt:

Code: Select all

 opencommandprompt , , , 1 

[admin]

It's all true, but this is just how Windows is designed. The child process automatically gets the parent's rights. I can't change it.

It might be a good idea though to add a clear "admin" mark somewhere if XY is running with admin privileges.