The Curse of the Cursor: SpiceDB Denial of Service via Panic

In the Go programming ecosystem, there is an unwritten rule—or rather, a very explicitly written convention—about function naming. If a function starts with Must (e.g., MustCompile, MustParse), it is a loaded gun. It tells the runtime: "If this fails, don't bother returning an error. Just panic and crash the program." These functions are great for initialization logic where hardcoded strings must be correct for the program to start. They are absolutely catastrophic when used on dynamic input.

SpiceDB, the authorization database designed to handle permissions at massive scale (think Google Docs sharing), forgot this rule. In a specific workflow for looking up resources, the server accepted a pagination cursor from the user, unwrapped it, and shoved the contents directly into tuple.MustParse. This is the digital equivalent of accepting a package from a stranger and immediately juggling it without checking if it's a bomb.

Pagination cursors are a standard mechanism in APIs. You ask for a list of resources, the server gives you the first 50 and a "cursor"—a bookmark—to get the next 50. In SpiceDB, these cursors are Protobuf messages (authzed.api.v1.Cursor) that contain a list of strings called sections. When a client asks for the next page, they send this cursor back to the server.

Deep in internal/graph/cursors.go, the LookupResources logic tries to pick up where it left off. It extracts a string from the cursor's sections field—data that is ostensibly controlled by the server but physically routed through the untrusted client. The code treated this string as a trusted internal tuple representation. It passed this string to tuple.MustParse, assuming it would always be valid. It didn't account for a malicious client modifying the cursor or hand-crafting a garbage one.

The vulnerability lived in internal/graph/cursors.go. The code took a string directly from the input and assumed it was safe.

Vulnerable Code:

// The code retrieves the string from the cursor
datastoreCursorString, _ := ci.headSectionValue()
if datastoreCursorString != "" {
    // FATAL FLAW: MustParse panics on error
    datastoreCursor = options.ToCursor(tuple.MustParse(datastoreCursorString))
}

If datastoreCursorString is "invalid:garbage", MustParse throws a panic. Since this isn't recovered, the Go runtime kills the process.

The Fix (v1.39.1): The patch is the standard "don't panic" fix. It switches to the safe Parse variant and checks the error.

datastoreCursorString, _ := ci.headSectionValue()
if datastoreCursorString != "" {
    // FIX: Use Parse and handle the error gracefully
    parsedCursor, err := tuple.Parse(datastoreCursorString)
    if err != nil {
        return fmt.Errorf("could not parse '%s' as tuple: %w", datastoreCursorString, err)
    }
    datastoreCursor = options.ToCursor(parsedCursor)
}

Exploiting this is trivially easy. You don't need authentication if the endpoint is public, and you don't need complex memory corruption techniques. You just need to speak gRPC.

1. Craft a Cursor: The cursor is a Base64-encoded Protobuf message. You can generate a valid one using the authzed buf definition, or just capture a valid one from a normal request.
2. Poison the Well: Modify the sections field in the Protobuf to contain a string that violates the tuple syntax (e.g., ":::bad_tuple").
3. Fire: Send a LookupResources request with your poisoned optional_cursor.

Because SpiceDB is often deployed as a central authorization service, a single malformed request can crash the pod. If an attacker puts this in a loop, they can keep the authorization service perpetually down. In a microservices architecture, when Authz goes down, everything usually fails closed. The app becomes a brick.

The remediation is straightforward: upgrade to v1.39.1. This version replaces the panic-inducing call with proper error handling. If you cannot upgrade immediately, you are in a tight spot because WAFs generally struggle to inspect the internal fields of gRPC Protobuf messages to validate tuple syntax. Rate limiting might slow down an attacker, but it won't stop them from crashing the service eventually. The only real fix is the patch.