In universal forwarder versions before 9.0, management services are available remotely by default. When not required, it introduces a potential exposure, but it is not a vulnerability. If exposed, we recommend each customer assess the potential severity specific to your environment. In 9.0, the universal forwarder now binds the management port to localhost preventing remote logins by default. If management services are not required in versions before 9.0, set disableDefaultPort = true in server.conf OR allowRemoteLogin = never in server.conf OR mgmtHostPort = localhost in web.conf. See Configure universal forwarder management security (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation#Configure_universal_forwarder_management_security) for more information on disabling the remote management services.

In Universal Forwarder for Windows versions below 9.4.2, 9.3.4, 9.2.6, and 9.1.9, a new installation of or an upgrade to an affected version can result in incorrect permissions assignment in the Universal Forwarder for Windows Installation directory (by default, C:\Program Files\SplunkUniversalForwarder). This lets non-administrator users on the machine access the directory and all its contents.

Splunk Enterprise 6.6.x, when configured to run as root but drop privileges to a specific non-root account, allows local users to gain privileges by leveraging access to that non-root account to modify $SPLUNK_HOME/etc/splunk-launch.conf and insert Trojan horse programs into $SPLUNK_HOME/bin, because the non-root setup instructions state that chown should be run across all of $SPLUNK_HOME to give non-root access.

Incorrect permissions on the Checkmk Windows Agent's data directory in Checkmk < 2.3.0p23, < 2.2.0p38 and <= 2.1.0p49 (EOL) allows a local attacker to read sensitive data.

Default permissions for a properties file were too permissive. Local system users could read potentially sensitive information. We updated the default permissions for noreply.properties set during package installation. No publicly available exploits are known.

A flaw was found in Ansible Engine when a file is moved using atomic_move primitive as the file mode cannot be specified. This sets the destination files world-readable if the destination file does not exist and if the file exists, the file could be changed to have less restrictive permissions before the move. This could lead to the disclosure of sensitive data. All versions in 2.7.x, 2.8.x and 2.9.x branches are believed to be vulnerable.

In Spring Cloud Contract, versions 4.1.x prior to 4.1.1, versions 4.0.x prior to 4.0.5, and versions 3.1.x prior to 3.1.10, test execution is vulnerable to local information disclosure via temporary directory created with unsafe permissions through the shaded com.google.guava:guava dependency in the org.springframework.cloud:spring-cloud-contract-shade dependency.

IBM CICS TX 11.1 could disclose sensitive information to a local user due to insecure permission settings. IBM X-Force ID: 229450.

A postinstall script in the dovecot rpm allows local users to read the contents of newly created SSL/TLS key files.

An issue exists AccountService 0.6.37 in the user_change_password_authorized_cb() function in user.c which could let a local users obtain encrypted passwords.

Rapid7 Metasploit Pro version 4.16.0-2019081901 and prior suffers from an instance of CWE-732, wherein the unique server.key is written to the file system during installation with world-readable permissions. This can allow other users of the same system where Metasploit Pro is installed to intercept otherwise private communications to the Metasploit Pro web interface.

Confd log files contain local users', including root’s, SHA512crypt password hashes with insecure access permissions. This allows a local attacker to attempt off-line brute-force attacks against these password hashes in Sophos UTM before version 9.710.

A temp directory creation vulnerability exists in all versions of Guava, allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava API com.google.common.io.Files.createTempDir(). By default, on unix-like systems, the created directory is world-readable (readable by an attacker with access to the system). The method in question has been marked @Deprecated in versions 30.0 and later and should not be used. For Android developers, we recommend choosing a temporary directory API provided by Android, such as context.getCacheDir(). For other Java developers, we recommend migrating to the Java 7 API java.nio.file.Files.createTempDirectory() which explicitly configures permissions of 700, or configuring the Java runtime's java.io.tmpdir system property to point to a location whose permissions are appropriately configured.