You don't need to do any of this
The bug you link to was fixed in Curl version 7.51.0.
- openssl: fix per-thread memory leak using 1.0.1 or 1.0.2
You specified Debian Stretch, which currently uses 7.52.1. It doesn't matter that it has an older version of OpenSSL installed -- you still have the updated Curl.
So as long as that system has been kept up-to-date (via
apt) it already has the fix.
Dynamic or static
Now, onto your original question:
Isn't the openssl statically built, and therefore remains inside curl binary?
No. Unless you set some specific variables when you ran
./configure, the resulting executable is dynamically linked, and needs a separate
libcurl.so. One of those will have been built at the same time.
And unless you copied that library file to the second server and placed it in a path where the loader would find it, then you will be using the one that is already installed (under
/usr/lib/x86_64-linux-gnu/). If you run
readelf -d on that file, you will see which version of OpenSSL it is linked against.
0x0000000000000001 (NEEDED) Shared library: [libssl.so.1.0.2]
If you had tried to use your newer version of
libcurl.so.4 on the second server, you would have seen an error something like this:
error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
To sum up: Your copy of Curl is using, and correctly reporting, the version of OpenSSL that is installed. The only way you would be affected by the memory leak is if you had manually built a version of Curl from before the fix (ie. older than 7.51.0).