DISCLAIMER: I have not yet had experience with user-reported bug priority shenanigans. I know the question asks for this, but it might help having the perspective of an outsider.

Your problem is not that you have too many high-priority bugs. Your problem is that you have too many people who have direct control over pug priority. If every user can directly assign a priority to their bug, they will almost automatically report their issue as high priority.

You could make it so bug priority has to be configured by a manager or a helpdesk drone, but this could lead to favoritism and social engineering, where a client gets artificially higher priority because of their status or because they know how to craft their messages to make them seem more important. It is also a lot more labor-intensive.

There is a middle ground, where your users have some control over the priority, but in a way that makes it harder to exploit the system. Essentially, you force your users to use a template for reporting bugs. They first select a category:

1. The program becomes unusable or crashes when I do something.
2. The program has a graphical defect that affects functionality.
3. The program does not allow me to do something I should be able to do.
   The program allows me to do something I shouldn't be able to do.
4. The program gives the wrong result when I do something.
5. The program takes too long to do something.
6. The program has a graphical defect that does not affect functionality.
7. The program has a defect that does not fit in one of the above categories.

To give examples:

1. My iPhone crashes when I receive a message containing Hebrew symbols.
2. My Android lock screen is rotated in such a way that half of it falls of the screen.
3. My Android phone sometimes doesn't accept my lockscreen code, even though I entered the right code.
4. When I try to navigate to PhoneHub.net, my phone redirects me to an adult site.
5. When I open the Facebook app, it takes a minute to open, even on fast connections and with no other apps running.
6. Your app has a spelling error.
7. I found a security defect in your program and would like to report it.

As you can see, each of these errors has a different grade of severity, and the categories are roughly ordered based on this severity. You can then assign each bug a priority based on the category, who reports it and keywords that appear in the description. Bugs in category 7 should get their priority assigned manually.

Note that this can happen fully automatically, and you should let this happen automatically; in fact automation is the key here. Users are prone to overestimating their own importance to the business, so they don't see an issue in reporting their bugs as a higher priority than they should. they're less inclined to deliberately place their bug in a different category, because that requires them to basically lie about the bug.

Users might still enter their bugs in the wrong category of course. The first thing you should do is, from version 1.0, show a friendly message encouraging users to provide accurate information about the bug to help the developers to find and fix it faster. Most users will understand and stop misreporting bugs. Some users might still continue providing wrong information. When that happens, send those users a gentle reminder via mail that accurate information is important and to please not abuse the system. If they continue falsifying records, you give them a warning that they're willfully abusing the system and continued abuse will result in their bugs automatically being assigned a lower category. If they persist, you can adjust their bug multiplier.

You can see parts of this system in place in high-throughput support situations: giant tech companies like Microsoft, Facebook, Google, Gaming companies with a lot of users like Valve and Blizzard, certain governments,... While I'm not sure of the workings behind the scene, you notice that their user-facing support system has a similar interface to what I suggest here, with a strict category system.