CVE-2026-23991: 
Datadog Agent vulnerability analysis and mitigation

CVE-2026-23991 is a denial-of-service vulnerability in go-tuf, the Go implementation of The Update Framework (TUF). When a TUF repository, mirror, or cache returns syntactically valid JSON that does not conform to the TUF metadata schema, the go-tuf client panics during parsing, causing a crash. The vulnerability affects github.com/theupdateframework/go-tuf/v2 versions 2.0.0 through 2.3.0 (prior to 2.3.1). It was published on January 20, 2026, with the CVE assigned on January 22, 2026. The CVSS v3.1 base score is 5.9 (Moderate) per the GitHub Security Advisory, reflecting high attack complexity due to the requirement to control or intercept a TUF repository or mirror (Github Advisory, go-tuf Security Advisory).

The root cause is an improper type assertion in the metadata.checkType function (CWE-617: Reachable Assertion; CWE-754: Improper Check for Unusual or Exceptional Conditions). Specifically, the code performed unchecked type assertions on the signed field and its _type sub-field of untrusted JSON input — m["signed"].(map[string]any)["_type"].(string) — without verifying that the assertion succeeded. If the input JSON is structurally valid but lacks the expected fields or types, Go's runtime panics on the failed assertion, crashing the client process. The panic occurs before any cryptographic signature validation, meaning an attacker does not need access to any TUF signing keys to trigger it (go-tuf Security Advisory, Fix Commit).

Successful exploitation causes the go-tuf client to crash (panic), resulting in a denial of service. Long-running services that rely on go-tuf for software update verification — such as supply chain tooling, container image signers, or package managers — can be forced into a restart/crash loop, disrupting update operations. There is no impact on confidentiality or integrity; the vulnerability is purely an availability issue. Downstream projects embedding go-tuf (e.g., cosign, jfrog-cli, and other CNCF supply chain tools) are also affected (Github Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure (Github Advisory). The EPSS score is approximately 0.037% (11th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an attacker to control or perform a man-in-the-middle attack on a TUF repository, mirror, or cache that the victim client communicates with, which raises the effective attack complexity (go-tuf Security Advisory).

1. Identify a target: Locate a system running go-tuf v2 (versions 2.0.0–2.3.0) that fetches TUF metadata from a repository or mirror — for example, a CI/CD pipeline, container signing tool, or software updater.
2. Gain a position to serve malformed metadata: Compromise a TUF mirror or cache, set up a rogue mirror that the client is configured to use, or perform a man-in-the-middle attack on the client's network traffic to a TUF repository (e.g., via DNS spoofing or ARP poisoning on an unprotected network).
3. Craft malformed TUF metadata: Construct a JSON response that is syntactically valid JSON but does not conform to TUF metadata structure — for example, omitting the signed field, setting it to a non-object type, or omitting the _type field within signed. Example: {"signed": "not-an-object", "signatures": []}.
4. Serve the malformed response: Return the crafted JSON when the go-tuf client requests any TUF metadata file (e.g., root.json, snapshot.json, targets.json).
5. Trigger the panic: The client's metadata.checkType function performs an unchecked type assertion on the malformed input, causing a Go runtime panic and crashing the client process before any signature validation occurs, resulting in denial of service (go-tuf Security Advisory, Fix Commit).

• Logs: Go runtime panic stack traces in application logs referencing metadata/metadata.go in the checkType function or internal/testutils/signer/signer.go; repeated crash/restart entries for services using go-tuf.
• Process: Unexpected termination of processes that use go-tuf for update verification (e.g., cosign, jfrog-cli, or custom TUF clients); services entering rapid restart loops.
• Network: Unexpected or anomalous TUF metadata responses from configured repositories or mirrors containing structurally unusual JSON (e.g., signed field is not an object); connections to unfamiliar IP addresses serving TUF metadata.

The fix is available in go-tuf v2.3.1, which replaces the unsafe type assertions in metadata.checkType with checked assertions that return proper errors instead of panicking (go-tuf Release v2.3.1, Fix Commit). All users of github.com/theupdateframework/go-tuf/v2 versions 2.0.0–2.3.0 should upgrade to v2.3.1 or later immediately. No official workarounds exist; however, as an interim measure, restricting client access to only trusted TUF repositories via network controls and enforcing HTTPS with certificate pinning can reduce the risk of a compromised mirror delivering malformed metadata (go-tuf Security Advisory).

The vulnerability was reported by 1seal and remediated by kommendorkapten (Fredrik Skogman) and rdimitrov from the go-tuf maintainer team (go-tuf Security Advisory). Downstream Linux distributions including SUSE, openSUSE, and Fedora issued advisories for affected packages (cosign, govulncheck-vulndb, jfrog-cli) that bundle go-tuf. The vulnerability received routine coverage from security aggregators and scanner vendors (Tenable Nessus, Qualys) but did not generate significant public controversy or social media discussion, consistent with its moderate severity and lack of active exploitation.