ctxmenu is a desktop program. It runs as the logged-in user on a Windows PC, reads and writes the context menu's registry keys, and can send files to web services the user has entered themselves. It is not a service, has no accounts, and does not listen on any port.

Four things make it security-relevant anyway, which is why the scope is spelled out here rather than left to guessing:

• It writes to the registry, some of it under HKLM, i.e. for all accounts.
• It requests elevated privileges for that and restarts itself.
• It sends files to addresses and stores the keys for that.
• Since 1.4.0 it replaces its own executable with one it fetched from GitHub.

Only the latest release.

The project has one maintainer. There is no branch on which an older version continues to be maintained, and a table that promised otherwise would be a promise no one could keep.

Please not as a public issue. Issues are public the moment they are filed, and every reader is someone who can act on it before a fix exists.

Two private channels, both are fine:

• Private report via GitHub: in this repository's Security tab, Report a vulnerability. Preferred: report, discussion, and fix stay in one place, and you see the patch before it goes public.
• Email to stefan@knaak.org with ctxmenu security in the subject. Nothing is encrypted on the receiving end; if a detail is too sensitive for plaintext mail, please ask briefly for a different channel.

What makes a report quick to act on: the version from the About window, the Windows build, the steps to trigger it, and, if available, the excerpt from %LOCALAPPDATA%\ctxmenu\ctxmenu.log. Review the log beforehand: it names registry paths and file names from your machine.

Anything one of these sentences describes:

• A way for the program to write something other than what the user confirmed, in particular outside the registry areas it manages, or without the backup it promises.
• A way for the elevated privileges to be used for something other than the one confirmed step; any way to influence the elevated operation from the outside.
• A way for a file to be sent without the user having consented to that for this tool, or to an address other than the one entered.
• A way for a stored key to reach someone who should not otherwise be able to read it.
• A way to make the updater install something the release signature does not cover: a checksums.txt accepted without a valid signature, an asset accepted whose SHA-256 is not the one that signed file names, or any path that writes over the running executable without both of those checks. The public half of the signing key is ctxmenu/release-signing.pub.pem and is compiled into every binary; the private half is not in this repository.
• A malicious OpenAPI document or a malicious response from a service that makes the program write outside the target folder, execute something it should not, or crash.
• A backup that does not restore what it claims to contain.

• The keys are stored in plaintext in %LOCALAPPDATA%\ctxmenu\. That is intentional and documented: they are protected by the permissions on the user profile, the same as in an .npmrc or .gitconfig. Anyone who does not want that uses a key with restricted permissions. An attacker who can read your profile has already won regardless.
• The program can break the context menu. That is its purpose. It backs up beforehand and states beforehand what it will do.
• An entry can execute any command that the user writes into it. That is the function of the context menu, not a flaw in it.
• Unencrypted http://, when explicitly allowed for a favorite. The program refuses it until someone sets the checkbox.
• SmartScreen warns about the .exe. It is not signed; a certificate Windows trusts by default costs several hundred euros a year. The checksum for each release is published with the release, and since 1.4.0 so is a signature over that list of checksums. Note that these are different things: Authenticode is what Windows checks before running a downloaded file, and the release signature is what the program checks before replacing itself. The second one does not remove the first warning.
• A release older than 1.4.0 cannot be installed by the updater, because it carries no signature. That is the intended behaviour, not a gap: an asset set that is allowed to arrive incomplete is one an attacker is allowed to strip.
• Reports from a vulnerability scanner without a path showing how this applies here. A dependency with a CVE in a code path this program does not use is not a vulnerability of this program.

• Acknowledgment of receipt within three days. If nothing arrives after a week, the mail got lost, please follow up via the other channel.
• An assessment within two weeks: confirmed, not a bug, or a follow-up question.
• Credit, if you want it, in the release that fixes it.
• No money. This is a spare-time project with no revenue.