Daily Digest
User Safety: safe
One-paragraph executive summary, 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).
Then Formal Vulnerabilities: For each system with entries, list each entry with subheading: #### [System Name] — [CVE ID] (CVSS [score or "UNSCORED"] [severity]) [add "🔴 ACTIVELY EXPLOITED (CISA KEV)" if confirmed_exploited_by_cisa_kev is true]
We need to check if any entries have confirmed_exploited_by_cisa_kev true. The data provided does not include that field. So none are KEV. So we just output CVSS score and severity.
If cvss_score is null, we output "UNSCORED". Severity may be null; we still show? Probably show as given.
We need to list entries for each system present in the data: Google Cloud Platform, Kubernetes, Docker. Possibly others? The data includes those three under FORMAL VULNERABILITY DATA. Also there is news for other systems like Microsoft Azure, AWS, etc. But we only include Formal Vulnerabilities for systems with entries. So we will have sections for Google Cloud Platform, Kubernetes, Docker.
We need to limit to top 10 entries per system if more than 10. Each system has less than 10: GCP has 1, Kubernetes has 4, Docker has 9 (maybe 9? Let's count: Docker entries list from CVE-2026-101065 to CVE-2025-27772 (that's 9). So all included.
We need to produce Summary, Affected Features / Interoperability, Source (list URLs), Actions (Fix, Workaround, Tradeoff). We must infer from description.
We must not invent details beyond what's given. If data too sparse, say so.
We need to parse each entry.
Let's process each.
Description: "An Incorrect Authorization vulnerability in the task configuration in Google Cloud Application Integration versions prior to 2026-06-17 on Google Cloud Platform allows an authenticated Google Cloud user to execute arbitrary internal RPCs from inside Google's production network under a privileged identity using an internal-only task type.
This vulnerability was patched on 17 June 2026, and no customer action is needed."
CVSS_score: null, cvss_severity: null.
So we output CVSS UNSCORED (no severity). Severity null.
Summary: Plain-English explanation: It's an auth flaw in Google Cloud Application Integration allowing authenticated GCP user to execute arbitrary internal RPCs from inside Google's production network under privileged identity using internal-only task type. Triggered by authenticated user with access to task configuration. No auth required beyond being authenticated GCP user. Exploitable by authenticated GCP user with permission to configure tasks.
Affected Features / Interoperability: Google Cloud Application Integration task configuration; could allow execution of arbitrary internal RPCs, potentially impacting internal services, privileged operations, etc. If raw data doesn't say downstream, we state that plainly rather than guessing. The description mentions ability to execute arbitrary internal RPCs from inside Google's production network under a privileged identity using an internal-only task type. So affected feature: task configuration in Application Integration. Downstream functionality: could allow privileged internal RPC execution, potentially affecting any internal service reachable via those RPCs. We can say that.
Source: list the two URLs.
Actions: Fix: official patched version/release: patched on 17 June 2026; no customer action needed (implies already patched). So we can say Fix: Patched as of 2026-06-17; no further action required. Workaround: none needed. Tradeoff: No significant tradeoff.
We need to process each.
Description: Edgelesssys Contrast is a confidential-computing runtime for Kubernetes. In versions 1.9.0 before 1.12.2, the initializer logs the full NewMeshCert response — which contains the workload secret — to standard output at INFO level. As a result, workload secrets are exposed to any Kubernetes user with get or list permission on pods/logs. Because workload secrets are used for encrypted storage and Vault integration, those must also be considered compromised. This is a regression of GHSA-h5f8-crrq-4pw8.
CVSS_score: 7.3, severity HIGH.
Summary: The initializer logs workload secrets to pod logs, exposing them to any user who can read pod logs. Triggered when using Contrast versions 1.9.0-1.12.1; any user with pod/logs read access can exploit. No auth beyond Kubernetes RBAC get/list on pods/logs.
Affected Features / Interoperability: Edgelesssys Contrast initializer logging; impacts workload secrets used for encrypted storage and Vault integration; could break encryption, expose secrets, affect any service relying on those secrets.
Source: list four URLs.
Actions: Fix: upgrade to Contrast 1.12.2 or later. Workaround: restrict access to pod logs, disable INFO logging, or redact logs; maybe set log level higher than INFO. Tradeoff: reducing visibility into logs may hinder debugging.
Description: path traversal vulnerability in Kubernetes kubectl client's kubectl cp command on Windows. When copying files from a container, kubectl runs tar inside container to build tar archive, transfers over network, unpacks locally. If tar binary in container is malicious, it can execute arbitrary code and emit unexpected output, allowing attacker who controls container contents to write files to arbitrary paths on user's local machine, limited by local user permissions. Only affects kubectl clients on Windows.
CVSS_score: 6.5, severity MEDIUM.
Summary: Malicious tar inside container can escape and write arbitrary files on Windows host when using kubectl cp. Triggered when user runs kubectl cp from Windows client copying from container; attacker needs ability to modify container's tar binary (e.g., via image). Exploitable by anyone who can run kubectl cp on Windows and has access to a container they can influence (e.g., via image). No auth beyond ability to exec kubectl cp.
Affected Features / Interoperability: kubectl cp command on Windows; could allow writing arbitrary files on host, potentially compromising host, affecting any workload that relies on host integrity, etc.
Source: list four URLs.
Actions: Fix: use patched kubectl version (the issue is in kubectl client; need to upgrade kubectl to version where fix applied). The description doesn't give version; we can say "Upgrade kubectl to a version where the vulnerability is patched (refer to Kubernetes release notes)". Workaround: avoid using kubectl cp on Windows, or ensure container's tar binary is trusted (use verified images, disable ability to replace tar). Tradeoff: losing convenience of cp; using alternative like exec and copy.
Description: SUSE Rancher Fleet vulnerability: user who can supply bundle content to a repository referenced by a GitRepo resource can cause Fleet to read files from filesystem of environment processing bundle and include contents in generated Bundle resource, exposing config/cred material user lacks RBAC to read, including Helm registry credentials when per-path Helm credentials configured. Affects Fleet versions listed.
CVSS_score: 6.5, severity MEDIUM.
Summary: Malicious bundle content can lead to arbitrary file read on Fleet bundle-processing job, exposing secrets. Triggered when user with ability to push to repo or modify GitRepo supplies malicious bundle. Exploitable by user with write access to GitRepo or bundle source.
Affected Features / Interoperability: Fleet's GitRepo resource processing; could expose Helm registry credentials and other secrets, impacting any service that uses those secrets (e.g., Vault, internal APIs). Could break trust in CI/CD pipelines.
Source: one URL.
Actions: Fix: upgrade Fleet to patched versions: 0.16.2, 0.15.7, 0.14.11, 0.13.16, 0.12.20 or later. Workaround: restrict who can create/modify GitRepo or push bundle content; enforce image signing, restrict repo access. Tradeoff: limiting developer flexibility.
Description: Fleet's Git webhook receiver (gitjob webhook service) when webhook secret not configured accepts unverified requests, allowing caller with network access to webhook service to alter GitRepo.spec.pollingInterval in any namespace, changing config outside authorized namespaces. Affects Fleet 0.16 before 0.16.2.
CVSS_score: 5.4, severity MEDIUM.
Summary: Missing webhook secret allows unauthenticated network caller to modify GitRepo config. Triggered when webhook secret missing; attacker needs network reach to webhook service. No Kubernetes credentials needed.
Affected Features / Interoperability: Fleet GitRepo polling interval; could affect sync frequency, potentially causing drift or DoS. Could impact any application relying on timely GitRepo updates.
Source: one URL.
Actions: Fix: upgrade to Fleet 0.16.2 or later; configure webhook secret. Workaround: ensure webhook secret is set; restrict network access to webhook service (e.g., network policies, firewall). Tradeoff: adding secret management overhead; network restrictions may affect legitimate webhook sources.
We need to process each.
Description: Obot platform Docker quickstart runs container listening on 0.0.0.0:8080 with authentication disabled by default; maps requests to synthetic "nobody" user with Owner/Admin roles; unauthenticated party reaching exposed port gets full admin access to Obot API/UI, including ability to register/launch attacker-controlled MCP servers; quickstart also mounts /var/run/docker.sock giving MCP runtime access to host Docker control surface. Fix is documentation-only: quickstart now enables authentication; operators should set OBOT_SERVER_ENABLE_AUTHENTICATION=true before exposing host to untrusted network.
CVSS_score: 9.8, severity CRITICAL.
Summary: Unauthenticated remote code/admin access via exposed Obot API due to missing auth in Docker quickstart; also gives Docker socket access leading to host compromise. Triggered when using Obot quickstart as documented; attacker needs network reach to port 8080. No auth required.
Affected Features / Interoperability: Obot API/UI, Docker socket access; could lead to full host Docker control, allowing attacker to run containers, access host, etc. Impacts any workload relying on Docker host security.
Source: two URLs.
Actions: Fix: set OBOT_SERVER_ENABLE_AUTHENTICATION=true (or use updated quickstart). Workaround: block port 8080 from untrusted networks, disable exposing container, or remove docker.sock mount. Tradeoff: disabling docker.sock mount may break MCP runtime functionality; blocking port may affect legitimate users.
Description: Horilla HR/CRM software; prior to 2.0.0, HorillaListView.export_data accepts columns POST param, interpolates into dynamic_fn_str and passes to exec(), allowing arbitrary OS command injection via crafted string; fixed in 2.0.0.
CVSS_score: 8.8, severity HIGH.
Summary: Server-side template injection leading to RCE via columns parameter; exploitable by authenticated user (since endpoint requires auth). Triggered when authenticated user submits malicious columns payload. No network beyond app.
Affected Features / Interoperability: HorillaListView.export_data function; could lead to full compromise of application host, affecting any data processed by Horilla (HR/CRM data). Could impact integration with other systems.
Source: three URLs (two duplicate). We'll list unique.
Actions: Fix: upgrade to Horilla 2.0.0 or later. Workaround: restrict access to export_data endpoint, input validation, disable exec via disabling dangerous functionality (maybe not feasible). Tradeoff: limiting functionality may affect export features.
Description: AzuraCast before 0.23.8 SSRF and local file read via AutoDJ remote playlist fetch; user with station Media permission can create/update playlist with source=remote_url and remote_type=playlist pointing to file:// or internal/loopback/link-local HTTP endpoint; leads to file read and SSRF; no patched version at time of publication.
CVSS_score: 7.7, severity HIGH.
Summary: SSRF/LFI via playlist fetch; exploitable by authenticated user with station Media permission. Triggered when user supplies malicious URL. No auth beyond that permission.
Affected Features / Interoperability: AutoDJ remote playlist fetch; could lead to reading sensitive files (e.g., /etc/passwd, .env) and making internal HTTP requests, impacting any internal services reachable via loopback, potentially exposing secrets, internal APIs.
Source: two URLs.
Actions: Fix: upgrade to AzuraCast 0.23.8 or later when available; if not, restrict user permissions, disable remote playlist feature, or implement URL allowlist via custom patch. Workaround: disable remote playlist input, restrict to trusted URLs, enforce network segmentation to block loopback access. Tradeoff: losing remote playlist functionality; network restrictions may affect legitimate integrations.
Description: Frigate NVR; prior to 0.18.0, prefix-matched location /api/go2rtc/api in docker/nginx config requires authentication but not admin role for GET requests, exposing proxied go2rtc API to viewer users; authenticated viewer can request streams, config, logs, stack, RTSP URLs that may contain camera credentials. Fixed in 0.18.0.
CVSS_score: 7.7, severity HIGH.
Summary: Insufficient authorization on go2rtc API endpoint allows viewers to get sensitive info. Triggered when viewer user makes GET requests to that path. No extra auth beyond viewer role.
Affected Features / Interoperability: go2rtc API exposed via Frigate; could leak internal addresses, config, logs, RTSP URLs with credentials, impacting video surveillance system and any integrated systems (e.g., Vault, monitoring). Could lead to credential exposure.
Source: five URLs (some duplicate). We'll list unique.
Actions: Fix: upgrade Frigate to 0.18.0 or later. Workaround: restrict access to /api/go2rtc/api to admin only via nginx auth or remove location block; disable viewer access to that endpoint. Tradeoff: viewers lose ability to view streams/config/logs; may affect usability.
Description: flaw in kube-compare; when processing container:// reference path, tool incorrectly executes untrusted container image's entrypoint instead of extracting data from stopped container; allows remote attacker to achieve arbitrary code execution on operator's workstation; if Docker daemon requires elevated privileges, code may run with root-mediated daemon privileges.
CVSS_score: 7.1, severity HIGH.
Summary: kube-compare mis-handles container:// leading to host code exec. Triggered when user runs kube-compare on a malicious container image reference. Attacker needs ability to supply container image reference (e.g., via argument). No auth beyond ability to run tool.
Affected Features / Interoperability: kube-compare tool; could lead to host compromise, affecting any workload on that workstation, potentially Docker host if used to manage containers. Could impact CI pipelines.
Source: two URLs.
Actions: Fix: upgrade kube-compare to patched version (not specified; assume latest). Workaround: avoid using container:// references with untrusted images; verify images before processing; run tool in sandboxed environment. Tradeoff: losing convenience of direct container inspection; sandbox may add overhead.
Description: heym before 0.0.105 does not act on result of credential authorization lookup in Redis workflow node; when _get_accessible_credential returns None, node treats failure as empty config and falls back to defaults, connecting to localhost:6379 with no password; authenticated workflow author who supplies non-owned or deleted credential ID gets read/write connection to whatever Redis is listening on backend loopback instead of error. Impact depends on deployment; stock docker-compose ships no Redis, so flaw surfaces as misleading connection error rather than data exposure.
CVSS_score: 5.5, severity MEDIUM.
Summary: Auth bypass via Redis node leading to unintended Redis connection; exploitable by authenticated workflow author who can specify credential ID. Triggered when workflow node runs with invalid cred. No additional auth beyond workflow author role.
Affected Features / Interoperability: heym Redis workflow node; could lead to unintended Redis access, potentially exposing or modifying data stored in Redis (if present). In default docker-compose no Redis, so limited impact; but if Redis is present, could lead to data leak or corruption.
Source: three URLs (two duplicate). We'll list unique.
Actions: Fix: upgrade heym to 0.0.105 or later. Workaround: ensure credential IDs are valid, restrict ability to specify credential IDs, or disable Redis workflow node if not needed. Tradeoff: losing Redis integration functionality.
Description: UpTrain version 0.7.1 and prior, /create_project endpoint vulnerable to RCE via checks and metadata parameters; any user with access and valid auth method may execute arbitrary code in host running UpTrain (most cases docker container). No known patch.
CVSS_score: null, severity null.
Summary: RCE via malicious checks/metadata parameters; exploitable by authenticated user with access to endpoint. Triggered when calling endpoint with malicious payload. No additional auth beyond valid auth method.
Affected Features / Interoperability: UpTrain /create_project endpoint; could lead to host compromise, affecting any containers/services on same host, potentially Docker host if UpTrain runs in container with socket mount, etc.
Source: two URLs.
Actions: Fix: no known patch; consider restricting access to endpoint, disabling endpoint, or implementing input validation via WAF or API gateway. Workaround: disable /create_project endpoint if not needed, or restrict to trusted users via strict auth and network policies. Tradeoff: losing project creation functionality.
Similar for /add_prompts endpoint.
CVSS_score null.
Summary: same as above but for /add_prompts.
Affected Features / Interoperability: UpTrain /add_prompts endpoint.
Source: two URLs.
Actions: same as above.
Similar for /new_run endpoint.
CVSS_score null.
Summary: same.
Affected Features / Interoperability: UpTrain /new_run endpoint.
Source: two URLs.
Actions: same.
Now we need to produce the report.
We need to include executive summary paragraph highlighting single most urgent item. Since no KEV entries, we look for highest CVSS score. The highest CVSS is CVE-2026-101065 with score 9.8 CRITICAL (Docker/Obot). So executive summary should highlight that as most urgent item.
We need to mention that it's a critical unauthenticated admin access via Docker quickstart leading to host Docker socket exposure.
Now produce markdown.
Structure:
[executive summary paragraph]
Then for each system, we need subsections? The spec 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]
Thus we directly use that heading format, no extra system heading. So we will list all entries under ### Formal Vulnerabilities, each with that heading.
We need to preserve order: Within each system, entries already sorted (KEV first then CVSS descending). Since no KEV, just CVSS descending.
We need to output for each system in the order they appear in the data: Google Cloud Platform, Kubernetes, Docker.
Thus we will list GCP entry first, then Kubernetes entries (4), then Docker entries (9).
We must not add extra text besides the required sections.
After Formal Vulnerabilities, we need ### News & Community Mentions only if there's news/forum data below. There is news data for many systems, but the spec says: Only include this subsection if there's news/forum data below. A short bullet list per system: one line per item with a 1-sentence plain-English gist, the source name, and the label. Label this unverified chatter, separate from the Formal Vulnerabilities above.
We have news data for Docker, Microsoft Azure, AWS, Google Cloud Platform, Kubernetes. Since we are only reporting Cloud Security scope, we should include news for all systems that have news? The spec says "Only include this subsection if there's news/forum data below." It doesn't restrict to only systems we covered in Formal Vulnerabilities. So we should include News & Community Mentions subsection with bullet list per system (maybe only those with news). Provide one line per item: a 1-sentence plain-English gist, the source name, and the link.
We need to label this unverified chatter, separate from Formal Vulnerabilities.
Thus after Formal Vulnerabilities, we add:
Then bullet list per system. For each system, we can have a subheading? The spec says: "A short bullet list per system: one line per item with a 1-sentence plain-English gist, the source name, and the link." It doesn't explicitly require subheading per system, but says per system. We could format as:
Docker
But spec says "one line per item with a 1-sentence plain-English gist, the source name, and the link." It doesn't say to include system name in line, but we can include it as part of the line or as a preceding heading. To be safe, we can include system name as part of the line: e.g., "- Docker: ... (The Hacker News) https://...". However spec says "one line per item with a 1-sentence plain-English gist, the source name, and the link." It might expect format like "- Gist (Source) URL". We'll include system name in the gist maybe.
We'll produce bullet list grouped by system with a heading like Docker then indented bullets. But that adds extra lines not specified. However it's still a bullet list per system. I think it's acceptable.
We'll do:
Docker
Microsoft Azure
AWS
Google Cloud Platform
Kubernetes