The usual dynamic linker on Linux uses a cache to find its libraries. The cache is stored in /etc/ld.so.cache, and is updated by ldconfig which looks on the paths it’s given in /etc/ld.so.conf (and nowadays typically files in /etc/ld.so.conf.d). Its contents can be listed by running ldconfig -p.
So there is no default value for LD_LIBRARY_PATH, default library lookup doesn’t need it at all. If LD_LIBRARY_PATH is defined, then it is used first, but doesn’t disable the other lookups (which also include a few default directories).
The ld.so(8) manpage has the details:
If a shared object dependency does not contain a slash, then it is
searched for in the following order:
Using the directories specified in the DT_RPATH dynamic section
attribute of the binary if present and DT_RUNPATH attribute does
not exist. Use of DT_RPATH is deprecated.
Using the environment variable LD_LIBRARY_PATH, unless the
executable is being run in secure-execution mode (see below), in
which case it is ignored.
Using the directories specified in the DT_RUNPATH dynamic section
attribute of the binary if present.
From the cache file /etc/ld.so.cache, which contains a compiled
list of candidate shared objects previously found in the augmented
library path. If, however, the binary was linked with the -z nodeflib linker option, shared objects in the default paths are
skipped. Shared objects installed in hardware capability
directories (see below) are preferred to other shared objects.
In the default path /lib, and then /usr/lib. (On some 64-bit
architectures, the default paths for 64-bit shared objects are
/lib64, and then /usr/lib64.) If the binary was linked with the
-z nodeflib linker option, this step is skipped.
If LD_LIBRARY_PATH is not set or is empty, it is ignored. If it is set to empty values (with LD_LIBRARY_PATH=: for example), those empty values are interpreted as the current directory.