How do you deal with bugs coming constantly to the backlog?

Several problems need to be addressed.

It is crucial that all stakeholders respect the Product Owner's decisions. The Product Owner is accountable for managing the Product Backlog. Although the Product Owner may choose to delegate certain tasks, such as creating Product Backlog Items, to other people, the Product Owner is the person who must make sure that the Product Backlog offers visibility and transparency into the work planned for the Scrum Team, that all Product Backlog Items are clear and understood by stakeholders, and that the work is appropriately ordered considering the needs of all stakeholders.

Some stakeholders do not understand the Product Owner's role or the importance of having a single voice to make decisions about delivering value through product development activities. The Scrum Master is accountable for, among other things, helping the organization understand the fundamentals of developing complex products and removing any barriers between the Scrum Team (including the Product Owner) and stakeholders.

Unfortunately, the Scrum Master does not seem to have accountability for their work. If your organizational leadership sees the value in adaptive and agile methods such as Scrum, perhaps they can assist in resolving this problem. However, although I would expect that the Scrum Master would facilitate any teaching or coaching about agile methods and the Scrum framework, it doesn't require the Scrum Master. The Product Owner can, on their own, educate stakeholders about the role and its value to the team, the organization, and the stakeholders.

Another problem to solve is the existence of reported defects. Stakeholders reporting issues with the product indicate other problems, such as missing requirements, failure to understand stakeholder requirements, or design errors. I recommend that teams perform root cause analysis on at least a subset of reported issues to understand why customers report them and change their ways of working to prevent them.

I would be cautious with requiring people to find the original requirement to report a defect. Missing or misunderstood requirements can make it difficult or impossible to point to a source. I would treat every reported issue as a desired change to the system and evaluate it. Given the product vision and intended use, the change can be ordered in the backlog if it is valid. Requests that aren't valid because they violate the vision or intended use can be deferred or rejected.

If the increments being produced by the Developers are defective, it's the Definition of Done which needs to be improved. That's the first thing to do.

Escalation is rarely enough to overcome organizational gravity. Find out who in the company actually wants better outcomes, and will establish a sense of urgency for the Scrum Framework to be implemented, so gravity is overcome. That includes the Scrum accountabilities which have so far been abdicated.

@Ian Mitchell, thanks for your comments. What if it's the business who creates the tickets with their acceptance criteria?, if there is a Sprint review they should be there to see if everything is working as expected, right?. The another question I have is if every acceptance criteria should be presented by devs in the Sprint Review in order to see if all these are working.

What if it's the business who creates the tickets with their acceptance criteria?, if there is a Sprint review they should be there to see if everything is working as expected, right?.

No, the work on the Sprint Backlog is a forecast of what is needed to meet the Sprint Goal. If the Developers require clarification about any items in the forecast, stakeholders in the business ought to make themselves available.

By the time of a Sprint Review, everyone ought to be assured that the Sprint Goal has been met, that the Increment is Done, and that it is not only working but ideally already in use. Stakeholders in the Sprint Review -- should they be invited -- are there to help update the Product Backlog with the latest business intelligence and market feedback.

They create tickets themwelves setting the prio to Highest or High including bugs. They don't understand reasons why I as Product Owner set the one or another to a lower priority. I had to escalate, one of the people I escalated to is the Scrum Master, who unfortunately doesn't communicate with me or is cooperative with me. But I also escalated this to my manager and the manager of the development team.

I would suggest you do a defect triage meeting with the required stakeholders (business, Scrum master and development team members needed). Ensure you have a list of bugs which need to be fixed in the upcoming sprint and the team needs to make a buffer to fix these during the next sprint.

In the retrospective discuss on why we have so many defects (should the definition of done be updated). 

Also set up a process with stakeholders where you as a PO can discuss new requirements with them and together prioritize these new requests. Once they start trusting you, you can ask them not to enter request themselves and let it go through you first.

In short you should work on increasing  the magnitude of your role as product owner within this business and establishing better ties with stakeholders (managers, sponsors, etc). In 90% organizations using Scrum or its sub versions they either don't know about framework provisions, or don't even want to know.

Good practical advice would be to create some sort of stakeholders map, listing their characters, power, attitudes and knowledge, and then think of adapting best way to set up some sort of facilitation allowing you to communicate with them frequently and establish yourself within an organisation.

Try to establish how THEY see a Product owner? In different orgs where knowledge and appetite for Scrum is low, and framework is only implemented because CEO said so(or because everyone else does it) roles of SM and PO are often misinterpreted as team leader, product manager, backlog administrator, salesman or even some sort of secretary. Make sure your stakeholders understand the provisions of your role, and responsibilities and powers which come with it, using diplomacy and facilitation techniques which apply.

On a team level please stay closer to developers, win their trust and respect. They are most knowledgeable about product, and also can be very helpful in solving technical backlog-JIRA problems together with you. Depending on knowledge of tech domain you can approach them from the position of expert, or position of underdog, which is often more beneficial.