[Srinivas B Kulkarni] Case 1:-If developer or po or anyone in team asking to extend the sprint which clearly means Scrum master have not mentored scrum team on time boxed or we should revisit scrum principles and explain the team in details with examples

Case2:-However if there is production release after the sprint which is adding business value or security related fix which will protect the system definitely we need to collaborate as a team and take the suitable decision

[David Fetterman] If we extend the Sprint, will those important tasks be done sooner? No. If those tasks will create customer value, will extending the Sprint get them in the hands of the customer faster?
Again, no, unless release is coupled to the Sprint cadence - which is not a good thing. The only possible justification here is that we would want to delay the Sprint Review to get feedback as quickly as possible after completing the important tasks. And this itself suggests an antipattern at work - the belief that the team can only solicit feedback in a Sprint Review at the end of the Sprint.
The Sprint should close as scheduled. The important work will be completed when it is completed, and if failure to get the work done in the Sprint means that the Sprint Goal is not achieved, the team should discuss possible improvements to their process in the retrospective.

[Philip Ledgerwood] If the team is asking to extend the timebox, that may mean that the timebox isn't valuable. If the organization is willing to pay for extra days to accomplish the Sprint Goal, then it's a valid question whether or not the timeboxes are getting us anything.

And if they aren't, then there's no reason to use them. We should stop doing Scrum and maybe keep parts of it that are helpful, ditch the rest, and find other things that may be a better fit for our work. We can still set focused product goals and not tie them to fixed timeboxes.

If the fixed timebox is valuable, then you don't want to eliminate it, which is effectively what you're doing if you extend the sprint.

[Andrew Johnson] Finish on time as planned or else nobody is given the chance to learn valuable lessons, on planning, estimates, commitments etc.
In the retro the team may find so many interesting things, time wasted elsewhere? Someone off sick? Environment issues? Under-estimated difficulty or lacking skills?

The work still gets done, it still takes a few more days as you said it would, no loss, and code isn't trrown out. After the retro and next sprint planning just repeat the User Story and set it as highest priority.

But experiencing failure is a valuable motivating lesson for the team.