One of the core tenets of Agile is that it is more important to figure out what works for the team than to blindly follow the rules. Yes, the "rule" is that you never take in work mid-sprint.
The reality is sometimes messier. If a critical defect comes in, and maybe a flaw is costing you money, or opening your company up to liability, or leaving an opening for hackers, or disabling a fundamental feature, you damn well fix it now, rules be damned.
In all of these cases, though, you should always consider "rollback" as the preferred option. This is not just because of the Agile process. It is also because rushed hotfixes are a common way to create even more disastrous defect. (I could tell stories...)
There are then two important things to consider.
1) You have to make sure this only happens for critical defects, not "the senior VP doesn't like the color of the background". This of course gets a little harder if you are in the habit of patching critical issues. So obviously the solution is to never get into this situation in the first place. This is why Agile puts such a strong emphasis on automated testing. If you have a truly robust CI and testing infrastructure, you should only see these sort of hotfix situations once in a blue moon.
2) How do you account for the work? That's easier. You did work, so you have a story. You point the story. It's included in the velocity. But of course as mentioned above, this should be uncommon.