Some sort of group recognition of the efforts of a team member can be a valuable motivator, but in this case it sounds like it's being misapplied. You state that the MVP is chosen by vote, but there's a lot of mentions of numbers of bugs fixed per sprint. It sounds like your time has a funny definition of MVP - I would assume that the person who deserves the title of "most valuable" is the person who added most value to the software in that sprint. If a team member is picking out bugs that can be fixed quickly, blasting through them as fast as possible, and causing regression bugs and other problems in their wake, then they're not adding value, they're creating more work for whoever has to follow them around identifying and fixing those problems.
My suggestion would be to try to start a proper discussion the next time your team has one of these votes. Don't just make it a show of hands; talk it through first. If someone seems to be gaining votes based on the sheer number of "fixes" they've made, point out (tactfully) where those fixes caused regressions, and suggest that perhaps the person who fixed those regressions should be nominated for cleaning up other people's mess. If someone spent the whole sprint slaving away on one nasty issue, point that out to the team, highlighting the fact that although this person's fix count is one, they've single-handedly solved a major problem with your software - a problem that was so nasty that nobody else wanted to touch it.
Picking out easy fixes and doing them in a rushed or haphazard manner isn't valuable, so developers who just do that probably shouldn't qualify as MVP candidates. When selecting the new MVP, forget all about the team and the people on it, and look at the software. Pick out the single most important change in that software since the last time. I mean single here; "not as many tiny bugs" is not a major change. Has a particularly glaring bug been fixed? Has a great new feature been added? Once you've identified what this one big change is, ask who was responsible for it. One of those people is probably your actual MVP. If "not as many tiny bugs" is the only difference, then and only then is bug count a valid measure of MVP - and even then, I'd look at ratio of bugs fixed to regression bugs caused. Every bug someone causes deducts at least 1 from their count. In fact, I'd say more than 1, because a bad fix will cause an unknown bug that you then have to find, which is worse than a known bug that's been found already. A known bug takes developer effort to fix; an unknown bug takes QA effort to find, and developer effort to fix, and then there's the risk that QA will miss it.
In theory, if developers realise that the way to the prize is to fix fewer, bigger problems, they'll aim for the tough ones, the complex ones, the blocking defects. This will require them to band together sometimes, either because there aren't enough meaty problems to go around, or because the problem is tricky enough to require more sets of eyes. Perhaps suggest that in cases like this, the award could be shared if it's not immediately clear which of a set of people did more work towards fixing a bug - and remember, work done != lines of code written. The developers will probably know that, but you said management is involved, and management don't always understand that point.
And hey, if all else fails, forget the MVP program. Talk to your fellow developers outside of the scrums, and point out the negative impact that the MVP awards are having on the software. See if you can get them to ignore it, or not make it such a big deal. Leave the trophy in a drawer, spend the cash prize on a round of drinks for the team after work, use the free lunch to get something you can share, like a bunch of cupcakes. Agile is a team system; highlighting individual performance risks pitting the team against each other. United you stand, divided you ship bug-filled software, after the deadline, over-budget.