The answer to this question can make or break contracts. We think that it's such a fundamental issue it has to be captured clearly. This is how we strictly define a bug.

A software issue can be classed as a bug where:
As you can see, bugs come in different shapes and sizes. Some bugs are minor, like alignment on a webpage. Some bugs are major, like blocking bugs, which prevent you from using the system entirely. It's important to categorize bugs by their severity, so that the worst ones can be fixed first.
Figure: Yellow screen of death
Figure: An incorrect sum is likely to be a bug
Using a Work Tracking tool allows you to create work items such as user stories, bugs, tasks, test cases etc. Only create bugs for defects, faults, flaws, or imperfections that fulfill your definition of a bug.
For everything else, use other work item types.
Figure: Work item types
Scrum wasn't designed for "fixed price, fixed scope" contracts. Any new features or modifications (non-bug items) not in the original Sprint or Sprints are classed as additional work and are outside the scope of the contract.
Any tasks which are bugs should be marked as additional items and be completed in the current Sprint if possible. Most importantly, after the Sprint Plan has been sent, a PBI should NOT be entered as an item (additional or otherwise) in ANY Sprints if they are not a bug. Instead, move all non-bug items to the Product Backlog for future review after the warranty period for the fixed price contract has passed.
Any new features or modifications (non-bug items) not in the original Product Backlog are classed as additional PBI's and placed on the Product Backlog.
Any tasks which are bugs found during the current Sprint should be fixed within the current Sprint.
Any tasks which are bugs found outside of the current Sprint should be added to the Product Backlog.
Figure: Adding a bug to the Product Backlog in Azure DevOps
See Do you know when to create bugs? and Do you know the 3 steps to a PBI?
Note: The above is our definition. Others have different definitions that we do not subscribe to: Painless Bug Tracking.
You can also use the Wiki definition of "Software Bug" as a reference to understand this concept: Wikipedia Definition of Software Bug.