What happens if the team finishes earlier all the user stories in the backlog?

From the Scrum Guide

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

So completing all of the user stories does not mean that they have completed the Sprint.  

Also from the Scrum Guide

They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.

So if the Developers were capable of completing the Sprint Backlog, I usually advocate that they have time for:

• refining items in the Product Backlog,
• learning more about the technologies they use or want to use,
• learning more about the problem space that their products are built to address
• team building
• upgrades to tools that they use

There are a lot of things that "extra time" could be used for that in the end would improve the team's ability to provide value. 

Perhaps the Product Backlog is not being refined appropriately. Maybe the work is there, but it hasn't yet emerged.

Are there any significant risks or unknowns left to mitigate for this product?

Thanks for your answers.

I suspected there's a problem about not emerging work. Also, product goals are often not clear, not shared or they don't exist at all.

About the fixed length of the sprint, I'm happy that I acted well, suggesting the team to spend the time remaining for activities that improve ther effectiveness, just like the ones that you listed.

The only time a Sprint is terminated (cancelled) is if the Sprint Goal itself becomes obsolete.

A Sprint could be cancelled if the Sprint Goal becomes obsolete.

If the team has achieved the Sprint Goal and completed any other Sprint Backlog Items they had pulled in, look to the great tips from Daniel on what other things can be done and Ian's suggestion around work that may be there but not yet emerged. 

Now, you mentioned...

We don't have a clear bigger product goal.

This is something to be looked at. The Product Goal is a key element as the Product Backlog exists as an ordered list of what is needed to fulfill the Product Goal. The Product Goal provides guidance and focus for building and managing the Product Backlog. 

You also mentioned...

We work frequently on small requests that may be implemented in one or two 2-weeks sprints

Frequent requests wording caught my eye. Can you elaborate on this a bit more? Is your work more demand based vs. product development? Are these requests being raised as part of stakeholder collaboration to be considered by the Product Owner? Or do requests come in and you fulfill them.