Rekor vulnerabilities

Rekor versions 1.4.3 and below allow SSRF to arbitrary internal services because /api/v1/index/retrieve supports retrieving a public key via a user-provided URL. The SSRF can only trigger GET requests, cannot mutate state, and the response is not returned, so only blind SSRF (internal network probing) is possible.

In Rekor (a software supply chain transparency log) versions 1.4.3 and below, the entry implementation can panic on attacker-controlled input when canonicalizing a proposed entry with an empty spec.message, causing a nil pointer dereference. The validate() function returns nil (success) when the message is empty, leaving sign1Msg uninitialized, and Canonicalize() later dereferences v.sign1Msg.Payload. 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 and the service continues, so the availability impact is minimal. This issue has been fixed in version 1.5.0.

Rekor, a software supply chain transparency log, contains a decompression bomb vulnerability in the `Package.Unmarshal()` function for APK files. An attacker can submit a specially crafted APK file that decompresses to a huge amount of memory, causing a server crash. The vulnerability affects versions 0.3.0 through 1.5.1 and is reachable via two unauthenticated endpoints.

The vulnerability in Rekor allows a malformed entry of type `intoto/v0.0.2` to cause a panic in a thread within the Rekor process. However, the service continues to run, and the client receives a 500 error message.