Overview 1,636 matches · 233 in Waratek scope · 0 protected · 17 exploited · 5 CISA KEV · 53 public PoC · 11 EPSS ≥ 0.5
1,636matches
233in Waratek scope14.2%
0protected0.0%
17exploited1.0%
5CISA KEV0.3%
53public PoC3.2%
11EPSS ≥ 0.50.7%
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
233
14.2%
Outside Waratek scope
20
1.2%
Not applicable
1,383
84.5%
Withdrawn CVE
0
0.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
1,636
100.0%
not established
0
0.0%
unrecorded
0
0.0%
split by
peak 368 / year
19981
Not applicable1
High1
not blocked1
No public exploit1
19990
20001
Not applicable1
Critical1
not blocked1
Working exploit published1
20010
20020
20030
20040
20051
Not applicable1
Critical1
not blocked1
No public exploit1
20060
20071
Not applicable1
Critical1
not blocked1
Working exploit published1
20080
20090
20100
20110
20122
Not applicable2
High1
Medium1
not blocked2
No public exploit2
20134
Outside Waratek scope1
Not applicable3
Medium2
Low2
not blocked4
Working exploit published1
No public exploit3
20143
Not applicable3
High1
Medium2
not blocked3
Exploited1
No public exploit2
20153
No exploit published1
Not applicable2
Medium3
not blocked3
No public exploit3
20161
Not applicable1
High1
not blocked1
No public exploit1
201748
No exploit published2
Not applicable46
Critical18
High23
Medium7
not blocked48
Exploited4
Working exploit published4
No public exploit40
2018125
No exploit published11
Outside Waratek scope2
Not applicable112
Critical55
High49
Medium21
not blocked125
Working exploit published6
No public exploit119
2019186
No exploit published65
Outside Waratek scope4
Not applicable117
Critical32
High82
Medium69
Low3
not blocked186
Exploited1
Working exploit published2
Proof of concept only1
No public exploit182
2020194
No exploit published36
Outside Waratek scope1
Not applicable157
Critical21
High77
Medium93
Low3
not blocked194
Exploited1
Working exploit published9
Proof of concept only2
No public exploit182
2021131
No exploit published7
Outside Waratek scope5
Not applicable119
Critical15
High52
Medium62
Low2
not blocked131
Exploited3
No public exploit128
2022164
No exploit published49
Outside Waratek scope3
Not applicable112
Critical13
High48
Medium102
Low1
not blocked164
Exploited2
Working exploit published4
Proof of concept only5
No public exploit153
2023135
No exploit published14
Outside Waratek scope1
Not applicable120
Critical18
High58
Medium59
not blocked135
Working exploit published2
Proof of concept only15
No public exploit118
2024131
No exploit published6
Outside Waratek scope1
Not applicable124
Critical13
High52
Medium63
Low3
not blocked131
Exploited3
Working exploit published2
Proof of concept only18
No public exploit108
2025137
No exploit published19
Not applicable118
Critical26
High39
Medium65
Low7
not blocked137
Exploited1
Working exploit published4
Proof of concept only18
No public exploit114
2026368
No exploit published23
Outside Waratek scope2
Not applicable343
Critical47
High138
Medium160
Low22
Unknown1
not blocked368
Exploited1
Working exploit published2
Proof of concept only70
No public exploit295
1999200220052008201120142017202020232026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-126390 | Medium | 2026-11-13 | Not applicable | No public exploit | n8n before 1.123.89 contains a credential leakage vulnerability in the NocoDB node that sends the configured NocoDB API token to attacker-chosen hosts when downloading attachments. Attackers with write access to a NocoDB attachment cell can insert a URL to their host, capturing the API token when the workflow executes with Download Attachments enabled. |
| CVE-2026-126388 | Medium | 2026-11-13 | Not applicable | No public exploit | n8n before 2.46.1 contains a credential exposure vulnerability that forwards Authorization headers and basic auth credentials on cross-origin redirects because sendCredentialsOnCrossOriginRedirect defaults to true. Attackers controlling a redirect target or an expression-fed URL in credential-using nodes can capture stored workflow credentials sent to their endpoint. |
| CVE-2026-126271 | High | 2026-11-13 | Not applicable | No public exploit | NocoDB before 2026.09.0 contains an information disclosure vulnerability that allows authenticated base Viewers to obtain TLS client private keys by reading a base's data source. The source read handler masked only the connection password, letting attackers retrieve the decrypted private key, client certificate and CA to connect directly to the external database, bypassing NocoDB permissions. |
| CVE-2026-127046 | Critical | 2026-11-12 | Not applicable | No public exploit | The MISP Modules website component contains an information disclosure vulnerability in the external tools management interface. The /external_tools/list endpoint returned stored API keys (the api_key field) in its JSON response via the ExternalTools model serializer. Additionally, the browser-based edit form pre-populated the API key input field with the stored credential value, exposing it in the DOM. The /external_tools/list endpoint is accessible without authentication (the regression tests verify the response for both authenticated and unauthenticated clients), meaning any network-reachable client could retrieve the API keys for all configured external tools. These keys are used by the server to authenticate submissions to external analysis or enrichment services, so their disclosure allows an attacker to impersonate the MISP instance or directly access those external services. The vulnerability also affected the edit workflow: the change_config endpoint previously required the API key to be present and non-empty on every save, forcing the key to round-trip through the client. The browser JavaScript stored the key in a reactive state object and updated the in-memory tool list with the credential value, further increasing the window of exposure in client-side memory and network traffic. Affected component: the website sub-application of MISP Modules, specifically the external_tools module (serializer in models.py, list endpoint, and the external_tools_index.html template). The impact is limited to confidentiality of the stored API keys; no integrity or availability impact on the MISP Modules website itself is indicated by the patch. |
| CVE-2026-126248 | High | 2026-11-11 | Not applicable | No public exploit | A insufficiently protected credentials vulnerability in Fortinet FortiAuthenticator 8.0.0 through 8.0.3, FortiAuthenticator 6.6.0 through 6.6.10 may allow an unauthenticated attacker to obtain sensitive information via HTTPS requests. |
| 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-89125 | Medium | 2026-11-10 | Not applicable | No public exploit | Due to Insecure Storage of Sensitive Information in SAP Web Dispatcher and Internet Communication Manager, an attacker with administrative privileges could obtain sensitive information from stored data. This may allow correlation of credentials across users and deployments, potentially leading to credential exposure and unauthorized access. Successful exploitation could expose credentials and facilitate unauthorized access to affected systems, resulting in a high impact on confidentiality and a low impact on integrity and availability. |
| CVE-2026-85907 | Medium | 2026-11-10 | Not applicable | No public exploit | Improper authentication in Windows SSDP Service allows an authorized attacker to elevate privileges locally. |
| CVE-2026-125329 | High | 2026-11-10 | Not applicable | No public exploit | Kaneo is a project management application with boards, Gantt charts, and GitHub integration that can be self-hosted or used as a cloud service. Prior to 2.13.0, GET /api/external-link/task/:taskId returns integration.config to any workspace member, including the viewer role, when a task has a linked Gitea issue or pull request. The plaintext integration.config contains the Gitea accessToken and webhookSecret, allowing the token's granted Gitea actions and forged webhook deliveries that pass HMAC verification. GitHub integrations and installations without a configured Gitea integration are not affected. This issue is fixed in version 2.13.0. |
| CVE-2026-125328 | Medium | 2026-11-10 | Not applicable | No public exploit | pgEdge Go LLM Library provides a unified Go interface for multiple LLM providers with streaming, tool calling, retries, and an HTTP and server-sent events proxy. From 0.1.0 until 0.2.0, GET /v1/health in llm/proxy/handlers.go uses handleHealth to ping providers with the operator's real credentials and returns their error text, while the Authorize hook in llm/proxy/proxy.go permits access by default when the consuming application does not configure it. When a provider rejects the configured credential, a remote caller who can reach the proxy can obtain part of the operator's third-party provider API key from the resulting error. This issue is fixed in version 0.2.0. |
| CVE-2026-125326 | Medium | 2026-11-10 | Not applicable | No public exploit | pgEdge RAG Server is an API server for retrieval-augmented generation over PostgreSQL content using pgvector. Prior to 2.0.0, the unauthenticated query API in internal/server/handlers.go returns err.Error() from failed LLM provider calls, preserving provider-controlled error text that can quote a partially masked submitted API key. A remote caller can cause an authentication failure and obtain part of the operator's credential for the third-party provider account through the query API error response. This issue is fixed in version 2.0.0. |
| CVE-2026-121680 | High | 2026-11-10 | Not applicable | No public exploit | Exposure of sensitive information to an unauthorized actor in Windows NTLM allows an unauthorized attacker to perform spoofing over a network. |
| CVE-2026-121675 | Medium | 2026-11-10 | Not applicable | No public exploit | Improper restriction of xml external entity reference in Microsoft PowerShell allows an unauthorized attacker to disclose information over a network. |
| CVE-2026-121669 | Medium | 2026-11-10 | Not applicable | No public exploit | Insufficiently protected credentials in Microsoft PowerShell Core allows an unauthorized attacker to disclose information over a network. |
| CVE-2026-119946 | Medium | 2026-11-10 | Not applicable | No public exploit | Improper access control in Windows HTTP.sys allows an unauthorized attacker to disclose information over a network. |
| CVE-2026-112806 | Medium | 2026-11-10 | Not applicable | No public exploit | Insufficiently protected credentials in Windows Print Spooler Components allows an authorized attacker to disclose information locally. |
| CVE-2026-112801 | High | 2026-11-10 | Not applicable | No public exploit | Insufficiently protected credentials in Windows eSCL Scanner allows an authorized attacker to elevate privileges locally. |
| CVE-2026-112185 | High | 2026-11-10 | Not applicable | No public exploit | In Eclipse Kura versions 5.1.0 through 5.6.2, the Configuration REST API v2 (org.eclipse.kura.rest.configuration.provider) does not restrict access to the configuration of the UserAdmin persistence component to identities holding the kura.admin permission. An authenticated identity holding only the rest.configuration permission can read the password hashes of all identities, including administrators, which are stored as unsalted SHA-256 digests. The same identity can also modify identities and permission assignments, and restore previous configuration snapshots, which allows escalation to full administrative privileges. The issue is fixed in Eclipse Kura 5.6.3. |
| CVE-2026-108470 | Medium | 2026-11-10 | Not applicable | No public exploit | Insufficiently protected credentials in Microsoft Authentication Library (MSAL) for Node.js allows an unauthorized attacker to disclose information over a network. |
| CVE-2026-115340 | High | 2026-11-09 | Not applicable | No public exploit | Progress Software WS_FTP Server versions prior to 2025.0.5 on Windows may write sensitive user credential and session data to a temporary file during file transfer operations. |
| CVE-2026-112164 | Medium | 2026-11-09 | Not applicable | No public exploit | The LaserGest mobile application encrypts stored assistance portal credentials with a hardcoded AES key and IV, allowing an attacker with access to the application package to recover them in cleartext. |
| CVE-2026-111452 | Medium | 2026-11-09 | Not applicable | No public exploit | Apache Airflow's secrets masker matched sensitive key names only in their snake_case form, so values stored under camelCase keys such as `privateKey`, `connectionString`, `webhookUrl` or `accessKey` — for example in a Connection's extra or a Variable — were not redacted in task logs, rendered template fields or API responses. A user who can read task logs or rendered templates, but is not meant to see those credentials, could read them in cleartext. Users are advised to upgrade to apache-airflow 3.4.0 or later. Airflow 2.x is also affected; Airflow 2 has reached end of life and will not receive a fix, so Airflow 2 users should upgrade to Apache Airflow 3.4.0 or later. |
| CVE-2026-107474 | Medium | 2026-11-09 | Not applicable | No public exploit | The Apache Airflow connections API did not mask the apprise provider's `config` connection extra, which can embed notification-service credentials. A user with permission to read connections could retrieve it in cleartext, although Airflow 3 treats connection credentials as write-only. Users are advised to upgrade to apache-airflow 3.4.0 or later. Airflow 2.x is also affected; Airflow 2 has reached end of life and will not receive a fix, so Airflow 2 users should upgrade to Apache Airflow 3.4.0 or later. |
| CVE-2026-17367 | Medium | 2026-11-07 | Not applicable | No public exploit | IBM API Connect 10.0.8.0 through 10.0.8.12 and 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information due to insufficiently protected credentials. |
| CVE-2026-66982 | Low | 2026-11-06 | Not applicable | No public exploit | HCL AION is affected by a vulnerability where browser autocomplete was enabled on sensitive login form fields, allowing the browser to store and suggest previously entered values. A malicious user with access to the same browser or system could retrieve saved credentials, potentially resulting in unintended behavior or security impact under certain conditions. |
| CVE-2026-123856 | Medium | 2026-11-06 | Not applicable | No public exploit | In JetBrains Toolbox App before 3.6.1 nTLM hash disclosure was possible via SVG tool icons from a Remote Development server |
| 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-123059 | High | 2026-11-05 | Not applicable | No public exploit | In Eclipse BaSyx Helm Charts version 2.2.0 of the `aas-basyx-v2-full` chart, deployments with the bundled Keycloak enabled store the client secret of the `basyx-technical-user` OAuth2 client in cleartext in a Kubernetes ConfigMap. This client uses the client-credentials grant and its service account holds the realm `admin` role. The chart correctly writes `keycloak.technicalUser.clientSecret` to a Kubernetes Secret, but the template `basyx-keycloak-realm.yaml` also substitutes the same value into the Keycloak realm-import JSON, which is stored in the ConfigMap `<keycloak.fullnameOverride>-realm`. A principal that can read ConfigMaps but not Secrets in the release namespace, such as a holder of the built-in Kubernetes `view` ClusterRole, can read the client secret from the ConfigMap. They can then exchange it at the Keycloak token endpoint for an access token with the `admin` role. That token grants full create, read, update, delete and execute rights on all BaSyx repositories and registries in the deployment. The bundled Keycloak is disabled by default. No fixed release of the `aas-basyx-v2-full` chart exists. Affected users should migrate to the `basyx` chart, or deploy without the bundled Keycloak and rotate the `basyx-technical-user` client secret. |
| CVE-2026-123047 | High | 2026-11-05 | Not applicable | No public exploit | In Eclipse BaSyx Helm Charts versions 3.0.0-rc.1 to 3.12.1 of the `basyx` chart, deployments with the bundled Keycloak enabled store the passwords of the Keycloak users that the chart creates in cleartext in a Kubernetes ConfigMap. The template `keycloak-init-config.yaml` rendered `keycloak.initialization.users`, including each user's `credentials[].value`, as `users.json` into the persistent ConfigMap `<release>-basyx-keycloak-init-config`. By default this includes the bootstrap administrator user. That user holds the `admin` role and has a non-temporary password. A principal that can read ConfigMaps but not Secrets in the release namespace, such as a holder of the built-in Kubernetes `view` ClusterRole, can read the password from the ConfigMap and log in to Keycloak as this user. The resulting token carries the `admin` role, which the default BaSyx ABAC rules map to full rights on all BaSyx APIs in the deployment. The bundled Keycloak is disabled by default. The issue is fixed in version 3.12.2 of the `basyx` chart, which moves the initialization users to the Keycloak credentials Secret. Affected users should upgrade and change the passwords of users that were created through the chart. |
| CVE-2026-119757 | Critical | 2026-11-05 | Not applicable | Exploited | BTCPay Server before 2.4.2, including 2.4.2 release candidates, contains an information disclosure vulnerability that allows unauthenticated remote attackers to retrieve .macaroon credential files for an LND (Lightning Network Daemon) node. Attackers can use the exposed macaroon to gain full control of the LND node, including moving funds, resulting in theft of funds from affected deployments. |
| CVE-2026-97693 | Critical | 2026-11-04 | Not applicable | No public exploit | Yuxi is a large-model-based intelligent knowledge base and knowledge graph agent development platform. From 0.6.0.beta1 until 0.7.1, there is insufficient isolation between execution-capable Docker sandboxes and trusted application services. A low-privileged authenticated user who can execute commands in their own sandbox can reach other tenants' sandbox APIs, access their files and secrets, execute commands in active sandboxes, and enumerate, create, or delete sandboxes through the unauthenticated provisioner without knowing administrator, database, or MinIO credentials. Sandboxes can also reach shared internal services; if shipped default service credentials remain unchanged, an attacker can use them, and if the exposed PostgreSQL account is a superuser, obtain command execution in the PostgreSQL container. These paths can disclose or modify cross-tenant data and sandbox state or cause denial of service through sandbox deletion without a container escape or kernel vulnerability. This vulnerability is fixed in 0.7.1. Existing deployments must separately rotate persisted PostgreSQL, Neo4j, or MinIO credentials that were previously set to documented or shipped defaults because upgrading the Compose files does not automatically rotate them. |
| CVE-2026-54378 | Critical | 2026-11-04 | Not applicable | Proof of concept only | VitaFit cloud API before 2026-10-30 contained a broken access control vulnerability that allows any authenticated user to obtain temporary AWS credentials by calling the POST /front/user/s3/token/ endpoint. Attackers can use these improperly scoped credentials to list the shared storage bucket and read or overwrite other users' stored files, enabling unauthorized cross-user data access and manipulation. |
| CVE-2026-121971 | High | 2026-11-04 | Not applicable | No public exploit | The component ScopingHttpClient in Symfony HttpClient merges the options of its default scope (such as auth_bearer or auth_basic) into a request before resolving a relative URL against the base_uri, allowing a network-path reference such as "//evil.example/steal" to be sent to another origin together with the default scope’s credentials, and resulting in potential disclosure of those credentials to an attacker-controlled server. This affects Symfony in versions 5.x prior to 5.4.56, 6.x prior to 6.4.50, 7.x prior to 7.4.23, and 8.x prior to 8.1.11. The resolved URL falls outside the origin of the base URI, yet it keeps the merged options, whereas the absolute spelling "https://evil.example/steal" receives none. The same happens with a different port or user-info part on the same host. This is reachable whenever an attacker controls the beginning of a URL passed to a client built with a base_uri and credentials, including those created with HttpClient::createForBaseUri() or configured under framework.http_client.scoped_clients. To solve the issue, after resolving a relative URL against the base URI of the default scope, ScopingHttpClient now compares the scheme and authority of the result with those of the base URI, parsed the way the request is sent. |
| CVE-2026-113372 | High | 2026-11-04 | Not applicable | No public exploit | Sonatype Nexus Repository 3 returns the private signing key of a YUM proxy or group repository to an account that holds only the read privilege for administering that repository. The account does not need the privilege to edit the repository. A party that holds the key can sign repository metadata as that repository. |
| CVE-2026-113371 | High | 2026-11-04 | Not applicable | No public exploit | Sonatype Nexus Repository 3 returns the signing passphrase of an APT or YUM repository, through an internal REST endpoint, to a user account that holds only the read privilege for administering that repository. The account does not need the privilege to edit the repository. |
| CVE-2026-89292 | Critical | 2026-11-03 | Not applicable | No public exploit | In Eclipse Mnestix Browser versions 1.6.0 up until but excluding 2.3.0 it was possible for an unauthenticated attacker to exfiltrate the MNESTIX_BACKEND_API_KEY for all configured Infrastructures. |
| CVE-2026-113733 | Low | 2026-11-03 | Not applicable | No public exploit | An issue was discovered in Django 6.1 before 6.1.3 and 6.0 before 6.0.10. The `django.contrib.admin.utils.display_for_field()` function did not obfuscate the password field of user models other than `AUTH_USER_MODEL`, or of an `AUTH_USER_MODEL` inheriting its password field from a concrete parent model through multi-table inheritance, which allows authenticated staff users with only the view permission on such a model to obtain full password hashes via the read-only change form. Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected. Django would like to thank Aaron chen for reporting this issue. |
| CVE-2026-105769 | Critical | 2026-11-02 | Not applicable | No public exploit | kaniko before 1.25.20 can send a Microsoft Entra ID (Azure AD) access token for Azure Resource Manager to an attacker-controlled registry host. kaniko uses the Azure Container Registry credential helper github.com/chrismellard/docker-credential-acr-env, which decides whether a host is an ACR registry with an unanchored regular expression, so any hostname containing .azurecr.io, .azurecr.cn, .azurecr.de or .azurecr.us is accepted. kaniko consults this helper for any registry that has no credentials in the Docker config and is not a Google or Amazon ECR registry, before contacting the registry. A Dockerfile that references an image on a lookalike host, such as FROM x.azurecr.io.attacker.com/img or COPY --from=<image>, causes the helper to obtain a token from the build's Azure identity (service principal environment variables, federated workload identity token, or managed identity) and POST it to https://<host>/oauth2/exchange. The attacker can use the token against Azure Resource Manager with the identity's role assignments until it expires, and can exchange it for credentials to any ACR registry the identity can access. No RUN instruction or push is required. This issue is fixed in 1.25.20. |
| CVE-2026-61730 | Critical | 2026-10-30 | Not applicable | No public exploit | SOCFortress CoPilot focuses on providing a single pane of glass for all your security operations needs. In affected deployments, the unauthenticated `/scoutsuite-report` `StaticFiles` mount in `backend/copilot.py` exposes the `scoutsuite-report` directory even though normal /api routes require JWT authentication. Generated HTML reports and `scoutsuite-results/scoutsuite_results_<name>.js` files disclose AWS, Azure and GCP IAM principals, resource inventories, misconfigurations and findings. Report names derive from caller-selected names with predictable defaults. During an admin- or analyst-initiated GCP scan, `backend/app/integrations/scoutsuite/routes/scoutsuite.py` saves the uploaded Google service-account JSON key into that same web-served directory. In `backend/app/integrations/scoutsuite/services/scoutsuite.py`, `generate_gcp_report_background` removes the key only after the scan finishes. Any anonymous client that can reach the host and request the file path can therefore retrieve the private key during the scan and use the service account's cloud permissions, as well as read retained cloud-security reports. Credential isolation is released in version 0.1.77; a release fully remediating the report-disclosure component has not been established. |
| CVE-2026-119566 | Medium | 2026-10-30 | Not applicable | No public exploit | Prometheus through 3.15.1 contains a credential leak vulnerability that allows attackers to capture Azure AD or Google IAM bearer tokens by redirecting remote_write requests to another host. Attackers controlling the remote-write endpoint or a redirecting server can return a 3xx to their host and replay the token, for example to write metrics to the victim's backend. |
| CVE-2026-116252 | High | 2026-10-30 | Not applicable | No public exploit | pgAdmin 4's materialized view refresh passed the target database's name to psql's --dbname argument unchanged. libpq treats a --dbname value containing "=" (or a postgresql:// URI) as a full connection string, whose keywords override the host, port and other settings pgAdmin had supplied. A database whose name is such a string, which any role with CREATEDB can create, therefore redirected the psql process pgAdmin starts for the refresh to a host and port of the creator's choosing, and the connecting user's saved server password was presented to that endpoint. It also let the pgAdmin host be made to open connections to arbitrary addresses. The same weakness was fixed for Backup, Restore, Maintenance and Import/Export Data in earlier releases (CVE-2026-86862); the materialized view refresh was the remaining caller. The fix routes the name through the same database_conninfo() helper, so libpq treats it strictly as a database name. This issue affects pgAdmin 4: before 9.19. |
| CVE-2026-116247 | High | 2026-10-30 | Not applicable | No public exploit | When a server in pgAdmin 4 had no password file, client certificate or client key configured, or the configured one could not be found, pgAdmin left the parameter out of the connection and libpq fell back to the defaults of the operating-system account running pgAdmin: ~/.pgpass, ~/.postgresql/postgresql.crt and postgresql.key, or PGPASSFILE, PGSSLCERT and PGSSLKEY. In server mode any user could therefore connect to a server with the service account's saved passwords or client certificate, and supplying only a copy of its public certificate was enough for libpq to pair it with the service account's private key. A pg_service.conf entry, or a maintenance database name read as a connection string by pg_dumpall, could bring the same files back for the utilities. The fix gives each of these parameters a value in server mode, the user's own file or otherwise a path that can never be opened, in the connection string, in the environment of the utilities and in the --dbname connection string that ranks above a service entry. Desktop mode is unchanged. This issue affects pgAdmin 4: before 9.19. |
| CVE-2026-116245 | High | 2026-10-30 | Not applicable | No public exploit | libpq looks a connection service up in the service file of the operating-system account running pgAdmin 4, and an entry there can hold a password or name a password file or client certificate. In server mode any user could set a server's Service, or a "service" connection parameter, to one of those entries and connect with its credentials. A PGPASSWORD or PGSERVICE variable set for that account was likewise used by libpq for every connection without a value of its own and passed on to the utilities, and pg_dumpall read a maintenance database name such as "service=..." as a connection string. The fix adds the SERVER_MODE_ALLOWED_SERVICES setting, empty by default: in server mode only a listed service can be used, the servicefile parameter is refused, and PGPASSWORD and PGSERVICE are removed from pgAdmin's environment at startup. The allowlist is checked again on the final connection string, and the pg_dumpall database name is wrapped as a connection string. This issue affects pgAdmin 4: before 9.19. |
| CVE-2026-116244 | High | 2026-10-30 | Not applicable | No public exploit | When a pgAdmin 4 connection was not meant to use a Kerberos user's delegated credentials, pgAdmin removed KRB5CCNAME from its environment, so the Kerberos library fell back to the default credential cache, or a client keytab, of the operating-system account running pgAdmin. libpq then answered any server that asked for GSSAPI authentication with that account's ticket, whatever user name the pgAdmin user gave, so in server mode any user could connect as the service account's Kerberos principal; gssencmode=disable did not prevent it. On Windows, SSPI used the service account's logon in the same way. psql was also started with pgAdmin's environment, which could hold another user's credential cache while that user was connecting. The fix points KRB5CCNAME and KRB5_CLIENT_KTNAME at a file that cannot exist except while a Kerberos-authenticated user connects with Kerberos, and gives every other connection, psql and the utilities require_auth=!gss,!sspi and gssencmode=disable, checked on the final connection string. require_auth needs libpq 16 or later. This issue affects pgAdmin 4: before 9.19. |
| CVE-2026-116242 | High | 2026-10-30 | Not applicable | No public exploit | pgAdmin 4 opens SSH tunnels with the sshtunnel library but gave it neither host_pkey_directories nor ssh_config_file, so it always loaded the unencrypted private keys in ~/.ssh of the operating-system account running pgAdmin, read that account's ~/.ssh/config (IdentityFile, User, HostName, ProxyCommand) for the tunnel host, and could use its ssh-agent. In server mode any user could therefore configure a tunnel to a host that accepts the service account's key, with no credentials of their own or with an identity file that did not exist in their storage, and reach it as that account. The fix makes tunnels in server mode use only the identity file or password the user configured: the service account's keys, configuration and agent are no longer used, and an identity file that cannot be found in the user's storage is reported instead of falling back to ~/.ssh. Desktop mode is unchanged. This issue affects pgAdmin 4: before 9.19. |
| CVE-2026-111502 | Medium | 2026-10-30 | Not applicable | No public exploit | Dell OpenManage Enterprise, versions prior to 4.8.0, contains an Insufficiently Protected Credentials vulnerability. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to Information disclosure. |
| CVE-2026-90861 | Medium | 2026-10-29 | Not applicable | No public exploit | Progress Software WS_FTP Server versions prior to 2024.0.7 and 2025.0.4 on Windows may expose a user's password in clear text to another administrator, who could use it to gain broader administrative access to the server. |
| CVE-2026-84295 | Critical | 2026-10-29 | Not applicable | No public exploit | Improper authentication in Progress Software WS_FTP Server versions prior to 2024.0.6 and 2025.0.3 on Windows could allow an unauthenticated remote attacker to access sensitive information, including administrative credentials. |
| CVE-2026-118763 | High | 2026-10-29 | Not applicable | No public exploit | sigstore-js provides JavaScript libraries for interacting with Sigstore services. Prior to 0.7.2, packages/oci/src/registry.ts contains a RegistryClient.signIn() method that stores registry Authorization and Docker configuration headers as defaults on a shared HTTP client, while RegistryClient.uploadBlob() sends a fresh PUT to an absolute blob-upload Location supplied by the registry without checking that its origin or scheme matches the registry. A malicious or compromised registry can therefore direct a user pushing an artifact through attachArtifactToImage() to an attacker-controlled host and receive the registry bearer token, Basic credentials, or custom authentication headers. Redirect-time header stripping does not prevent the leak because the cross-host PUT is a new explicit request rather than a followed redirect. This is a residual of CVE-2026-59891, whose fix changed credential selection in credentials.ts but did not constrain where credentials are sent from registry.ts. Version 0.7.2 fixes the issue by separating registry credentials from client-wide defaults and sending them only to the registry origin. |
| CVE-2026-110192 | Medium | 2026-10-29 | Not applicable | No public exploit | IBM Langflow OSS 1.0.0 through 1.12.8 could allow a remote authenticated attacker to obtain sensitive information due to insufficiently protected credentials. |
| CVE-2026-104314 | Medium | 2026-10-29 | Not applicable | No public exploit | IBM Langflow OSS 1.0.0 through 1.12.3 could allow an authenticated attacker with a read or share grant on a target flow to retrieve the flow owner's stored third-party credentials in cleartext from the API response. |
| CVE-2026-88967 | High | 2026-10-28 | Not applicable | No public exploit | A user with query access to an Azure Monitor data source in Grafana can cause server-side requests to an attacker-controlled endpoint that disclose the data source's Azure access token (server-side request forgery). |
| CVE-2026-87097 | Medium | 2026-10-28 | Not applicable | No public exploit | Sensitive information disclosure due to insufficiently protected credentials. The following products are affected: Acronis Cyber Protect 17 (Linux, Windows) before build 42587. |
| CVE-2026-104384 | High | 2026-10-28 | Not applicable | No public exploit | Insufficiently Protected Credentials in tunnel gateway and provisioning interfaces in EagleCloud Aquila versions through 2.6.7.2 on on-premises platforms allows unauthenticated remote attackers to escalate privileges via authentication abuse to access the access keys, secret keys, and deployment secrets |
| CVE-2026-59158 | High | 2026-10-27 | Not applicable | Proof of concept only | Nuxt Ollama integrates the official Ollama JavaScript library into Nuxt applications. Prior to 1.3.1, `src/module.ts` unconditionally merges all module options, including a configured cloud `api_key`, into `runtimeConfig.public.ollama`. Nuxt serializes this public configuration into the server-rendered HTML `window.__NUXT__` payload, exposing the API key in plaintext to any unauthenticated client that fetches a page. `src/runtime/composables/useOllama.ts` also reads the public key and sends it as an `Authorization` `Bearer` credential in browser-side Ollama requests. Following the documented cloud configuration is sufficient; the visible application template need not make an Ollama request for the secret to leak. A stolen key permits unauthorized cloud API requests at the operator's expense, quota or rate-limit exhaustion, and access to stored models or conversations if the key grants those permissions. This issue is fixed in version 1.3.1. |
| CVE-2026-116683 | High | 2026-10-27 | Not applicable | No public exploit | CTFer.io's CTFd Terraform Provider manages CTFd resources as code. From 0.1.5 until 2.8.2, ctfd_team.password is stored as a non-sensitive value in Terraform state. A local or remote user with access to that state can read the team password without an additional decryption step. This issue is fixed in 2.8.2. |
| CVE-2026-101034 | Medium | 2026-10-27 | Not applicable | No public exploit | An attacker who obtained the hardcoded key could decrypt domain/service account passwords, task run-as credentials, and sysprep passwords stored in or transmitted by GSS Deployment Server installation. |
| CVE-2026-113440 | Medium | 2026-10-26 | Not applicable | No public exploit | Insufficiently Protected Credentials vulnerability in hackney in benoitc hackney allows a redirecting server to obtain the basic_auth and cookie credentials of a request via a same-host redirect to another scheme or port. With follow_redirect enabled, hackney:follow_redirect/10 in src/hackney.erl reissues the request to the Location target after hackney:maybe_strip_auth_on_redirect/3, which compared only the hostname of the current and the redirect URL. A redirect from https to http on the same host resent the Authorization and Cookie headers in cleartext, where an on-path attacker can read them, and a redirect to another port on the same host handed them to a different service. location_trusted forwards credentials to any target by design and is unchanged. This issue affects hackney: from 2.0.0 before 4.9.0. |
| CVE-2026-115750 | Medium | 2026-10-23 | Not applicable | Proof of concept only | mcp-from-openapi from 2.5.0 before 2.9.0 contains a credential exposure vulnerability that allows attackers to capture Authorization and Cookie headers because safeFetch() forwards them on cross-origin redirects. Attackers controlling a spec host or abusing an open redirect can redirect fromURL() spec requests to their own origin to steal bearer tokens or cookies. |
| CVE-2026-21811 | Low | 2026-10-22 | Not applicable | No public exploit | HCL AppScan Azure Boards Plugin is potentially affected by an Information Disclosure vulnerability involving secrets accessible in plaintext during pipeline execution. Depending on the pipeline configuration, these secrets could be exposed through task outputs, debug logs, environment variable dumps, or build agent scripts, despite being masked in the user interface. |
| CVE-2026-115371 | High | 2026-10-22 | Not applicable | No public exploit | Incus 6.0.3 before 6.0.7, 6.6.0 before 7.0.2, and 7.1.0 before 7.5.0 contains an improper authorization vulnerability that allows restricted TLS clients to read storage bucket keys in the default project. Attackers can query the bucket keys endpoints to obtain S3 access and secret keys, then read, modify or delete objects in those buckets. |
| CVE-2026-114221 | Medium | 2026-10-22 | Not applicable | No public exploit | NT OneAPP developed by NewType Infortech has a Credential Disclosure vulnerability. Unauthenticated remote attackers can trigger an HTTP Basic Authentication challenge from an unvalidated source in the WebView under specific conditions, thereby obtaining the NUP Portal passcode of a logged-in user. |
| CVE-2026-114070 | Medium | 2026-10-21 | Not applicable | No public exploit | Trigger.dev 4.5.0 before 4.6.0 contains an information disclosure vulnerability in the Dashboard Agent input proxy that stores a delegated user-actor token in browser-readable session input records. Attackers holding a chat's public session token can read the in records endpoint to recover the token from payload.metadata.userActorToken and replay it for environment JWT exchange. |
| CVE-2026-103090 | High | 2026-10-21 | Not applicable | Proof of concept only | Missing Authentication for Critical Function (CWE-306) and Insufficiently Protected Credentials (CWE-522) in the control plane enrollment status handler (HandleEnrollStatus at GET /enroll/status in internal/controlplane/server.go) in Google OSS Agent Mesh (SAM) versions 0.1.0-alpha.1 through 0.1.0-alpha.8 allow an unauthenticated remote attacker to retrieve an approved bootstrap-enrolled peer's signed Biscuit identity token by supplying a peer_id obtainable from the unauthenticated GET /info endpoint. A related flaw in POST /enroll allowed any bootstrap-token holder to re-fetch another peer's credential. An attacker can replay the disclosed Biscuit token as a bearer credential on /policies to read mesh authorization policies and on /routers/lease to overwrite advertised router multiaddrs. Users should upgrade to version 0.1.0-alpha.9 or later, which requires cryptographic proof of possession of the enrollment private key on credential-releasing endpoints, enforces rate limiting, and validates router lease addresses. |
| CVE-2026-94266 | High | 2026-10-20 | Not applicable | Proof of concept only | libcurl could accidentally return a URL for `curl_easy_getinfo()`'s `CURLINFO_EFFECTIVE_URL` option containing credentials, even though neither the URL provided to libcurl nor the redirected URL did. |
| CVE-2026-113652 | Medium | 2026-10-20 | Not applicable | No public exploit | ApostropheCMS is an open-source Node.js content management system. From 1.25.0 until 1.28.0, uploadfs Azure backend leaks account-level SAS token into every public attachment URL. When uploadfs is configured with the Azure backend and sas: true, createContainer() builds the BlobServiceClient from a URL that embeds the full SAS query string, and Azure SDK v12 derived clients inherit that query string. This issue is fixed in version 1.28.0. |
| 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-112303 | Medium | 2026-10-19 | Not applicable | No public exploit | GDevelop desktop app through 5.6.284 contains a credential leak vulnerability that allows attackers to steal the gd_resource cookie by supplying attacker-controlled resource URLs in project files. Attackers can get victims to open a crafted project, causing downloadLocalFile() to send the cookie to their server and expose private cloud project resources. |
| CVE-2026-111927 | High | 2026-10-17 | Not applicable | No public exploit | Coder before 2.29.20, 2.33.0 before 2.33.12, 2.34.0 before 2.34.8, and 2.35.0 before 2.35.4 contains an improper hostname validation flaw in GetWorkspaceProxyByHostname whose SIMILAR TO pattern performs a prefix match, so any domain that is a string prefix of a workspace-proxy access URL is trusted as a proxy. Attackers owning such a domain can lure an authenticated victim to a crafted /api/v2/applications/auth-redirect link, capture the redirected application_connect API key, and replay it to access the victim's workspace apps. |
| CVE-2026-96626 | High | 2026-10-16 | Not applicable | No public exploit | Arcane is an interface for managing Docker containers, images, networks, and volumes. Prior to 2.5.0, UpdateRegistry and TestRegistry in backend/api/services/container_registry_service.go allow the registry URL to change while preserving the stored encrypted token. When a holder of registries:update and registries:test repoints a generic registry URL without supplying a replacement token, TestRegistry decrypts the preserved token and RegistryLogin sends it to the attacker-controlled host because normalizeRegistryServerAddressInternal does not restrict the destination. This exposes the stored container-registry PAT or password and can enable image access or tampering. This issue is fixed in version 2.5.0. |
| CVE-2026-36436 | High | 2026-10-15 | Not applicable | No public exploit | An issue in Trisolutions BRPerfX version 1.4.4.0 exposes LDAP credentials in plaintext within the administrative configuration interface. An authenticated administrator can inspect the client-side code to retrieve the credential. |
| CVE-2026-104617 | Medium | 2026-10-15 | Not applicable | No public exploit | There are two invocations of `qrencode` to display a QR code for scanning. These invocations leak the private data $pin / $key via /proc accessible for arbitrary low-privileged users in the system. |
| CVE-2026-102944 | High | 2026-10-14 | Not applicable | Proof of concept only | cpp-httplib is a C++ header-only HTTP/HTTPS library. Prior to 0.51.0, create_redirect_client() removes Host, Proxy-Authorization, and Authorization headers when following a cross-origin 301, 302, 307, or 308 redirect but leaves Cookie headers attached. detail::redirect() copies the request for those redirect codes, so cookies supplied directly or through default_headers_ are sent to the redirect target. An attacker who controls a redirect response, or a network position for a non-HTTPS origin, can receive session cookies intended for the original origin. A 303 redirect is not affected because that path clears all request headers. This issue is fixed in version 0.51.0. |
| CVE-2026-63160 | Critical | 2026-10-13 | Not applicable | No public exploit | Omnispace Agora Project before 26.10.0 contains a vulnerability where the persistent remember-me token is stored verbatim server-side, making the stored value identical to the bearer credential held in the user's cookie. Attackers who gain access to the stored token, such as through database or backup disclosure, can replay the plaintext value to authenticate as the victim user without needing their password. |
| CVE-2026-109953 | Medium | 2026-10-13 | Not applicable | Proof of concept only | FreeRDP 3.0.0 before 3.32.0 contains an insufficiently protected credentials vulnerability where the /restricted-admin option fails to suppress CredSSP credential delegation, sending the cleartext password to the RDP server. A compromised or man-in-the-middle destination host can decode TSPasswordCreds and the Client Info PDU to obtain reusable administrative domain, username, and password values. |
| CVE-2026-108904 | High | 2026-10-11 | Not applicable | No public exploit | pH7Builder (pH7 Social Dating CMS) before 18.5.0 contains an information disclosure vulnerability that allows API clients to obtain sensitive member data because UserController::users() and user() return unfiltered database rows. Attackers holding a valid private API key can retrieve bcrypt password hashes, non-expiring hashValidation reset tokens, and TOTP secrets to take over accounts and bypass two-factor authentication. |
| CVE-2026-78835 | Critical | 2026-10-09 | Not applicable | Proof of concept only | Rocket Software Rocket Remote Desktop 18.0.8583.1 is vulnerable to Insufficiently Protected Credentials. |
| CVE-2026-39460 | Critical | 2026-10-09 | Not applicable | No public exploit | Usernames and passwords, including the default factory credentials, are stored in plaintext within the configuration file. With administrator rights, the configuration file can be viewed through the CLI or they can be exported from the device through a TFTP transfer from the web interface. A TFTP transfer can be initiated through SNMP which does not require authentication. |
| CVE-2026-107857 | Medium | 2026-10-09 | Not applicable | No public exploit | Mindwtr is a free offline-first task management application for desktop and mobile. Prior to 1.1.5, the mobile application writes the Cloud sync bearer token and WebDAV password to unencrypted AsyncStorage under @mindwtr_cloud_token and @mindwtr_webdav_password. A party with access to the application database or an exposed device backup can recover these credentials and use them to access the user's synchronized tasks and attachments. This issue is fixed in version 1.1.5. |
| CVE-2026-87428 | High | 2026-10-08 | Not applicable | No public exploit | In Brocade ASCG before 3.5.0, a local unauthorized user on the ASCG VM who can issue a request to the SANnav host network namespace can extract stored management credentials for onboarded SANnav instances and compromise connected Brocade SANnav servers or managed Brocade Fibre Channel switches. |
| CVE-2026-107715 | Medium | 2026-10-08 | Not applicable | Proof of concept only | The Mechanize library is used for automating interaction with websites. Prior to 2.14.1, Mechanize sends caller-supplied credential headers to a different host after an HTTP redirect. Mechanize#request_headers= is reapplied by Mechanize::HTTP::Agent#request_add_headers even after Mechanize::HTTP::Agent#response_redirect strips per-request headers, and the protected header lists omit Proxy-Authorization and Cookie2. An attacker who controls a redirect target can capture bearer tokens or session cookies supplied through request_headers= or the per-request headers argument, while Mechanize#cookie_jar and Mechanize::HTTP::AuthStore are not affected. This issue is fixed in version 2.14.1. |
| CVE-2026-107714 | Medium | 2026-10-08 | Not applicable | No public exploit | The Mechanize library is used for automating interaction with websites. Prior to 2.14.1, Mechanize::HTTP::Agent#response_redirect treats redirects as same-origin when the host matches without consistently comparing scheme and port. A same-host HTTPS-to-HTTP redirect can send Authorization and Cookie headers over cleartext, while a same-host redirect to another port can send a caller-supplied Cookie header to a different service. Cookies in Mechanize#cookie_jar remain scoped separately; the issue affects caller-supplied headers and can disclose credentials without affecting integrity or availability. This issue is fixed in version 2.14.1. |
| CVE-2026-107503 | High | 2026-10-08 | Not applicable | No public exploit | In Eclipse Ditto versions 3.6.0 to 3.8.13 and 3.9.0 to 3.9.7, the Ditto Explorer UI loads its complete environment configuration, including the Ditto API URI and the OpenID Connect (OIDC) provider settings, from an arbitrary cross-origin URL supplied in the environmentsURL query parameter. It adopts this configuration without user confirmation and persists it in the browser's localStorage. A crafted link can therefore set an attacker-controlled OIDC authority with autoSso enabled. The UI then automatically starts a login at the genuine identity provider but exchanges the returned authorization code together with its PKCE code_verifier at an attacker-controlled token endpoint. This lets the attacker redeem the code for the victim's access and refresh tokens. Alternatively, an attacker-controlled api_uri causes the UI to send the victim's bearer token or Basic credentials to the attacker. Because the configuration is persisted, later visits to the UI without the crafted link repeat the token theft. In versions 3.9.0 to 3.9.7, the Swagger UI OIDC integration of the Helm chart and the Docker Compose deployment is affected in the same way, but requires the user to start the login. The issue is fixed in 3.8.14 and 3.9.8. |
| CVE-2026-107399 | Medium | 2026-10-08 | Not applicable | No public exploit | The Mechanize library is used for automating interaction with websites. Prior to 2.14.1, Mechanize applies no origin trust boundary in Mechanize::HTTP::Agent#response_follow_meta_refresh when Mechanize#follow_meta_refresh is enabled. A page containing a meta refresh to another origin causes headers configured through Mechanize#request_headers= to be reapplied to the refresh request, allowing an attacker who controls content in the crawl to capture bearer tokens or session cookies. The default configuration is not affected because follow_meta_refresh is false, and the exposure is limited to caller-supplied default headers. This issue is fixed in version 2.14.1. |
| CVE-2026-105833 | High | 2026-10-08 | Not applicable | No public exploit | EspoCRM before 10.0.5 contains an insecure direct object reference vulnerability in PersonalAccount\Service that allows users with Email Account scope access to retrieve other users' IMAP passwords. Attackers who know a victim's Email Account record ID can request that record to steal stored IMAP credentials and access the victim's mailbox. |
| CVE-2026-76483 | Critical | 2026-10-07 | Not applicable | No public exploit | As part of Cisco's ongoing commitment to proactive security and product quality, the engineering team for Cisco License On-Prem, formerly Cisco Smart Software Manager On-Prem (SSM On-Prem), has conducted a comprehensive internal security review. This review resulted in software hardening releases that address multiple internally discovered vulnerabilities. The vulnerabilities tracked by CVE-2026-76483 are related to issues with insufficiently protected credentials that are grouped under the Common Weakness Enumeration (CWE) Pillar CWE-522. |
| 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-107232 | High | 2026-10-07 | Not applicable | 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 on 3.x and 2.16.1 on 2.x, the client infers that an HTTP proxy tunnel exists from the last request method rather than the CONNECT result. After a proxy rejects CONNECT, redirect or authentication handlers can write an origin request and its Authorization credentials onto the still-plaintext proxy connection. Basic credentials can be recovered directly, while NTLM responses may be cracked or relayed. This issue is fixed in versions 3.0.12 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-105138 | High | 2026-10-07 | Not applicable | No public exploit | Obot 0.12.0 before 0.26.2 contains an insufficiently protected credentials vulnerability that allows authenticated users to read static secrets set on MCP catalog entries by admins or power users. Basic users granted an entry by access control rules can request GET /api/all-mcps/entries/{entry_id} to obtain plaintext API keys or tokens and abuse them against backend services. |
| CVE-2026-101331 | High | 2026-10-07 | Not applicable | No public exploit | IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to obtain sensitive information due to insufficiently protected credentials. |
| CVE-2026-105763 | Critical | 2026-10-06 | Not applicable | No public exploit | Twenty is an open-source CRM (customer relationship management) platform. From 1.20.10 until 2.7.0, the /metadata GraphQL connectedAccounts query returned connectionParameters from ConnectedAccountDTO for every connected account in a workspace, including plaintext IMAP, SMTP, and CalDAV passwords, because the field was not hidden and the lookup did not enforce the calling user's identity or account visibility. A normal workspace member could obtain other members' external-service credentials and use them to access mail or calendars and potentially reset third-party accounts. Google and Microsoft OAuth-only workspaces were not affected. This issue is fixed in version 2.7.0. |
| CVE-2026-104850 | High | 2026-10-06 | Not applicable | No public exploit | MCP TypeScript SDK is the official TypeScript SDK for Model Context Protocol servers and clients. Starting in version 1.12.0 and prior to versions 1.31.0 and 2.2.0, the SDK's OAuth client support let the MCP server a client connected to decide which authorization server received the client's OAuth credentials. Stored and pre-provisioned credentials were not bound to the authorization server they belong to. A malicious or compromised MCP server could name its own authorization server in its protected resource metadata. Without any user interaction, the client would send that server the `refresh_token` and `client_secret` stored from an earlier sign-in (1.x), or the configured `client_secret` or signed assertion of a bundled non-interactive provider (1.x and 2.x). Only those applications that use the SDK as an MCP client over HTTP with an `authProvider`: your own `OAuthClientProvider`, or the bundled `ClientCredentialsProvider`, `PrivateKeyJwtProvider`, `StaticPrivateKeyJwtProvider` or (2.x) `CrossAppAccessProvider` and that may connect to an MCP server the owners does not fully trust while holding credentials for a legitimate authorization server are affected. `@modelcontextprotocol/sdk` 1.31.0 (1.x) and `@modelcontextprotocol/client` 2.2.0 (2.x) patch the issue. A workaround for those who cannot upgrade is available. 2.0.0 and 2.1.0 already accept `expectedIssuer`. On 1.x, the only workaround is to connect OAuth-enabled clients only to MCP servers you trust. |
| CVE-2026-86671 | High | 2026-10-05 | Not applicable | No public exploit | In Eclipse Che versions 7.29.0 and later, the GET `/api/scm/resolve` and `POST /api/factory/resolver` endpoints pass an attacker-controlled URL to `URLFetcher.fetch()`, which calls `new URL(url).openConnection()` with no scheme or host allow-list and returns the response body to the caller. Any authenticated Che user can read arbitrary local files via the file:// scheme (including the pod's Kubernetes service-account token at `file:///var/run/secrets/kubernetes.io/serviceaccount/token`), reach internal HTTP services and cloud instance metadata endpoints (169.254.169.254), and have their stored SCM personal access token attached as an `Authorization` header to a host of their choosing. The same credential-forwarding behavior also fires when a victim opens a workspace from a malicious devfile whose `parent.uri` points to an attacker-controlled server, enabling exfiltration of the victim's SCM PAT without direct API access. No fix is available. |
| CVE-2026-105742 | Medium | 2026-10-05 | Not applicable | Proof of concept only | Docling simplifies document processing by parsing diverse formats and providing integrations with the generative AI ecosystem. From 2.95.0 until 2.132.0, the HTML image resource loader in docling/backend/utils/image_resource_loader.py forwards headers configured through the HTMLBackendOptions.headers setting to every remote image URL named by an untrusted document when enable_remote_fetch=True and fetch_images=True. The loader does not restrict those credentials to the source document's origin, allowing requests that carry custom headers such as API keys and cookies to follow cross-origin redirects and expose the caller's configured credentials to a document author. The default configuration is not affected because remote fetching and configured headers are required. This issue is fixed in 2.132.0. |
| CVE-2026-93474 | Medium | 2026-10-02 | Not applicable | No public exploit | Charging station authentication identifiers are publicly accessible via web-based mapping platforms. |
| CVE-2026-92537 | Medium | 2026-10-01 | Not applicable | No public exploit | The Newsletter – Send awesome emails from WordPress plugin for WordPress is vulnerable to Insufficiently Protected Credentials in all versions up to, and including, 9.3.9 The plugin's public click-tracking REST route `/tnp/l/` is registered with `permission_callback => '__return_true'` and, upon receiving a valid keyed-MD5 signature, calls `set_user_cookie()`, which emits a `Set-Cookie: newsletter=<id>-<raw_token>` response header to the requester because the subscriber object loaded via `get_user()` lacks the `_trusted` property, causing `get_user_key()` to return the raw token column value instead of its MD5-masked variant. This makes it possible for unauthenticated attackers who obtain any signed click-tracking URL for a target subscriber to receive that subscriber's permanent raw authentication cookie, which they can then use to export the subscriber's full PII record via the JSON profile-export endpoint (`?na=px`), rewrite the subscriber's stored profile (`?na=ps`), and silently unsubscribe the subscriber via the RFC-8058 one-click endpoint (`?na=ocu`), none of which require a nonce, password, or email challenge. Signed tracking URLs are embedded in every external link of every newsletter delivered to a subscriber, carry no timestamp, and never expire until the site's relink key rotates, meaning that any party who observes such a URL — through a forwarded email, a shared inbox, a mail-gateway log, or Referer headers on the redirect target, which has no Referrer-Policy set — can replay it indefinitely to obtain the victim's credential. |
| CVE-2026-104051 | High | 2026-10-01 | Not applicable | No public exploit | PictShare before 3.7.1 contains an information disclosure vulnerability that allows unauthenticated attackers to obtain the secret delete_code and uploader metadata by calling the API::info() endpoint which returns the complete raw metadata object without a field whitelist. Attackers can use the publicly visible file hash to retrieve the delete_code via the info API and then invoke the delete API to permanently delete arbitrary files, while also exposing uploader IP, User Agent, remote port, and SHA-1 hash, resulting in loss of content integrity, availability, and uploader privacy. |