Increased CVE Activity in Curl?

I'm one of the maintainer of an Open Source project [1] that strongly relies upon libcurl. I'm really grateful to Daniel and all the contributors for all the work in curl/libcurl, this is one of our common software gem that is used by many (even in space [2]), so thanks a lot!

[1]: https://github.com/Orange-OpenSource/hurl

[2]: https://daniel.haxx.se/blog/2020/12/17/curl-supports-nasa/

I'm looking at these CVEs thinking "How could curl have a CVE", and to be fair, some of these do seem theoretically significant if combined with other software bugs.

But some of these just look like regular bugs. For example, https://curl.se/docs/CVE-2022-27778.html

    curl might remove the wrong file when --no-clobber is used together with --remove-on-error.
    The --remove-on-error option tells curl to remove the output file when it returns an error, and not leave a partial file behind. The --no-clobber option prevents curl from overwriting a file if it already exists, and instead appends a number to the name to create a new unused file name.
    If curl adds a number to not "clobber" the output and an error occurs during transfer, the remove on error logic would remove the original file name without the added number.

Which seems like at worst it deletes a previous version of a file fetched with curl, and leaves a partial file, rather than deleting the partial file. I understand there's perhaps a very unlikely scenario in which this could lead to a system being compromised, but it depends on too many other factors that are also increasingly unlikely, it seems on the order of likelihood of reversing SHA-256

Did the author of cURL ever get his US Visitor Visa, or is he still considered too dangerous to allow into the USA? \s