z/OS V1R2.0 C/C++ User's Guide, APPENDIX1.C89.3 Options states:
In order to run an application which is link-edited with a definition side-deck,
the DLL must be made available (the definition side-deck created along with the
DLL is not needed at execution time). When the DLL resides in the HFS, it must
be in either the working directory or in a directory named on the LIBPATH
environment variable. Otherwise it must be a member of a data set in the search
order used for MVS programs.
A test indeed shows that when LIBPATH is not set, the working directory is
searched. (It is *not* searched if LIBPATH is *set*, what isn't clear from
the above. Also note that USS executables don't have a compiled-in LIBPATH.)
Searching the working directory for DLLs must be considered a security hole
even while in an environment *without* LIBPATH defined the to-be-attacked
commands will not work in the normal case, so that it is unlikely that they
are in use at all. Anyway, putting some trojan horse DLLs into /tmp and
waiting for the administrator to misspell some command looking for DLLs
has a chance to succeed.