Daily Digest
User Safety: safe
The most urgent item in today's digest is Docker CVE-2026-85751 (CVSS 9.8 CRITICAL) affecting Mailu mail server deployments, where a misconfigured proxy authentication setup allows unauthenticated remote attackers to bypass authentication entirely by spoofing trusted proxy identity via the X-Forwarded-By header. In the Kubernetes ecosystem, CVE-2026-12564 (CVSS 9.6 CRITICAL) remains critically relevant to healthcare environments, as it enables authenticated attackers to exfiltrate Kubernetes service account tokens through the AAP Controller's HashiCorp Vault credential plugin, potentially exposing database credentials and the Django SECRET_KEY stored in control-plane secrets. No CISA KEV-confirmed entries were identified in today's data; all vulnerabilities below are prioritized by CVSS severity.
Summary: A flaw in the AAP Controller's HashiCorp Vault credential plugin causes the `kubernetes_auth()` function in `awx_plugins/credentials/hashivault.py` to read the controller pod's Kubernetes service account token and send it to an attacker-controlled URL when a HashiCorp Vault Secret Lookup credential with kubernetes_role authentication is tested. An authenticated attacker with credential-creation privileges can exfiltrate the service account token, gaining Kubernetes API access to control plane namespaces with full pod CRUD and secret read permissions, including database credentials and the Django SECRET_KEY.
Affected Features / Interoperability: The HashiCorp Vault credential plugin in AAP Controller (AWX), specifically the `kubernetes_auth()` function. Downstream impacts include exposure of Kubernetes API access to control plane namespaces, potential compromise of database credentials stored as Kubernetes secrets, and exposure of the Django SECRET_KEY — which could lead to session forgery or further application compromise in AAP/Ansible Tower deployments.
Source:
Actions:
Summary: The Observability Operator creates a ServiceAccount with a ClusterRole upon deployment of the Namespace-Scoped Custom Resource MonitorStack. This allows an adversarial Kubernetes account with only namespaced-level roles to create a MonitorStack in an authorized namespace and then escalate to cluster-level permissions by impersonating the ServiceAccount created by the Operator, resulting in privilege escalation.
Affected Features / Interoperability: The Observability Operator's ServiceAccount creation logic and MonitorStack Custom Resource. Downstream impacts include cluster-wide privilege escalation for any tenant with namespace-level access, potentially compromising monitoring data and allowing lateral movement across the cluster.
Source:
Actions:
Summary: The Red Hat OpenShift AI (RHOAI) overlay for the training operator incorrectly aggregates `trainjobs` management permissions into the native Kubernetes `edit ClusterRole`. This allows any user with `edit ClusterRole` permissions in a namespace to create, modify, and delete `TrainJobs`. When combined with a separate vulnerability (TRN-01) permitting arbitrary pod configurations, a remote attacker with namespace editor privileges could escalate privileges, potentially leading to arbitrary code execution.
Affected Features / Interoperability: RHOAI training operator, the `edit ClusterRole` aggregation logic, and TrainJobs custom resources. Downstream impacts include privilege escalation for namespace editors, potential arbitrary code execution when combined with TRN-01, and compromise of AI/ML training workloads in OpenShift environments.
Source:
Actions:
Summary: A flaw in the RHOAI training-operator allows a user with standard edit or admin roles in any Kubernetes namespace to escalate privileges. Through the creation of training jobs, an attacker can impersonate service accounts, access the host filesystem, and potentially execute arbitrary code remotely. This arises from the aggregation of training job permissions onto native Kubernetes edit and admin ClusterRoles, coupled with unrestricted PodTemplateSpec passthrough.
Affected Features / Interoperability: RHOAI training-operator, edit and admin ClusterRoles, PodTemplateSpec passthrough, and training job custom resources. Downstream impacts include service account impersonation, host filesystem access, potential remote arbitrary code execution, and compromise of AI training workloads.
Source:
Actions:
Summary: A vulnerability in CRI-O checkpoint restore allows a user who can create a pod from a malicious checkpointed container to bypass the destination Kubernetes security context. The restored process may retain credentials, Linux capabilities, no_new_privs, and seccomp state from the checkpoint instead of enforcing the destination configuration, allowing execution with elevated privileges across the container security boundary. Affected upstream supported versions are CRI-O 1.34 and later; downstream Red Hat products are affected from OCP 4.17 onward. Exploitation requires permission to create a pod from a malicious checkpoint image and checkpoint restore functionality to be available.
Affected Features / Interoperability: CRI-O checkpoint/restore functionality, Kubernetes pod security contexts, container credentials, Linux capabilities, no_new_privs, and seccomp profiles. Downstream impacts include bypassing container security boundaries, privilege escalation across pods, and potential cluster compromise. Fixes have been applied to supported branches but are not yet released.
Source:
Actions:
Summary: A flaw in the Data Science Pipelines Operator (DSPO) means its ClusterRole includes extensive privileges beyond what is necessary for its operation, such as the ability to execute commands within pods and manage cluster-wide roles. If the DSPO pod were compromised, an attacker could leverage these excessive permissions to gain full administrative control over the entire Kubernetes cluster.
Affected Features / Interoperability: Data Science Pipelines Operator (DSPO) ClusterRole, pod command execution, and cluster-wide role management. Downstream impacts include full cluster administrative control if the DSPO pod is compromised, affecting all data science workloads and associated resources.
Source:
Actions:
Summary: Mailu, a mail server distributed as Docker images, trusted a client-controlled X-Forwarded-By header for header-based proxy authentication in deployments with PROXY_AUTH_WHITELIST configured but REAL_IP_HEADER unset (from Mailu 2.0 until 2024.06.55, and prior to Mailu helm-charts 2.7.3). The `proxy_hide_header` directive in the nginx template hid the header from upstream responses but did not overwrite the incoming request value, allowing an unauthenticated remote attacker to spoof the trusted proxy identity and bypass authentication. This issue is fixed in Mailu 2024.06.55 and Mailu helm-charts 2.7.3.
Affected Features / Interoperability: Mailu mail server Docker deployments, nginx proxy configuration (`proxy_hide_header` directive), PROXY_AUTH_WHITELIST and REAL_IP_HEADER settings, and header-based proxy authentication. Downstream impacts include complete authentication bypass for mail services, unauthorized email access, and potential data exfiltration in healthcare environments handling protected health information (PHI).
Source:
Actions:
Summary: Tinyauth, an authentication and authorization server, compares forwarded hostnames case-sensitively while reverse proxies route equivalent hostnames case-insensitively. This allows an authenticated low-privilege user to bypass per-app access controls with a differently cased hostname. The lookup in `internal/service/access_controls_service.go` through `lookupStaticACLs` and `GetAccessControls`, and the Docker-label fallback in `internal/service/docker_service.go` through `GetLabels`, can miss the configured app and return an empty access-control object. The proxy handler then treats empty restrictions as permissive. Unauthenticated users remain subject to login, and global login-time allowlists are not bypassed. This issue is fixed in version 5.1.2.
Affected Features / Interoperability: Tinyauth authentication server, access control lookups (`lookupStaticACLs`, `GetAccessControls`), Docker-label fallback (`GetLabels`), and proxy handler (`proxyHandler`). Downstream impacts include unauthorized access to applications protected by Tinyauth, potential data exposure, and bypass of per-app access controls in reverse proxy deployments.
Source:
Actions:
Summary: In draw.io prior to version 30.2.7, the OAuth callback handler in `src/main/java/com/mxgraph/online/AbsAuth.java` skips comparison of `stateToken` and `cookieToken` whenever `IS_GAE` is false, affecting self-hosted Docker and WAR deployments. An attacker can provide an authorization code for their own cloud-storage identity and induce a victim to visit a callback URL, causing the victim's draw.io session to become authenticated as the attacker's identity without valid state binding. The shared handler affects Google Drive, OneDrive, GitHub, GitLab, and Dropbox integrations. The victim can then unknowingly perform cloud-storage actions under the attacker's identity, causing session integrity loss and misattribution, but the identity binding does not itself grant access to existing victim cloud files. This issue is fixed in version 30.2.7.
Affected Features / Interoperability: draw.io OAuth callback handler (`AbsAuth.java`), stateToken/cookieToken comparison logic, and cloud-storage integrations (Google Drive, OneDrive, GitHub, GitLab, Dropbox). Downstream impacts include session integrity loss, misattribution of cloud-storage actions, and potential unauthorized cloud-storage operations under the victim's identity. Note: existing victim cloud files are not directly accessible through this vulnerability.
Source:
Actions:
Summary: A vulnerability in the Thinkst Canary honeypot Redis service allows an unauthenticated remote attacker to execute a Denial-of-Service attack against the honeypot. The vulnerability is accessible when the Redis service is enabled only; the Canary is not affected if the Redis service is disabled. Thinkst has addressed this issue on all supported platforms. New update files are available on all platforms except Docker; for Docker customers, a new Docker image has been published. Customers with automatic updates enabled already have updates in distribution. If automatic updates are disabled, customers are advised to update their Canaries. Workarounds are available for customers unable to update at this time.
Affected Features / Interoperability: Thinkst Canary honeypot Redis service. Downstream impacts include denial-of-service against the honeypot, potentially disrupting deception-based monitoring. The Canary is unaffected if Redis is disabled.
Source:
Actions:
⚠ The following items are unverified community/news chatter and are not authoritative security advisories.
AWS:
Microsoft Azure: