What you're describing isn't technically Scrum; it violates several key Scrum and agile principles. If your Scrum-like process allows for changes in scope or level of effort within an iteration in ways that routinely impact the Sprint Goal, then you will have to reduce your forecast for each Sprint to account for the defects and uncertainty introduced by your process.
You appear to be conflating bugs/defects with new work, because the following is an agile oxymoron (emphasis mine):
When we have a story which can pass but produces a defect to be fixed, the PO or BA involved will usually write a new story and immediately insert it into the sprint on the basis that it is important enough because it is a business priority.
By definition, you can't have a story that meets a reasonable Definition of Done (DoD) but is also "defective." Depending on the DoD agreed upon between the Development Team and the Product Owner, a story could possibly be "Done" while generating technical debt or iterative improvements that need to be addressed in a future Sprint, but cannot result in an unreleasable increment because of serious bugs, defects, or regressions.
In other words, if the issues identified are serious enough that they must be resolved before the increment can be released, the increment can't be considered "done." On the other hand, if the issues don't prevent the increment from being considered as releasable by the Development Team or the Product Owner (or according to the agreed-upon Definition of Done), then the issue is new work that must be placed onto the Product Backlog and scheduled for a future iteration.
The team should undertake the following action items as part of the framework's ongoing inspect-and-adapt cycle:
Ensure that each Sprint has a cohesive Sprint Goal that ties the work together with a clear scope and a focused objective.
Ensure that only the Development Team is able to add work directly to the Sprint Backlog.
Ensure that any reviews performed by the business analysts or Product Owner as part of the acceptance criteria for stories are:
- Part of the formal Definition of Done.
- Included in the estimation of each story.
Create a project definition that distinguishes clearly between bugs/defects and new work in order to prevent scope creep.
Reframe your Sprint process as a way to plan and scope work in cycles, as opposed to treating is as a way to task the team with work.
What all of these items have in common is that they work together to ensure that each Sprint is treated as a time box in which the team can develop a potentially-releasable increment. Because Scrum is an iterative development methodology, the underlying principle is that all work must be scoped for, planned, and delivered in tightly-bound time boxes. Any practice that puts Sprint Goals in jeopardy or that doesn't respect the time box is an anti-pattern, and should be dealt with in the team's Sprint Retrospectives and other inspect-and-adapt ceremonies.