This is exactly why QA should be quality assistance not assurance.
When bug is found closely to release date, QA informs management. Business decides if it is a release-critical bug (and release is postponed), or not critical, and bug is added to list of known bugs and triaged for fixing.
It is business decision, not QA decision, to release a product, which likely has many other (non-release-critical) bugs.
Failure of QA was not to miss the bug, but to test critical areas well ahead of the release so such surprises will be avoided, and to get release code stable enough ahead of release to have time to do so. But again, buck stops with the management failing to develop the corporate culture prioritizing the quality, establishing processes to have automated tests for critical areas.
Quality cannot be "assured" by more diligent testing - only by consistently following the process which builds quality into the product.
What exactly you do depends of way too many variables:
- do you have one customer, or many?
- how important is the bug for majority of customers: inconvenience? are lives at risk?
- how critical is the bug for keeping good name for your brand
- how customers will be affected if release is postponed, do they have a workaround, say continuing to use old release
- how important are other features released (if ie. regulations are changing for certain date, you have to release even with release-critical bugs)
- how long it will take and how much it will cost to release new fixed release (resources)
- do you have skills to fix it, or you have to pay someone else
- etc.
Please note that many of these variables are business-related, not QA-releated.
Also see this Workplace.SE question: https://workplace.stackexchange.com/questions/62542/how-to-tell-client-about-having-missed-their-deadline - and more there.