Daily Digest
The most urgent items are two PostgreSQL vulnerabilities (CVE-2026-6473 and CVE-2026-6477, both CVSS 8.8) that allow an unprivileged database user to achieve arbitrary code execution as the operating system user running the database via integer wraparound and a libpq stack-buffer overflow. Both affect all supported PostgreSQL versions prior to the May 2026 patch releases (18.4, 17.10, 16.14, 15.18, 14.23) and are directly relevant to the healthcare enterprise PostgreSQL fleet and the homelab Postgres/Vault PKI/mTLS stack. No CISA KEV entries are present in this dataset, so these highest-CVSS issues take top priority.
Summary: A case-sensitivity mismatch in Cloud Foundry UAA’s identity zone authorization check allows a remote authenticated attacker with only the `zones.write` authority to bypass restrictions and access the privileged system zone when UAA is backed by MySQL using its default case-insensitive collation. The attacker can overwrite the system zone’s JWT signing key, forge admin JWTs, and fully compromise UAA and any trusting Cloud Foundry deployment. PostgreSQL and HSQLDB backends are not affected.
Affected Features / Interoperability: Cloud Foundry UAA identity zone management when persisted to MySQL with default collation; impacts JWT-based authentication and authorization across the Cloud Foundry platform. Downstream integrations relying on UAA-issued tokens (e.g., service-to-service auth, SSO) would be compromised.
Source: https://www.cloudfoundry.org/blog/cve-2026-59335-uaa-case-insensitive-check-bypass/
Actions:
Summary: An unauthenticated, network-accessible vulnerability in MySQL Cluster (HTTP interface) that requires human interaction (e.g., phishing) to exploit. Successful exploitation can lead to full takeover of the MySQL Cluster. Affected versions: 8.0.0–8.0.48, 8.4.0–8.4.11, 9.7.0–9.7.2.
Affected Features / Interoperability: MySQL Cluster management and HTTP endpoints; could impact cluster replication, data distribution, and any applications relying on Cluster’s high-availability features.
Source: https://www.oracle.com/security-alerts/cspuaug2026.html
Actions:
Summary: Integer wraparound in multiple PostgreSQL server features allows an unprivileged database user to cause an undersized allocation and out-of-bounds write, leading to arbitrary code execution as the OS user running the database. Triggered by passing gigabyte-scale user inputs to affected database functions.
Affected Features / Interoperability: Core server functions that handle large user inputs (exact functions not specified in advisory). Could impact any workload that processes large objects, bulk imports, or user-supplied data via SQL functions. Replication, logical decoding, and extensions that call into vulnerable code paths may also be affected.
Source: https://www.postgresql.org/support/security/CVE-2026-6473/, https://access.redhat.com/errata/RHSA-2026:22878, https://access.redhat.com/errata/RHSA-2026:26181, https://access.redhat.com/errata/RHSA-2026:26203, https://access.redhat.com/errata/RHSA-2026:26204
Actions:
Summary: The libpq functions `lo_export()`, `lo_read()`, `lo_lseek64()`, and `lo_tell64()` use the unsafe `PQfn(..., result_is_int=0, ...)` which allows a malicious server superuser to overwrite a client stack buffer with an arbitrarily large response. This affects `psql`'s `\lo_export` command and `pg_dump`, enabling a compromised server to attack backup/admin clients.
Affected Features / Interoperability: Large object (LO) operations in libpq, `psql`, and `pg_dump`. Any client using these functions (including backup scripts, replication tools, and custom applications) is vulnerable when connecting to a malicious or compromised server.
Source: https://www.postgresql.org/support/security/CVE-2026-6477/, https://access.redhat.com/errata/RHSA-2026:21182, https://access.redhat.com/errata/RHSA-2026:22878, https://access.redhat.com/errata/RHSA-2026:26181, https://access.redhat.com/errata/RHSA-2026:26203
Actions:
Summary: Identical to the MySQL entry above: a case-sensitivity bypass in Cloud Foundry UAA when backed by MySQL. The advisory explicitly states PostgreSQL backends are not affected. This entry appears in the PostgreSQL feed likely due to shared CVE tracking; no PostgreSQL-specific vulnerability exists.
Affected Features / Interoperability: None for PostgreSQL; the vulnerability is specific to MySQL-backed UAA deployments.
Source: https://www.cloudfoundry.org/blog/cve-2026-59335-uaa-case-insensitive-check-bypass/
Actions:
Summary: CloudNativePG (PostgreSQL operator for Kubernetes) embedded cleartext role passwords in `ALTER ROLE`/`CREATE ROLE` statements prior to versions 1.28.4, 1.29.2, and 1.30.0. When `pg_stat_statements` is preloaded with `track_utility` enabled, an untrusted tenant with `pg_monitor` or `pg_read_all_stats` can read those passwords, reconnect as superuser via TCP, and execute OS commands via `COPY ... FROM PROGRAM`. Clusters using SCRAM-SHA-256 verifiers in managed-role Secrets are not affected.
Affected Features / Interoperability: CloudNativePG-managed PostgreSQL clusters in Kubernetes; impacts secret handling, role management, and `pg_stat_statements` visibility. Downstream: any Kubernetes-hosted PostgreSQL workloads using CloudNativePG with password-based authentication and `pg_stat_statements` enabled.
Source: https://github.com/cloudnative-pg/cloudnative-pg/commit/2f0342747e1f160425b9d51753c0069b0d6117d5, https://github.com/cloudnative-pg/cloudnative-pg/commit/3cd5af5d388c26758acf13c19ea806b4bcebb3fe, https://github.com/cloudnative-pg/cloudnative-pg/commit/9a13573dbe3d78721b7ea92141e6d2324a2c0ef0, https://github.com/cloudnative-pg/cloudnative-pg/pull/10724, https://github.com/cloudnative-pg/cloudnative-pg/releases/tag/v1.28.4
Actions:
Summary: baserCMS before 5.3.0 has a SQL injection in `BcDatabaseService.php` allowing authenticated administrators to inject table names and configuration values into SQL statements (sequence update, CSV export, table management). Combined with a backup-restore code injection flaw, attackers can plant malicious table names and extract data via error-based SQL injection against the PostgreSQL backend.
Affected Features / Interoperability: baserCMS admin panel features: sequence management, CSV export, table management, and backup/restore. Impacts any PostgreSQL database used by baserCMS.
Source: https://github.com/baserproject/basercms/releases/tag/5.3.0, https://github.com/baserproject/basercms/security/advisories/GHSA-cg65-f2m7-9fqj, https://www.vulncheck.com/advisories/basercms-sql-injection-and-code-injection-via-bcdatabaseservice-php
Actions:
Summary: A covert timing channel in the comparison of MD5-hashed passwords during PostgreSQL authentication allows credential recovery. Does not affect `scram-sha-256` (default in all supported releases). Only impacts databases with MD5 passwords carried over from upgrades from PostgreSQL 13 or earlier.
Affected Features / Interoperability: PostgreSQL authentication subsystem for MD5-hashed passwords. Client drivers and applications using password authentication with legacy MD5 hashes.
Source: https://www.postgresql.org/support/security/CVE-2026-6478/, https://access.redhat.com/errata/RHSA-2026:21182, https://access.redhat.com/errata/RHSA-2026:22878, https://access.redhat.com/errata/RHSA-2026:26181, https://access.redhat.com/errata/RHSA-2026:26203
Actions:
Summary: Vulnerability in the Advanced Networking Option (ANO) of Oracle Database Server (versions 12.1.0.2, 12.2.0.1, 19c). An unauthenticated attacker with network access via Oracle Net can compromise ANO, requiring human interaction. Successful attacks may significantly impact additional products and result in takeover of ANO. The July 2021 CPU introduced Native Network Encryption changes to mitigate this and prevent weaker ciphers.
Affected Features / Interoperability: Oracle Advanced Networking Option (encryption/integrity for Oracle Net). Downstream: any database links, client connections, or middleware relying on ANO for network security.
Source: http://packetstormsecurity.com/files/165255/Oracle-Database-Protection-Mechanism-Bypass.html, http://packetstormsecurity.com/files/165258/Oracle-Database-Weak-NNE-Integrity-Key-Derivation.html, http://seclists.org/fulldisclosure/2021/Dec/19, http://seclists.org/fulldisclosure/2021/Dec/20, https://www.oracle.com/security-alerts/cpuapr2022.html
Actions:
Unverified chatter — not authoritative vulnerability intelligence.
MySQL
PostgreSQL
Oracle Database
Microsoft SQL Server
One-paragraph executive summary.
Then `### Formal Vulnerabilities`
For each system with entries, I'll do `#### [System Name]` maybe? The structure says: "For EACH entry: #### [System Name] — [CVE ID] (CVSS [score or "UNSCORED"] [severity]) [add "🔴 ACTIVELY EXPLOITED (CISA KEV)" if confirmed_exploited_by_cisa_kev is true]". So each entry starts with `#### [System Name] — [CVE ID] ...`. I'll do that.
I need to be careful with the system name formatting. The data has "AWS", "Kubernetes", "Docker", "Terraform". I'll use those.
Let's draft each entry.
AWS — CVE-2026-54874 (CVSS 7.5 HIGH)
Summary: ...
Affected Features / Interoperability: ...
Source: ...
Actions: ...
Kubernetes — CVE-2026-66794 (CVSS 9.3 CRITICAL)
etc.
Kubernetes — CVE-2026-10059 (CVSS 9.1 CRITICAL)
etc.
Kubernetes — CVE-2026-62440 (CVSS 9.1 CRITICAL)
etc.
Kubernetes — CVE-2026-55765 (CVSS 8.5 HIGH)
etc.
Kubernetes — CVE-2026-4740 (CVSS 8.2 HIGH)
etc.
Kubernetes — CVE-2026-53572 (CVSS 5.9 MEDIUM)
etc.
Kubernetes — CVE-2026-53487 (CVSS 4.3 MEDIUM)
etc.
Kubernetes — CVE-2026-32637 (CVSS UNSCORED) - cvss_severity is null, cvss_score is null. I'll put (CVSS UNSCORED) and severity maybe "UNSCORED" or omit. The format says: CVSS [score or "UNSCORED"] [severity]. If score is null, I'll put (CVSS UNSCORED). Severity also null, maybe I'll just say (CVSS UNSCORED) and not add severity, or say (CVSS UNSCORED severity: N/A). I'll follow: if score is null, use "UNSCORED" for score, and for severity, if null, maybe just leave blank or say "UNSCORED". I'll put (CVSS UNSCORED) and not force a severity if not given. The format example: `CVSS [score or "UNSCORED"] [severity]`. I'll do `(CVSS UNSCORED)` if score null, and if severity null, maybe just `(CVSS UNSCORED)`. I'll check: "CVSS [score or "UNSCORED"] [severity]". I'll include severity only if available. For CVE-2026-32637, cvss_score null, cvss_severity null. I'll write `(CVSS UNSCORED)`.
Docker — CVE-2026-55581 (CVSS 8.4 HIGH)
Docker — CVE-2026-55582 (CVSS 8.4 HIGH)
Docker — CVE-2026-49217 (CVSS 7.5 HIGH)
Docker — CVE-2026-44517 (CVSS 6.3 MEDIUM)
Terraform — CVE-2026-64679 (CVSS 8.1 HIGH)
Terraform — CVE-2026-45099 (CVSS UNSCORED) - cvss_score null, cvss_severity null.
Now, Affected Features / Interoperability for each. I'll need to read descriptions carefully and extract what's impacted.
Let's do them one by one, carefully.
First, executive summary:
"The most urgent item is CVE-2026-66794 in Kubernetes (CVSS 9.3 CRITICAL), an unauthenticated authentication bypass in Multicluster Engine for Kubernetes that allows an attacker to proxy requests to arbitrary services across managed clusters, potentially leading to full cluster compromise. No CISA KEV-confirmed entries are present in this digest, so priority is determined by CVSS severity; the highest-rated vulnerability across all systems is this Kubernetes entry, followed by critical issues in Docker and Terraform. All other systems either have no formal vulnerability entries or are covered under news chatter."
Wait, the user said: "highlighting the single most urgent item (a CISA KEV-confirmed entry always outranks a merely high-CVSS entry, since it's confirmed exploitation vs. theoretical severity)." Since there are no KEV entries, I'll just highlight the highest CVSS. I'll make sure to note that no KEV entries are present, so the most urgent is the highest CVSS.
Now, Formal Vulnerabilities section. I'll list entries per system in their given order (KEV first, then CVSS descending). Since no KEV, just the order given.
I need to ensure I don't re-sort. The data says entries within each system are ALREADY SORTED (KEV-confirmed first, then CVSS descending) -- present them in this order, do not re-sort. So I'll present them exactly as they appear in the data for each system.
Let's verify the order for each system:
Now, for each entry, I need to produce:
`#### [System Name] — [CVE ID] (CVSS [score or "UNSCORED"] [severity]) [🔴 ACTIVELY EXPLOITED (CISA KEV) if true]`
Since no KEV tag, I'll omit the bracket part if not applicable. Actually, the format says: add "🔴 ACTIVELY EXPLOITED (CISA KEV)" if confirmed_exploited_by_cisa_kev is true. Since it's not in data, I won't add it. I'll just have `#### AWS — CVE-2026-54874 (CVSS 7.5 HIGH)`.
Then Summary, Affected Features / Interoperability, Source, Actions.
Let's craft summaries and affected features carefully, using only data provided, not guessing beyond what's reasonable but stating if sparse.
I'll start writing the markdown.
Important: "Output ONLY the final Markdown report. Do not think out loud, do not show your reasoning process, do not narrate how you're analyzing or sorting the data. Go straight to the finished report text."
So I'll just output the markdown.
Let's structure:
[Executive summary paragraph]
[Entries]
[Bullets]
Now, write executive summary:
"The highest-priority vulnerability in this digest is CVE-2026-66794 in Kubernetes (CVSS 9.3 CRITICAL), an unauthenticated authentication bypass in Multicluster Engine for Kubernetes that enables proxying requests to arbitrary services across managed clusters, potentially resulting in full cluster compromise. No CISA KEV-confirmed entries of actively exploited vulnerabilities are present in this dataset, so severity ordering follows CVSS; the Kubernetes entry ranks above all high-severity findings in Docker and Terraform. All other systems either lack formal vulnerability entries or are represented only in community chatter."
Wait, the user said: "highlighting the single most urgent item (a CISA KEV-confirmed entry always outranks a merely high-CVSS entry, since it's confirmed exploitation vs. theoretical severity)." I should explicitly state that no KEV entries are present, so the most urgent is the highest CVSS. That's fine.
Now, Formal Vulnerabilities. I'll list each entry.
Let's do AWS first.
Summary: OpenSSL DTLS implementation buffers incoming records in full 16 KB read buffers rather than the actual record size, allowing a remote peer to amplify memory retention by approximately 1200x via a stream of small forged DTLS records, leading to Denial of Service. No authentication is required; exploitation is network-reachable.
Affected Features / Interoperability: OpenSSL DTLS servers and peers. Any service relying on DTLS for secure UDP transport (e.g., HTTPS over UDP, VPN gateways, VoIP) may experience memory exhaustion and process crashes. The raw data does not indicate impact on database replication, client drivers, or extensions beyond the TLS layer.
Source: GitHub commits [1], [2], [3], [4], [5]; reported by Amazon Web Services.
Actions:
Next, Kubernetes entries.
Summary: An unauthenticated attacker with access to the user-facing route in Multicluster Engine for Kubernetes can manipulate URL path segments to bypass authentication and authorization checks, proxying requests to arbitrary services across any managed cluster. This enables unauthorized access to internal services, potentially leading to information disclosure or full cluster compromise.
Affected Features / Interoperability: The `cluster-proxy-addon` component of Multicluster Engine for Kubernetes. Compromise could expose or allow manipulation of any service reachable through the proxy, including database endpoints and control planes. The raw data does not specify impact on standard Kubernetes API server behavior or etcd replication.
Source: Red Hat Errata RHSA-2026:59556, RHSA-2026:59593, CVE page, Bugzilla #2507539.
Actions:
Summary: A tenant administrator with namespace-scoped privileges can create a namespaced ClusterCurator controller, inadvertently granting the ability to mint a token for a ServiceAccount with cluster-wide administrative authority. This privilege escalation allows the tenant to gain full control over the cluster beyond intended namespace boundaries.
Affected Features / Interoperability: CloudNativePG ClusterCurator controller within Kubernetes. Exploitation could allow unauthorized superuser access and OS command execution via `COPY ... FROM PROGRAM` if pg_stat_statements is preloaded with `track_utility` enabled. The raw data does not indicate impact on general Kubernetes resource permissions outside the controller.
Source: Red Hat Errata RHSA-2026:59556, CVE page, Bugzilla #2483187.
Actions:
Summary: Improper access control in Apache CloudStack's Kubernetes Service (CKS) plugin allows cross-tenant manipulation of the Kubernetes cluster when adding or removing nodes. An attacker can manipulate cross-tenant operations to affect cluster state.
Affected Features / Interoperability: Apache CloudStack Kubernetes Service (CKS) plugin. Impacts node lifecycle operations and cluster management within CloudStack. The raw data does not specify impact on underlying Kubernetes API server security or etcd integrity.
Source: Apache CloudStack mailing list archive.
Actions:
Summary: CloudNativePG embedded cleartext role passwords in `ALTER ROLE` and `CREATE ROLE` statements prior to 1.28.4 and 1.29.2. When pg_stat_statements is preloaded with `track_utility` enabled and an untrusted tenant holds `pg_monitor` or `pg_read_all_stats`, the tenant can recover platform-managed superuser or application-owner passwords, reconnect via TCP, and execute OS commands via `COPY ... FROM PROGRAM`.
Affected Features / Interoperability: CloudNativePG managed PostgreSQL deployments within Kubernetes. Affects role password handling in Secrets; clusters using SCRAM-SHA-256 verifiers in managed-role Secrets were not affected. The raw data does not indicate impact on standard PostgreSQL replication or client driver behavior.
Source: GitHub commits, Pull #10724, Release v1.28.4.
Actions:
Summary: Improper validation of Kubernetes client certificate renewal in Open Cluster Management (OCM) allows a managed cluster administrator to forge a client certificate approved by the OCM controller, enabling cross-cluster privilege escalation and potential control over other managed clusters, including the hub.
Affected Features / Interoperability: Open Cluster Management (OCM) and Red Hat Advanced Cluster Management (ACM). Impacts certificate renewal logic and cross-cluster trust relationships. The raw data does not specify impact on standard Kubernetes API server certificate handling.
Source: Red Hat Errata RHSA-2026:11414, RHSA-2026:13542, RHSA-2026:13853, RHSA-2026:8218, RHSA-2026:9848.
Actions:
Summary: KEDA PostgreSQL scaler constructs libpq connection strings from tenant-controlled values without proper escaping of tabs, newlines, quotes, and backslashes. An attacker able to create or modify a TriggerAuthentication or ScaledObject can inject host or sslmode parameters, redirect database connections to attacker-controlled servers, expose credentials, or disable intended TLS protection.
Affected Features / Interoperability: KEDA PostgreSQL scaler in Kubernetes. Impacts automated scaling based on PostgreSQL metrics; exploitation could lead to credential theft and man-in-the-middle attacks on database connections. The raw data does not indicate impact on KEDA scalers for other database types.
Source: GitHub commits, issue #7784, PR #7787, release v2.20.0, advisory GHSA-6w3m-4hhp-775q.
Actions:
Summary: Kite Kubernetes dashboard allows authenticated users with any role to request the `/api/v1/overview` endpoint for clusters their roles do not permit by selecting the cluster via `x-cluster-name`. The route is registered before RBAC middleware, and the endpoint only checks if the user has any roles, returning aggregate inventory and capacity data from unauthorized clusters.
Affected Features / Interoperability: Kite Kubernetes dashboard. Exposes aggregate cluster capacity and inventory data to unauthorized authenticated users. The raw data does not indicate impact on actual cluster resources or API server security.
Source: GitHub security advisories GHSA-gvhc-wv3v-7pf8.
Actions:
Summary: Velero backup restoration prior to 1.18.1 allows an attacker who compromises the backup object-storage backend to upload a malicious backup tarball containing parent-directory paths that escape the extraction directory during restore, potentially overwriting sensitive files in the Velero pod filesystem.
Affected Features / Interoperability: Velero backup and restore operations. Impact is limited to the Velero pod filesystem; the raw data does not indicate impact on Kubernetes cluster resources, etcd, or underlying infrastructure beyond the pod's file system.
Source: GitHub gosec issue #324, Velero commits, advisory GHSA-j2g6-362q-6qc6.
Actions:
Now Docker entries.
Summary: mcp-shell default Docker security.yaml includes `/bin/bash` in `allowed_executables`, and validation does not reject the `-c` shell command-mode flag, allowing a caller to provide `/bin/bash -c <arbitrary-command>` which executes outside the intended allowlist as `mcpuser` outside the container's security context.
Affected Features / Interoperability: mcp-shell MCP server running inside Docker. Impacts command execution functionality; the raw data does not indicate impact on broader Docker daemon behavior or host system access beyond the `mcpuser` process context.
Source: GitHub commits, PR #16, Release v0.6.0, advisory GHSA-3x77-wg38-92r3.
Actions: