This is working as intended. You're running software that interferes with expected functionality. #122134 to fix CVE-2024-3219 caused it to show up, before this your man-in-the-middle software was snooping the localhost connections being used to build a socket pair work-alike for inter process communication on Windows without being noticed.

If you wanted to propose a workaround PR for this to go back to not caring about sockets being intercepted and snooped on, it would wind up requiring doing authentication handshake through both ends of the socket to ensure they were communicating with one another. (and only doing the existing raise if that handshake fails)

I do not consider that a good idea... This smells like a Proxifier bug, it should not be intercepting localhost sockets.

This is working as intended

I disagree. Throwing an error isn't working as intended because according to curl/curl#10144 (comment) "The problem is not Proxifier specific... any MITM tool including some antiviruses can cause this", so the upshot is that #122134 has caused a regression which leads to an unexpected crash in several dependencies which scripts whose socketpairs are not explicitly defined may be unknowingly depending upon.

it should not be intercepting localhost sockets

I agree. However this undesirable behavior on the affected platform cannot be easily influenced so a workaround in cpython seems to be required, unfortunately.

it would wind up requiring doing authentication handshake

The authentication doesn't have to be strong because it is confined to localhost. The workaround in curl seems to be satisfactory enough to send and validate a dummy packet containing the current time, or otherwise a random check digit or suchlike might be desired if spoofing local sockets is really that much of a concern.

Alternatively, the error message could be improved to mention "socketpair" and/or with details about the local peers who are involved with the connection in order to more easily identify where the problem is coming from.