A DESCRIPTION OF THE PROBLEM :
Panama's SymbolLookup.libraryLookup(Path, Arena) takes a Path argument and strips away the underlying FileSystem implementation and attempts to load the path from the default filesystem of the host. This should be checked for and documented in some way. Alternatively a mechanism to load it into a temporary location could be provided, but that may be a little out of scope of this and is trivial to extract the files manually.

There is also a chance this could be used in a malicious manor if a system is just iterating over a list of paths and someone drops a loadable executable somewhere. A minor risk, but it could still feasibly happen.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
A very simple Jar and example program is all it takes:

The native library could be whatever as the library will never be loaded.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Either throw an exception or transparently handle loading from a non-default FileSystem.
ACTUAL -
LibraryLookup attempts to load the native library from the provided path on the default filesystem instead of the one that the provided Path references.

---------- BEGIN SOURCE ----------
import java.lang.foreign.SymbolLookup;
import java.nio.file.Paths;

public class Example {
    public static void main(String[] args) throws Throwable {
        var path = Paths.get(Example.class.getProtectionDomain().getCodeSource().getLocation().toURI());
        SymbolLookup lookup;
        try(var fs = FileSystems.newFileSystem(jar)) {
            var path = fs.getPath(System.mapLibraryName("someLib"));
            // On Linux this will attempt to load /libsomeLib.so instead of libsomeLib.so in the root of the jar.
            lookup = SymbolLookup.libraryLookup(path, Arena.ofAuto());
        }
        lookup.find("someSymbol").ifPresentOrElse(
            System.out::println,
            () -> System.out.println("Failed to find symbol")
        );
    }
}
---------- END SOURCE ----------