Szafirhost

SzafirHost verifies the downloaded native library archive with one JarFile parser (reading the Central Directory) but extracts native libraries with JarInputStream parser (reading sequentially from local file headers). An attacker who controls the served archive can insert a malicious DLL/SO/DYLIB as a local-file-header entry between the last legitimate entry and the Central Directory, without adding it to the Central Directory. The signature verifier never sees the injected entry and accepts the archive as validly signed; the extractor reads it sequentially and writes the attacker library to the native temp directory with no hash check), while the archive-size check still passes. This can lead to remote code execution. This issue was fixed in version 1.2.2.

Published: 2026-06-29T12:16:55.559Z
Updated: 2026-06-29T13:58:14.780Z

SzafirHost verifies the signature of the downloaded JAR file using class JarInputStream (reading from the beginning of the file), but loads classes using class JarFile/URLClassLoader (reading the Central Directory from the end). It can lead to remote code execution by allowing an attacker to combine a genuine, signed JAR file with a malicious ZIP file, causing the verification to pass but the malicious class to be loaded. This issue was fixed in version 1.2.1.

Published: 2026-05-15T08:48:11.694Z
Updated: 2026-05-15T11:07:58.948Z

SzafirHost downloads necessary files in the context of the initiating web page. When called, SzafirHost updates its dynamic library. JAR files are correctly verified based on a list of trusted file hashes, and if a file was not on that list, it was checked to see if it had been digitally signed by the vendor. The application doesn't verify hash or vendor's digital signature of uploaded DLL, SO, JNILIB or DYLIB file. The attacker can provide malicious file which will be saved in users /temp folder and executed by the application. This issue was fixed in version 1.1.0.

Published: 2026-04-02T14:01:42.262Z
Updated: 2026-04-02T14:21:50.711Z