Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Package tekton-chains-fips version 0.26.0-r1 fixes 9 vulnerabilities: ghsa-4qg8-fj49-pxjh, ghsa-whqx-f9j3-ch6m, ghsa-846p-jg2w-w324, ghsa-fphv-w9fq-2525, ghsa-59jp-pj84-45mr...
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "tekton-chains-fips"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.26.0-r1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.26.0-r1"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package tekton-chains-fips version 0.26.0-r1 fixes 9 vulnerabilities: ghsa-4qg8-fj49-pxjh, ghsa-whqx-f9j3-ch6m, ghsa-846p-jg2w-w324, ghsa-fphv-w9fq-2525, ghsa-59jp-pj84-45mr...",
"id": "CLEANSTART-2026-NP82781",
"modified": "2026-07-30T09:29:45Z",
"published": "2026-07-30T07:10:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tektoncd/chains"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in tekton-chains-fips 0.26.0-r1",
"upstream": [
"ghsa-4qg8-fj49-pxjh",
"ghsa-whqx-f9j3-ch6m",
"ghsa-846p-jg2w-w324",
"ghsa-fphv-w9fq-2525",
"ghsa-59jp-pj84-45mr",
"ghsa-f83f-xpx7-ffpw",
"ghsa-273p-m2cw-6833",
"ghsa-4c4x-jm2x-pf9j",
"ghsa-fcv2-xgw5-pqxf"
]
}
GHSA-273P-M2CW-6833
Vulnerability from github – Published: 2026-01-22 18:41 – Updated: 2026-01-23 15:46Summary
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
{
"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:49Summary
/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.
{
"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-4QG8-FJ49-PXJH
Vulnerability from github – Published: 2025-12-05 18:19 – Updated: 2025-12-05 18:19Impact
Excessive memory allocation
Function api.ParseJSONRequest currently splits (via a call to strings.Split) an optionally-provided OID (which is untrusted data) on periods. Similarly, function api.getContentType splits the Content-Type header (which is also untrusted data) on an application string.
As a result, in the face of a malicious request with either an excessively long OID in the payload containing many period characters or a malformed Content-Type header, a call to api.ParseJSONRequest or api.getContentType incurs allocations of O(n) bytes (where n stands for the length of the function's argument). Relevant weakness: CWE-405: Asymmetric Resource Consumption (Amplification)
Patches
Upgrade to v2.0.3.
Workarounds
There are no workarounds with the service itself. If the service is behind a load balancer, configure the load balancer to reject excessively large requests.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.0.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/sigstore/timestamp-authority"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-66564"
],
"database_specific": {
"cwe_ids": [
"CWE-405"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-05T18:19:00Z",
"nvd_published_at": "2025-12-04T23:15:47Z",
"severity": "HIGH"
},
"details": "### Impact\n\n**Excessive memory allocation**\n\nFunction [api.ParseJSONRequest](https://github.com/sigstore/timestamp-authority/blob/26d7d426d3000abdbdf2df34de56bb92246c0365/pkg/api/timestamp.go#L63) currently splits (via a call to [strings.Split](https://pkg.go.dev/strings#Split)) an optionally-provided OID (which is untrusted data) on periods. Similarly, function [api.getContentType](https://github.com/sigstore/timestamp-authority/blob/26d7d426d3000abdbdf2df34de56bb92246c0365/pkg/api/timestamp.go#L114) splits the `Content-Type` header (which is also untrusted data) on an `application` string.\n\nAs a result, in the face of a malicious request with either an excessively long OID in the payload containing many period characters or a malformed `Content-Type` header, a call to `api.ParseJSONRequest` or `api.getContentType` incurs allocations of O(n) bytes (where n stands for the length of the function\u0027s argument). Relevant weakness: [CWE-405: Asymmetric Resource Consumption (Amplification)](https://cwe.mitre.org/data/definitions/405.html)\n\n### Patches\n\nUpgrade to v2.0.3.\n\n### Workarounds\n\nThere are no workarounds with the service itself. If the service is behind a load balancer, configure the load balancer to reject excessively large requests.",
"id": "GHSA-4qg8-fj49-pxjh",
"modified": "2025-12-05T18:19:00Z",
"published": "2025-12-05T18:19:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sigstore/timestamp-authority/security/advisories/GHSA-4qg8-fj49-pxjh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66564"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/timestamp-authority/commit/0cae34e197d685a14904e0bad135b89d13b69421"
},
{
"type": "PACKAGE",
"url": "https://github.com/sigstore/timestamp-authority"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "Sigstore Timestamp Authority allocates excessive memory during request parsing"
}
GHSA-59JP-PJ84-45MR
Vulnerability from github – Published: 2026-01-13 18:47 – Updated: 2026-01-13 18:47Security Disclosure: SSRF via MetaIssuer Regex Bypass
Summary
Fulcio's metaRegex() function uses unanchored regex, allowing attackers to bypass MetaIssuer URL validation and 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
- Affects ALL deployments using MetaIssuers
Patches
Upgrade to v1.8.5.
Workarounds
None. If anchors are included in the meta issuer configuration URL, they will be escaped before the regular expression is compiled, not making this a sufficient mitigation. Deployments must upgrade to the latest Fulcio release v1.8.5.
Affected Code
File: pkg/config/config.go
Function: metaRegex() (lines 143-156)
func metaRegex(issuer string) (*regexp.Regexp, error) {
quoted := regexp.QuoteMeta(issuer)
replaced := strings.ReplaceAll(quoted, regexp.QuoteMeta("*"), "[-_a-zA-Z0-9]+")
return regexp.Compile(replaced) // Missing ^ and $ anchors
}
The Bug
The regex has no ^ (start) or $ (end) anchors. Go's regexp.MatchString() does substring matching, so:
Pattern: https://oidc.eks.*.amazonaws.com/id/*
Regex: https://oidc\.eks\.[-_a-zA-Z0-9]+\.amazonaws\.com/id/[-_a-zA-Z0-9]+
Input: https://attacker.com/x/https://oidc.eks.foo.amazonaws.com/id/bar
Result: MATCHES (substring found)
Exploit
- Attacker sends JWT with
issclaim:https://attacker.com/path/https://oidc.eks.x.amazonaws.com/id/y - Fulcio's
GetIssuer()matches this against MetaIssuer patterns - Unanchored regex matches the embedded pattern as substring
- Fulcio calls
oidc.NewProvider()with attacker's URL - HTTP request goes to
attacker.com, notamazonaws.com - Attacker returns OIDC discovery with
jwks_uripointing to internal service - Fulcio fetches from internal service → SSRF
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.8.4"
},
"package": {
"ecosystem": "Go",
"name": "github.com/sigstore/fulcio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.8.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22772"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-13T18:47:57Z",
"nvd_published_at": "2026-01-12T21:15:59Z",
"severity": "MODERATE"
},
"details": "# Security Disclosure: SSRF via MetaIssuer Regex Bypass\n\n## Summary\n\nFulcio\u0027s `metaRegex()` function uses unanchored regex, allowing attackers to bypass MetaIssuer URL validation and 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- Affects ALL deployments using MetaIssuers\n\n## Patches\n\nUpgrade to v1.8.5.\n\n## Workarounds\n\nNone. If anchors are included in the meta issuer configuration URL, they will be escaped before the regular expression is compiled, not making this a sufficient mitigation. Deployments must upgrade to the latest Fulcio release v1.8.5.\n\n## Affected Code\n\n**File**: `pkg/config/config.go` \n**Function**: `metaRegex()` (lines 143-156)\n\n```go\nfunc metaRegex(issuer string) (*regexp.Regexp, error) {\n quoted := regexp.QuoteMeta(issuer)\n replaced := strings.ReplaceAll(quoted, regexp.QuoteMeta(\"*\"), \"[-_a-zA-Z0-9]+\")\n return regexp.Compile(replaced) // Missing ^ and $ anchors\n}\n```\n\n## The Bug\n\nThe regex has no `^` (start) or `$` (end) anchors. Go\u0027s `regexp.MatchString()` does substring matching, so:\n\n```\nPattern: https://oidc.eks.*.amazonaws.com/id/*\nRegex: https://oidc\\.eks\\.[-_a-zA-Z0-9]+\\.amazonaws\\.com/id/[-_a-zA-Z0-9]+\n\nInput: https://attacker.com/x/https://oidc.eks.foo.amazonaws.com/id/bar\nResult: MATCHES (substring found)\n```\n\n## Exploit\n\n1. Attacker sends JWT with `iss` claim: `https://attacker.com/path/https://oidc.eks.x.amazonaws.com/id/y`\n2. Fulcio\u0027s `GetIssuer()` matches this against MetaIssuer patterns\n3. Unanchored regex matches the embedded pattern as substring\n4. Fulcio calls `oidc.NewProvider()` with attacker\u0027s URL\n5. HTTP request goes to `attacker.com`, not `amazonaws.com`\n6. Attacker returns OIDC discovery with `jwks_uri` pointing to internal service\n7. Fulcio fetches from internal service \u2192 SSRF",
"id": "GHSA-59jp-pj84-45mr",
"modified": "2026-01-13T18:47:57Z",
"published": "2026-01-13T18:47:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sigstore/fulcio/security/advisories/GHSA-59jp-pj84-45mr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22772"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/fulcio/commit/eaae2f2be56df9dea5f9b439ec81bedae4c0978d"
},
{
"type": "PACKAGE",
"url": "https://github.com/sigstore/fulcio"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Fulcio is vulnerable to Server-Side Request Forgery (SSRF) via MetaIssuer Regex Bypass"
}
GHSA-846P-JG2W-W324
Vulnerability from github – Published: 2026-01-21 16:19 – Updated: 2026-01-22 15:43Security 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.
{
"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-F83F-XPX7-FFPW
Vulnerability from github – Published: 2025-12-05 18:18 – Updated: 2025-12-05 18:18Function identity.extractIssuerURL currently splits (via a call to strings.Split) its argument (which is untrusted data) on periods.
As a result, in the face of a malicious request with an (invalid) OIDC identity token in the payload containing many period characters, a call to extractIssuerURL incurs allocations to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant factor of about 16. Relevant weakness: CWE-405: Asymmetric Resource Consumption (Amplification)
Details See identity.extractIssuerURL
Impact Excessive memory allocation
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.8.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/sigstore/fulcio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.8.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-66506"
],
"database_specific": {
"cwe_ids": [
"CWE-405"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-05T18:18:26Z",
"nvd_published_at": "2025-12-04T22:15:49Z",
"severity": "HIGH"
},
"details": "Function [identity.extractIssuerURL](https://github.com/sigstore/fulcio/blob/main/pkg/identity/issuerpool.go#L44-L45) currently splits (via a call to [strings.Split](https://pkg.go.dev/strings#Split)) its argument (which is untrusted data) on periods.\n\nAs a result, in the face of a malicious request with an (invalid) OIDC identity token in the payload containing many period characters, a call to `extractIssuerURL` incurs allocations to the tune of O(n) bytes (where n stands for the length of the function\u0027s argument), with a constant factor of about 16. Relevant weakness: [CWE-405: Asymmetric Resource Consumption (Amplification)](https://cwe.mitre.org/data/definitions/405.html)\n\nDetails\nSee [identity.extractIssuerURL](https://github.com/sigstore/fulcio/blob/main/pkg/identity/issuerpool.go#L44-L45)\n\nImpact\nExcessive memory allocation",
"id": "GHSA-f83f-xpx7-ffpw",
"modified": "2025-12-05T18:18:26Z",
"published": "2025-12-05T18:18:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sigstore/fulcio/security/advisories/GHSA-f83f-xpx7-ffpw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66506"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/fulcio/commit/765a0e57608b9ef390e1eeeea8595b9054c63a5a"
},
{
"type": "PACKAGE",
"url": "https://github.com/sigstore/fulcio"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "Fulcio allocates excessive memory during token parsing"
}
GHSA-FCV2-XGW5-PQXF
Vulnerability from github – Published: 2026-01-22 20:28 – Updated: 2026-02-27 21:37Summary
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.
{
"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:43Security 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).
{
"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-WHQX-F9J3-CH6M
Vulnerability from github – Published: 2026-01-13 14:58 – Updated: 2026-01-13 14:58Impact
A Cosign bundle can be crafted to successfully verify an artifact even if the embedded Rekor entry does not reference the artifact's digest, signature or public key. When verifying a Rekor entry, Cosign verifies the Rekor entry signature, and also compares the artifact's digest, the user's public key from either a Fulcio certificate or provided by the user, and the artifact signature to the Rekor entry contents. Without these comparisons, Cosign would accept any response from Rekor as valid. A malicious actor that has compromised a user's identity or signing key could construct a valid Cosign bundle by including any arbitrary Rekor entry, thus preventing the user from being able to audit the signing event.
This vulnerability only affects users that provide a trusted root via --trusted-root or when fetched automatically from a TUF repository, when no trusted key material is provided via SIGSTORE_REKOR_PUBLIC_KEY. When using the default flag values in Cosign v3 to sign and verify (--use-signing-config=true and --new-bundle-format=true for signing, --new-bundle-format=true for verification), users are unaffected. Cosign v2 users are affected using the default flag values.
This issue had previously been fixed in https://github.com/sigstore/cosign/security/advisories/GHSA-8gw7-4j42-w388 but recent refactoring caused a regression. We have added testing to prevent a future regression.
Steps to Reproduce
echo blob > /tmp/blob
cosign sign-blob -y --new-bundle-format=false --bundle /tmp/bundle.1 --use-signing-config=false /tmp/blob
cosign sign-blob -y --new-bundle-format=false --bundle /tmp/bundle.2 --use-signing-config=false /tmp/blob
jq ".rekorBundle |= $(jq .rekorBundle /tmp/bundle.2)" /tmp/bundle.1 > /tmp/bundle.3
cosign verify-blob --bundle /tmp/bundle.3 --certificate-identity-regexp='.*' --certificate-oidc-issuer-regexp='.*' /tmp/blob
Patches
Upgrade to Cosign v2.6.2 or Cosign v3.0.4. This does not affect Cosign v1.
Workarounds
You can provide trusted key material via a set of flags under certain conditions. The simplest fix is to upgrade to the latest Cosign v2 or v3 release.
Note that the example below works for cosign verify, cosign verify-blob,cosign verify-blob-attestation, andcosign verify-attestation`.
SIGSTORE_REKOR_PUBLIC_KEY=<path to Rekor pub key> cosign verify-blob --use-signing-config=false --new-bundle-format=false --bundle=<path to bundle> <artifact>
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.3"
},
"package": {
"ecosystem": "Go",
"name": "github.com/sigstore/cosign/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.6.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/sigstore/cosign/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.6.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22703"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-13T14:58:50Z",
"nvd_published_at": "2026-01-10T07:16:03Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nA Cosign bundle can be crafted to successfully verify an artifact even if the embedded Rekor entry does not reference the artifact\u0027s digest, signature or public key. When verifying a Rekor entry, Cosign verifies the Rekor entry signature, and also compares the artifact\u0027s digest, the user\u0027s public key from either a Fulcio certificate or provided by the user, and the artifact signature to the Rekor entry contents. Without these comparisons, Cosign would accept any response from Rekor as valid. A malicious actor that has compromised a user\u0027s identity or signing key could construct a valid Cosign bundle by including any arbitrary Rekor entry, thus preventing the user from being able to audit the signing event.\n\nThis vulnerability only affects users that provide a trusted root via `--trusted-root` or when fetched automatically from a TUF repository, when no trusted key material is provided via `SIGSTORE_REKOR_PUBLIC_KEY`. When using the default flag values in Cosign v3 to sign and verify (`--use-signing-config=true` and `--new-bundle-format=true` for signing, `--new-bundle-format=true` for verification), users are unaffected. Cosign v2 users are affected using the default flag values.\n\nThis issue had previously been fixed in https://github.com/sigstore/cosign/security/advisories/GHSA-8gw7-4j42-w388 but recent refactoring caused a regression. We have added testing to prevent a future regression.\n\n#### Steps to Reproduce\n\n```\necho blob \u003e /tmp/blob\ncosign sign-blob -y --new-bundle-format=false --bundle /tmp/bundle.1 --use-signing-config=false /tmp/blob\ncosign sign-blob -y --new-bundle-format=false --bundle /tmp/bundle.2 --use-signing-config=false /tmp/blob\njq \".rekorBundle |= $(jq .rekorBundle /tmp/bundle.2)\" /tmp/bundle.1 \u003e /tmp/bundle.3\ncosign verify-blob --bundle /tmp/bundle.3 --certificate-identity-regexp=\u0027.*\u0027 --certificate-oidc-issuer-regexp=\u0027.*\u0027 /tmp/blob\n```\n\n### Patches\n\nUpgrade to Cosign v2.6.2 or Cosign v3.0.4. This does not affect Cosign v1.\n\n### Workarounds\n\nYou can provide trusted key material via a set of flags under certain conditions. The simplest fix is to upgrade to the latest Cosign v2 or v3 release.\n\nNote that the example below works for `cosign verify`, `cosign verify-blob, `cosign verify-blob-attestation`, and `cosign verify-attestation`.\n\n```\nSIGSTORE_REKOR_PUBLIC_KEY=\u003cpath to Rekor pub key\u003e cosign verify-blob --use-signing-config=false --new-bundle-format=false --bundle=\u003cpath to bundle\u003e \u003cartifact\u003e\n```",
"id": "GHSA-whqx-f9j3-ch6m",
"modified": "2026-01-13T14:58:50Z",
"published": "2026-01-13T14:58:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sigstore/cosign/security/advisories/GHSA-whqx-f9j3-ch6m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22703"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/cosign/pull/4623"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/cosign/commit/6832fba4928c1ad69400235bbc41212de5006176"
},
{
"type": "PACKAGE",
"url": "https://github.com/sigstore/cosign"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Cosign verification accepts any valid Rekor entry under certain conditions"
}
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.