I am having a small .NET console application that the user launches on its local machine, passing a path argument to which the application is writing a file.
Can this be considered a path traversal vulnerability?
I was thinking this is not a real vulnerability that can be exploited since the application is launched by the user supplying a path. Won't this be having the user's permissions?
Correct, at least in that use case. Path traversal, and all other forms of unsafe input, require that the client (source of the input, be it a user, web browser, etc.) want privileges that the server (thing that processes the input, could be a literal web / database server but also things like a driver or RPC service, or even another user on the same service) has. For a local app - unless the caller is sandboxed (and your app somehow isn't) - that's not the case; you have the same privileges as any software running under your account.
However, it could become a problem in the future. Maybe somebody sets up a webapp that invokes your native app. Or some privileged service consumes an untrusted user's input and passes it to your code (which is now running with the service's privileges). As such, it's generally a good idea to remove any obvious attack vectors. That's also good practice for writing any kind of client-server system, which are everywhere now.
Personally, I consider this a valid vulnerability, but the risk is significantly reduced due to the lack of impact.
Some people will say it's not a vulnerability, but is a non-compliance with best practice.
Either way, most people would recommend this be fixed.
There is no universal consensus on the definition of "vulnerability" and for some people's definition you need a material impact, while for others it's sufficient to have a violation of expected behaviour that could potentially have a security impact.
There are a number of MS command line tools vulnerable to deserialization flaws. Historically, this was considered not a vulnerability as you couldn't cross a security boundary. However, more recently, these have resurfaced as techniques that red teamers (and potentially, malicious attackers) use to bypass EDR.
