This is going to be a pretty by the rules answer. Before I give you that, remember that you're working with people and that if the developers and product owner have a good conversation and decide it's worth it, then who cares?

As a Professional Scrum trainer with Scrum.org, my by the book answer would be this:

The sprint backlog consists of the work selected by the developers to meet the sprint goal and their plan to deliver that work. It's their plan, their commitment, thier goal.

There are 2 people who can initiate the renegotiation of the scope.

1. The developers. For any reason that endangers the sprint goal, causes the product to be undone or when they find out they have too much or too little work, the developers can reach out to the product owner to renegotiate the scope of the sprint. The scope can usually only be changed if it does not cause the sprint goal to be endangered.
2. The product owner. The product owner can request the developers to consider changing selected work for the sprint. Ideally when the product owner has found better or alternate ways to achieve the sprint goal or when something urgent has come up which could be added to the srpint backlog without endangering the sprint goal. Ideally this would cause some other work to be removed from the sprint backlog.

A team can't infinitely add more work to the sprint. Though many teams leave some room in their plan to deal with these kinds of "unexpected issues", if they pop up regularly.

The Product Owner has one final instrument to force a scope change, they could cancel the sprint. This would cause an immediate replanning and renegotiation of the sprint goal. A Product Owner should only do this when not delivering the current sprint goal weighs up to delivering the new goal. e.g. when the sprint goal has become obsolete.

The developers could also force the hand of the product owner if the defect that was found is so severe that they would consider the product no longer in a done state. E.g. a security vulnerability is found, and it must be fixed. In that case they could opt to fix the issue as part of whatever work they're working on now. They couldn't deliver the increment otherwise, since a Scrum Team only delivers increment that adhere to the Definition of Done.

The Scrum Master's role in this is to ensure:

• That the Product Owner doesn't change scope on a whim.
• That the developers don't deliver increments that don't adhere to the Definition of Done.
• No outsider of the Scrum Team overrules the shared decision of the Scrum Team.

The Scrum Master could use the Retrospective to help the team explore why these issues happen regularly. And what could the Scrum Team do to either fix that situation or for them to be in a better form to handle these kinds of issues (e.g., fix them with far less effort and faster so that they're less of a problem). If this happens frequently and the team can't immediately resolve the cause of speed up the delivery, they could opt to leave room in their sprint plan to handle these kinds of issues by simply planning less work.

This is going to be a pretty by the rules answer. Before I give you that, remember that you're working with people and that if the developers and product owner have a good conversation and decide it's worth it, then who cares?

As a Professional Scrum trainer with Scrum.org, my by the book answer would be this:

The sprint backlog consists of the work selected by the developers to meet the sprint goal and their plan to deliver that work. It's their plan, their commitment, thier goal.

There are 2 people who can initiate the renegotiation of the scope.

1. The developers. For any reason that endangers the sprint goal, causes the product to be undone or when they find out they have too much or too little work, the developers can reach out to the product owner to renegotiate the scope of the sprint. The scope can usually only be changed if it does not cause the sprint goal to be endangered.
2. The product owner. The product owner can request the developers to consider changing selected work for the sprint. Ideally when the product owner has found better or alternate ways to achieve the sprint goal or when something urgent has come up which could be added to the srpint backlog without endangering the sprint goal. Ideally this would cause some other work to be removed from the sprint backlog.

A team can't infinitely add more work to the sprint. Though many teams leave some room in their plan to deal with these kinds of "unexpected issues", if they pop up regularly.

The Product Owner has one final instrument to force a scope change, they could cancel the sprint. This would cause an immediate replanning and renegotiation of the sprint goal. A Product Owner should only do this when not delivering the current sprint goal weighs up to delivering the new goal. e.g. when the sprint goal has become obsolete.

The developers could also force the hand of the product owner if the defect that was found is so severe that they would consider the product no longer in a done state. E.g. a security vulnerability is found, and it must be fixed. In that case they could opt to fix the issue as part of whatever work they're working on now. They couldn't deliver the increment otherwise, since a Scrum Team only delivers increment that adhere to the Definition of Done.

The Scrum Master's role in this is to ensure:

• That the Product Owner doesn't change scope on a whim.
• That the developers don't deliver increments that don't adhere to the Definition of Done.
• No outsider of the Scrum Team overrules the shared decision of the Scrum Team.

The Scrum Master could use the Retrospective to help the team explore why these issues happen regularly. And what could the Scrum Team do to either fix that situation or for them to be in a better form to handle these kinds of issues (e.g., fix them with far less effort and faster so that they're less of a problem). If this happens frequently and the team can't immediately resolve the cause or speed up the delivery, they could opt to leave room in their sprint plan to handle these kinds of issues by simply planning less work.