A flaw was found in 389 Directory Server. The ldap_utf8prev() function reads bytes before the start of a buffer without bounds checking, causing a heap buffer over-read in string filter parsing that may influence internal filter processing behavior.

A flaw was found in OpenShift Service Mesh 2.6.3 and 2.5.6. Rate-limiter avoidance, access-control bypass, CPU and memory exhaustion, and replay attacks may be possible due to improper HTTP header sanitization in Envoy.

In OpenShift Container Platform, a user with permissions to create or modify Routes can craft a payload that inserts a malformed entry into one of the cluster router's HAProxy configuration files. This malformed entry can match any arbitrary hostname, or all hostnames in the cluster, and direct traffic to an arbitrary application within the cluster, including one under attacker control.

An incorrect default permissions vulnerability was found in the mig-controller. Due to an incorrect cluster namespaces handling an attacker may be able to migrate a malicious workload to the target cluster, impacting confidentiality, integrity, and availability of the services located on that cluster.

A flaw was found in Red Hat Quay's container image upload process. An authenticated user with push access to any repository on the registry can interfere with image uploads in progress by other users, including those in repositories they do not have access to. This could allow the attacker to read, modify, or cancel another user's in-progress image upload.

A flaw was found in Red Hat Satellite in tfm-rubygem-foreman_azure_rm in versions before 2.2.0. A credential leak was identified which will expose Azure Resource Manager's secret key through JSON of the API output. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A vulnerability was found in 3Scale, when used with Keycloak 15 (or RHSSO 7.5.0) and superiors. When the auth_type is use_3scale_oidc_issuer_endpoint, the Token Introspection policy discovers the Token Introspection endpoint from the token_introspection_endpoint field, but the field was removed on RH-SSO 7.5. As a result, the policy doesn't inspect tokens, it determines that all tokens are valid.

A flaw was found in the Red Hat 3scale API Management Platform, where member permissions for an API's admin portal were not properly enforced. This flaw allows an authenticated user to bypass normal account restrictions and access API services where they do not have permission.

A vulnerability was found in Foreman's loader macros introduced with report templates. These macros may allow an authenticated user with permissions to view and create templates to read any field from Foreman's database. By using specific strings in the loader macros, users can bypass permissions and access sensitive information.

A flaw was found in atomic-openshift of openshift-4.2 where the basic-user RABC role in OpenShift Container Platform doesn't sufficiently protect the GlusterFS StorageClass against leaking of the restuserkey. An attacker with basic-user permissions is able to obtain the value of restuserkey, and use it to authenticate to the GlusterFS REST service, gaining access to read, and modify files.

A flaw was found in github.com/openshift/apiserver-library-go, used in OpenShift 4.12 and 4.11, that contains an issue that can allow low-privileged users to set the seccomp profile for pods they control to "unconfined." By default, the seccomp profile used in the restricted-v2 Security Context Constraint (SCC) is "runtime/default," allowing users to disable seccomp for pods they can create and modify.

Module: plugins/modules/nexmo.py CVSS 3.1: 6.5 MEDIUM — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N Issue: api_key and api_secret are declared no_log=True at the input level, but both credentials are immediately URL-encoded into a GET request as query parameters, bypassing all no_log protection. Vulnerable Code (lines 82-93): msg = { "api_key": module.params.get("api_key"), "api_secret": module.params.get("api_secret"), "from": module.params.get("src"), "text": module.params.get("msg"), } url = f"{NEXMO_API}?{urlencode(msg)}" response, info = fetch_url(module, url, headers=headers) Observed Output: https://rest.nexmo.com/sms/json?api_key=a1b2c3d4&api_secret=MyS3cr3tK3y!!&from=AnsibleBot&to=15551234567&text=Hello Exposure Vectors: Ansible verbose output (-vvv) logs the full request URL Vonage/Nexmo server access logs record credentials in query string HTTP proxies, SIEM, and network inspection tools capture the full URL AWX/Automation Controller network debug logs Fix: Switch to POST with credentials in the request body: data = urlencode({"api_key": api_key, "api_secret": api_secret, "from": src, "to": number, "text": msg}) fetch_url(module, NEXMO_API, data=data, method="POST", headers={"Content-Type": "application/x-www-form-urlencoded"})

ovirt-ansible-roles before version 1.0.6 has a vulnerability due to a missing no_log directive, resulting in the 'Add oVirt Provider to ManageIQ/CloudForms' playbook inadvertently disclosing admin passwords in the provisioning log. In an environment where logs are shared with other parties, this could lead to privilege escalation.

IBM App Connect Enterprise 11.0.0.17 through 11.0.0.19 and 12.0.4.0 and 12.0.5.0 contains an unspecified vulnerability in the Discovery Connector nodes which may cause a 3rd party system’s credentials to be exposed to a privileged attacker. IBM X-Force ID: 238211.

A flaw was found in ansible-collection-community-general. This vulnerability allows for information exposure (IE) of sensitive credentials, specifically plaintext passwords, via verbose output when running Ansible with debug modes. Attackers with access to logs could retrieve these secrets and potentially compromise Keycloak accounts or administrative access.

Module: plugins/modules/keyring_info.py CVSS 3.1: 5.5 MEDIUM — AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N Issue: The module retrieves a passphrase from the OS native keyring (GNOME Keyring, macOS Keychain, Windows Credential Manager) and places it directly into result["passphrase"] with no output suppression, no no_log protection, and no documentation warning. Root Cause: Line 105 (protected): keyring_password=dict(type="str", required=True, no_log=True) Line 127 (NOT protected): result["passphrase"] = passphrase Observed Output: { "changed": false, "passphrase": "MyMasterP@ssw0rd!SSH_Key_Secret" } Visible via register + debug: { "keyring_result": { "changed": false, "passphrase": "MyMasterP@ssw0rd!SSH_Key_Secret" } } Impact: Master passwords, SSH key passphrases and service credentials appear in all Ansible output register: keyring_result followed by debug: var=keyring_result prints passphrase in full Ansible fact caching backends (Redis, JSON file, memcached) may persist the passphrase AWX/Tower job logs silently store the live credential Fix: module.exit_json(changed=False, passphrase=passphrase, _ansible_no_log=True) Also add a documentation warning requiring callers to use no_log: true at the task level. PoCs Fig 1: PoC execution showing passphrase in plaintext output Fig 2: Source code showing no_log=True on input (line 105) vs unprotected output (line 127)

A flaw was found in the way Ansible (2.3.x before 2.3.3, and 2.4.x before 2.4.1) passed certain parameters to the jenkins_plugin module. Remote attackers could use this flaw to expose sensitive information from a remote host's logs. This flaw was fixed by not allowing passwords to be specified in the "params" argument, and noting this in the module documentation.

An access-control flaw was found in the OpenStack Orchestration (heat) service before 8.0.0, 6.1.0 and 7.0.2 where a service log directory was improperly made world readable. A malicious system user could exploit this flaw to access sensitive information.

A vulnerability was found in Quarkus CXF. Passwords and other secrets may appear in the application log in spite of the user configuring them to be hidden. This issue requires some special configuration to be vulnerable, such as SOAP logging enabled, application set client, and endpoint logging properties, and the attacker must have access to the application log.

A vulnerability was found in Red Hat OpenShift Jenkins. The bearer token is not obfuscated in the logs and potentially carries a high risk if those logs are centralized when collected. The token is typically valid for one year. This flaw allows a malicious user to jeopardize the environment if they have access to sensitive information.

ovirt-engine before version 4.1.7.6 with log level set to DEBUG includes passwords in the log file without masking. Only administrators can change the log level and only administrators can access the logs. This presents a risk when debug-level logs are shared with vendors or other parties to troubleshoot issues.

A flaw was found in the AMQ Broker that discloses JDBC encrypted usernames and passwords when provided in the AMQ Broker application logfile when using the jdbc persistence functionality. Versions shipped in Red Hat AMQ 7 are vulnerable.

A flaw was found in several ansible modules, where parameters containing credentials, such as secrets, were being logged in plain-text on managed nodes, as well as being made visible on the controller node when run in verbose mode. These parameters were not protected by the no_log feature. An attacker can take advantage of this information to steal those credentials, provided when they have access to the log files containing them. The highest threat from this vulnerability is to data confidentiality. This flaw affects Red Hat Ansible Automation Platform in versions before 1.2.2 and Ansible Tower in versions before 3.8.2.

A flaw was found in ansible. Credentials, such as secrets, are being disclosed in console log by default and not protected by no_log feature when using those modules. An attacker can take advantage of this information to steal those credentials. The highest threat from this vulnerability is to data confidentiality. Versions before ansible 2.9.18 are affected.

A flaw was found in ansible module where credentials are disclosed in the console log by default and not protected by the security feature when using the bitbucket_pipeline_variable module. This flaw allows an attacker to steal bitbucket_pipeline credentials. The highest threat from this vulnerability is to confidentiality.

A vulnerability was found in OpenShift Assisted Installer. During generation of the Discovery ISO, image pull secrets were leaked as plaintext in the installation logs. An authenticated user could exploit this by re-using the image pull secret to pull container images from the registry as the associated user.

A flaw was found in noobaa-operator in versions before 5.7.0, where internal RPC AuthTokens between the noobaa operator and the noobaa core are leaked into log files. An attacker with access to the log files could use this AuthToken to gain additional access into noobaa deployment and can read/modify system configuration.

A security flaw was found in Ansible Engine, all Ansible 2.7.x versions prior to 2.7.17, all Ansible 2.8.x versions prior to 2.8.11 and all Ansible 2.9.x versions prior to 2.9.7, when managing kubernetes using the k8s module. Sensitive parameters such as passwords and tokens are passed to kubectl from the command line, not using an environment variable or an input configuration file. This will disclose passwords and tokens from process list and no_log directive from debug module would not have any effect making these secrets being disclosed on stdout and log files.

An Improper Output Neutralization for Logs flaw was found in Ansible when using the uri module, where sensitive data is exposed to content and json output. This flaw allows an attacker to access the logs or outputs of performed tasks to read keys used in playbooks from other users within the uri module. The highest threat from this vulnerability is to data confidentiality.

A flaw was found in the Ansible Engine when using module_args. Tasks executed with check mode (--check-mode) do not properly neutralize sensitive data exposed in the event data. This flaw allows unauthorized users to read this data. The highest threat from this vulnerability is to confidentiality.

A flaw was found in OpenShift Container Platform version 4.1 and later. Sensitive information was found to be logged by the image registry operator allowing an attacker able to gain access to those logs, to read and write to the storage backing the internal image registry. The highest threat from this vulnerability is to data integrity.

A flaw was found in the OpenShift API Server, where it failed to sufficiently protect OAuthTokens by leaking them into the logs when an API Server panic occurred. This flaw allows an attacker with the ability to cause an API Server error to read the logs, and use the leaked OAuthToken to log into the API Server with the leaked token.

An information-disclosure flaw was found in the way Heketi before 10.1.0 logs sensitive information. This flaw allows an attacker with local access to the Heketi server to read potentially sensitive information such as gluster-block passwords.

On version 1.9.0, If DEBUG logging is enable, F5 Container Ingress Service (CIS) for Kubernetes and Red Hat OpenShift (k8s-bigip-ctlr) log files may contain BIG-IP secrets such as SSL Private Keys and Private key Passphrases as provided as inputs by an AS3 Declaration.

IBM Knowledge Catalog Standard Cartridge 5.0.0, 5.0.1, 5.0.2, 5.0.3, 5.1, 5.1.1, 5,1.2, 5.1.3, 5.2.0, 5.2.1 stores potentially sensitive information in log files that could be read by a local privileged user.

A vulnerability was found in Undertow web server before 2.0.21. An information exposure of plain text credentials through log files because Connectors.executeRootHandler:402 logs the HttpServerExchange object at ERROR level using UndertowLogger.REQUEST_LOGGER.undertowRequestFailed(t, exchange)

A vulnerability was found in ceilometer before version 12.0.0.0rc1. An Information Exposure in ceilometer-agent prints sensitive configuration data to log files without DEBUG logging being activated.

In Ansible, all Ansible Engine versions up to ansible-engine 2.8.5, ansible-engine 2.7.13, ansible-engine 2.6.19, were logging at the DEBUG level which lead to a disclosure of credentials if a plugin used a library that logged credentials at the DEBUG level. This flaw does not affect Ansible modules, as those are executed in a separate process.

Ansible, versions 2.9.x before 2.9.1, 2.8.x before 2.8.7 and Ansible versions 2.7.x before 2.7.15, is not respecting the flag no_log set it to True when Sumologic and Splunk callback plugins are used send tasks results events to collectors. This would discloses and collects any sensitive data.

A flaw was found in the JBoss EAP Vault system in all versions before 7.2.6.GA. Confidential information of the system property's security attribute value is revealed in the JBoss EAP log file when executing a JBoss CLI 'reload' command. This flaw can lead to the exposure of confidential information.

OpenShift Container Platform 4 does not sanitize secret data written to static pod logs when the log level in a given operator is set to Debug or higher. A low privileged user could read pod logs to discover secret material if the log level has already been modified in an operator by a privileged user.

The Kubernetes client-go library logs request headers at verbosity levels of 7 or higher. This can disclose credentials to unauthorized users via logs or command output. Kubernetes components (such as kube-apiserver) prior to v1.16.0, which make use of basic or bearer token authentication, and run at high verbosity levels, are affected.

OpenShift Container Platform, versions 4.1 and 4.2, does not sanitize secret data written to pod logs when the log level in a given operator is set to Debug or higher. A low privileged user could read pod logs to discover secret material if the log level has already been modified in an operator by a privileged user.

A flaw was found in, all under 2.0.20, in the Undertow DEBUG log for io.undertow.request.security. If enabled, an attacker could abuse this flaw to obtain the user's credentials from the log files.

A flaw was found in IPA, all 4.6.x versions before 4.6.7, all 4.7.x versions before 4.7.4 and all 4.8.x versions before 4.8.3, in the way that FreeIPA's batch processing API logged operations. This included passing user passwords in clear text on FreeIPA masters. Batch processing of commands with passwords as arguments or options is not performed by default in FreeIPA but is possible by third-party components. An attacker having access to system logs on FreeIPA masters could use this flaw to produce log file content with passwords exposed.

A flaw was found in keycloak in versions before 9.0.0. A logged exception in the HttpMethod class may leak the password given as parameter. The highest threat from this vulnerability is to data confidentiality.

It was discovered that a world-readable log file belonging to Candlepin component of Red Hat Satellite 6.4 leaked the credentials of the Candlepin database. A malicious user with local access to a Satellite host can use those credentials to modify the database and prevent Satellite from fetching package updates, thus preventing all Satellite hosts from accessing those updates.

An information-disclosure flaw was found in the way that gluster-block before 0.5.1 logs the output from gluster-block CLI operations. This includes recording passwords to the cmd_history.log file which is world-readable. This flaw allows local users to obtain sensitive information by reading the log file. The highest threat from this vulnerability is to data confidentiality.

The ovirt-engine-provisiondb utility in Red Hat Enterprise Virtualization (RHEV) Engine 4.0 allows local users to obtain sensitive database provisioning information by reading log files.

A vulnerability was found in Ansible engine 2.x up to 2.8 and Ansible tower 3.x up to 3.5. When a module has an argument_spec with sub parameters marked as no_log, passing an invalid parameter name to the module will cause the task to fail before the no_log options in the sub parameters are processed. As a result, data in the sub parameter fields will not be masked and will be displayed if Ansible is run with increased verbosity and present in the module invocation arguments for the task.