immudb is a cool, modern database that’s all about trust — it uses cryptographic proof and verification to make sure your data can't be changed without you knowing. But if you ever used immudb before version 1.4.1, there was a sneaky bug (CVE-2022-36111) that could let a bad actor trick your app into trusting fake data. Here’s what happened, how the exploit works, some code to show you, and what to do next.

What is immudb and What is "Proof"?

immudb is built to be a tamper-evident database. When a value is saved, it gets cryptographically tied to all previous states — a bit like a blockchain. When you read data, immudb gives a cryptographic "proof" (like a receipt with a digital signature) that you can verify in your app before trusting the data.

If everything works as designed, the server can't give you a fake value without your client noticing. That’s awesome... until it isn’t.

CVE-2022-36111: What’s the Issue?

In immudb versions before 1.4.1, if you’re using an SDK client and connect to a malicious server (one controlled by an attacker), that server could generate a falsified cryptographic proof. If your client performed certain verification steps in a certain order, it would accept the fake proof. This means your app could believe it got the right value, even though it was replaced.

Needs a *malicious* server – not triggered by legit servers.

- Requires the *client* to follow a *specific set of operations* to be fooled (not every request is at risk).

Exploit Details: How Could an Attacker Abuse This?

Imagine an app using the immudb client SDK to verify data integrity from an immudb server. If the server is hostile, it can hand the SDK a crafted, invalid cryptographic proof. As long as the client follows the "acceptance steps" in the right (wrong) way — which can happen in some automated workflows — the client will think that all is okay, and trust data that’s fake.

The consequences? You could be building an audit log, a payment system, a legal record — and be trusting data that was tampered with... and have NO idea.

Let’s say you have Go code like this, before v1.4.1

import (
    "github.com/codenotary/immudb/pkg/client"
)

func checkData(key string) {
    cli, err := client.NewImmuClient(client.DefaultOptions())
    if err != nil {
        panic(err)
    }
    // Attacker runs a fake immudb server here!
    entry, err := cli.Get([]byte(key))
    if err != nil {
        panic(err)
    }
    // Faked proof accepted by old SDK: entry.Value is not what was really stored!
    println("Data (untrusted!):", string(entry.Value))
}

If the fake server crafts the right proof, your client happily says the data checks out, when it’s not.

Technical Detail: Why Was the SDK Fooled?

The bug was in how the client SDK checked that the *root hash* (the summary of all data) was connected to the *transaction hash* provided by the server. The SDK didn’t strictly ensure these cryptographic links, so an attacker could *swap in* a different transaction and make the proof look valid.

Only a malicious server could do this: genuine immudb servers never send falsified proofs.

Wait for a client app to call Get() and verify a value.

3. The fake server crafts a proof for a different key/value, not what was actually in the DB.

The SDK (pre-1.4.1) verifies the proof and says “OK!”, app trusts the value.

If you want to see references, check the security advisory or release notes for 1.4.1.

If you use immudb client SDK < 1.4.1, upgrade NOW!

- Fix version: 1.4.1 or later (Download link)

Servers themselves are *not* vulnerable, only the client SDK.

- If your apps rely on the cryptographic proof of immudb and could ever connect to a non-trusted database endpoint (esp. during dev/test), this is crucial.

More Info & References

- Official Advisory: GHSA-5r3h-x7rc-64vf
- immudb GitHub Releases
- Common Vulnerabilities and Exposures (CVE) - CVE-2022-36111

Conclusion: The Takeaway

immudb’s cryptographic proofs are powerful — but only if we keep the implementation tight. CVE-2022-36111 shows how even "safe-by-design" systems need strong verification *everywhere*. Don’t risk getting tricked by a faked proof: upgrade your SDK, and trust your data again.

Timeline

Published on: 11/23/2022 18:15:00 UTC
Last modified on: 11/27/2022 04:33:00 UTC