Usually ubiquitous projects like this will privately distribute patches to large distros or corps so they can push security updates or at least prepare to push them on the disclosure date so that risk of exploit is lower by the date of disclosure. Otherwise there would be a lag and people would be more exposed for a period after disclosure.

* Buffer overflows tend to lead to remote code execution which is the most serious outcome and should always be treated as serious by default.

* libcurl is absolutely everywhere, not only in corporate networks.

* There is no such things as a trustworthy network; corporations are moving away from that model as it just doesn't work (zero trust). I can think of plenty of ways a motivated attacker might get L2 access to a corporate network if they aren't too picky about what they get access to, when and how long.

* Users can connect work devices to non-corporate networks. The generic example used to be coffee shops, now there's WFH.

* Non-corporate users matter too.

* Horizontal privilege escalation. Chaining multiple exploits into a successful attack is table stakes for modern attackers.

* It was only an example. There is a long history of people (especially those employed by companies with vulnerable products, though that's not the case here) being dismissive about exploitability and wrong about it.

If you want to critique my comment, point out that libcurl didn't actually merge libproxy which would've brought WPAD support... but my real point is that one should not dismiss a buffer overflow in libcurl.