I like to quip that there are no "bugs" in agile development. The formal concept of a Bug, which developers were afraid of, and everybody tried to hush-hush, and customers loved to blame the devs and let them fix it in their spare time is a relic of the old times of fixed-price, fixed-scope, fixed-time waterfall project management.
In the agile world, which you are presumably working in, based on your mention of 2-week sprints, bugs are the same as everything else; they begin life as a story (or whatever name you like to use) in the product backlog, eventually make their way into a sprint backlog, and finally get fixed and deployed. Even if you're not using SCRUM, where this particular terminology comes from, all agile process have these concepts in some form or other.
If someone starts talking about getting bugs fixed for free, this is a great time to point out that in exchange for treating bug-fixes like regular work, customers get the benefit of quick turnarounds for their implementations - we do not require them to write a 1000 page requirement book anymore and deliver in very quick succession.
So for you, this means that you simply write down everything there is to say on this bug in your task tracking system, whichever it may be; then you present it to the usual people (your PO, the team, etc.) in the relevant meetings that you regularly have (say, in a daily, or a refinement session). You can talk with your PO at any time (you do not need to wait for an official sprint event), of course, as can every other stakeholder.
Obviously, same as stories having different priorities, you can give a priority to this one. If you think it's really blatant (like a possibility of the VISA data of your customers being shown on a public web site...), then you would handle it differently than a minor code smell with a distant possibility of some attacker with deep knowledge of your code misusing it.
Note that even in the agile world, there is a separate concept called "incident". This is not a bug, and not a story, but something which inflicts problems on a production system and needs to be fixed right now (i.e., database down, "Error 500" on the login page, and so on). If your bug is of this calibre, then you would obviously do differently - follow your incident process instead of your story process.