What to do when Bug is raised which is highest priority

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+to+handle+Bugs+and+Production+Support…

Given that you are near the end of your Sprint, I would suggest not terminating the Sprint as you probably achieved some value of completing some of the stories if you have been managing work in progress successfully. Getting any value from the Sprint, is better than delivering no value.

If you read the beginning of the Sprint, and it would compromise their entire Sprint then I would advise looking into terminating it if it made sense...

Just my $.02

I agree if the PO has raised the bug with highest priority then it needs to be fixed in the current at the risk of not completing some of the backlog items. Given that you are the tail end of your sprint you are probably working on relatively lower priority items and moving them out wont be an issue.
However a few thing ...
1) In spirit of the Scrum transparency the PO should provided enough context as to why the defect is high priority.

2) Ideally defect prioritization should be a joint effort . What worked best for me was the case when I had a weekly meeting where all the defects in the backlog were reviewed . The meeting was attended by PO, SM , tech lead, SMEs , person who filed the defect and any one else who might help clarify the priority of the defect. The meeting helps in clarify the source of the defect as well as cost benefit analysis for the PO and then a joint decision was taken when to fix it or defer it to next sprint.

3) Verify that it is really a defect. Sometimes an enhancement or even product feature is disguised as bug. Again (2) above will help in clarifying this.

4) The effort is small enough. Most defect should not take more than few hours of dev time to fix. If its more then that probably its a missed requirement

I would suggest not terminating the Sprint as you probably achieved. If new sprint update is released then check out what is new in this. Follow Scrum roles and fix this bug first this is very important to implement Scrum for software.