1. Code the fix while you're sitting on some pointless video call.
2. Merge the resulting fix in as part of another MR
3. In the unlikely event anyone questions you, say that you needed to make changes in that area anyway, and it'll reduce the support burden.
This requires a lot of passion and motivation from individual developers within the company. Of all things they could be slacking off with during a pointless video call, they have to choose to spend than time doing thankless bug fixing.
This is a good way to introduce regressions, particularly if you don't have the QA resources to do full regression testing each release and lack automated test coverage.
I don't say this to scold you, but I think most of us should keep in mind that even simple code changes incur risk and add testing requirements.