Having worked with some truly horrid C# at my first job, I've ran headlong into this problem. While I wound up leaving, in the time I spent with it I took the mindset of treating the code as a patient.
All code, no matter how awful, WTF-ridden, poorly-conceived, inadequately-implemented, or just plain bad was intended by its developers to solve a problem, with the tools they had at their disposal. Does that make the code good? Nope. Does that makes maintaining it less painful? Assuredly not. Of course, your question isn't about the developer pain; its about whether you can look at this code day-in and day-out for however long you remain employed at your current shop.
To that end, when working with code, I view it as a doctor might: an entity that is exhibiting symptoms of a particular trait.
We call symptoms of intended behaviors 'correct behavior' most of the time...except for when the reasoning behind the behavior being 'intended' is bad. When this circumstance occurs, it might be helpful to pull together something that you can present to your management to explain the behavior you're seeing, and an optimal process that would improve how the app works, and finally the minimal changeset to modify those symptoms. If all goes well, they'll approve and let you do what a developer does best: leave code in better condition than you find it. If not? It might not be so bad, they might just have a business reason (too little time, too little money).
When I encounter symptoms of an unintended behavior, I prefer to follow whatever bug-reporting workflow is in place in my shop; it's the quickest, most efficient way to inform your leaders of the problems besetting your app. In my first job, there were some issues we didn't get to address for about two months due to the nature of the industry we were operating in, but not reporting it (or worse, making rogue changes) would have had far worse side-effects, which leads to still-lower respect for your code base.
Better still, try to find constructive ways to get your managers to speed up the process by which bugs are responded to (this was a problem at that first shop of mine), because the longer you know a bug is in the wild, the less your respect for the code will be at the end of the day. Morale matters!
When I see malformed code that dosen't match standards for the language, I don't blame the code for being malformed, but I do consider the developer who wrote it; maybe they're not familiar with the language? (I encountered this case with a coworker who had zero programming experience, but a rich history as a manual tester; this person wrote some truly horrid copy/paste code that it took me weeks to stabilize.)
When you encounter this case, you have two options. If the developer is there and in easy access, make yourself available as a teaching resource; you can influence this person to write code to the standards of your language and your shop. Help them be a better developer, chances are they're having a difficult time, but are putting on a tough face and grimacing through it just like you. Better still, you can sleep easier at night knowing that the volumes of poor code will be decreasing over time, which is always welcome.
If the person isn't in easy access, or has already left, when an excuse to revise the code appears in a positive, low-risk fashion, take it. You're doing your organization a favor by being the change you want to create.
If in a few weeks you've tried all of this and still seen no improvements to your own consideration of your codebase, and to others' treatment of it, there's nothing for it: you shouldn't support something you hate, as you'll do it sub-par as to make all the symptoms I've just talked about worse. But, before you start chatting up that recruiter, make absolutely sure you've exhausted every option to improve that codebase, and to get your coworkers to do the same. I would imagine if you're cringing in this much pain, this can't be pleasurable to them, either!
