You aren't properly differentiating between stories (or, more canonically, Product Backlog Items), tasks, and chores. You are also failing to differentiate between bugs, defects, and incomplete work.
Each of these things gets handled slightly differently, and not all of them actually belong within the current scope. In short, your problem is that you haven't correctly defined the goal of Sprint, the scope of the story you're working on, or the Definition of Done.
The team needs to do a better job of scoping and planning the work during Sprint Planning. If you're regularly finding unexpected work of significant scope during each iteration, then the team is not spending enough time thinking through the level of effort and developing the work breakdowns for the Sprint Backlog during the Sprint Planning exercise.
Because iterative methodologies often leverage emergent design, a certain amount of refactoring, rework, and unplanned tasks are not unexpected. In fact, they should inform your level-of-effort planning throughout the process. This includes selecting PBIs, decomposing stories into tasks for the Sprint Backlog, and estimating available capacity for the current Sprint.
Finally, triage the problems properly. In practical terms, that means:
- Stories that have been improperly scoped or planned should be reviewed against the Sprint Goal to see if an Early Termination is called for.
- If new tasks are required, they should go on the Sprint Backlog and discussed as a potential blocker or dependency during the daily standup.
- If new stories are uncovered, they should go onto the Product Backlog for a future Sprint. If they are blockers, see #1 & #2.
- If in-Sprint defects are uncovered, see #1 & #2.
- If defects or bugs from a previous Sprint are uncovered, that was a failure of the Definition of Done. Bring it up to the Product Owner and review the DoD with the team. Then follow steps 1-3.
- Anything else that's new work goes onto the Product Backlog.
- Anything essential for the current Sprint Goal should be a task on the Sprint Backlog, not a story. If the task puts your Sprint Goal in jeopardy: go to #1, do not pass GO, and do not collect $200.
- Ask your teammates, your Scrum Master, and your Product Owner for advice.
Scrum and iterative methodologies in general rely heavily on time boxing and careful scoping. If you aren't doing enough scoping work during Sprint Planning, and if the team isn't rigorous about managing the work within the time box, then that's an implementation failure that will eventually derail the project.
It's not that surprises aren't routinely uncovered in Scrum; they are, and the framework allows for that. It's just that treating all work as in-scope for the current iteration is a fundamental no-no for effective Scrum.