The team need to work on the bug, and explain to the Product Owner that the planned Sprint Goal is likely to be compromised as a result of this action. It sounds as though the PO already knows this.
Alternatively, the Product Owner has the option of terminating the Sprint now, working with the team to release the maximum value possible from the work that has been completed, and asking the team to use the remaining portion of the timebox to work on fixing the defect.
Terminating a Sprint is a drastic option. It usually makes more sense to work on the bug and revise the Sprint Backlog accordingly. The Sprint Backlog is essentially a forecast; it is understood that unplanned critical events can occur mid-sprint and that teams must accommodate them. The important thing is to make sure that the root cause of the defect is understood so that the team can adapt accordingly, and thereby make similar problems less likely to happen again. The Sprint Retrospective is a suitable inspect-and-adapt event for this purpose.
The Bradley Bug Chart goes through these scenarios: http://www.scrumcrazy.com/One+way+t...t+in+Scrum