There are three things to consider: Sprint length, Sprint Planning, and Product Ownership.
One of the determining factors in Sprint length is the ability to synchronize with the business or stakeholders. You want them to be long enough such that you can get value-added work done, but short enough to be able to incorporate valuable feedback. You also need them to be long enough to allow stakeholders to generate feedback, but not have to wait a long time to get an Increment with the feedback incorporated. In your case, perhaps a 3 week Sprint is too long - if feedback comes in very early after Sprint Planning, the stakeholders may be waiting nearly 6 weeks to see that particular feedback delivered.
Another common piece of advice is to not allocate 100% of your Sprint to the Sprint Goal. Consider that the Sprint Goal is what the team is committing to delivering to the stakeholders. If your entire Sprint capacity is dedicated to the Sprint Goal, you have no way to handle things that come up, such as team members needing to take time off without warning or production issues that require immediate attention or minor changes to the Sprint Backlog based on feedback. A rule of thumb that I've seen and encourage applied is between 60-70%, as a maximum, of the Sprint Backlog should be related to the Sprint Goal. If your organization frequently has the team handling emergent issues, you can consider dedicating even less of the Sprint Backlog to the Sprint Goal.
The third point is Product Ownership. The Product Owner needs the ultimate authority to order the Product Backlog, which often means the ability to say no to stakeholders. However, having a Sprint length that better supports synchronization with stakeholders outside of the Scrum Team and a Sprint Backlog that is more forgiving to emergent issues can both help the Product Owner and the Development Team support changes while still being able to give reasonable forecasts and then reflecting back on the forecasts.
This also sounds like a good opportunity for the team's Scrum Master to teach the stakeholders about the value of iterative and incremental development, empiricism, and the strengths of Agile Software Development and Scrum.