Path Traversal Vulnerability in nitroshare

Description

NitroShare Desktop v0.3.4 contains a path traversal vulnerability in its LAN file transfer server. The server listens on all network interfaces (port 40818) without authentication. When receiving files, the name field from the sender's JSON item header is passed without verifying the resolved path stays within the transfer root directory, C:\UserName\Downloads\NitroShare. An attacker on the same LAN can send a crafted filename containing ../ (classic dot dot slash attack) sequences to write files anywhere the current user has access, including the Windows Startup folder for code execution on next login (hence the POC that was created). No user interaction is required. Additionally, TLS is disabled by default (the method of authentication that the application offers), meaning that no authentication is required by default, which I assume most users will do based on years working in IT and Information Securtiy.

Steps to Reproduce

1. Connect to NitroShare's transfer server on TCP port 40818 from the LAN.
2. Send a JSON transfer header packet: {"name":"attacker","size":"<n>","count":"1"}.
3. Send a JSON item header packet with a path traversal filename:
   root@kitploit:~

   {"name":"../../AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup/payload.exe","directory":false,"created":"0","last_modified":"0","last_read":"0","size":"<n>"}
   

4. Send binary packet(s) containing the malicious file content.
5. The file is written outside the download directory to the attacker-chosen path.
6. If targeting the Startup folder, the payload executes automatically on next user login.

A working PoC is provided (poc_path_traversal_via_lan_transfer___arbitrary_file_w.py) and has been verified against NitroShare 0.3.4 on Windows.

Suggested Remediation

1. Sanitize received filenames — Strip or reject path separators (/, \) and .. sequences. After resolving with QDir::absoluteFilePath(), verify the result starts with the root transfer directory before proceeding.
2. Require a password or Enable TLS by default — Ship with TLS enabled and auto-generate certificates on first run, or create the option to have a password.
3. Add transfer approval prompt — Prompt the user before writing received files to disk.
4. Implement authentication — Require a pairing mechanism (shared secret, QR code, or certificate exchange) before accepting transfers.

Disclosure Timeline

• April 13, 2026 - Contacted developer via e-mail that was published on Github repo. No response.
• April 19, 2026 - Second Attempt. No response.
• May 3, 2026 - Third attempt. No response.
• July 22, 2026 - NotCVE-2026-0009 assigned
• July 28, 2026 - CVE-2026-66050 assigned