Vulnerabilities

All versions before 3.7.0.

Medium

When establishing a backend connection to the JVM, earlier versions of the Wrapper assumed a reasonable level of trust for processes running in the local environment. Although the connection was authenticated, it relied on a key exposed on the command line. There was a narrow window in which a malicious process could capture the key and win a race condition by connecting before the JVM.

On Windows, the risk of key capture was limited because the key was only exposed to processes running under the same user account or with Administrator privileges. However, there was a risk of pipe squatting: an attacker could potentially preemptively create the named pipe before the Wrapper, preventing the legitimate connection from being established.

These vulnerabilities are primarily a concern for multi-user systems where untrusted users have local execution rights, or in environments that have already been compromised. If exploited, the local attacker could cause a Denial of Service (preventing the JVM from connecting), intercept sensitive data passed between the Wrapper and the JVM, or, in certain cases, send a false process ID (PID) to trick the Wrapper into terminating an unintended process.

Starting with version 3.7.0, the Wrapper has adopted a stricter security posture that no longer assumes a trusted local environment. To establish a truly secure channel with the JVM, several aspects of the backend communication have been redesigned from channel creation to authentication and data integrity verification.

The most notable changes are:

• The default backend connection type has been changed to PIPE, which is inherently more secure than TCP/IP sockets for one-to-one inter-process communication.

• On Windows, additional safeguards prevent pipe squatting and Denial of Service attacks, reinforced by PID and SID (Security Identifier) validation during peer process authentication.

• For all connection types, the authentication key, previously passed as a command-line system property (-Dwrapper.key), is now delivered exclusively to the launched Java process and generated with stronger cryptographic entropy, mitigating the risk of disclosure or guessing.

• The connection lifecycle has been redesigned to reject and skip unauthorized connection attempts (ensuring availability for the legitimate process) and to reset cleanly if the JVM must be restarted.

• The integrity of the reported client PID (as well as the PIDs of child processes for the Professional Edition) received over the established connection is now strictly verified to prevent unauthorized process termination.

• On Unix systems, backend channel file descriptors are no longer inherited by unrelated subprocesses, eliminating a potential vector for interference.

• Upgrade to Wrapper version 3.7.0 or higher.

• Until an upgrade can be performed, consider the following applicable mitigations on Unix systems:

  • When running Wrapper version 3.6.0 or later (see #13), use wrapper.backend.type=PIPE. Because anonymous pipes rely on file descriptors that are exclusively inherited by child processes, the connection is inherently protected from unrelated local processes even if the authentication key is visible.

  • Ensure OS-level hardening is configured to hide process command lines from unprivileged users. Mechanisms vary by platform (e.g., hidepid for /proc on Linux, or security.bsd.see_other_uids=0 sysctl on FreeBSD). Note that some operating systems restrict this visibility by default.

• Ensure that the machine hosting the Wrapper restricts local execution access only to trusted users.

All versions before 3.6.3.

Warning

Applications using Wrapper 3.5.16 or higher can set wrapper.disable_tests to TRUE to block potential misuse of testing features. If this setting is not applied, the security risk is high for applications allowing the execution of unverified - and potentially malicious - code.

The WrapperManager class exposes several methods designed to test common application failures. While useful for testing, these methods can pose a security risk if invoked by untrusted code at runtime.

The Wrapper has supported the use of a Security Manager to control access to these and other functionalities since very early versions. However, the Security Manager is rarely used by developers, and was therefore deprecated since Java 17, then disabled at startup since Java 24.

As an alternative, the wrapper.disable_tests property was introduced in version 3.5.16 to globally disable the testing methods. However, its default value was FALSE in all versions prior to 3.6.2, meaning that the property had to be explicitly added to the configuration and set to TRUE to be effective.

If neither the Security Manager nor the wrapper.disable_tests property is used to restrict access, untrusted code running within the application (such as a malicious or compromised plugin, JAR file, or dynamically loaded module) could invoke these methods, causing issues like slowdown or crashes, leading to a denial-of-service (DoS) condition.

Version 3.6.3 improves the default security posture by changing the default value of wrapper.disable_tests to TRUE, logging a warning when the property is explicitly set to FALSE, and adding measures to prevent untrusted execution of any testing features within the JVM.

• Add wrapper.disable_tests=TRUE to your configuration file (if the Wrapper version is 3.5.16 or higher), or

• Upgrade to at least Wrapper version 3.6.3.

• As a general guideline for secure application design, always restrict plugin and module loading to trusted and verified code.

Versions from 3.5.8 to 3.5.60.

Critical (if sensitive data are passed via the backend, which is possible since version 3.5.57, and the backend is set to PIPE)

When using wrapper.backend.type=PIPE, the Wrapper would create named pipe with permissions that are too open. Windows Editions are not affected and can use PIPE safely.

There was a security concern when wrapper.app.property properties were used to pass sensitive data via the backend as it was possible for any user with access to the server to view the contents of the pipe.

The default transmission type uses SOCKET, which does not have this problem.

• Use wrapper.backend.type=SOCKET, or

• Upgrade to Wrapper version 3.6.0 (or higher), which use anonymous pipes with appropriate permissions.

All versions before 3.5.58.

Warning

For compatibility with older versions of Windows, Microsoft has decided that SeImpersonatePrivilege will be enabled by default for Windows services. This privilege is automatically added by the service control manager (SCM) via dynamic addition of the SERVICE group when a service is started.

SeImpersonatePrivilege lets a process borrow the identity of a different user. While this can be useful to test how the process behaves under different user contexts, this can also pose significant security risks. The privilege can indeed be abused by to escalate to the LocalSystem account which has the highest privileges level on a Windows system.

This security issue only applies to services configured to run with an account other than LocalSystem (otherwise the service already has the highest possible privileges). However, it is often a good idea to run under a dedicated service account in order to restrict access of the Java application on the hosting system, and conversely, to prevent other third-party processes from accessing the application and Wrapper files.

Starting with version 3.5.58, the Wrapper will disable SeImpersonatePrivilege when running as a Windows service with an account other than LocalSystem (NT AUTHORITY\SYSTEM). Most Java applications will not need this privilege, but in case it is needed, the wrapper.ntservice.impersonation property can be used to re-enable it.

• Upgrade to Wrapper version 3.5.58 or higher.

• Set the required privileges for the service (requires the Professional Edition, version 3.5.57 or higher).

• It is possible to edit the Local Security Policy settings, but there is a risk of affecting other services (not recommended).

All versions before 3.5.58.

High (if the conditions below are met).

The Wrapper Java API provides the WrapperManager.log() method to allow user code to log a message at the specified log level. If the second argument, which is the message to log, contained a '%' character, the Wrapper could crash causing a denial of service.

Your application is at risk if it uses user inputs that are ultimately passed to the WrapperManager.log() method.

• Upgrade to Wrapper version 3.5.58 or higher.

• Or, make sure to strip any '%' character in the message to log before calling WrapperManager.log().

Version 3.5.55.

Warning

Windows binaries not signed.

Please use version 3.5.56, which is signed with an upgraded EV certificate.

Versions 3.5.44 and 3.5.45.

Warning

Jar file is signed with an older code signing certificate (expiring on 2020-12-15 but with a timestamp valid until 2027-06-27).

The jar file is safe to execute.

No special action required.

Version 3.5.44.

Medium

The Windows binaries (wrapper.exe, wrapperw.exe, wrapper.dll) are not digitally signed.

Although the lack of a signature does not in itself pose a security threat, it is not possible to verify the authenticity and integrity of binaries without a digital signature. Microsoft Defender SmartScreen may therefore block the first execution and warn of a security risk.

• Upgrade to Wrapper version 3.5.45 or higher.

• Always make sure to download the Wrapper binaries from the official Java Service Wrapper website and store them in a safe place where they can't be altered.

Versions from 3.5.35 to 3.5.40.

High (when wrapper.lang.windows.encoding is used)

Starting with version 3.5.35, wrapper.lang.windows.encoding makes it possible to change the encoding of the locale used by the Wrapper process. This is useful, for example, to print the log output in UTF-8 or using a specific encoding.

When wrapper.lang.windows.encoding is set, the Wrapper reads the JVM output in a different mode. This mode has a bug where a percentage character '%' in the JVM output could cause the Wrapper to crash.

Your application is particularly exposed if client user input can end up in the logs, making it vulnerable to denial of service attacks.

• Upgrade to Wrapper version 3.5.41 or higher, or

• Comment wrapper.lang.windows.encoding or set it to its default value (ANSI).

Version 3.5.35.

High

wrapper.lang.windows.encoding makes it possible to change the encoding of the locale used by the Wrapper process. UTF-8 strings are handled with a separate function that uses a fixed-size buffer of 4096 characters. JVM output larger than this width would cause a buffer overflow.

Your application is particularly at risk if large user inputs can end up in the logs, as they could cause the Wrapper to crash and lead to a denial of service.

The Wrapper is not affected when wrapper.lang.windows.encoding is left to its default value 'ANSI' or when an encoding other than UTF-8 is used.

• Upgrade to Wrapper version 3.5.41 or higher, or

• Set wrapper.lang.windows.encoding to a value other than UTF-8.

Versions from 3.5.8 to 3.5.11.

Critical

On UNIX platforms, the default umask is set to 0000 rather than inheriting the value from the parent process when running as a daemon process.

The log and other files have global read/write access.

The default umask of the Java process would also be 0000, and thus of any files created by the Java application, unless they explicitly set new permissions.

The anchor file, if used, can be deleted by anyone and cause the Wrapper to stop.

• Upgrade to Wrapper version 3.5.12 or higher, or

• Set the wrapper.umask property to a safe value.

All versions before 3.3.7.

Warning

Strict SELinux security policy could prevent the Wrapper from loading the libwrapper.so library.

This is only a problem when running on a system with SELinux enabled.

• Upgrade to Wrapper version 3.3.7 or higher.

All versions before 3.3.0.

High

Crashes may occasionally occur with 64-bit UNIX caused by a native synchronization problem when system signals are trapped. Bug #1614010.

This vulnerability could be used by third-party processes to attempt denial of service attacks.

32-bit binaries are not affected. Windows is not affected.

• Upgrade to Wrapper version 3.3.0 or higher, or

• Use wrapper.ignore_signals=TRUE (not recommended).

Versions from 3.0.0 to 3.1.2, and then from 3.2.2 to 3.2.3.

High

The value of the wrapper.ntservice.account and wrapper.ntservice.password were being stored in plain text within the registry if they were specified on the command line when installing the Wrapper as a Windows service.

• Bug #1538725

• Bug #1110183

• Upgrade to Wrapper version 3.1.2 or higher.

• Do not specify wrapper.ntservice.account or wrapper.ntservice.password on the command line when installing the Wrapper as a Windows service.

All versions before 2.2.6.

High

A percentage character '%' in the JVM output could cause the Wrapper to crash.

Your application is particularly exposed if client user input can end up in the logs, making it vulnerable to denial of service attacks.

• Upgrade to Wrapper version 2.2.6 or higher.