# SSRF protection in curl

- Thread: https://externals.io/message/132871
- Original archive: https://news-web.php.net/php.internals/132871
- Started by Sjoerd Langkemper on 2026-10-15T08:47:39+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #132871 — Sjoerd Langkemper — 2026-10-15T08:47:39+00:00

URL: https://externals.io/message/132871#132871

If an application performs HTTP requests based on user input, it is often desirable to verify that the connection is done to an allowed host. Otherwise the functionality could be abused to request resources on the server or on the same network as the server (SSRF).

Xavier Leune made some pull requests to make this possible in curl. The idea is to hook in a callback that can verify the IP address that curl is going to connect to.

22159: exposes callbacks such as CURLOPT_OPENSOCKETFUNCTION. These are supported by curl, but exposing the socket to userland comes with problems.
23657: introduces CURLOPT_PRECONNECTFUNCTION. This is not supported by curl and is PHP-only, deviating from the normally thin abstraction on top of curl.

The current plan is to expose only CURLOPT_OPENSOCKETFUNCTION with the signature function(string $address, int $port): bool. This is pretty limited compared with what OPENSOCKETFUNCTION can normally do, but at least makes it possible to do SSRF protection.

What do you think? How can we expose SSRF protection to applications that perform curl requests?

Regards,

Sjoerd Langkemper

---

## #132872 — Xavier Leune — 2026-10-15T09:07:28+00:00

URL: https://externals.io/message/132871#132872 · In reply to: #132871

Hi Sjoerd,

Thanks for reopening this discussion ! I planned to do it in the
coming days too, I'm really eager to see this land in PHP :)
I'm pretty open about the 2 ways to implement it, however the discussion on
23657 about 22159 suggested a socket class bound to curl only, to make
things easier to manage and to remove the dependency to ext/socket.

In my opinion, CURLOPT_OPENSOCKETFUNCTION with the boolean may be a good
idea. I'm not sure there is a real use case to open a wider support in PHP
- this option exists for almost 2 decades and I'm not sure anyone needed it.
For the record I plan to implement the feature in a polyfill extension -
with the same approach that we'll retain for PHP, to offer support in lower
php versions.

There are a lot of small details we can discuss if we retain the
OPENSOCKET_FUNCTION: the signature may be expanded to offer the same level
of data as curl offers
<https://curl.se/libcurl/c/CURLOPT_OPENSOCKETFUNCTION.html>. This would
make things easier if we want to support a full `CurlSocket` object later.

There is a first draft here: https://github.com/xavierleune/curl-hardening
My idea was to use this extension as a sandbox before pushing a new
discussion here, I will follow the API we may agree on for PHP 8.7.

I think the approach in the current extension may address the concerns
expressed by Bukka on 22159, while giving room to expand the support later.

Do you think this approach is worth pursuing ?

Thanks,

Xavier

Le jeu. 15 oct. 2026 à 10:48, Sjoerd Langkemper <sjoerd-php@linuxonly.nl> a
écrit :

> If an application performs HTTP requests based on user input, it is often
> desirable to verify that the connection is done to an allowed host.
> Otherwise the functionality could be abused to request resources on the
> server or on the same network as the server (SSRF).
>
> Xavier Leune made some pull requests to make this possible in curl. The
> idea is to hook in a callback that can verify the IP address that curl is
> going to connect to.
>
> 22159: exposes callbacks such as CURLOPT_OPENSOCKETFUNCTION. These are
> supported by curl, but exposing the socket to userland comes with problems.
> 23657: introduces CURLOPT_PRECONNECTFUNCTION. This is not supported by
> curl and is PHP-only, deviating from the normally thin abstraction on top
> of curl.
>
> The current plan is to expose only CURLOPT_OPENSOCKETFUNCTION with the
> signature function(string $address, int $port): bool. This is pretty
> limited compared with what OPENSOCKETFUNCTION can normally do, but at
> least makes it possible to do SSRF protection.
>
> What do you think? How can we expose SSRF protection to applications that
> perform curl requests?
>
> Regards,
>
> Sjoerd Langkemper