CWE-111 Unsafe JNI: Native Code Inside Java Apps

CWE-111, Direct Use of Unsafe JNI, is about what happens at the edge of the Java runtime. When a Java application uses the Java Native Interface (JNI) to call code written in another programming language, it can expose the application to weaknesses in that code, even if those weaknesses cannot occur in Java.

It matters to any Java team that ships a library with a native component, links a vendor DLL or shared object, or wraps an image, crypto or compression library. Many of those wrappers sit deep in the dependency tree where nobody is looking.

How it happens

Java gives you memory safety, strong typing and bounds checking. Native code gets none of it. MITRE puts it plainly: many safety features that programmers take for granted do not apply to native code, so all such code needs careful review. The languages used for native code may be more susceptible to buffer overflows and other attacks, and native code is unprotected by the security features the runtime environment enforces.

Here is the typical shape. Java passes data into a native method.

public class ImageNative {
    static { System.loadLibrary("imgproc"); }

    // Implemented in C. Java does not check what happens inside.
    public native byte[] resize(byte[] input, int width, int height);
}

// Caller
byte[] out = new ImageNative().resize(userUpload, userWidth, userHeight);

Nothing in this Java code is wrong by itself. The risk is what the C function does with userWidth and userHeight and the size of userUpload. If it trusts them, a crafted value can overflow a buffer inside the native library, and the JVM cannot stop it.

What an attacker gains

MITRE lists a bypass of protection mechanisms. The protections in question are the ones the Java runtime normally provides. Once an attacker reaches a memory safety bug in native code, the guarantees you assumed from using Java no longer apply to that process.

How to find it

MITRE notes that automated static analysis (SAST) can find some instances of this weakness. Begin with an inventory. Search your own source for native method declarations and System.loadLibrary or System.load calls. Then widen to dependencies: which of your libraries bundle .so, .dll or .dylib files?

That second step is a software composition question. The free in-browser scan at gold.safeguard.sh/scan takes your dependency manifest without a login, keeps the file on your machine, and covers up to 100 dependencies, so you can check each library against known vulnerabilities. It is a quick way to see which of your packages are already flagged, including ones with native parts.

Click through it at your own pace, or open it full screen.

How to fix it

MITRE gives three mitigations.

1. Implement error handling around the JNI call. Treat the boundary as a place where failures can happen, and make sure a failure does not leave the application in an unsafe state.
2. Do not use JNI calls if you do not trust the native library. If you cannot vouch for it, keep it out of your process.
3. Be reluctant to use JNI calls. A Java API equivalent may exist. Pure Java keeps the safety features that native code gives up.

Add two practices of your own. Validate sizes and ranges on the Java side before the call, since the Java layer is the last place with strong checks.

public byte[] resizeSafely(byte[] input, int width, int height) {
    if (input == null || input.length == 0 || input.length > MAX_BYTES) {
        throw new IllegalArgumentException("bad input size");
    }
    if (width < 1 || width > 4096 || height < 1 || height > 4096) {
        throw new IllegalArgumentException("bad dimensions");
    }
    try {
        return nativeResize(input, width, height);
    } catch (RuntimeException e) {
        throw new IllegalStateException("image processing failed", e);
    }
}

And keep the native library patched. Reachability analysis helps here by showing whether your code calls the vulnerable function in a flagged library, so you can sort real exposure from noise.

Quick check

Sources

• MITRE CWE-111