Impact
An unauthenticated remote attacker can trigger unbounded memory growth on the timestamp authority server.
This vulnerability exists because the global wrapMetrics middleware records the raw HTTP request path (r.URL.Path) and raw HTTP request method (r.Method) as Prometheus labels for latency and request count metric vectors. Since this middleware runs before standard routing occurs, it executes for all incoming requests, including those for unmatched paths (yielding 404 responses) or arbitrary request methods. The Prometheus library registers a new, permanent time-series entry for every distinct label combination. An attacker can continuously issue requests containing random paths (e.g., /api/v1/timestamp/<uuid>) or random HTTP methods to exhaust system memory.
Patches
This issue has been patched by limiting the metric label values to a strict allowlist of expected paths (/ping, /api/v1/timestamp, /api/v1/timestamp/certchain) and expected HTTP methods (GET, POST, HEAD, OPTIONS). Unrecognized paths or methods are normalized to a static string ("unrecognized").
Users should update to version v2.0.7 or later.
Workarounds
1. Block or drop incoming requests with invalid HTTP methods or unknown request paths at a reverse proxy or load balancer before they reach the timestamp authority server. 2. Configure rate-limiting on the public interface to prevent remote attackers from issuing millions of unique requests in a short duration.
Authorization bypass via certificate bag manipulation in sigstore/timestamp-authority verifier
An authorization bypass vulnerability exists in sigstore/timestamp-authority verifier (timestamp-authority/v2/pkg/verification): VerifyTimestampResponse function correctly verifies the certificate chain but when the TSA specific constraints are verified in VerifyLeafCert, the first non-CA certificate from the PKCS#7 certificate bag is used instead of the leaf certificate from the certificate chain. An attacker can exploit this by prepending a forged certificate to the certificate bag while the message is signed with an authorized key. The library validates the signature using the one certificate but performs authorization checks on the another, allowing an attacker to bypass some authorization controls.
This vulnerability does not apply to timestamp-authority service, only to users of timestamp-authority/v2/pkg/verification package.
This vulnerability does not apply to sigstore-go even though it is a user of timestamp-authority/v2/pkg/verification: Providing TSACertificate option to VerifyTimestampResponse fully mitigates the issue.
Patches
The issue will be fixed in timestamp-authority 2.0.6
Workarounds
Users of VerifyTimestampResponse can use the TSACertificate option to specify the exact certificate they expect to be used: this fully mitigates the issue.
References
This issue was found after reading CVE-2026-33753 / GHSA-3xxc-pwj6-jgrj (originally reported by @Jaynornj and @Pr00fOf3xpl0it)
Impact
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.