This appears to require attacker controlled data already being written to a settings XML file in specific locations on disk.
Put simply, this requires another prerequisite arbitrary file write vulnerability to be reachable.
This isn’t “zero click” unless we’re going under the assumption that an attacker already has full control over my machine before that. At best, this is a persistence mechanism, not initial access.
This is a little bit 'if you can execute code as a user you can execute code as a user'. All of the exploit pathways involve capabilities that would give you any number of paths to code execution. The check should probably be fixed but I question whether it's really doing much in the first place.
RCE... not really. CE yes, but the Code being Executed needs to be separately supplied and you need local permissions so there is nothing Remote about it. It's not that you exploit Np++ upon opening your malicious file or so (and even that would be neither network-bound nor zero-click!).
Steps to reproduce:
1. Place a malicious file on disk (e.g. ~/Downloads/definitely_legit.exe)
2. Modify shortcuts.xml (in the user's %AppData%, requiring local user permissions) to point to this file in a special way
3. The shortcut triggers and runs the exe when the user next starts and uses Notepad++ (the user needs to trigger the shortcut, but that can be something that they will do anyway such as typing any key)
This functionality is by design, but by prefixing a trusted path and then /../'ing your way back out of the trusted location, it doesn't show a warning before executing
Vulnerability rated as high because of the impact, despite the near-impossible exploitability. The CVSS vector for "email the user a malicious file and have them save and execute it", not bothering with the whole shortcuts method, would result in an even higher rating...
How is this supposed to be zero-click? All attack scenarios require either the attacker to modify configuration files, or the user to click on a malicious shortcut.
> either the attacker to modify configuration files, or the user to click on a malicious shortcut.
don't you mean "x and y" instead of "either x or y"?
It's not triggered by a default-configured shortcut, you need both modifying of the shortcuts definition file and the target user to trigger it. Notably, modifying the shortcuts definition file requires a permission level equal to or higher than the user has
OP, I assume your comment[1] is getting flagged because of the obvious LLM usage. No one wants to interact with a comment that's not written by a human.
Or it's more that people recognize that this isn't a "Zero-Click RCE" and we're tired of people trying to claim that every damn bug is a huge security risk.
If an attacker can already either modify the existing shortcuts.xml file or convince me to download and run a .lnk file that links to a different one they managed to get onto my computer then they don't need to use Notepad++ to do their dirty work.
It's just sad that these kind of bugs still slip through. So many people lack the ability to come up with the most straightforward edge cases for their validation code.
To me it feels like people who build LEGO their whole lives but never once stray away from the step-by-step manual and never have built something "outside the box".
“Zero-Click RCE”
This appears to require attacker controlled data already being written to a settings XML file in specific locations on disk.
Put simply, this requires another prerequisite arbitrary file write vulnerability to be reachable.
This isn’t “zero click” unless we’re going under the assumption that an attacker already has full control over my machine before that. At best, this is a persistence mechanism, not initial access.
We are living through CVE-inflation (or CVEflation?) where anyone who discovers a bug using LLMs will instantly claim it is huge security hole.
This is a third bug that emerged following a maintainer fix. If you check my profile, you might be able to reconsider your statement.
This is a little bit 'if you can execute code as a user you can execute code as a user'. All of the exploit pathways involve capabilities that would give you any number of paths to code execution. The check should probably be fixed but I question whether it's really doing much in the first place.
RCE... not really. CE yes, but the Code being Executed needs to be separately supplied and you need local permissions so there is nothing Remote about it. It's not that you exploit Np++ upon opening your malicious file or so (and even that would be neither network-bound nor zero-click!).
Steps to reproduce:
1. Place a malicious file on disk (e.g. ~/Downloads/definitely_legit.exe)
2. Modify shortcuts.xml (in the user's %AppData%, requiring local user permissions) to point to this file in a special way
3. The shortcut triggers and runs the exe when the user next starts and uses Notepad++ (the user needs to trigger the shortcut, but that can be something that they will do anyway such as typing any key)
This functionality is by design, but by prefixing a trusted path and then /../'ing your way back out of the trusted location, it doesn't show a warning before executing
Vulnerability rated as high because of the impact, despite the near-impossible exploitability. The CVSS vector for "email the user a malicious file and have them save and execute it", not bothering with the whole shortcuts method, would result in an even higher rating...
Steps to reproduce:
1. Get pwned
2. Open Notepad++
3. Get pwned again (?)
I have a similar RCE for Midnight Commander.
1. Download my virus
2. Open Midnight Commander
3. Launch virus via MC.
How is this supposed to be zero-click? All attack scenarios require either the attacker to modify configuration files, or the user to click on a malicious shortcut.
> either the attacker to modify configuration files, or the user to click on a malicious shortcut.
don't you mean "x and y" instead of "either x or y"?
It's not triggered by a default-configured shortcut, you need both modifying of the shortcuts definition file and the target user to trigger it. Notably, modifying the shortcuts definition file requires a permission level equal to or higher than the user has
No interactio needed from the user, presuming the attacker can already modify files and execute commands!
OP, I assume your comment[1] is getting flagged because of the obvious LLM usage. No one wants to interact with a comment that's not written by a human.
[1]: https://news.ycombinator.com/item?id=48473753
Or it's more that people recognize that this isn't a "Zero-Click RCE" and we're tired of people trying to claim that every damn bug is a huge security risk.
If an attacker can already either modify the existing shortcuts.xml file or convince me to download and run a .lnk file that links to a different one they managed to get onto my computer then they don't need to use Notepad++ to do their dirty work.
Local attack vector without privilege escalation should downgrade cve from high to low, and moderate to 'not a cve'.
malicious attackers can unlock your door from the inside. fear and panic!
[flagged]
It's just sad that these kind of bugs still slip through. So many people lack the ability to come up with the most straightforward edge cases for their validation code.
To me it feels like people who build LEGO their whole lives but never once stray away from the step-by-step manual and never have built something "outside the box".