Put bug into backlog or the current sprint

Are you sure this is a bug, and not a changed requirement for which an existing test must also change?

It is a bug triggered by a bad new requirement.

Does the Product Owner think that this new requirement is "bad"?

What are his or her thoughts about how validation now ought to work for this feature?

The validation should be conditional instead of a blanket "required".

Is integration testing part of your Definition of Done?

Even though the bug is a result of multiple stories, it was introduced with your second story.  Is that story "done" and are you going to have a potentially releasable increment at the end of this sprint?  Or will that bug block you from that?

You need to raise this to the product owner. discuss f2f. Obviously both these requirements can't coexist. He will need to scrap either one. If either one is scrapped then it is obvious that it's a change in requirement. then both the PBIs exist. If either one is not scrapped then you need to raise this a bug and assign it to the product owner. But the bugs needs to be raised by the testing team. You just need to be a facilitator. 

I'd argue it should actually be a discussion within the team, for nobody would ever have all the answers. So PO and DT would need to discuss and reach the best solution.

As you said it is a change in requirements, good or bad could be debated.  But honestly, this is what agile and Scrum are all about.  Complete Story 1 per the story definition and satisfy DoD.  Then implement story 2 in the same way.  The bug you reference seems to be due to the change in requirements introduced in story 2.  

Should this bug be put into backlog so it can be fixed in other sprint?

Can story 2 meet the DoD with the bug in place?  If yes, it can go into the backlog and fixed at a later time but if you have time in the sprint, why not fix it?  If no, fix the bug so you can meet the DoD.

First: Scrum does not have an official position on this.

Personally, here's how I think of "bugs": bugs are ONLY defects currently impacting users (i.e. is in production.) If it's something that comes up as part of the execution of a story, it's just part of the work necessary to get that story to done.

So--making an assumption here that you're currently in Sprint 2 and working on this story--IF you are creating a fully integrated increment--as is demanded by Scrum--in order to implement the second story, you need to reconcile the conflict between the two stories. Until then, you should NOT release the story to production, as you know it will negatively impact your users (and at that point, once it's in prod, it goes from being work to do into a bug.) The story is NOT done if you aren't creating a successfully integrated increment, so you MUST reconcile the issue.

Work with the Product Owner to clarify the ideal behavior. Yes, this might require some refactoring and making some changes to the behavior of the field. That's kind of the whole point of and iterative approach to software development: get 1 thing working, then the next, then the next, revising and adjusting what was done before as necessary.

If you're past Sprint 2 and that story's already in production...it's a bug, and you have to decide what you're going to do with it. My recommendation? Either it's a Critical Fix that needs to take precedence over the Sprint Goal OR it should be prioritized at the top of the list for the next Sprint OR