CVE-2026-112168 affects GALENO SISTEMI's MAGISTRA software version 3.12. The vulnerability involves the use of weak custom encryption, reliance on an outdated compression algorithm for database protection, and the presence of embedded secrets, leading to cleartext storage of sensitive information.
Apache Airflow's audit log stored Connection and Variable secret values in cleartext in the `Log.extra` column because the secrets masker matched only on configured sensitive key names. An authenticated low-privilege user with read access to the event-log / audit API — with no prior access to the affected connection or variable — could read those rows and recover the credentials verbatim. Users should upgrade to apache-airflow 3.4.0 or later, which masks these values and restricts the affected audit rows to authorized users. 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.
Chartbrew is an open-source web application that can connect directly to databases and APIs and use the data to create charts. Prior to 5.2.3, public dashboard passwords were stored in plaintext, accepted through a URL query parameter, and checked without effective attempt throttling. The vulnerable surface is public password-protected dashboard storage and validation routes. An unauthenticated attacker targets a public password-protected dashboard and repeatedly submits candidate passwords or obtains password-bearing server or proxy logs. Unlimited online guesses enable brute force, while cleartext storage and URL transport expose the secret in application storage and server or proxy access logs. The target must be a public dashboard with password protection enabled. Even failed attempts reveal chart count and configuration without the password; a recovered password grants access to the protected dashboard and its chart data. This vulnerability is fixed in 5.2.3.
OpenHuman versions prior to 0.57.5 use the JSON-RPC bearer token as an approval session identifier, which is exposed in persisted approval records, events, debug logs, and RPC responses. This exposure allows an attacker who obtains these artifacts to recover the token and access the core RPC interface with the privileges of the token. The vulnerability can lead to exposure of sensitive agent and integration data and permit privileged operations. The issue is fixed in version 0.57.5.
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.
Eclipse BaSyx Helm Charts versions 3.0.0-rc.1 through 3.12.1 have a vulnerability where Keycloak user passwords are stored in cleartext within a Kubernetes ConfigMap. This allows any principal with read access to ConfigMaps in the release namespace, such as those with the Kubernetes 'view' ClusterRole, to retrieve admin user passwords and gain full administrative access to BaSyx APIs. The issue is fixed in version 3.12.2 by moving credentials to a Kubernetes Secret.
MailEnable Auth Cleartext Storage Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of MailEnable. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the handling of mailbox credentials. The issue results from storing sensitive information in plaintext. An attacker can leverage this in conjunction with other vulnerabilities to disclose stored credentials, leading to further compromise. Was ZDI-CAN-34478.
Cleartext storage of sensitive information in the user account data in Devolutions Server 2026.3.12.0 and earlier allows an attacker with read access to the database or a database backup to obtain users' TOTP shared secrets via the unencrypted copy of the security key written when an administrator saves a user.
IBM Langflow OSS versions 1.0.0 through 1.12.4 store sensitive information in cleartext, which could allow a remote authenticated attacker to access this data. This vulnerability is identified as CWE-312 and has a CVSS score of 6.5, indicating a medium severity risk. The flaw does not impact integrity or availability but compromises confidentiality. No public exploits or vendor patches are currently documented.
MLflow versions from 2.19.0 up to but not including 3.17.0 contain a vulnerability where the mlflow.crewai.autolog() function records CrewAI Agent objects without properly sanitizing nested credential data. This results in plaintext provider API keys being included in trace data sent to the MLflow trace backend or OTLP destinations, exposing sensitive credentials to unauthorized readers. The issue is resolved in version 3.17.0.
boneIO versions from 1.2.0 up to but not including 1.6.0 store sensitive passwords, including MQTT broker and web panel passwords, in cleartext. The API endpoint GET /api/config exposes these passwords to any authenticated user. Due to a related issue (CVE-2026-77053) disabling authentication by default, unauthenticated attackers on the local network can also retrieve these passwords. The vulnerability was fixed in version 1.6.0 by hashing web panel passwords and restricting access to password files, and by removing password exposure from the API and logs.
CVE-2026-96293 is a vulnerability in WatchGuard Endpoint Security's Full Disk Encryption feature for macOS. It allows a local, unprivileged user or process to access the FileVault Personal Recovery Key by reading a diagnostic log file that is stored in cleartext and readable by all local users. This vulnerability affects WatchGuard Agent versions prior to 1.17.23.0000. The issue has been fixed in version 1.17.23.0000.
NT OneAPP by NewType Infortech has a vulnerability where sensitive information such as usernames and passwords is stored in cleartext within backup data. An unauthenticated local attacker who gains ADB backup access authorization and user confirmation of the backup can extract this sensitive information. This exposure affects versions from 0 up to and including 1.5.22.
WSO2 Universal Gateway versions prior to specific fixed releases expose sensitive credentials such as remote log server credentials, truststore passwords, and keystore passwords in cleartext within the Management Console and product files. This vulnerability arises because the system does not adequately protect these credentials when the remote logging feature is enabled. An attacker with administrative or direct file access can retrieve these credentials, potentially compromising the confidentiality and integrity of the remote log server.
Eclipse Jetty's SessionAuthentication component stores authentication credentials, including plaintext passwords, in a serializable object. When sessions are persisted to a session data store, these plaintext passwords may be written to persistent storage. An attacker with sufficient privileges to read this stored session data could obtain user passwords. The vulnerability affects multiple Jetty versions from 9.4.0 through 12.1.12. The CVSS 4.0 score is 5.6, indicating a medium severity risk.
CVE-2026-77564 is a low-severity vulnerability in Talos Linux where sensitive authentication information is stored in cleartext within support bundles generated by talosctl. This affects versions prior to 1.12.9 and between 1.13.0 and before 1.13.3. Improper sharing of these support bundles could lead to unintended disclosure of private registry credentials. Versions 1.12.9 and 1.13.3 and later redact sensitive data, and Talos 1.14 and later additionally encrypt support bundles by default to reduce exposure risk.
Vikunja versions prior to 2.4.0 store sensitive tokens such as password-reset, email-confirmation, and account-deletion tokens in plaintext within the user_tokens database table. This cleartext storage allows an attacker with read access to the database to use these tokens to take over user accounts without needing passwords. The issue is fixed in version 2.4.0.
Mindwtr versions prior to 1.1.5 store sensitive Cloud sync bearer tokens and WebDAV passwords in cleartext within unencrypted AsyncStorage on mobile devices. This allows anyone with access to the application database or device backups to retrieve these credentials and access the user's synchronized tasks and attachments. The issue is resolved in version 1.1.5.
## 1. Vulnerability Summary
nginx-ui's `Node.Secret` is a master credential that bypasses all JWT/password authentication for the entire API. The application accepts this credential via a **URL query parameter** (`?node_secret=`), causing it to be recorded in plaintext in HTTP access logs, reverse proxy logs, browser history, and HTTP `Referer` headers. Additionally, the official cluster configuration format embeds node secrets directly into URL query strings stored in `app.ini` and environment variables, creating a systemic credential exposure pattern across the entire cluster deployment model.
An attacker who gains read access to any log aggregation system, proxy log, or configuration file can extract the node secret and obtain full, persistent, unauthenticated administrative access to the nginx-ui API — including reading TLS private keys, modifying nginx configurations, and (when chained with Bug #1) achieving OS-level code execution.
---
## 2. Root Cause Analysis
### 2.1 Node Secret Accepted as URL Query Parameter
The `getNodeSecret` function reads the credential from the URL query string as a fallback when the `X-Node-Secret` header is absent: [1](#3-0)
This function is called in both `AuthRequired()` and `AuthRequiredWS()` middleware, meaning the query parameter bypass works for **all authenticated HTTP and WebSocket endpoints**: [2](#3-1) [3](#3-2)
The same pattern is repeated in the WebSocket origin checker, which also reads `node_secret` from the URL: [4](#3-3)
### 2.2 Node Secret Is a Full Authentication Bypass
The documentation explicitly states this is by design: [5](#3-4)
When the secret matches, the middleware sets the request context to an admin-level init user and calls `c.Next()` — bypassing all JWT validation, session checks, and 2FA: [2](#3-1)
### 2.3 Cluster Configuration Embeds Node Secrets in URLs
The official cluster configuration format, documented and used in `app.example.ini`, stores node secrets as URL query parameters: [6](#3-5)
The `parseNodeUrl` function extracts the secret from the URL's query string and stores it in the database as the node's `Token` field: [7](#3-6)
This means node secrets are embedded in:
- `app.ini` on disk (readable by any process with filesystem access)
- The `NGINX_UI_CLUSTER_NODE` environment variable (visible in `ps aux`, Docker inspect, Kubernetes pod specs, CI/CD logs)
- The SQLite database `nodes` table as the `token` column in plaintext
### 2.4 Node Secret Generation Uses UUID
The secret is auto-generated as a UUID v4 if not set: [8](#3-7)
UUID v4 has 122 bits of entropy, which is adequate. However, the exposure surface described in this report makes entropy irrelevant — the secret is leaked through operational channels, not brute-forced.
---
## 3. Exposure Surface
The following table maps each exposure vector to its source in the codebase:
| Vector | How It Happens | Who Can See It |
|---|---|---|
| **HTTP access logs** | `GET /api/settings?node_secret=xxx` logged by nginx/caddy/apache | Log readers, SIEM operators |
| **Application logs** | Gin debug mode logs full request URLs | Server operators, log aggregators |
| **Browser history** | Admin uses `?node_secret=` URL directly | Anyone with browser access |
| **HTTP Referer header** | Page with `?node_secret=` in URL links to external resource | Third-party servers |
| **WebSocket URL logs** | `ws://host/api/ws?node_secret=xxx` logged by proxies | Proxy log readers |
| **`app.ini` on disk** | Cluster node URLs contain `node_secret=` | Filesystem readers |
| **Environment variables** | `NGINX_UI_CLUSTER_NODE=...&node_secret=...` | `ps aux`, Docker inspect, K8s pod specs |
| **CI/CD pipeline logs** | Env vars printed during deployment | CI/CD log viewers |
| **Database** | `nodes.token` column stored in plaintext SQLite | DB file readers |
---
## 4. Proof of Concept
### Scenario A: Log-Based Secret Extraction
**Step 1 — Attacker gains read access to nginx access logs** (e.g., via a misconfigured log aggregator, a compromised monitoring account, or a separate vulnerability).
**Step 2 — Search logs for the pattern:**
```bash
grep -oP 'node_secret=[^&\s"]+' /var/log/nginx/access.log
# Output: node_secret=a1b2c3d4-e5f6-7890-abcd-ef1234567890
```
**Step 3 — Use the extracted secret for full API access:**
```http
GET /api/settings HTTP/1.1
Host: target:9000
X-Node-Secret: a1b2c3d4-e5f6-7890-abcd-ef1234567890
```
Response: Full settings JSON including `JwtSecret`, `NodeSecret`, all nginx paths, and all configured credentials.
```http
GET /api/nginx/config?filepath=/etc/nginx/nginx.conf HTTP/1.1
Host: target:9000
X-Node-Secret: a1b2c3d4-e5f6-7890-abcd-ef1234567890
```
Response: Full nginx configuration including any embedded credentials.
### Scenario B: Environment Variable Exposure in Docker/Kubernetes
**Step 1 — Attacker reads a Kubernetes pod spec or Docker Compose file:**
```yaml
environment:
- NGINX_UI_CLUSTER_NODE=http://10.0.0.1:9000?name=node1&node_se
The TP-Link Tapo S505 device firmware version 1.6 stores device-specific cryptographic material in plaintext within nonvolatile storage. This cleartext storage allows an attacker with physical access to the device to extract sensitive cryptographic information. Exploitation could lead to disclosure of this material and potentially increase the risk of unauthorized access to protected information or communications related to the device.