That's an interesting situation you describe there!
Obviously, you cannot deny the developer to search for a solution in his free time. However, there has to be a clear separation between his free-time work and the project. If he works on the project's code, trying/integrating a solution, the separation is not clear anymore. This is a problem you, as the Scrum Master, need to prevent.
I experienced a similar situation not to long ago: I worked in a student team on a 1-year-project. We used Scrum. One colleague was really into finding an elegant solution for the bootstrapping logic of our program. Despite our "working solution", he spent more time to implement an even better one; out of personal interest. It turned out to be more complicated than he anticipated, but since he already invested a lot of time, he kept spending more and more. In the end, this effectively reduced his working time, because after he spend much time on the issue, he wouldn't work on something else that long. He intended to separate the tasks, but he didn't manage to do that, because somewhere in his head working on the project still was working on the project.
So much for the risk. End of the story is: the developer turned up with a very elegant solution that saved us a lot of work since that day. Don't know if as much as he spent, but, in the end, some might say it was worth it.
However, the difference between my project and yours is that we were students, while you are employees. It maybe that this makes the separation easier, but in my eyes it also makes it more important. Especially if the PO already gave you additional time (multiple times) for the issue and you weren't able to fix it. If it's a corner case to him that's not worth further effort, than this is his decision to make. Developers tend to have a different view on such things, especially if their personal pride is involved. But it's the PO's decision. The team has to accept that. Period.
If he wants to figure out a workaround for the bug in the open-source framework, he's free to do that at home, in his own setup. He should not work on it from the company, nor using the project's code. If he should come up with a solution and still be interested in integrating it, you can talk to the PO again. Then you can tell him it will be so and so much effort and you know it, because your developer actually already tried it and it worked. If it's not too much work, I'm pretty sure the PO will accept the change. After all, he want's a robust product.
Hope this helps somewhat.