Overview 233 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
233matches
0protected0.0%
0exploited0.0%
0CISA KEV0.0%
0public PoC0.0%
0EPSS ≥ 0.50.0%
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
233
100.0%
Outside Waratek scope
0
0.0%
Not applicable
0
0.0%
Withdrawn CVE
0
0.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
233
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
4
1.7%
Forecast only
0
0.0%
No public exploit
229
98.3%
split by
peak 65 / year
20151
No exploit published1
Medium1
not blocked1
No public exploit1
20160
20172
No exploit published2
Critical1
Medium1
not blocked2
No public exploit2
201811
No exploit published11
High9
Medium2
not blocked11
No public exploit11
201965
No exploit published65
High37
Medium28
not blocked65
No public exploit65
202036
No exploit published36
High5
Medium28
Low3
not blocked36
No public exploit36
20217
No exploit published7
High1
Medium6
not blocked7
No public exploit7
202249
No exploit published49
High8
Medium40
Low1
not blocked49
Proof of concept only1
No public exploit48
202314
No exploit published14
High4
Medium10
not blocked14
Proof of concept only1
No public exploit13
20246
No exploit published6
High4
Medium2
not blocked6
No public exploit6
202519
No exploit published19
High1
Medium17
Low1
not blocked19
No public exploit19
202623
No exploit published23
Critical5
High3
Medium14
Unknown1
not blocked23
Proof of concept only2
No public exploit21
201520162017201820192020202120222023202420252026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-97867 | Unknown | 2026-11-10 | No exploit published | No public exploit | The EJBd remote protocol returns datasource connection details, including database credentials, to remote clients that look up a datasource. A remote client able to reach the EJBd endpoint can obtain the database credentials and connect to the database directly. Users are recommended to upgrade to version 10.3.0 or 11.0.0-M2, which fix the issue. |
| CVE-2026-73116 | Critical | 2026-11-05 | No exploit published | No public exploit | Insufficiently Protected Credentials vulnerability in Apache Juneau. The Apache Juneau RestClient followed HTTP redirects while keeping credential headers from the original request, so a server that redirected the client to a different host or port, or from HTTPS to HTTP, could receive headers such as Authorization, Cookie, Proxy-Authorization and X-API-Key. This issue affects Apache Juneau: through 9.2.0. Users are recommended to upgrade to version 9.2.1, which fixes the issue. The fix applies to HTTP clients created by the RestClient builder; applications that supply their own HttpClient must disable automatic redirects or strip credential headers on cross-origin redirects themselves. |
| CVE-2026-111765 | High | 2026-10-20 | No exploit published | Proof of concept only | A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Starting in version 1.3.0.Final and prior to version 1.3.2.Final, the AndroidA2AHttpClient synchronous POST path overrides the disabled-redirect setting in AndroidA2AHttpClient.createConnection() with the PostBuilder default followRedirects value of true, leaving a residual of the earlier credential-redirect fix. JSONRPCTransport and RestTransport add interceptor-produced authentication headers and call synchronous post() without disabling redirects. AuthInterceptor permits X-API-Key, API-Key, X-Auth-Token, and X-Authentication headers; Android's repackaged OkHttp strips Authorization on cross-authority redirects but retains these nonstandard headers, disclosing a complete configured API key or token to another authority. The additional exposure applies when redirect or front-door behavior is compromised separately from the credential-handling component, or those components operate in different trust domains; a completely malicious initial origin already receives the credential on the first request. Autonomous clients require no human action, while user-invoked workflows can require interaction. Explicit followRedirects(false) prevents the redirected request. The demonstrated impact is credential disclosure, not subsequent credential use, integrity or availability impact, code execution, or host compromise. This issue is fixed in version 1.3.2.Final. |
| CVE-2026-111763 | Medium | 2026-10-20 | No exploit published | No public exploit | A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Prior to 1.3.0.Final, a malicious or compromised remote agent can cause the default JDK-based client to forward a configured API key to a third-party server. When a client application configures credentials through `CredentialService`, `AuthInterceptor.intercept` in `client/transport/spi/src/main/java/org/a2aproject/sdk/client/transport/spi/interceptors/auth/AuthInterceptor.java` uses `APIKeySecurityScheme.name()` from the remote AgentCard directly as the HTTP header name containing the credential, without checking that the declared location is HEADER. JdkA2AHttpClient uses followRedirects(NORMAL), so an agent-controlled cross-origin redirect forwards the custom credential-bearing header even when the standard Authorization header is stripped. The attack requires configured API key credentials for the agent's security scheme and control of the agent's AgentCard and redirect response, but no additional client privileges. This issue is fixed in version 1.3.0.Final. |
| CVE-2026-107285 | Medium | 2026-10-07 | No exploit published | No public exploit | The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.12 and 2.16.1, a proxied ws request is carried through CONNECT, but NettyRequestFactory.newNettyRequest and requestUri decide whether to attach proxy authentication and an absolute-form target only from whether the URI is secure. Because ws is not marked secure, the tunneled WebSocket upgrade sent to the origin includes the proxy's Proxy-Authorization value. Basic credentials are directly recoverable and Digest responses can be replayed or cracked offline. This issue is fixed in versions 3.0.12 and 2.16.1. |
| CVE-2026-107282 | Critical | 2026-10-07 | No exploit published | No public exploit | The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.13 and 2.16.1, cross-host request replay updates the current request but leaves the target request and related proxy context pointing at the original origin. Connection-pool selection, CONNECT handling, realm selection, and TLS setup can consequently send the original host's path, Host header, Authorization credentials, or plaintext request to the replay destination. Documented ResponseFilter failover and retry paths can trigger the replay. This issue is fixed in versions 3.0.13 and 2.16.1. |
| CVE-2026-107231 | High | 2026-10-07 | No exploit published | No public exploit | The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.13 and 2.16.1, Realm.Builder treats a Digest challenge that yields no usable nonce as a Basic challenge. A malicious origin or proxy can label a challenge Digest while omitting or emptying the nonce, causing the client to resend the username and password using reversible Basic authentication. Both origin and proxy challenge parsers are affected. This issue is fixed in versions 3.0.13 and 2.16.1. |
| CVE-2026-85720 | Medium | 2026-09-17 | No exploit published | No public exploit | The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.0.0 until 2.16.1 and 3.0.12, a request using an HTTP proxy to reach an HTTPS origin can expose preemptive origin credentials because NettyRequestFactory and NettyRequestSender.sendRequestWithNewChannel attach Authorization to the plaintext CONNECT request before the TLS tunnel exists. Basic or Digest credentials and per-connection NTLM, Kerberos, or SPNEGO tokens intended for the origin are therefore visible to the proxy and to observers on the client-to-proxy hop. The tunneled request still receives origin Authorization after the tunnel is established, while Proxy-Authorization remains on CONNECT for its intended proxy recipient. This issue is fixed in versions 2.16.1 and 3.0.12. |
| CVE-2026-85717 | Medium | 2026-09-17 | No exploit published | No public exploit | The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.14.5 to 2.16.0 and from 3.0.9 to 3.0.11, a client configured with a client-wide Realm and redirect following can disclose credentials after a cross-origin redirect because the Interceptors authentication path falls back to the client configuration after redirect handling clears the per-exchange realm. If the attacker-controlled target returns 401, the client can send Basic or Digest credentials or a Negotiate or NTLM token to that origin. Per-request realms are stripped correctly, and this issue is a residual bypass of the earlier cross-origin credential-stripping fixes. This issue is fixed in versions 2.16.1 and 3.0.12. |
| CVE-2026-92133 | Medium | 2026-09-16 | No exploit published | No public exploit | Jenkins GitLab Plugin 1.2149.vcfc32c82b_f7f and earlier caches the GitLab API client built for alternative GitLab API token credentials under a cache key derived from the credentials ID alone, omitting the folder in which the credentials are resolved, allowing attackers with Item/Configure permission to access GitLab API token credentials they are not entitled to use. |
| CVE-2026-84179 | Medium | 2026-09-14 | No exploit published | No public exploit | Description getTopologyPageInfo merged the Nimbus daemon configuration with the topology's own configuration and returned the result without redaction in the topology_conf field of TopologyPageInfo. The Storm UI copied that value verbatim into the configuration field of GET /api/v1/topology/{id} and of the corresponding metrics endpoint. Where the cluster is configured with them, the merged map includes storm.zookeeper.auth.payload, which Storm's own documentation directs operators to keep in storm-cluster-auth.yaml under permissions that deny access from workers, together with the keystore and truststore passwords for the Thrift, Netty and ZooKeeper TLS configuration, and any plugin key whose name denotes a secret. getTopologyPageInfo is a topology read-only operation. Under SimpleACLAuthorizer a principal listed in topology.readonly.users or topology.readonly.groups could therefore read daemon credentials that the dedicated cluster configuration API, getNimbusConf, redacts and that is gated on nimbus.users instead. The sibling operations that exist to serve configuration were masked; the topology page, which merges in strictly more daemon state, was not. Mitigation Upgrade to 3.1.0, where credential-bearing values are masked before any configuration is served over the Nimbus API. Users who cannot upgrade immediately should remove any principal that is not trusted with cluster credentials from topology.readonly.users, topology.readonly.groups, topology.users and topology.groups, and should rotate the ZooKeeper authentication payload and any TLS keystore or truststore passwords that were reachable through the topology page. Credit Wanxin Yin (yaklang.io) reported this issue to the Apache Security Team. |
| CVE-2026-82434 | Critical | 2026-09-14 | No exploit published | No public exploit | Description When ZooKeeper authentication is configured, Storm deliberately retains `storm.zookeeper.topology.auth.payload` in the topology configuration, because workers need it. Nimbus then served that configuration verbatim to any caller holding read-only topology permissions, so a user whose only grant was the ability to view a topology received its ZooKeeper credential. That credential is not read-only. The cluster state implementation uses write-capable ACLs for worker heartbeats, backpressure and error state, so a recipient can forge or remove that state for the topology concerned. It is not a write credential on assignments. The same advisory covers the submission client, which logged the generated payload at INFO on every submission that generated one, and the SASL handlers, which logged it at DEBUG. The credential therefore also reached any log aggregation or support bundle collected from the cluster. Mitigation Upgrade to 3.1.0, where the payload is removed from the configuration served to read-only callers and is no longer written to logs. Users who cannot upgrade immediately should rotate `storm.zookeeper.topology.auth.payload` for existing topologies, review retained logs and support bundles for the value, and restrict read-only topology permissions to trusted principals. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
| CVE-2026-82433 | Medium | 2026-09-14 | No exploit published | No public exploit | Description `getNimbusConf` returned the complete daemon configuration without redaction after only a user-level authorization check. Where the cluster is configured with them, that response includes `storm.zookeeper.auth.payload` and the keystore and truststore passwords for the Thrift, Netty and ZooKeeper TLS configuration. The project masks passwords elsewhere before display, so the omission here is inconsistent rather than intended. The UI endpoint `/api/v1/cluster/configuration` compounded this. It carried no `@AuthNimbusOp` annotation, and the authorization filter treated a missing annotation as "no gate required" and returned immediately, so the endpoint applied no per-user check at all and proxied the request under the UI daemon's own principal. Any user able to pass `ui.filter` therefore received the full configuration, including principals that Nimbus itself would have refused. Mitigation Upgrade to 3.1.0, where credential-bearing values are masked before the configuration is served and where every UI API endpoint must declare its authorization explicitly. Users who cannot upgrade immediately should place the UI behind an authenticating reverse proxy that restricts `/api/v1/cluster/configuration`, and should rotate the ZooKeeper authentication payload and any TLS keystore or truststore passwords that were reachable through it. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
| CVE-2026-75015 | Medium | 2026-09-14 | No exploit published | No public exploit | Insufficiently Protected Credentials vulnerability in Apache Syncope. Audit events, when sent to the configured store, are not sufficiently masked for the sensitive values they might carry on their payloads, thus allowing administrators to access such sensitive values. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. |
| CVE-2026-86600 | High | 2026-09-08 | No exploit published | No public exploit | In affected Snowflake drivers, WORKLOAD_IDENTITY authentication requests a cloud workload-identity token and attaches it to the login request without verifying that the configured host is a Snowflake endpoint. An attacker who can modify the connection configuration can cause the driver to mint a fresh attestation and send it to a host they control. The captured token can be replayed to Snowflake for its remaining lifetime in accounts where that workload identity is already registered. On Azure, the token audience is also taken from connection configuration. Combined with an attacker-controlled host, the driver can request a Managed Identity access token scoped to a non-Snowflake Azure resource and deliver it to the attacker. That path is the only case in which impact extends beyond Snowflake; it is bounded by the token lifetime and the managed identity’s permissions. Successful exploitation requires WORKLOAD_IDENTITY authentication on a workload that already has an ambient cloud identity. Patched driver versions restrict this authenticator to recognized Snowflake hosts. Users must manually upgrade. |
| CVE-2026-55860 | Medium | 2026-08-28 | No exploit published | No public exploit | MariaDB Connector/R2DBC is a non-blocking MariaDB and MySQL client implemented in Java. Prior to 1.4.1, org.mariadb:r2dbc-mariadb does not gate clear-text password authentication plugins on transport encryption because the AuthenticationPlugin interface has no capability for a plugin to require a secure connection. A hostile or man-in-the-middle MariaDB server can send an AuthSwitchRequest naming mysql_clear_password or dialog (PAM) over a plain-TCP unencrypted connection, and AuthenticationFlow permits ClearPasswordPluginFlow or PamPluginFlow to return the user's password as cleartext bytes on the wire. The disclosed credentials can subsequently be used to authenticate directly to the database server. This issue is fixed in version 1.4.1. |
| CVE-2026-55857 | Medium | 2026-08-28 | No exploit published | No public exploit | MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. Prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9, PAM dialog authentication can be coerced into transmitting the account password over an insecure connection. The mysql_clear_password plugin is gated behind a secure transport, but the sibling PAM handler SendPamAuthPacketFactory, named dialog by the server, does not declare that requirement and inherits the default secure-required value false; older branches implement the same affected behavior in SendPamAuthPacket. A hostile or man-in-the-middle server can send an Authentication Switch Request for dialog over plain TCP, causing the driver to return the user's password in cleartext when sslMode=DISABLE and restrictedAuth=null, which is the default configuration. Properly verified TLS and local Unix sockets are not exposed to this transport vector. This issue is fixed in versions 2.7.14, 3.3.5, 3.4.3, and 3.5.9. |
| CVE-2026-55856 | Medium | 2026-08-28 | No exploit published | No public exploit | MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. Prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9, when a Java application connects with sslMode=verify-full or sslMode=verify-ca, supplies a password, and does not configure serverSslCert or trustStore, Connector/J can accept an untrusted self-signed certificate through the fallbackToSystemTrustStore=true ephemeral trust manager and record its certFingerprint for later identity binding. The OK-packet and authentication-switch paths enforce the certificate fingerprint, but the initial-handshake path does not. HandshakeResponse.encode() can therefore build and send a mysql_clear_password response before checking certFingerprint != null && !isMitMProof(), sslMode, or whether the authentication plugin is resistant to a man-in-the-middle, and the initial path also bypasses restrictedAuth. An active man-in-the-middle or hostile server can present a self-signed certificate, claim to be MariaDB, select mysql_clear_password as the initial authentication plugin, and receive the full database password before the connection is rejected. This issue is fixed in versions 2.7.14, 3.3.5, 3.4.3, and 3.5.9. |
| CVE-2026-16104 | Medium | 2026-07-17 | No exploit published | No public exploit | A flaw was found in the authentication configuration endpoint of the keycloak-services component, which is the core engine for Red Hat Build of Keycloak identity and access management. The issue occurs because the system fails to mask sensitive configuration values, such as reCAPTCHA secret keys, when they are requested by administrators with view-only permissions. This can lead to the exposure of third-party service credentials to unauthorized personnel or through administrative logs. |
| CVE-2026-41715 | Medium | 2026-06-09 | No exploit published | No public exploit | In specific scenarios involving HTTP redirects from a secure to an insecure endpoint, the Reactor Netty HTTP client may leak credentials. In order for this to happen, the HTTP client must have been explicitly configured to follow redirects. Affected versions: Reactor Netty 1.0.0 through 1.0.51; 1.1.0 through 1.1.35; 1.2.0 through 1.2.17; 1.3.0 through 1.3.5. |
| CVE-2026-2255 | Medium | 2026-05-27 | No exploit published | No public exploit | Hitachi Vantara Pentaho Data Integration & Analytics versions before 10.2.0.6 and 11.0.0.0, including 9.3.x and 8.3.x, expose Hadoop cluster credentials in plain text through the Cluster Test API. Although the user should not see those explicitly, the defect is mitigated by the fact the user can already leverage those credentials to submit jobs under the same account through the backend API. |
| CVE-2026-45091 | Critical | 2026-05-12 | No exploit published | No public exploit | sealed-env is a cross-stack, zero-trust secret management library for Node.js and Java/Spring Boot. In sealed-env enterprise mode, versions 0.1.0-alpha.1 through 0.1.0-alpha.3 embedded the operator's literal TOTP secret in the JWS payload of every minted unseal token. JWS payload is base64-encoded JSON, NOT encrypted. Any party who could observe a minted token (CI build logs, container env dumps, kubectl describe pod, Sentry/Rollbar stack traces, log aggregators) could decode the payload and extract the TOTP secret in plaintext. This vulnerability is fixed in 0.1.0-alpha.4. |
| CVE-2026-34361 | Critical | 2026-03-31 | No exploit published | Proof of concept only | HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to version 6.9.4, the FHIR Validator HTTP service exposes an unauthenticated "/loadIG" endpoint that makes outbound HTTP requests to attacker-controlled URLs. Combined with a startsWith() URL prefix matching flaw in the credential provider (ManagedWebAccessUtils.getServer()), an attacker can steal authentication tokens (Bearer, Basic, API keys) configured for legitimate FHIR servers by registering a domain that prefix-matches a configured server URL. This issue has been patched in version 6.9.4. |
| CVE-2025-54380 | Medium | 2025-07-26 | No exploit published | No public exploit | Opencast is a free, open-source platform to support the management of educational audio and video content. Prior to version 17.6, Opencast would incorrectly send the hashed global system account credentials (ie: org.opencastproject.security.digest.user and org.opencastproject.security.digest.pass) when attempting to fetch mediapackage elements included in a mediapackage XML file. A previous CVE prevented many cases where the credentials were inappropriately sent, but not all. Anyone with ingest permissions could cause Opencast to send its hashed global system account credentials to a url of their choosing. This issue is fixed in Opencast 17.6. |
| CVE-2025-53743 | Medium | 2025-07-09 | No exploit published | No public exploit | Jenkins Applitools Eyes Plugin 1.16.5 and earlier does not mask Applitools API keys displayed on the job configuration form, increasing the potential for attackers to observe and capture them. |
| CVE-2025-53671 | Medium | 2025-07-09 | No exploit published | No public exploit | Jenkins Nouvola DiveCloud Plugin 1.08 and earlier does not mask DiveCloud API Keys and Credentials Encryption Keys displayed on the job configuration form, increasing the potential for attackers to observe and capture them. |
| CVE-2025-53669 | Medium | 2025-07-09 | No exploit published | No public exploit | Jenkins VAddy Plugin 1.2.8 and earlier does not mask Vaddy API Auth Keys displayed on the job configuration form, increasing the potential for attackers to observe and capture them. |
| CVE-2025-53667 | Medium | 2025-07-09 | No exploit published | No public exploit | Jenkins Dead Man's Snitch Plugin 0.1 does not mask Dead Man's Snitch tokens displayed on the job configuration form, increasing the potential for attackers to observe and capture them. |
| CVE-2025-53666 | Medium | 2025-07-09 | No exploit published | No public exploit | Jenkins Dead Man's Snitch Plugin 0.1 stores Dead Man's Snitch tokens unencrypted in job config.xml files on the Jenkins controller, where they can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system. |
| CVE-2025-53665 | Medium | 2025-07-09 | No exploit published | No public exploit | Jenkins Apica Loadtest Plugin 1.10 and earlier does not mask Apica Loadtest LTP authentication tokens displayed on the job configuration form, increasing the potential for attackers to observe and capture them. |
| CVE-2025-53664 | Medium | 2025-07-09 | No exploit published | No public exploit | Jenkins Apica Loadtest Plugin 1.10 and earlier stores Apica Loadtest LTP authentication tokens unencrypted in job config.xml files on the Jenkins controller, where they can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system. |
| CVE-2025-53663 | Medium | 2025-07-09 | No exploit published | No public exploit | Jenkins IBM Cloud DevOps Plugin 2.0.16 and earlier stores SonarQube authentication tokens unencrypted in job config.xml files on the Jenkins controller, where they can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system. |
| CVE-2025-53662 | Medium | 2025-07-09 | No exploit published | No public exploit | Jenkins IFTTT Build Notifier Plugin 1.2 and earlier stores IFTTT Maker Channel Keys unencrypted in job config.xml files on the Jenkins controller, where they can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system. |
| CVE-2025-53661 | Medium | 2025-07-09 | No exploit published | No public exploit | Jenkins Testsigma Test Plan run Plugin 1.6 and earlier does not mask Testsigma API keys displayed on the job configuration form, increasing the potential for attackers to observe and capture them. |
| CVE-2025-53660 | Medium | 2025-07-09 | No exploit published | No public exploit | Jenkins QMetry Test Management Plugin 1.13 and earlier does not mask Qmetry Automation API Keys displayed on the job configuration form, increasing the potential for attackers to observe and capture them. |
| CVE-2025-53657 | Medium | 2025-07-09 | No exploit published | No public exploit | Jenkins ReadyAPI Functional Testing Plugin 1.11 and earlier does not mask SLM License Access Keys, client secrets, and passwords displayed on the job configuration form, increasing the potential for attackers to observe and capture them. |
| CVE-2025-53656 | Medium | 2025-07-09 | No exploit published | No public exploit | Jenkins ReadyAPI Functional Testing Plugin 1.11 and earlier stores SLM License Access Keys, client secrets, and passwords unencrypted in job config.xml files on the Jenkins controller, where they can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system. |
| CVE-2025-53654 | Medium | 2025-07-09 | No exploit published | No public exploit | Jenkins Statistics Gatherer Plugin 2.0.3 and earlier stores the AWS Secret Key unencrypted in its global configuration file on the Jenkins controller, where it can be viewed by users with access to the Jenkins controller file system. |
| CVE-2025-53653 | Medium | 2025-07-09 | No exploit published | No public exploit | Jenkins Aqua Security Scanner Plugin 3.2.8 and earlier stores Scanner Tokens for Aqua API unencrypted in job config.xml files on the Jenkins controller, where they can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system. |
| CVE-2025-53650 | High | 2025-07-09 | No exploit published | No public exploit | Jenkins Credentials Binding Plugin 687.v619cb_15e923f and earlier does not properly mask (i.e., replace with asterisks) credentials present in exception error messages that are written to the build log. |
| CVE-2025-30197 | Low | 2025-03-19 | No exploit published | No public exploit | Jenkins Zoho QEngine Plugin 1.0.29.vfa_cc23396502 and earlier does not mask the QEngine API Key form field, increasing the potential for attackers to observe and capture it. |
| CVE-2024-37362 | Medium | 2025-02-20 | No exploit published | No public exploit | The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval. (CWE-522) Hitachi Vantara Pentaho Data Integration & Analytics versions before 10.2.0.0 and 9.3.0.8, including 8.3.x, discloses database passwords when saving connections to RedShift. Products must not disclose sensitive information without cause. Disclosure of sensitive information can lead to further exploitation. |
| CVE-2024-47805 | High | 2024-10-02 | No exploit published | No public exploit | Jenkins Credentials Plugin 1380.va_435002fa_924 and earlier, except 1371.1373.v4eb_fa_b_7161e9, does not redact encrypted values of credentials using the `SecretBytes` type when accessing item `config.xml` via REST API or CLI. |
| CVE-2024-28981 | High | 2024-09-12 | No exploit published | No public exploit | Hitachi Vantara Pentaho Data Integration & Analytics versions before 10.1.0.0 and 9.3.0.8, including 8.3.x, discloses database passwords when searching metadata injectable fields. |
| CVE-2024-4536 | Medium | 2024-05-07 | No exploit published | No public exploit | In Eclipse Dataspace Components from version 0.2.1 to 0.6.2, in the EDC Connector component ( https://github.com/eclipse-edc/Connector ), an attacker might obtain OAuth2 client secrets from the vault. In Eclipse Dataspace Components from version 0.2.1 to 0.6.2, we have identified a security vulnerability in the EDC Connector component ( https://github.com/eclipse-edc/Connector ) regarding the OAuth2-protected data sink feature. When using a custom, OAuth2-protected data sink, the OAuth2-specific data address properties are resolved by the provider data plane. Problematically, the consumer-provided clientSecretKey, which indicates the OAuth2 client secret to retrieve from a secrets vault, is resolved in the context of the provider's vault, not the consumer. This secret's value is then sent to the tokenUrl, also consumer-controlled, as part of an OAuth2 client credentials grant. The returned access token is then sent as a bearer token to the data sink URL. This feature is now disabled entirely, because not all code paths necessary for a successful realization were fully implemented. |
| CVE-2024-34147 | Medium | 2024-05-02 | No exploit published | No public exploit | Jenkins Telegram Bot Plugin 1.4.0 and earlier stores the Telegram Bot token unencrypted in its global configuration file on the Jenkins controller where it can be viewed by users with access to the Jenkins controller file system. |
| CVE-2023-50291 | High | 2024-02-09 | No exploit published | No public exploit | Insufficiently Protected Credentials vulnerability in Apache Solr. This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9.0.0 before 9.3.0. One of the two endpoints that publishes the Solr process' Java system properties, /admin/info/properties, was only setup to hide system properties that had "password" contained in the name. There are a number of sensitive system properties, such as "basicauth" and "aws.secretKey" do not contain "password", thus their values were published via the "/admin/info/properties" endpoint. This endpoint populates the list of System Properties on the home screen of the Solr Admin page, making the exposed credentials visible in the UI. This /admin/info/properties endpoint is protected under the "config-read" permission. Therefore, Solr Clouds with Authorization enabled will only be vulnerable through logged-in users that have the "config-read" permission. Users are recommended to upgrade to version 9.3.0 or 8.11.3, which fixes the issue. A single option now controls hiding Java system property for all endpoints, "-Dsolr.hiddenSysProps". By default all known sensitive properties are hidden (including "-Dbasicauth"), as well as any property with a name containing "secret" or "password". Users who cannot upgrade can also use the following Java system property to fix the issue: '-Dsolr.redaction.system.pattern=.*(password|secret|basicauth).*' |
| CVE-2023-29055 | High | 2024-01-29 | No exploit published | No public exploit | In Apache Kylin version 2.0.0 to 4.0.3, there is a Server Config web interface that displays the content of file 'kylin.properties', that may contain serverside credentials. When the kylin service runs over HTTP (or other plain text protocol), it is possible for network sniffers to hijack the HTTP payload and get access to the content of kylin.properties and potentially the containing credentials. To avoid this threat, users are recommended to * Always turn on HTTPS so that network payload is encrypted. * Avoid putting credentials in kylin.properties, or at least not in plain text. * Use network firewalls to protect the serverside such that it is not accessible to external attackers. * Upgrade to version Apache Kylin 4.0.4, which filters out the sensitive content that goes to the Server Config web interface. |
| CVE-2023-50770 | Medium | 2023-12-13 | No exploit published | No public exploit | Jenkins OpenId Connect Authentication Plugin 2.6 and earlier stores a password of a local user account used as an anti-lockout feature in a recoverable format, allowing attackers with access to the Jenkins controller file system to recover the plain text password of that account, likely gaining administrator access to Jenkins. |
| CVE-2018-16153 | High | 2023-12-12 | No exploit published | No public exploit | An issue was discovered in Apereo Opencast 4.x through 10.x before 10.6. It sends system digest credentials during authentication attempts to arbitrary external services in some situations. |
| CVE-2023-49280 | High | 2023-12-04 | No exploit published | No public exploit | XWiki Change Request is an XWiki application allowing to request changes on a wiki without publishing directly the changes. Change request allows to edit any page by default, and the changes are then exported in an XML file that anyone can download. So it's possible for an attacker to obtain password hash of users by performing an edit on the user profiles and then downloading the XML file that has been created. This is also true for any document that might contain password field and that a user can view. This vulnerability impacts all version of Change Request, but the impact depends on the rights that has been set on the wiki since it requires for the user to have the Change request right (allowed by default) and view rights on the page to target. This issue cannot be easily exploited in an automated way. The patch consists in denying to users the right of editing pages that contains a password field with change request. It means that already existing change request for those pages won't be removed by the patch, administrators needs to take care of it. The patch is provided in Change Request 1.10, administrators should upgrade immediately. It's possible to workaround the vulnerability by denying manually the Change request right on some spaces, such as XWiki space which will include any user profile by default. |
| CVE-2023-49653 | Medium | 2023-11-29 | No exploit published | No public exploit | Jenkins Jira Plugin 3.11 and earlier does not set the appropriate context for credentials lookup, allowing attackers with Item/Configure permission to access and capture credentials they are not entitled to. |
| CVE-2023-46651 | Medium | 2023-10-25 | No exploit published | No public exploit | Jenkins Warnings Plugin 10.5.0 and earlier does not set the appropriate context for credentials lookup, allowing attackers with Item/Configure permission to access and capture credentials they are not entitled to. This fix has been backported to 10.4.1. |
| CVE-2023-40347 | Medium | 2023-08-16 | No exploit published | No public exploit | Jenkins Maven Artifact ChoiceListProvider (Nexus) Plugin 1.14 and earlier does not set the appropriate context for credentials lookup, allowing attackers with Item/Configure permission to access and capture credentials they are not entitled to. |
| CVE-2023-40345 | Medium | 2023-08-16 | No exploit published | No public exploit | Jenkins Delphix Plugin 3.0.2 and earlier does not set the appropriate context for credentials lookup, allowing attackers with Overall/Read permission to access and capture credentials they are not entitled to. |
| CVE-2023-37951 | Medium | 2023-07-12 | No exploit published | No public exploit | Jenkins mabl Plugin 0.0.46 and earlier does not set the appropriate context for credentials lookup, allowing attackers with Item/Configure permission to access and capture credentials they are not entitled to. |
| CVE-2023-28857 | High | 2023-06-27 | No exploit published | Proof of concept only | Apereo CAS is an open source multilingual single sign-on solution for the web. Apereo CAS can be configured to use authentication based on client X509 certificates. These certificates can be provided via TLS handshake or a special HTTP header, such as “ssl_client_cert”. When checking the validity of the provided client certificate, X509CredentialsAuthenticationHandler performs check that this certificate is not revoked. To do so, it fetches URLs provided in the “CRL Distribution Points” extension of the certificate, which are taken from the certificate itself and therefore can be controlled by a malicious user. If the CAS server is configured to use an LDAP server for x509 authentication with a password, for example by setting a “cas.authn.x509.ldap.ldap-url” and “cas.authn.x509.ldap.bind-credential” properties, X509CredentialsAuthenticationHandler fetches revocation URLs from the certificate, which can be LDAP urls. When making requests to this LDAP urls, Apereo CAS uses the same password as for initially configured LDAP server, which can lead to a password leak. An unauthenticated user can leak the password used to LDAP connection configured on server. This issue has been addressed in version 6.6.6. Users are advised to upgrade. There are no known workarounds for this vulnerability. |
| CVE-2023-33264 | Medium | 2023-05-22 | No exploit published | No public exploit | In Hazelcast through 5.0.4, 5.1 through 5.1.6, and 5.2 through 5.2.3, configuration routines don't mask passwords in the member configuration properly. This allows Hazelcast Management Center users to view some of the secrets. |
| CVE-2023-33000 | High | 2023-05-16 | No exploit published | No public exploit | Jenkins NS-ND Integration Performance Publisher Plugin 4.8.0.149 and earlier does not mask credentials displayed on the configuration form, increasing the potential for attackers to observe and capture them. |
| CVE-2023-32988 | Medium | 2023-05-16 | No exploit published | No public exploit | A missing permission check in Jenkins Azure VM Agents Plugin 852.v8d35f0960a_43 and earlier allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins. |
| CVE-2023-2633 | Medium | 2023-05-16 | No exploit published | No public exploit | Jenkins Code Dx Plugin 3.1.0 and earlier does not mask Code Dx server API keys displayed on the configuration form, increasing the potential for attackers to observe and capture them. |
| CVE-2023-2632 | Medium | 2023-05-16 | No exploit published | No public exploit | Jenkins Code Dx Plugin 3.1.0 and earlier stores Code Dx server API keys unencrypted in job config.xml files on the Jenkins controller where they can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system. |
| CVE-2022-26885 | High | 2022-11-24 | No exploit published | No public exploit | When using tasks to read config files, there is a risk of database password disclosure. We recommend you upgrade to version 2.0.6 or higher. |
| CVE-2022-41933 | Medium | 2022-11-23 | No exploit published | No public exploit | XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. When the `reset a forgotten password` feature of XWiki was used, the password was then stored in plain text in database. This only concerns XWiki 13.1RC1 and newer versions. Note that it only concerns the reset password feature available from the "Forgot your password" link in the login view: the features allowing a user to change their password, or for an admin to change a user password are not impacted. This vulnerability is particularly dangerous in combination with other vulnerabilities allowing to perform data leak of personal data from users, such as GHSA-599v-w48h-rjrm. Note that this vulnerability only concerns the users of the main wiki: in case of farms, the users registered on subwiki are not impacted thanks to a bug we discovered when investigating this. The problem has been patched in version 14.6RC1, 14.4.3 and 13.10.8. The patch involves a migration of the impacted users as well as the history of the page, to ensure no password remains in plain text in the database. This migration also involves to inform the users about the possible disclosure of their passwords: by default, two emails are automatically sent to the impacted users. A first email to inform about the possibility that their password have been leaked, and a second email using the reset password feature to ask them to set a new password. It's also possible for administrators to set some properties for the migration: it's possible to decide if the user password should be reset (default) or if the passwords should be kept but only hashed. Note that in the first option, the users won't be able to login anymore until they set a new password if they were impacted. Note that in both options, mails will be sent to users to inform them and encourage them to change their passwords. |
| CVE-2022-45392 | Medium | 2022-11-15 | No exploit published | No public exploit | Jenkins NS-ND Integration Performance Publisher Plugin 4.8.0.143 and earlier stores passwords unencrypted in job config.xml files on the Jenkins controller where they can be viewed by attackers with Extended Read permission, or access to the Jenkins controller file system. |
| CVE-2022-45384 | Medium | 2022-11-15 | No exploit published | No public exploit | Jenkins Reverse Proxy Auth Plugin 1.7.3 and earlier stores the LDAP manager password unencrypted in the global config.xml file on the Jenkins controller where it can be viewed by attackers with access to the Jenkins controller file system. |
| CVE-2022-42132 | Medium | 2022-11-15 | No exploit published | No public exploit | The Test LDAP Users functionality in Liferay Portal 7.0.0 through 7.4.3.4, and Liferay DXP 7.0 fix pack 102 and earlier, 7.1 before fix pack 27, 7.2 before fix pack 17, 7.3 before update 4, and DXP 7.4 GA includes the LDAP credential in the page URL when paginating through the list of users, which allows man-in-the-middle attackers or attackers with access to the request logs to see the LDAP credential. |
| CVE-2022-43419 | Medium | 2022-10-19 | No exploit published | No public exploit | Jenkins Katalon Plugin 1.0.32 and earlier stores API keys unencrypted in job config.xml files on the Jenkins controller where they can be viewed by users with Extended Read permission, or access to the Jenkins controller file system. |
| CVE-2019-14840 | High | 2022-10-17 | No exploit published | Proof of concept only | A flaw was found in the RHDM, where sensitive HTML form fields like Password has auto-complete enabled which may lead to leak of credentials. |
| CVE-2022-41255 | Medium | 2022-09-21 | No exploit published | No public exploit | Jenkins CONS3RT Plugin 1.0.0 and earlier stores Cons3rt API token unencrypted in job config.xml files on the Jenkins controller where it can be viewed by users with access to the Jenkins controller file system. |
| CVE-2022-41247 | Medium | 2022-09-21 | No exploit published | No public exploit | Jenkins BigPanda Notifier Plugin 1.4.0 and earlier stores the BigPanda API key unencrypted in its global configuration file on the Jenkins controller where they can be viewed by users with access to the Jenkins controller file system. |
| CVE-2022-38665 | Medium | 2022-08-23 | No exploit published | No public exploit | Jenkins CollabNet Plugins Plugin 2.0.8 and earlier stores a RabbitMQ password unencrypted in its global configuration file on the Jenkins controller where it can be viewed by users with access to the Jenkins controller file system. |
| CVE-2022-38663 | Medium | 2022-08-23 | No exploit published | No public exploit | Jenkins Git Plugin 4.11.4 and earlier does not properly mask (i.e., replace with asterisks) credentials in the build log provided by the Git Username and Password (`gitUsernamePassword`) credentials binding. |
| CVE-2021-3513 | High | 2022-08-22 | No exploit published | No public exploit | A flaw was found in keycloak where a brute force attack is possible even when the permanent lockout feature is enabled. This is due to a wrong error message displayed when wrong credentials are entered. The highest threat from this vulnerability is to confidentiality. |
| CVE-2022-36901 | Medium | 2022-07-27 | No exploit published | No public exploit | Jenkins HTTP Request Plugin 1.15 and earlier stores HTTP Request passwords unencrypted in its global configuration file on the Jenkins controller where they can be viewed by users with access to the Jenkins controller file system. |
| CVE-2022-34816 | Medium | 2022-06-30 | No exploit published | No public exploit | Jenkins HPE Network Virtualization Plugin 1.0 stores passwords unencrypted in its global configuration file on the Jenkins controller where they can be viewed by users with access to the Jenkins controller file system. |
| CVE-2022-34809 | Medium | 2022-06-30 | No exploit published | No public exploit | Jenkins RQM Plugin 2.8 and earlier stores a password unencrypted in its global configuration file on the Jenkins controller where it can be viewed by users with access to the Jenkins controller file system. |
| CVE-2022-34808 | Medium | 2022-06-30 | No exploit published | No public exploit | Jenkins Cisco Spark Plugin 1.1.1 and earlier stores bearer tokens unencrypted in its global configuration file on the Jenkins controller where they can be viewed by users with access to the Jenkins controller file system. |
| CVE-2022-34807 | Medium | 2022-06-30 | No exploit published | No public exploit | Jenkins Elasticsearch Query Plugin 1.2 and earlier stores a password unencrypted in its global configuration file on the Jenkins controller where it can be viewed by users with access to the Jenkins controller file system. |
| CVE-2022-34806 | Medium | 2022-06-30 | No exploit published | No public exploit | Jenkins Jigomerge Plugin 0.9 and earlier stores passwords unencrypted in job config.xml files on the Jenkins controller where they can be viewed by users with Extended Read permission, or access to the Jenkins controller file system. |
| CVE-2022-34805 | Medium | 2022-06-30 | No exploit published | No public exploit | Jenkins Skype notifier Plugin 1.1.0 and earlier stores a password unencrypted in its global configuration file on the Jenkins controller where it can be viewed by users with access to the Jenkins controller file system. |
| CVE-2022-34803 | Medium | 2022-06-30 | No exploit published | No public exploit | Jenkins OpsGenie Plugin 1.9 and earlier stores API keys unencrypted in its global configuration file and in job config.xml files on the Jenkins controller where they can be viewed by users with Extended Read permission (config.xml), or access to the Jenkins controller file system. |
| CVE-2022-34802 | Medium | 2022-06-30 | No exploit published | No public exploit | Jenkins RocketChat Notifier Plugin 1.5.2 and earlier stores the login password and webhook token unencrypted in its global configuration file on the Jenkins controller where they can be viewed by users with access to the Jenkins controller file system. |
| CVE-2022-34800 | Medium | 2022-06-30 | No exploit published | No public exploit | Jenkins Build Notifications Plugin 1.5.0 and earlier stores tokens unencrypted in its global configuration files on the Jenkins controller where they can be viewed by users with access to the Jenkins controller file system. |
| CVE-2022-34799 | Medium | 2022-06-30 | No exploit published | No public exploit | Jenkins Deployment Dashboard Plugin 1.0.10 and earlier stores a password unencrypted in its global configuration file on the Jenkins controller where it can be viewed by users with access to the Jenkins controller file system. |
| CVE-2022-34796 | Medium | 2022-06-30 | No exploit published | No public exploit | A missing permission check in Jenkins Deployment Dashboard Plugin 1.0.10 and earlier allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins. |
| CVE-2022-34213 | Medium | 2022-06-23 | No exploit published | No public exploit | Jenkins Squash TM Publisher (Squash4Jenkins) Plugin 1.0.0 and earlier stores passwords unencrypted in its global configuration file on the Jenkins controller where they can be viewed by users with access to the Jenkins controller file system. |
| CVE-2022-34202 | Medium | 2022-06-23 | No exploit published | No public exploit | Jenkins EasyQA Plugin 1.0 and earlier stores user passwords unencrypted in its global configuration file on the Jenkins controller where they can be viewed by users with access to the Jenkins controller file system. |
| CVE-2022-34199 | Medium | 2022-06-23 | No exploit published | No public exploit | Jenkins Convertigo Mobile Platform Plugin 1.1 and earlier stores passwords unencrypted in job config.xml files on the Jenkins controller where they can be viewed by users with Extended Read permission, or access to the Jenkins controller file system. |
| CVE-2020-28865 | High | 2022-06-16 | No exploit published | No public exploit | An issue was discovered in PowerJob through 3.2.2, allows attackers to change arbitrary user passwords via the id parameter to /appinfo/save. |
| CVE-2022-31044 | High | 2022-06-15 | No exploit published | No public exploit | Rundeck is an open source automation service with a web console, command line tools and a WebAPI. The Key Storage converter plugin mechanism was not enabled correctly in Rundeck 4.2.0 and 4.2.1, resulting in use of the encryption layer for Key Storage possibly not working. Any credentials created or overwritten using Rundeck 4.2.0 or 4.2.1 might result in them being written in plaintext to the backend storage. This affects those using any `Storage Converter` plugin. Rundeck 4.3.1 and 4.2.2 have fixed the code and upon upgrade will re-encrypt any plain text values. Version 4.3.0 does not have the vulnerability, but does not include the patch to re-encrypt plain text values if 4.2.0 or 4.2.1 were used. To prevent plaintext credentials from being stored in Rundeck 4.2.0/4.2.1, write access to key storage can be disabled via ACLs. After upgrading to 4.3.1 or later, write access can be restored. |
| CVE-2022-30952 | Medium | 2022-05-17 | No exploit published | No public exploit | Jenkins Pipeline SCM API for Blue Ocean Plugin 1.25.3 and earlier allows attackers with Job/Configure permission to access credentials with attacker-specified IDs stored in the private per-user credentials stores of any attacker-specified user in Jenkins. |
| CVE-2022-29052 | Medium | 2022-04-12 | No exploit published | No public exploit | Jenkins Google Compute Engine Plugin 4.3.8 and earlier stores private keys unencrypted in cloud agent config.xml files on the Jenkins controller where they can be viewed by users with Extended Read permission, or access to the Jenkins controller file system. |
| CVE-2022-26850 | Medium | 2022-04-06 | No exploit published | No public exploit | When creating or updating credentials for single-user access, Apache NiFi wrote a copy of the Login Identity Providers configuration to the operating system temporary directory. On most platforms, the operating system temporary directory has global read permissions. NiFi immediately moved the temporary file to the final configuration directory, which significantly limited the window of opportunity for access. NiFi 1.16.0 includes updates to replace the Login Identity Providers configuration without writing a file to the operating system temporary directory. |
| CVE-2022-28141 | Medium | 2022-03-29 | No exploit published | No public exploit | Jenkins Proxmox Plugin 0.5.0 and earlier stores the Proxmox Datacenter password unencrypted in the global config.xml file on the Jenkins controller where it can be viewed by users with access to the Jenkins controller file system. |
| CVE-2022-28135 | Medium | 2022-03-29 | No exploit published | No public exploit | Jenkins instant-messaging Plugin 1.41 and earlier stores passwords for group chats unencrypted in the global configuration file of plugins based on Jenkins instant-messaging Plugin on the Jenkins controller where they can be viewed by users with access to the Jenkins controller file system. |
| CVE-2022-0862 | Medium | 2022-03-23 | No exploit published | No public exploit | A lack of password change protection vulnerability in a depreciated API of McAfee Enterprise ePolicy Orchestrator (ePO) prior to 5.10 Update 13 allows a remote attacker to change the password of a compromised session without knowing the existing user's password. This functionality was removed from the User Interface in ePO 10 and the API has now been disabled. Other protection is in place to reduce the likelihood of this being successful through sending a link to a logged in user. |
| CVE-2022-0859 | Medium | 2022-03-23 | No exploit published | No public exploit | McAfee Enterprise ePolicy Orchestrator (ePO) prior to 5.10 Update 13 allows a local attacker to point an ePO server to an arbitrary SQL server during the restoration of the ePO server. To achieve this the attacker would have to be logged onto the server hosting the ePO server (restricted to administrators) and to know the SQL server password. |
| CVE-2022-27218 | Medium | 2022-03-15 | No exploit published | No public exploit | Jenkins incapptic connect uploader Plugin 1.15 and earlier stores tokens unencrypted in job config.xml files on the Jenkins controller where they can be viewed by users with Extended Read permission, or access to the Jenkins controller file system. |
| CVE-2022-27217 | Medium | 2022-03-15 | No exploit published | No public exploit | Jenkins Vmware vRealize CodeStream Plugin 1.2 and earlier stores passwords unencrypted in job config.xml files on the Jenkins controller where they can be viewed by users with Extended Read permission, or access to the Jenkins controller file system. |