Every CVESearch/Get API key

GHSA-9fm9-c4h4-8g93

Out-of-bounds read when decoding internal keys shorter than 16 bytes

7.9 HighFix available

GHSA-9fm9-c4h4-8g93 is a high vulnerability (CVSS 7.9) in surrealkv, published November 3, 2026. No source lists public exploit code. Fixed in surrealkv 1.2.0.

What does this mean?
Severity
7.9 HighCVSS 3.1, OSV
Exploit chance
UnscoredNo EPSS score yet
Exploitation
None knownNot on CISA’s or ENISA’s lists
Fixed in
1.2.0surrealkv

Description

InternalKeyRef::from_encoded is a safe constructor whose only length check is debug_assert!(encoded.len() >= 16), which is compiled out in release builds. Its accessors perform unchecked length arithmetic on the slice: user_key() slices &encoded[..len - 16], trailer()/seq_num() pass len - 16 and timestamp() passes len - 8 to read_u64_be, which computes buffer.as_ptr().add(offset) and performs an 8-byte load. For a short slice the subtraction underflows usize, the pointer wraps below the allocation and eight bytes before the buffer are read (undefined behavior; confirmed with AddressSanitizer as a heap-buffer-overflow). In debug builds the same call panics instead.

The same invariant is missing at the on-disk decode boundary: BlockIterator::seek_next_entry rebuilds the current key from block bytes with upper-bound checks only, and BlockIterator::key() wraps it in InternalKeyRef, which surrealdb's kv-surrealkv backend then reads through key_ref.timestamp(). A crafted or corrupted SSTable therefore reaches the same unchecked subtraction without any unsafe at the call site.

1.2.0 rejects internal keys shorter than their 8-byte trailer before any accessor computes an offset and makes the accessors bounds-checked (fix in commit ac642f9, surrealdb 4.0.0 ships surrealkv 1.2.0).

Attack profile

How easy it is to exploit

Attack vector
Local
Complexity
Low
Privileges needed
None
User interaction
None

What an attacker can affect

Confidentiality
High
Integrity
None
Availability
Low

Affected packages

Affected packages
PackageAffectedFixed
surrealkv
crates.io
0.0.0-0 up to 1.2.0
1.2.0

What each source reports

OSV Score usedRUSTSEC-2026-04527.9

Out-of-bounds read when decoding internal keys shorter than 16 bytes

InternalKeyRef::from_encoded is a safe constructor whose only length check is debug_assert!(encoded.len() >= 16), which is compiled out in release builds. Its accessors perform unchecked length arithmetic on the slice: user_key() slices &encoded[..len - 16], trailer()/seq_num() pass len - 16 and timestamp() passes len - 8 to read_u64_be, which computes buffer.as_ptr().add(offset) and performs an 8-byte load. For a short slice the subtraction underflows usize, the pointer wraps below the allocation and eight bytes before the buffer are read (undefined behavior; confirmed with AddressSanitizer as a heap-buffer-overflow). In debug builds the same call panics instead.

The same invariant is missing at the on-disk decode boundary: BlockIterator::seek_next_entry rebuilds the current key from block bytes with upper-bound checks only, and BlockIterator::key() wraps it in InternalKeyRef, which surrealdb's kv-surrealkv backend then reads through key_ref.timestamp(). A crafted or corrupted SSTable therefore reaches the same unchecked subtraction without any unsafe at the call site.

1.2.0 rejects internal keys shorter than their 8-byte trailer before any accessor computes an offset and makes the accessors bounds-checked (fix in commit ac642f9, surrealdb 4.0.0 ships surrealkv 1.2.0).

Record
RUSTSEC-2026-0452
CVSS 3.1
7.9 HighCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L
Updated
2026-11-06

History

History
RecordedChangedSources
first indexedOSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

References

MoveEnter Open