The first time it happens, handle it quietly. The dev was most likely just trying to add value/effort to the project and did not mean to specifically undermine you. He did, but give him the benefit of the doubt that it was not his intention.
At the time, kind correct back and allow for the possibility that the dev may actually be correct. Something along the lines of telling the stakeholders:
We'll look into a more detailed estimate and see what we can do. For now, I'm going to ballpark estimate [your estimate] but we will refine this.
After the meeting, speak to the dev directly. In order to create the least amount of friction and enhance the likelihood of the dev hearing what you're going to say, first hear them out. Listen, interpret, and provide accurate feedback. Maybe they are right, maybe they are not.
Let them know you appreciate their input (regardless of being correct, they are trying to help), but explain how the meeting was not the right place or time for that input.
Now that their idea has been heard, shift the conversation to how your estimate factors in more than just the dev's own work. Your estimate contains safety padding, time for internal development needs, time for meetings and expected delays due to back and forth communication, other concurrent workloads for your dev team, and so on.
Stress that you are the public face of your dev team, and that the dev is present in the meeting specifically for the technical questions, not to represent the team; and that the main focus contains more than just the technical part, so the dev cannot and should not override your input.
If this happens again in a second meeting, swiftly meet the dev's statement with established facts, in front of the stakeholders.
[Dev], as we talked about before, the estimate I provide contains more than just the barebones technical implementation. There are additional considerations that you are not aware of, so your estimate cannot possibly account for them.
[Stakeholder], I apologize for the confusion. I expect the task to take [your original estimate] in its entirety.
Sidenote: if the dev starts arguing with you and elaborates their position or digs deeper into why your estimate is off, shut it down immediately, telling them that they can talk with you after the current meeting. Do not let them take control of the conversation.
At this point, after the meeting, sternly discuss this with the dev. This is the part where I would no longer first ask them for their input, but rather strongly point out that their behavior is effectively undermining your position, and that you cannot tolerate this in meetings with stakeholders/clients. Get them to verbally agree to not pull this move again.
If it happens a third time, this is the part where I would consider an official warning, disciplinary action (depending on the severity of their behavior), and formally uninviting the dev from further meetings.
This is no longer a matter of a well-intentioned dev who makes a faux-pas. This is a matter of a developer who bypasses you even when explicitly instructed not to, actively undermines your leadership, and plays the dev team off against the stakeholders. That is not a person I would trust or freely allow into open discussions.