You're not speaking of a bug that has no technical solution, but of one that the company at this time doesn't intend to solve.
It would probably be better to change the question's title, to something like "How to report a bug that I know the company currently doesn't want to solve".
The question as is written now can be read as if you're required to solve the problem before you can file a bug ticket for it.
I'm pretty sure it's not so (if it is your company is demented), and what you mean is that you need to provide a solution proposal.
What to do
If so, in general the fact that you know that the problem is not going to be solved for the time being should not thwart your filing of the bug in any way.
A problem remains a problem even if there's no budget to fix it at this time, and filing a bug for it is useful in that:
- It documents the problem. Although it's not very likely that every user of the product will check its bug filings before using it, there's a chance that someone will and he will become aware that he needs to keep this problem into account when using the product.
- It increases a lot the likelihood that it will get fixed in the future: the bug ticket will be seen frequently by the developers, every time they will think a little about it and:
- at a certain point some of them might have formed such a good idea about how to fix it that it will have become quick and cheap to do it, and so it will be probably get done.
- there might be times in your product's lifecycle when all the existing bug are reconsidered for fixing (for example when working towards a new major release).
At those times there's a good chance that there will be time/budget for fixing the problem in subject, but if it hasn't a bug entry most likely no one will know about it and so that won't happen.
There's a chance that someone will remember it and bring about it even if it doesn't have a bug entry, but it's not very likely.
Note that even projects that are born with a short lifetime, where you don't expect to ever get back to fix the remaining bugs, very frequently live much longer, and so bug reports will have more usefulness than you anticipate.
Further report of temporary mitigation
However, knowing that the bug won't be fixed at this time can still be a useful information for you:
all right, there's no budget/time to fix the problem properly at this time, but then there's frequently some cheap temporary mitigation that can be done to protect against it: in this case, most likely you can warn the users in the documentation and/or in a warning at the time when the file has to be specified.
This is not an alternative solution, as it would most likely be better to have proper, safe validation inside the software; so, you should still file a bug with the request for complete validation, but you should also report a request for the addition of warnings in the documentation and/or in the input process.
You'll most likely need to file a separate bug entry for this (unless your bug tracking system supports specifying temporary mitigations in the same ticket - I don't know any that do).
Note that if the the problem might cause security issues publicizing it to the users might no be a great idea: if the application is an internal one it's most likely ok, if you are not too much concerned with insider threats, otherwise it's probably better not to.
However, I'm sure no company would ever release a software with known security bugs! (need a thousand ROTFL gifs here)