JEDI-SEC | Security Research & Digital Defense

Tag: go

  • GHSA-9ppr-wfw9-xvr2: Netfoil doesn’t decrement TTL

    • Severity: MEDIUM
    • Ecosystems: go
    • Packages: github.com/tinfoil-factory/netfoil

    ### Summary
    TTL was not decremented, so stale records would continue to be served.

    Source: GitHub Security Advisories · 2026-11-03

  • GHSA-m3qr-fvp4-78xj: Arc has unauthenticated application log disclosure via `/api/v1/logs`

    • Severity: LOW
    • Ecosystems: go
    • Packages: github.com/basekick-labs/arc

    ## Summary

    Arc exposes `GET /api/v1/logs` without authentication even when authentication is enabled by default. The route is registered before the global Fiber authentication middleware, and the handler returns recent buffered application logs without performing its own authorization check.

    ## Details

    Arc applies the global auth middleware after calling `server.RegisterRoutes()`:

    – `cmd/arc/main.go:1598-1599` registers base routes via `server.RegisterRoutes()`.
    – `cmd/arc/main.go:1601-1618` configures and installs `auth.NewMiddleware(…)` later.

    `server.RegisterRoutes()` registers `GET /api/v1/logs` as a base route:

    – `internal/api/server.go:164-183` registers base health, metrics, and logs routes, including `s.app.Get(“/api/v1/logs”, s.logsHandler)`.

    The logs handler returns buffered logs without checking authentication or authorization:

    – `internal/api/server.go:537-567` parses `limit`, `level`, and `since_minutes`, reads `logger.GetBuffer().GetRecent(…)`, and returns JSON.
    – `internal/logger/buffer.go:9-16` defines log entries returned to callers: timestamp, level, component, message, and caller.
    – `internal/logger/buffer.go:33-39` creates a global log buffer holding the last 10,000 entries.
    – `internal/api/server.go:540-558` permits up to `limit=1000` and `since_minutes=1440` in one unauthenticated request.

    Authentication is enabled by default and `/api/v1/logs` is not listed as a public route:

    – `internal/config/config.go:841-843` defaults auth to enabled.…

    Source: GitHub Security Advisories · 2026-11-03

  • GHSA-8fmv-6rg5-5924: Kubeflow Pipelines: Pipeline archive upload allows decompression bomb to exhaust server memory

    • Severity: HIGH
    • CVE: CVE-2026-118761
    • Ecosystems: go, go
    • Packages: github.com/kubeflow/pipelines, github.com/kubeflow/pipelines

    ## Summary

    The Kubeflow Pipelines API server decompresses uploaded pipeline archives without adequately bounding expanded data in affected versions. A small ZIP or gzip-compressed tar archive can consume disproportionately large amounts of memory while the server locates or reads the pipeline file, potentially exhausting API-server resources and interrupting service.

    Multipart pipeline and pipeline-version upload processing decompresses the archive before namespace authorization, so a caller who can reach those endpoints does not need a successful pipeline-create authorization decision to trigger the issue. External authentication and network controls can restrict reachability. URL-import handlers authorize before fetching and decompressing a remote archive.

    The amount of expansion needed to exhaust memory depends on deployment resource limits and concurrent activity; no particular archive is guaranteed to crash every deployment.

    ## Remediation

    Upgrade the API server to **[Kubeflow Pipelines 2.18.0](https://github.com/kubeflow/pipelines/releases/tag/2.18.0)**. Versions through 2.17.3 are affected; the first affected release has not been established.

    [PR #14171](https://github.com/kubeflow/pipelines/pull/14171) bounds compressed input and extracted pipeline data. [PR #14186](https://github.com/kubeflow/pipelines/pull/14186) strengthens the total tar traversal budget, including metadata and skipped entries. The 2.18 release also includes configurable upload and specificat…

    Source: GitHub Security Advisories · 2026-10-30

  • GHSA-wg5q-x4j9-qm54: Kubeflow Pipelines: Run-log endpoint permits unauthorized access to pod logs

    • Severity: HIGH
    • CVE: CVE-2026-118759
    • Ecosystems: go, go
    • Packages: github.com/kubeflow/pipelines, github.com/kubeflow/pipelines

    ## Summary

    The Kubeflow Pipelines API server’s `GET /apis/v1alpha1/runs/{run_id}/nodes/{node_id}/log` handler retrieves logs without authorizing the caller against the selected run. A caller who can reach the backend and knows a victim run ID and a suitable pod or node identifier can read live or archived logs using the API server’s permissions.

    For live logs, the vulnerable handler also accepts the supplied node ID as a pod name in the run’s namespace without verifying that the pod belongs to the run. Depending on the API server’s pod-log permissions, a known run ID can therefore permit reading the `main` container logs of an unrelated pod in that namespace. Logs may contain sensitive workload data or credentials.

    The affected handler does not authenticate the request itself. An external authentication gate or network policy can restrict reachability; public ingress exposure and unauthenticated enumeration of run IDs are not assumed.

    ## Remediation

    Upgrade the API server to **[Kubeflow Pipelines 2.18.0](https://github.com/kubeflow/pipelines/releases/tag/2.18.0)**. Versions through 2.17.3 are affected; the first affected release has not been established.

    [PR #13684](https://github.com/kubeflow/pipelines/pull/13684) authorizes the caller with the `readLog` verb before retrieving live or archived logs. For live logs, it also verifies that the pod’s `pipeline/runid` label matches the requested run. Custom Kubernetes roles must grant `readLog` on `runs` in the `pipelines.ku…

    Source: GitHub Security Advisories · 2026-10-30