Medium CWE-532 CVEs
56 CVEs, 1 protected by Waratek
Overview 56 matches · 1 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
Protected by Waratek
1
1.8%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
55
98.2%
blocked by ARMR today
1
1.8%
partly blocked
0
0.0%
not blocked
55
98.2%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
1
1.8%
Forecast only
0
0.0%
No public exploit
55
98.2%
split by
peak 14 / year
20181
No exploit published1
Medium1
not blocked1
No public exploit1
20196
No exploit published6
Medium6
not blocked6
No public exploit6
20205
No exploit published5
Medium5
not blocked5
No public exploit5
20213
No exploit published3
Medium3
not blocked3
No public exploit3
20222
No exploit published2
Medium2
not blocked2
No public exploit2
20239
No exploit published9
Medium9
not blocked9
No public exploit9
20249
No exploit published9
Medium9
not blocked9
Proof of concept only1
No public exploit8
20257
No exploit published7
Medium7
not blocked7
No public exploit7
202614
Protected by Waratek1
No exploit published13
Medium14
blocked by ARMR today1
not blocked13
No public exploit14
201820192020202120222023202420252026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-18800 | Medium | 2026-11-02 | No exploit published | No public exploit | When an Event Publisher output adapter is configured with properties that are irrelevant to its function, the affected products log these irrelevant properties. This can inadvertently include sensitive user credentials or other confidential information depending on the nature of the misconfigured property. A malicious actor with access to the 'wso2carbon' log files could retrieve sensitive information logged by the system. This may potentially lead to unauthorized access if the logged data contains credentials or other critical secrets. |
| CVE-2026-111762 | Medium | 2026-10-20 | Protected by Waratek | No public exploit | A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Prior to 1.3.0.Final, RestHandler.parseRequestBody in `transport/rest/src/main/java/org/a2aproject/sdk/transport/rest/handler/RestHandler.java` logs the entire JSON request body at SEVERE level when JsonFormat.parser().merge() throws InvalidProtocolBufferException. With push notifications enabled, createTaskPushNotificationConfiguration reaches this parser for requests to `/v1/tenants/{tenant}/tasks/{taskId}/pushNotificationConfigs`, whose token and authentication.credentials fields can contain bearer tokens and authentication credentials for client push endpoints. A valid JSON body that fails protobuf deserialization, including an unknown field under strict parsing or a schema mismatch, causes those secrets to be written to the server logs in cleartext. An attacker with access to the server logs or a log aggregation system can retrieve the credentials and potentially use the credentials to send forged task status updates to the client's push notification endpoint. This issue is fixed in version 1.3.0.Final. |
| CVE-2026-85260 | Medium | 2026-10-19 | No exploit published | No public exploit | Insertion of Sensitive Information into Log File vulnerability in Apache Camel MLLP component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The camel-mllp component carries a logPhi option that governs whether HL7 payload content may be written to the log. It defaulted to true, so a deployment that did nothing logged protected health information out of the box. Two further paths wrote payload content to the log regardless of the setting, so even an operator who had turned logPhi off was still exposed on those paths. MLLP is used to carry HL7 clinical messages, so the content concerned is patient data, and it reached ordinary application logs where it is subject to whatever retention, aggregation and access the deployment applies to logs generally rather than to clinical records. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. logPhi now defaults to false and is honoured on the paths that previously ignored it. This is a changed default: a deployment that relied on payload logging must now set logPhi=true explicitly. Because the upgrade guide for a change like this lives on the main branch only, operators upgrading within the 4.18.x or 4.22.x lines should treat this advisory as the notice of that change. For deployments that cannot upgrade immediately, set logPhi=false and be aware that two paths will continue to log payload content until the fix is applied; restrict access to the logs accordingly. |
| CVE-2026-86597 | Medium | 2026-09-08 | No exploit published | No public exploit | Insertion of sensitive information into log files in the Snowflake Python, Go, JDBC, Node.js, PHP PDO, and ODBC drivers allowed authentication tokens, query-result encryption keys, pre-signed cloud-storage URLs, and SAML assertions to be written to diagnostic logs in circumstances where the available log redaction did not cover all affected log paths and data types. An attacker with read access to the log destination, whether the local filesystem, a log aggregation service, or a CI/CD artifact store, could obtain credentials and decryption keys that, if still valid at the time of access, could be used to authenticate to the corresponding Snowflake account or cloud-storage object. Successful exploitation requires read access to the log destination, and impact is bounded by credential lifetime and object scope. The fix is available in Snowflake Connector for Python v4.7.3, Snowflake Go Driver v2.2.0, Snowflake JDBC Driver v4.3.4 (including the snowflake-jdbc-fips and snowflake-jdbc-thin), Snowflake Node.js Driver v3.3.0, Snowflake PHP PDO Driver v4.2.0, and Snowflake ODBC Driver v3.20.0. Users must manually upgrade and should securely delete previously generated diagnostic logs containing sensitive information where retention is not required. |
| CVE-2026-59302 | Medium | 2026-08-27 | No exploit published | No public exploit | Potential for logging sensitive data in Spring Cloud Stream. Spring Cloud Stream 5.0.0 - 5.0.2 Spring Cloud Stream 4.3.0 - 4.3.3 Spring Cloud Stream 4.2.0 - 4.2.6 |
| CVE-2026-59301 | Medium | 2026-08-27 | No exploit published | No public exploit | Potential for logging sensitive data in Spring Cloud Function Azure. Spring Cloud Function 5.0.0 - 5.0.3 Spring Cloud Function 4.3.0 - 4.3.4 Spring Cloud Function 4.2.0 - 4.2.7 |
| CVE-2026-54704 | Medium | 2026-07-01 | No exploit published | No public exploit | OpenTelemetry Java Instrumentation provides OpenTelemetry auto-instrumentation and instrumentation libraries for Java. In versions prior to 2.28.0, the JDBC auto-instrumentation may fail to sanitize passwords in SQL CONNECT statements when the password is double-quoted. As a result, clear-text database passwords can be added to trace span attributes and exported to observability backends. This issue has been fixed in version 2.28.0. |
| CVE-2026-45581 | Medium | 2026-06-08 | No exploit published | No public exploit | fabric-chaincode-java is a Java based implementation of Hyperledger Fabric chaincode shim APIs. From version 2.3.1 to before version 2.5.10, when chaincode is deployed in chaincode-as-a-service mode with TLS enabled, the chaincode server INFO level logging includes the TLS private key password in plaintext. An attacker with access to the chaincode server logs could recover the TLS private key password. If the attacker can also obtain the TLS private key, they could impersonate the chaincode server. This issue has been patched in version 2.5.10. |
| CVE-2026-41004 | Medium | 2026-05-07 | No exploit published | No public exploit | When enabling trace logging in Spring Cloud Config Server sensitive information was placed in plain text in the logs. Spring Cloud Config 3.1.x: affected from 3.1.0 through 3.1.13 (inclusive); upgrade to 3.1.14 or greater (Enterprise Support Only). Spring Cloud Config 4.1.x: affected from 4.1.0 through 4.1.9 (inclusive); upgrade to 4.1.10 or greater (Enterprise Support Only). Spring Cloud Config 4.2.x: affected from 4.2.0 through 4.2.6 (inclusive); upgrade to 4.2.7 or greater (Enterprise Support Only). Spring Cloud Config 4.3.x: affected from 4.3.0 through 4.3.2 (inclusive); upgrade to 4.3.3 or greater. Spring Cloud Config 5.0.x: affected from 5.0.0 through 5.0.2 (inclusive); upgrade to 5.0.3 or greater. |
| CVE-2026-33558 | Medium | 2026-04-20 | No exploit published | No public exploit | Information exposure vulnerability has been identified in Apache Kafka. The NetworkClient component will output entire requests and responses information in the DEBUG log level in the logs. By default, the log level is set to INFO level. If the DEBUG level is enabled, the sensitive information will be exposed via the requests and responses output log. The entire lists of impacted requests and responses are: * AlterConfigsRequest * AlterUserScramCredentialsRequest * ExpireDelegationTokenRequest * IncrementalAlterConfigsRequest * RenewDelegationTokenRequest * SaslAuthenticateRequest * createDelegationTokenResponse * describeDelegationTokenResponse * SaslAuthenticateResponse This issue affects Apache Kafka: from any version supported the listed API above through v3.9.1, v4.0.0. We advise the Kafka users to upgrade to v3.9.2, v4.0.1, or later to avoid this vulnerability. |
| CVE-2026-34164 | Medium | 2026-04-16 | No exploit published | No public exploit | Valtimo is an open-source business process automation platform. In versions 13.0.0 through 13.21.0, the InboxHandlingService logs the full content of every incoming inbox message at INFO level. Inbox messages can contain highly sensitive information including personal data (PII), citizen identifiers (BSN), and case details. This data is exposed to anyone with access to application logs or any Valtimo user with the admin role through the Admin UI logging module. This issue has been fixed in version 13.22.0. If developers are unable to upgrade immediately, they can restrict access to application logs and adjust the log level for com.ritense.inbox to WARN or higher in their application configuration as a workaround. |
| CVE-2026-27315 | Medium | 2026-04-07 | No exploit published | No public exploit | Sensitive Information Leak in cqlsh in Apache Cassandra 4.0 allows access to sensitive information, like passwords, from previously executed cqlsh command via ~/.cassandra/cqlsh_history local file access. Users are recommended to upgrade to version 4.0.20, which fixes this issue. -- Description: Cassandra's command-line tool, cqlsh, provides a command history feature that allows users to recall previously executed commands using the up/down arrow keys. These history records are saved in the ~/.cassandra/cqlsh_history file in the user's home directory. However, cqlsh does not redact sensitive information when saving command history. This means that if a user executes operations involving passwords (such as logging in or creating users) within cqlsh, these passwords are permanently stored in cleartext in the history file on the disk. |
| CVE-2026-1622 | Medium | 2026-02-04 | No exploit published | No public exploit | Neo4j Enterprise and Community editions versions prior to 2026.01.3 and 5.26.21 are vulnerable to a potential information disclosure by a user who has ability to access the local log files. The "obfuscate_literals" option in the query logs does not redact error information, exposing unredacted data in the query log when a customer writes a query that fails. It can allow a user with legitimate access to the local log files to obtain information they are not authorised to see. If this user is also in a position to run queries and trigger errors, this vulnerability can potentially help them to infer information they are not authorised to see through their intended database access. We recommend upgrading to versions 2026.01.3 (or 5.26.21) where the issue is fixed, and reviewing query log files permissions to ensure restricted access. If your configuration had db.logs.query.obfuscate_literals enabled, and you wish the obfuscation to cover the error messages as well, you need to enable the new configuration setting db.logs.query.obfuscate_errors once you have upgraded Neo4j. |
| CVE-2025-59355 | Medium | 2026-01-19 | No exploit published | No public exploit | A vulnerability. When org.apache.linkis.metadata.util.HiveUtils.decode() fails to perform Base64 decoding, it records the complete input parameter string in the log via logger.error(str + "decode failed", e). If the input parameter contains sensitive information such as Hive Metastore keys, plaintext passwords will be left in the log files when decoding fails, resulting in information leakage. Affected Scope Component: Sensitive fields in hive-site.xml (e.g., javax.jdo.option.ConnectionPassword) or other fields encoded in Base64. Version: Apache Linkis 1.0.0 – 1.7.0 Trigger Conditions The value of the configuration item is an invalid Base64 string. Log files are readable by users other than hive-site.xml administrators. Severity: Low The probability of Base64 decoding failure is low. The leakage is only triggered when logs at the Error level are exposed. Remediation Apache Linkis 1.8.0 and later versions have replaced the log with desensitized content. logger.error("URL decode failed: {}", e.getMessage()); // 不再输出 str Users are recommended to upgrade to version 1.8.0, which fixes the issue. |
| CVE-2025-62262 | Medium | 2025-10-27 | No exploit published | No public exploit | Information exposure through log file vulnerability in LDAP import feature in Liferay Portal 7.4.0 through 7.4.3.97, and older unsupported versions, and Liferay DXP 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions allows local users to view user email address in the log files. |
| CVE-2025-37727 | Medium | 2025-10-10 | No exploit published | No public exploit | Insertion of sensitive information in log file in Elasticsearch can lead to loss of confidentiality under specific preconditions when auditing requests to the reindex API https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-reindex |
| CVE-2025-49009 | Medium | 2025-06-05 | No exploit published | No public exploit | Para is a multitenant backend server/framework for object persistence and retrieval. A vulnerability that exists in versions prior to 1.50.8 in `FacebookAuthFilter.java` results in a full request URL being logged during a failed request to a Facebook user profile. The log includes the user's access token in plain text. Since WARN-level logs are often retained in production and accessible to operators or log aggregation systems, this poses a risk of token exposure. Version 1.50.8 fixes the issue. |
| CVE-2025-48955 | Medium | 2025-06-02 | No exploit published | No public exploit | Para is a multitenant backend server/framework for object persistence and retrieval. A vulnerability that exists in versions prior to 1.50.8 exposes both access and secret keys in logs without redaction. These credentials are later reused in variable assignments for persistence but do not require logging for debugging or system health purposes. Version 1.50.8 fixes the issue. |
| CVE-2025-30677 | Medium | 2025-04-09 | No exploit published | No public exploit | Apache Pulsar contains multiple connectors for integrating with Apache Kafka. The Pulsar IO Apache Kafka Source Connector, Sink Connector, and Kafka Connect Adaptor Sink Connector log sensitive configuration properties in plain text in application logs. This vulnerability can lead to unintended exposure of credentials in log files, potentially allowing attackers with access to these logs to obtain Apache Kafka credentials. The vulnerability's impact is limited by the fact that an attacker would need access to the application logs to exploit this issue. This issue affects Apache Pulsar IO's Apache Kafka connectors in all versions before 3.0.11, 3.3.6, and 4.0.4. 3.0.x version users should upgrade to at least 3.0.11. 3.3.x version users should upgrade to at least 3.3.6. 4.0.x version users should upgrade to at least 4.0.4. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions. |
| CVE-2025-27391 | Medium | 2025-04-09 | No exploit published | No public exploit | Insertion of Sensitive Information into Log File vulnerability in Apache ActiveMQ Artemis. All the values of the broker properties are logged when the org.apache.activemq.artemis.core.config.impl.ConfigurationImpl logger has the debug level enabled. This issue affects Apache ActiveMQ Artemis: from 1.5.1 before 2.40.0. It can be mitigated by restricting log access to only trusted users. Users are recommended to upgrade to version 2.40.0, which fixes the issue. |
| CVE-2025-0736 | Medium | 2025-01-28 | No exploit published | No public exploit | A flaw was found in Infinispan, when using JGroups with JDBC_PING. This issue occurs when an application inadvertently exposes sensitive information, such as configuration details or credentials, through logging mechanisms. This exposure can lead to unauthorized access and exploitation by malicious actors. |
| CVE-2024-52067 | Medium | 2024-11-21 | No exploit published | No public exploit | Apache NiFi 1.16.0 through 1.28.0 and 2.0.0-M1 through 2.0.0-M4 include optional debug logging of Parameter Context values during the flow synchronization process. An authorized administrator with access to change logging levels could enable debug logging for framework flow synchronization, causing the application to write Parameter names and values to the application log. Parameter Context values may contain sensitive information depending on application flow configuration. Deployments of Apache NiFi with the default Logback configuration do not log Parameter Context values. Upgrading to Apache NiFi 2.0.0 or 1.28.1 is the recommendation mitigation, eliminating Parameter value logging from the flow synchronization process regardless of the Logback configuration. |
| CVE-2024-9621 | Medium | 2024-10-08 | No exploit published | No public exploit | 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. |
| CVE-2023-49921 | Medium | 2024-07-26 | No exploit published | No public exploit | An issue was discovered by Elastic whereby Watcher search input logged the search query results on DEBUG log level. This could lead to raw contents of documents stored in Elasticsearch to be printed in logs. Elastic has released 8.11.2 and 7.17.16 that resolves this issue by removing this excessive logging. This issue only affects users that use Watcher and have a Watch defined that uses the search input and additionally have set the search input’s logger to DEBUG or finer, for example using: org.elasticsearch.xpack.watcher.input.search, org.elasticsearch.xpack.watcher.input, org.elasticsearch.xpack.watcher, or wider, since the loggers are hierarchical. |
| CVE-2024-39460 | Medium | 2024-06-26 | No exploit published | No public exploit | Jenkins Bitbucket Branch Source Plugin 886.v44cf5e4ecec5 and earlier prints the Bitbucket OAuth access token as part of the Bitbucket URL in the build log in some cases. |
| CVE-2024-38460 | Medium | 2024-06-16 | No exploit published | No public exploit | In SonarQube before 10.4 and 9.9.4 LTA, encrypted values generated using the Settings Encryption feature are potentially exposed in cleartext as part of the URL parameters in the logs (such as SonarQube Access Logs, Proxy Logs, etc). |
| CVE-2024-1102 | Medium | 2024-04-25 | No exploit published | No public exploit | A vulnerability was found in jberet-core logging. An exception in 'dbProperties' might display user credentials such as the username and password for the database-connection. |
| CVE-2024-28154 | Medium | 2024-03-06 | No exploit published | No public exploit | Jenkins MQ Notifier Plugin 1.4.0 and earlier logs potentially sensitive build parameters as part of debug information in build logs by default. |
| CVE-2023-50740 | Medium | 2024-03-06 | No exploit published | No public exploit | In Apache Linkis <=1.4.0, The password is printed to the log when using the Oracle data source of the Linkis data source module. We recommend users upgrade the version of Linkis to version 1.5.0 |
| CVE-2024-23686 | Medium | 2024-01-19 | No exploit published | Proof of concept only | DependencyCheck for Maven 9.0.0 to 9.0.6, for CLI version 9.0.0 to 9.0.5, and for Ant versions 9.0.0 to 9.0.5, when used in debug mode, allows an attacker to recover the NVD API Key from a log file. |
| CVE-2023-31417 | Medium | 2023-10-26 | No exploit published | No public exploit | Elasticsearch generally filters out sensitive information and credentials before logging to the audit log. It was found that this filtering was not applied when requests to Elasticsearch use certain deprecated URIs for APIs. The impact of this flaw is that sensitive information such as passwords and tokens might be printed in cleartext in Elasticsearch audit logs. Note that audit logging is disabled by default and needs to be explicitly enabled and even when audit logging is enabled, request bodies that could contain sensitive information are not printed to the audit log unless explicitly configured. |
| CVE-2023-44483 | Medium | 2023-10-20 | No exploit published | No public exploit | All versions of Apache Santuario - XML Security for Java prior to 2.2.6, 2.3.4, and 3.0.3, when using the JSR 105 API, are vulnerable to an issue where a private key may be disclosed in log files when generating an XML Signature and logging with debug level is enabled. Users are recommended to upgrade to version 2.2.6, 2.3.4, or 3.0.3, which fixes this issue. |
| CVE-2023-41934 | Medium | 2023-09-06 | No exploit published | No public exploit | Jenkins Pipeline Maven Integration Plugin 1330.v18e473854496 and earlier does not properly mask (i.e., replace with asterisks) usernames of credentials specified in custom Maven settings in Pipeline build logs if "Treat username as secret" is checked. |
| CVE-2023-40338 | Medium | 2023-08-16 | No exploit published | No public exploit | Jenkins Folders Plugin 6.846.v23698686f0f6 and earlier displays an error message that includes an absolute path of a log file when attempting to access the Scan Organization Folder Log if no logs are available, exposing information about the Jenkins controller file system. |
| CVE-2023-29471 | Medium | 2023-04-27 | No exploit published | No public exploit | Lightbend Alpakka Kafka before 5.0.0 logs its configuration as debug information, and thus log files may contain credentials (if plain cleartext login is configured). This occurs in akka.kafka.internal.KafkaConsumerActor. |
| CVE-2022-43772 | Medium | 2023-04-03 | No exploit published | No public exploit | Hitachi Vantara Pentaho Business Analytics Server versions before 9.4.0.0 and 9.3.0.1, including 8.3.x with the Big Data Plugin expose the username and password of clusters in clear text into system logs. |
| CVE-2023-25721 | Medium | 2023-03-28 | No exploit published | No public exploit | Veracode Scan Jenkins Plugin before 23.3.19.0, when the "Connect using proxy" option is enabled and configured with proxy credentials and when the Jenkins global system setting debug is enabled and when a scan is configured for remote agent jobs, allows users (with access to view the job log) to discover proxy credentials. |
| CVE-2023-20859 | Medium | 2023-03-23 | No exploit published | No public exploit | In Spring Vault, versions 3.0.x prior to 3.0.2 and versions 2.3.x prior to 2.3.3 and older versions, an application is vulnerable to insertion of sensitive information into a log file when it attempts to revoke a Vault batch token. |
| CVE-2023-0815 | Medium | 2023-02-23 | No exploit published | No public exploit | Potential Insertion of Sensitive Information into Jetty Log Files in multiple versions of OpenNMS Meridian and Horizon could allow disclosure of usernames and passwords if the logging level is set to debug. Users should upgrade to Meridian 2023.1.0 or newer, or Horizon 31.0.4. Meridian and Horizon installation instructions state that they are intended for installation within an organization's private networks and should not be directly accessible from the Internet. |
| CVE-2022-31684 | Medium | 2022-10-19 | No exploit published | No public exploit | Reactor Netty HTTP Server, in versions 1.0.11 - 1.0.23, may log request headers in some cases of invalid HTTP requests. The logged headers may reveal valid access tokens to those with access to server logs. This may affect only invalid HTTP requests where logging at WARN level is enabled. |
| CVE-2022-27195 | Medium | 2022-03-15 | No exploit published | No public exploit | Jenkins Parameterized Trigger Plugin 2.43 and earlier captures environment variables passed to builds triggered using Jenkins Parameterized Trigger Plugin, including password parameter values, in their `build.xml` files. These values are stored unencrypted and can be viewed by users with access to the Jenkins controller file system. |
| CVE-2021-3425 | Medium | 2021-06-01 | No exploit published | No public exploit | 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. |
| CVE-2021-21361 | Medium | 2021-03-09 | No exploit published | No public exploit | The `com.bmuschko:gradle-vagrant-plugin` Gradle plugin contains an information disclosure vulnerability due to the logging of the system environment variables. When this Gradle plugin is executed in public CI/CD, this can lead to sensitive credentials being exposed to malicious actors. This is fixed in version 3.0.0. |
| CVE-2020-7021 | Medium | 2021-02-10 | No exploit published | No public exploit | Elasticsearch versions before 7.10.0 and 6.8.14 have an information disclosure issue when audit logging and the emit_request_body option is enabled. The Elasticsearch audit log could contain sensitive information such as password hashes or authentication tokens. This could allow an Elasticsearch administrator to view these details. |
| CVE-2020-25640 | Medium | 2020-11-24 | No exploit published | No public exploit | A flaw was discovered in WildFly before 21.0.0.Final where, Resource adapter logs plain text JMS password at warning level on connection error, inserting sensitive information in the log file. |
| CVE-2020-1698 | Medium | 2020-05-11 | No exploit published | No public exploit | 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. |
| CVE-2020-7599 | Medium | 2020-03-30 | No exploit published | No public exploit | All versions of com.gradle.plugin-publish before 0.11.0 are vulnerable to Insertion of Sensitive Information into Log File. When a plugin author publishes a Gradle plugin while running Gradle with the --info log level flag, the Gradle Logger logs an AWS pre-signed URL. If this build log is publicly visible (as it is in many popular public CI systems like TravisCI) this AWS pre-signed URL would allow a malicious actor to replace a recently uploaded plugin with their own. |
| CVE-2020-1928 | Medium | 2020-01-28 | No exploit published | No public exploit | An information disclosure vulnerability was found in Apache NiFi 1.10.0. The sensitive parameter parser would log parsed values for debugging purposes. This would expose literal values entered in a sensitive property when no parameter was present. |
| CVE-2019-14885 | Medium | 2020-01-23 | No exploit published | No public exploit | 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. |
| CVE-2019-10370 | Medium | 2019-08-07 | No exploit published | No public exploit | Jenkins Mask Passwords Plugin 2.12.0 and earlier transmits globally configured passwords in plain text as part of the configuration form, potentially resulting in their exposure. |
| CVE-2019-10367 | Medium | 2019-08-07 | No exploit published | No public exploit | Due to an incomplete fix of CVE-2019-10343, Jenkins Configuration as Code Plugin 1.26 and earlier did not properly apply masking to some values expected to be hidden when logging the configuration being applied. |
| CVE-2019-10364 | Medium | 2019-07-31 | No exploit published | No public exploit | Jenkins Amazon EC2 Plugin 1.43 and earlier wrote the beginning of private keys to the Jenkins system log. |
| CVE-2019-10358 | Medium | 2019-07-31 | No exploit published | No public exploit | Jenkins Maven Integration Plugin 3.3 and earlier did not apply build log decorators to module builds, potentially revealing sensitive build variables in the build log. |
| CVE-2019-10345 | Medium | 2019-07-31 | No exploit published | No public exploit | Jenkins Configuration as Code Plugin 1.20 and earlier did not treat the proxy password as a secret to be masked when logging or encrypted for export. |
| CVE-2019-10194 | Medium | 2019-07-11 | No exploit published | No public exploit | Sensitive passwords used in deployment and configuration of oVirt Metrics, all versions. were found to be insufficiently protected. Passwords could be disclosed in log files (if playbooks are run with -v) or in playbooks stored on Metrics or Bastion hosts. |
| CVE-2018-1999036 | Medium | 2018-08-01 | No exploit published | No public exploit | An exposure of sensitive information vulnerability exists in Jenkins SSH Agent Plugin 1.15 and earlier in SSHAgentStepExecution.java that exposes the SSH private key password to users with permission to read the build log. |