Scrum is an agile framework that embraces changing requirements, but the framework has rules for how and when changes can be introduced. Minor changes should be deferred, while drastic changes should trigger an Early Termination of the current Sprint.
One option is to defer changes until the next Sprint Planning session. Every Sprint starts a new cycle of prioritization and planning, so it's perfectly acceptable to complete a Sprint and then change the project's direction, scope, or priorities.
The idea with deferment is to provide change control by preventing changes in scope or deliverables from occurring within the current iteration. If the current Sprint Goal and user stories will still provide value, then the new work should be deferred until the Product Owner prioritizes it for a future Sprint.
Another option is early termination of the Sprint. If the current Sprint Goal no longer provides value to the Product Owner, or the changes are so drastic that they invalidate the current user stories, then the Product Owner may call for an Early Termination and an immediate return to Sprint Planning.
This has a cost to the project, both in terms of process overhead and lost work. That is why it is the Product Owner's decision: the Product Owner is responsible for determining what user stories have value to the project, and using the Product Backlog to allocate resources. If the benefit of failing early outweighs the cost of abandoning the current iteration, then it's generally in the project's best interest to avoid additional sunk costs.