(GHSA-273P-M2CW-6833)

Vulnerability from cleanstart – Published: 2026-07-30 07:10 – Updated: 2026-09-18 11:59 – Source website

Withdrawn 2026-09-18

Summary

Security fixes in spire-server-fips 1.14.1-r1

Details

Package spire-server-fips version 1.14.1-r1 fixes 6 vulnerabilities: ghsa-273p-m2cw-6833, ghsa-4c4x-jm2x-pf9j, ghsa-846p-jg2w-w324, ghsa-fcv2-xgw5-pqxf, ghsa-fphv-w9fq-2525...

References

URL

Type

https://github.com/spiffe/spire

WEB

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "CleanStart",
        "name": "spire-server-fips"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.14.1-r1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.14.1-r1"
      ]
    }
  ],
  "credits": [],
  "database_specific": {},
  "details": "Package spire-server-fips version 1.14.1-r1 fixes 6 vulnerabilities: ghsa-273p-m2cw-6833, ghsa-4c4x-jm2x-pf9j, ghsa-846p-jg2w-w324, ghsa-fcv2-xgw5-pqxf, ghsa-fphv-w9fq-2525...",
  "id": "CLEANSTART-2026-FA78759",
  "modified": "2026-09-18T11:59:01.768079Z",
  "published": "2026-07-30T07:10:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/spiffe/spire"
    }
  ],
  "related": [],
  "schema_version": "1.7.3",
  "summary": "Security fixes in spire-server-fips 1.14.1-r1",
  "upstream": [
    "ghsa-273p-m2cw-6833",
    "ghsa-4c4x-jm2x-pf9j",
    "ghsa-846p-jg2w-w324",
    "ghsa-fcv2-xgw5-pqxf",
    "ghsa-fphv-w9fq-2525",
    "ghsa-jqc5-w2xx-5vq4"
  ],
  "withdrawn": "2026-09-18T11:59:01.768079Z"
}

GHSA-273P-M2CW-6833

Vulnerability from github – Published: 2026-01-22 18:41 – Updated: 2026-01-23 15:46

Summary

Rekor's COSE v0.0.1 entry type nil pointer dereference in Canonicalize via empty Message

Details

Summary

Rekor’s cose v0.0.1 entry implementation can panic on attacker-controlled input when canonicalizing a proposed entry with an empty spec.message. validate() returns nil (success) when message is empty, leaving sign1Msg uninitialized, and Canonicalize() later dereferences v.sign1Msg.Payload.

Impact

A malformed proposed entry of the cose/v0.0.1 type can cause a panic on a thread within the Rekor process. The thread is recovered so the client receives a 500 error message and service still continues, so the availability impact of this is minimal.

Patches

Upgrade to v1.5.0

Workarounds

None

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.4.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/rekor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-23831"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-22T18:41:23Z",
    "nvd_published_at": "2026-01-22T22:16:19Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nRekor\u2019s cose v0.0.1 entry implementation can panic on attacker-controlled input when canonicalizing a proposed entry with an empty `spec.message`. `validate()` returns nil (success) when `message` is empty, leaving `sign1Msg` uninitialized, and `Canonicalize()` later dereferences `v.sign1Msg.Payload`.\n\n## Impact\n\nA malformed proposed entry of the `cose/v0.0.1` type can cause a panic on a thread within the Rekor process. The thread is recovered so the client receives a 500 error message and service still continues, so the availability impact of this is minimal.\n\n## Patches\n\nUpgrade to v1.5.0\n\n## Workarounds\n\nNone",
  "id": "GHSA-273p-m2cw-6833",
  "modified": "2026-01-23T15:46:17Z",
  "published": "2026-01-22T18:41:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/rekor/security/advisories/GHSA-273p-m2cw-6833"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23831"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/rekor/commit/39bae3d192bce48ef4ef2cbd1788fb5770fee8cd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/rekor"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/rekor/releases/tag/v1.5.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Rekor\u0027s COSE v0.0.1 entry type nil pointer dereference in Canonicalize via empty Message"
}

GHSA-4C4X-JM2X-PF9J

Vulnerability from github – Published: 2026-01-22 18:41 – Updated: 2026-01-23 15:49

Summary

Rekor affected by Server-Side Request Forgery (SSRF) via provided public key URL

Details

Summary

/api/v1/index/retrieve supports retrieving a public key via a user-provided URL, allowing attackers to trigger SSRF to arbitrary internal services.

Since the SSRF only can trigger GET requests, the request cannot mutate state. The response from the GET request is not returned to the caller so data exfiltration is not possible. A malicious actor could attempt to probe an internal network through Blind SSRF.

Impact

SSRF to cloud metadata (169.254.169.254)
SSRF to internal Kubernetes APIs
SSRF to any service accessible from Fulcio's network

Patches

Upgrade to v1.5.0. Note that this is a breaking change to the search API and fully disables lookups by URL. If you require this feature, please reach out and we can discuss alternatives.

Workarounds

Disable the search endpoint with --enable_retrieve_api=false.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.4.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/rekor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24117"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-22T18:41:26Z",
    "nvd_published_at": "2026-01-22T22:16:21Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`/api/v1/index/retrieve` supports retrieving a public key via a user-provided URL, allowing attackers to trigger SSRF to arbitrary internal services.\n\nSince the SSRF only can trigger GET requests, the request cannot mutate state. The response from the GET request is not returned to the caller so data exfiltration is not possible. A malicious actor could attempt to probe an internal network through [Blind SSRF](https://portswigger.net/web-security/ssrf/blind).\n\n## Impact\n\n* SSRF to cloud metadata (169.254.169.254)\n* SSRF to internal Kubernetes APIs\n* SSRF to any service accessible from Fulcio\u0027s network\n\n## Patches\n\nUpgrade to v1.5.0. Note that this is a breaking change to the search API and fully disables lookups by URL. If you require this feature, please reach out and we can discuss alternatives.\n\n## Workarounds\n\nDisable the search endpoint with `--enable_retrieve_api=false`.",
  "id": "GHSA-4c4x-jm2x-pf9j",
  "modified": "2026-01-23T15:49:13Z",
  "published": "2026-01-22T18:41:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/rekor/security/advisories/GHSA-4c4x-jm2x-pf9j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24117"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/rekor/commit/60ef2bceba192c5bf9327d003bceea8bf1f8275f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/rekor"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/rekor/releases/tag/v1.5.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Rekor affected by Server-Side Request Forgery (SSRF) via provided public key URL"
}

GHSA-846P-JG2W-W324

Vulnerability from github – Published: 2026-01-21 16:19 – Updated: 2026-01-22 15:43

Summary

go-tuf affected by client DoS via malformed server response

Details

Security Disclosure: Client DoS via malformed server response

Summary

If the TUF repository (or any of its mirrors) returns invalid TUF metadata JSON (valid JSON but not well formed TUF metadata), the client will panic during parsing, causing a DoS. The panic happens before any signature is validated. This means that a compromised repository/mirror/cache can DoS clients without having access to any signing key.

Impact

Client crashes upon receiving and parsing malformed TUF metadata. This can cause long running services to enter an restart/crash loop.

Workarounds

None currently.

Affected code

The metadata.checkType function did not properly type assert the (untrusted) input causing it to panic on malformed data.

Severity

5.9 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/theupdateframework/go-tuf/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-23991"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617",
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-21T16:19:28Z",
    "nvd_published_at": "2026-01-22T03:15:47Z",
    "severity": "MODERATE"
  },
  "details": "# Security Disclosure: Client DoS via malformed server response\n\n## Summary\n\nIf the TUF repository (or any of its mirrors) returns invalid TUF metadata JSON (valid JSON but not well formed TUF metadata), the client will panic _during parsing_, causing a DoS. The panic happens before any signature is validated. This means that a compromised repository/mirror/cache can DoS clients without having access to any signing key.\n\n## Impact \n\nClient crashes upon receiving and parsing malformed TUF metadata. This can cause long running services to enter an restart/crash loop.\n\n## Workarounds\n\nNone currently. \n\n## Affected code\n\nThe `metadata.checkType` function did not properly type assert the (untrusted) input causing it to panic on malformed data.",
  "id": "GHSA-846p-jg2w-w324",
  "modified": "2026-01-22T15:43:38Z",
  "published": "2026-01-21T16:19:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/go-tuf/security/advisories/GHSA-846p-jg2w-w324"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23991"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/go-tuf/commit/73345ab6b0eb7e59d525dac17a428f043074cef6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/theupdateframework/go-tuf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/go-tuf/releases/tag/v2.3.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "go-tuf affected by client DoS via malformed server response"
}

GHSA-FCV2-XGW5-PQXF

Vulnerability from github – Published: 2026-01-22 20:28 – Updated: 2026-02-27 21:37

Summary

sigstore legacy TUF client allows for arbitrary file writes with target cache path traversal

Details

Summary

The legacy TUF client pkg/tuf/client.go, which supports caching target files to disk, constructs a filesystem path by joining a cache base directory with a target name sourced from signed target metadata, but it does not validate that the resulting path stays within the cache base directory.

Note that this should only affect clients that are directly using the TUF client in sigstore/sigstore or are using an older version of Cosign. As this TUF client implementation is deprecated, users should migrate to https://github.com/sigstore/sigstore-go/tree/main/pkg/tuf as soon as possible.

Note that this does not affect users of the public Sigstore deployment, where TUF metadata is validated by a quorum of trusted collaborators.

Impact

A malicious TUF repository can trigger arbitrary file overwriting, limited to the permissions that the calling process has.

Workarounds

Users can disable disk caching for the legacy client by setting SIGSTORE_NO_CACHE=true in the environment, migrate to https://github.com/sigstore/sigstore-go/tree/main/pkg/tuf, or upgrade to the latest sigstore/sigstore release.

Severity

5.8 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.10.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/sigstore"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.10.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24137"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-22T20:28:56Z",
    "nvd_published_at": "2026-01-23T00:15:52Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe legacy TUF client `pkg/tuf/client.go`, which supports caching target files to disk, constructs a filesystem path by joining a cache base directory with a target name sourced from signed target metadata, but it does not validate that the resulting path stays within the cache base directory.\n\nNote that this should only affect clients that are directly using the TUF client in sigstore/sigstore or are using an older version of Cosign. As this TUF client implementation is deprecated, users should migrate to https://github.com/sigstore/sigstore-go/tree/main/pkg/tuf as soon as possible.\n\nNote that this does not affect users of the public Sigstore deployment, where TUF metadata is validated by a quorum of trusted collaborators. \n\n## Impact\n\nA malicious TUF repository can trigger arbitrary file overwriting, limited to the permissions that the calling process has.\n\n## Workarounds\n\nUsers can disable disk caching for the legacy client by setting `SIGSTORE_NO_CACHE=true` in the environment, migrate to https://github.com/sigstore/sigstore-go/tree/main/pkg/tuf, or upgrade to the latest sigstore/sigstore release.",
  "id": "GHSA-fcv2-xgw5-pqxf",
  "modified": "2026-02-27T21:37:24Z",
  "published": "2026-01-22T20:28:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore/security/advisories/GHSA-fcv2-xgw5-pqxf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24137"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore/commit/8ec410a2993ea78083aecf0e473a85453039496e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/sigstore"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore/releases/tag/v1.10.4"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2026-4358"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "sigstore legacy TUF client allows for arbitrary file writes with target cache path traversal"
}

GHSA-FPHV-W9FQ-2525

Vulnerability from github – Published: 2026-01-21 16:19 – Updated: 2026-01-22 15:43

Summary

go-tuf improperly validates the configured threshold for delegations

Details

Security Disclosure: Improper validation of configured threshold for delegations

Summary

A compromised or misconfigured TUF repository can have the configured value of signature thresholds set to 0, which effectively disables signature verification.

Impact

Unathorized modification to TUF metadata files is possible at rest, or during transit as no integrity checks are made.

Patches

Upgrade to v2.3.1

Workarounds

Always make sure that the TUF metadata roles are configured with a threshold of at least 1.

Affected code:

The metadata.VerifyDelegate did not verify the configured threshold prior to comparison. This means that a misconfigured TUF repository could disable the signature verification by setting the threshold to 0, or a negative value (and so always make the signature threshold computation to pass).

Severity

5.9 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/theupdateframework/go-tuf/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-23992"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-21T16:19:32Z",
    "nvd_published_at": "2026-01-22T03:15:47Z",
    "severity": "MODERATE"
  },
  "details": "# Security Disclosure: Improper validation of configured threshold for delegations\n\n## Summary\n\nA compromised or misconfigured TUF repository can have the configured value of signature thresholds set to 0, which effectively disables signature verification. \n\n## Impact\n\nUnathorized modification to TUF metadata files is possible at rest, or during transit as no integrity checks are made.\n\n## Patches\n\nUpgrade to v2.3.1\n\n## Workarounds\n\nAlways make sure that the TUF metadata roles are configured with a threshold of at least 1.\n\n## Affected code:\n\nThe `metadata.VerifyDelegate` did not verify the configured threshold prior to comparison. This means that a misconfigured TUF repository could disable the signature verification by setting the threshold to 0, or a negative value (and so always make the signature threshold computation to pass).",
  "id": "GHSA-fphv-w9fq-2525",
  "modified": "2026-01-22T15:43:46Z",
  "published": "2026-01-21T16:19:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/go-tuf/security/advisories/GHSA-fphv-w9fq-2525"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23992"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/go-tuf/commit/b38d91fdbc69dfe31fe9230d97dafe527ea854a0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/theupdateframework/go-tuf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/go-tuf/releases/tag/v2.3.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "go-tuf improperly validates the configured threshold for delegations"
}

GHSA-JQC5-W2XX-5VQ4

Vulnerability from github – Published: 2026-01-26 23:49 – Updated: 2026-01-29 03:26

Summary

go-tuf Path Traversal in TAP 4 Multirepo Client Allows Arbitrary File Write via Malicious Repository Names

Details

Security Vulnerability: Path Traversal in TAP 4 Multirepo Client

Summary

go-tuf's TAP 4 Multirepo Client uses the map file repository name string (repoName) as a filesystem path component when selecting the local metadata cache directory. If an application accepts a map file from an untrusted source, an attacker can supply a repoName containing traversal (e.g., ../escaped-repo) and cause go-tuf to create directories and write the root metadata file outside the intended LocalMetadataDir cache base, within the running process's filesystem permissions.

Affected Component

Field	Value
File	`metadata/multirepo/multirepo.go`
Function	`(*MultiRepoClient) initTUFClients() error`
Callsite	`metadataDir := filepath.Join(client.Config.LocalMetadataDir, repoName)` (around line 129 at the pinned commit)

Impact

When the TAP 4 map file content is attacker-controlled, this enables arbitrary file write relative to the process permissions (via metadata persistence during client initialization). This can be used to overwrite files writable by the process (for example, configuration files in writable directories) and may enable further compromise depending on the deployment environment.

Note: Exploitability is deployment-dependent. If the map file is always local and trusted (not attacker-controlled), this reduces to a misconfiguration risk rather than a remotely triggerable issue.

Attacker Model

Attacker can cause the application to load a TAP 4 map file whose repositories keys are attacker-controlled (for example: fetched from a URL, supply-chain substituted, or otherwise attacker-influenced input).
Local caching is enabled (DisableLocalCache=false) and the configured LocalMetadataDir is writable by the running process.

Claim Ceiling: HIGH when the map file is attacker-controlled; if the map file is always local and trusted, this is closer to a configuration footgun and likely lands as MEDIUM/LOW.

Field	Value
Affected Versions	≤ 2.4.0
Verified On	Commit `bde5f18dc95dfac365fc452ee4e278e5fd66d4b4` (tag v2.4.0)

Note: First affected version has not been bisected.

Reproduction

Attachments include poc.zip with: - canonical.log (contains [CALLSITE_HIT], [PROOF_MARKER]) - control.log (contains [CALLSITE_HIT], [NC_MARKER], does not contain [PROOF_MARKER]) - fix.patch (minimal validation sketch)

Expected: Multirepo repository names are treated as identifiers; a TAP 4 map file containing traversal or absolute paths is rejected (or safely normalized so that all writes stay under LocalMetadataDir).

Actual: A traversal repoName escapes LocalMetadataDir and go-tuf persists root.json under the escaped path during initialization.

Run Local Repro

rm -rf _poc
mkdir -p _poc
unzip -q -o poc.zip -d _poc
cd _poc/poc
make canonical
make control

Workarounds

Treat TAP 4 map files as trusted configuration only (do not fetch from untrusted sources).
Validate repo names before passing the map file to go-tuf (reject absolute paths, path separators, and traversal components like . / ..).
If acceptable for the application, disable local caching to avoid writing metadata to disk (DisableLocalCache=true).

Suggested Remediation

Validate multirepo repository names as identifiers (not paths) before using them in filepath.Join. Reject: - Absolute paths - Path separators (/ and \) - Traversal components (. and ..)

If it is important to accept a wider set of repo names, a safer alternative is to map repo names to a stable, validated directory name (for example via encoding or hashing) and to ensure all writes stay under the cache base directory.

Triage Questions

Is the TAP 4 map file expected to ever be fetched from untrusted sources in supported deployments?
Should invalid repo names be treated as a hard error (reject initialization), or as a soft error (skip that repository entry)?

Attachments

Reported by: Oleh

Severity

4.7 (Medium)


                  
                    CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/theupdateframework/go-tuf/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24686"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-26T23:49:55Z",
    "nvd_published_at": "2026-01-27T01:16:02Z",
    "severity": "MODERATE"
  },
  "details": "# Security Vulnerability: Path Traversal in TAP 4 Multirepo Client\n\n## Summary\n\ngo-tuf\u0027s TAP 4 Multirepo Client uses the map file repository name string (`repoName`) as a filesystem path component when selecting the local metadata cache directory. If an application accepts a map file from an untrusted source, an attacker can supply a `repoName` containing traversal (e.g., `../escaped-repo`) and cause go-tuf to create directories and write the root metadata file outside the intended `LocalMetadataDir` cache base, within the running process\u0027s filesystem permissions.\n\n## Affected Component\n\n| Field | Value |\n|-------|-------|\n| **File** | `metadata/multirepo/multirepo.go` |\n| **Function** | `(*MultiRepoClient) initTUFClients() error` |\n| **Callsite** | `metadataDir := filepath.Join(client.Config.LocalMetadataDir, repoName)` (around line 129 at the pinned commit) |\n\n## Impact\n\nWhen the TAP 4 map file content is attacker-controlled, this enables arbitrary file write relative to the process permissions (via metadata persistence during client initialization). This can be used to overwrite files writable by the process (for example, configuration files in writable directories) and may enable further compromise depending on the deployment environment.\n\n\u003e **Note:** Exploitability is deployment-dependent. If the map file is always local and trusted (not attacker-controlled), this reduces to a misconfiguration risk rather than a remotely triggerable issue.\n\n## Attacker Model\n\n- Attacker can cause the application to load a TAP 4 map file whose `repositories` keys are attacker-controlled (for example: fetched from a URL, supply-chain substituted, or otherwise attacker-influenced input).\n- Local caching is enabled (`DisableLocalCache=false`) and the configured `LocalMetadataDir` is writable by the running process.\n\n**Claim Ceiling:** HIGH when the map file is attacker-controlled; if the map file is always local and trusted, this is closer to a configuration footgun and likely lands as MEDIUM/LOW.\n\n| Field | Value |\n|-------|-------|\n| **Affected Versions** | \u2264 2.4.0 |\n| **Verified On** | Commit `bde5f18dc95dfac365fc452ee4e278e5fd66d4b4` (tag v2.4.0) |\n\n\u003e **Note:** First affected version has not been bisected.\n\n## Reproduction\n\nAttachments include `poc.zip` with:\n- `canonical.log` (contains `[CALLSITE_HIT]`, `[PROOF_MARKER]`)\n- `control.log` (contains `[CALLSITE_HIT]`, `[NC_MARKER]`, does not contain `[PROOF_MARKER]`)\n- `fix.patch` (minimal validation sketch)\n\n**Expected:** Multirepo repository names are treated as identifiers; a TAP 4 map file containing traversal or absolute paths is rejected (or safely normalized so that all writes stay under `LocalMetadataDir`).\n\n**Actual:** A traversal `repoName` escapes `LocalMetadataDir` and go-tuf persists `root.json` under the escaped path during initialization.\n\n### Run Local Repro\n\n```bash\nrm -rf _poc\nmkdir -p _poc\nunzip -q -o poc.zip -d _poc\ncd _poc/poc\nmake canonical\nmake control\n```\n\n## Workarounds\n\n1. Treat TAP 4 map files as trusted configuration only (do not fetch from untrusted sources).\n2. Validate repo names before passing the map file to go-tuf (reject absolute paths, path separators, and traversal components like `.` / `..`).\n3. If acceptable for the application, disable local caching to avoid writing metadata to disk (`DisableLocalCache=true`).\n\n## Suggested Remediation\n\nValidate multirepo repository names as identifiers (not paths) before using them in `filepath.Join`. Reject:\n- Absolute paths\n- Path separators (`/` and `\\`)\n- Traversal components (`.` and `..`)\n\nIf it is important to accept a wider set of repo names, a safer alternative is to map repo names to a stable, validated directory name (for example via encoding or hashing) and to ensure all writes stay under the cache base directory.\n\n## Triage Questions\n\n1. Is the TAP 4 map file expected to ever be fetched from untrusted sources in supported deployments?\n2. Should invalid repo names be treated as a hard error (reject initialization), or as a soft error (skip that repository entry)?\n\n## Attachments\n\n- [poc.zip](https://github.com/user-attachments/files/24849854/poc.zip)\n- [addendum.md](https://github.com/user-attachments/files/24849855/addendum.md)\n- [e2e.zip](https://github.com/user-attachments/files/24849856/e2e.zip)\n- [PR_DESCRIPTION.md](https://github.com/user-attachments/files/24849858/PR_DESCRIPTION.md)\n\n---\n\n*Reported by: Oleh*",
  "id": "GHSA-jqc5-w2xx-5vq4",
  "modified": "2026-01-29T03:26:24Z",
  "published": "2026-01-26T23:49:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/go-tuf/security/advisories/GHSA-jqc5-w2xx-5vq4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24686"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/go-tuf/commit/d361e2ea24e427581343dee5c7a32b485d79fcc0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/theupdateframework/go-tuf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "go-tuf Path Traversal in TAP 4 Multirepo Client Allows Arbitrary File Write via Malicious Repository Names"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

(GHSA-273P-M2CW-6833)

GHSA-273P-M2CW-6833

Summary

Impact

Patches

Workarounds

GHSA-4C4X-JM2X-PF9J

Summary

Impact

Patches

Workarounds

GHSA-846P-JG2W-W324

Security Disclosure: Client DoS via malformed server response

Summary

Impact

Workarounds

Affected code

GHSA-FCV2-XGW5-PQXF

Summary

Impact

Workarounds

GHSA-FPHV-W9FQ-2525

Security Disclosure: Improper validation of configured threshold for delegations

Summary

Impact

Patches

Workarounds

Affected code:

GHSA-JQC5-W2XX-5VQ4

Security Vulnerability: Path Traversal in TAP 4 Multirepo Client

Summary

Affected Component

Impact

Attacker Model

Reproduction

Run Local Repro

Workarounds

Suggested Remediation

Triage Questions

Attachments

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour