As of August 25, 2026, Seagate’s public product-security page lists three CVEs dated 2026.
Apex, Cantina’s autonomous OffSec agent, discovered all three in openSeaChest.
Each flaw arose when a count, range, or index governed a memory operation without a final check against the destination.
openSeaChest is Seagate’s open-source toolkit for diagnosing, configuring, and maintaining storage devices. It translates SCSI and NVMe device responses and command parameters into allocation sizes, loop bounds, and array indices.
Modern infrastructure routinely acts on metadata supplied by devices and other machines, often without an operator inspecting each value. In storage tooling, a device-reported count or caller-supplied range can become an allocation size, loop bound, or array index. That translation forms a security boundary between the device-facing protocol and host memory.
Apex followed three values to the memory operations they governed: a device-reported SCSI length, a requested NVMe LBA range, and an NVMe FLBAS index. Each path was missing or misapplying the bound that should have kept the operation inside allocated memory.
Artwork by Cantina
One allocation, one loop, one index
The first bug began with a SCSI defect-list length returned by the device. openSeaChest converted that wire-format length into an element count and multiplied it by the in-memory descriptor size. On the tested 64-bit build, each descriptor occupied 16 bytes. Because the allocation product was stored in a uint32_t, a required 4 GiB payload wrapped to zero while the original element count remained intact. The allocation still contained the structure’s embedded first entry, so the write to element 1 was the first write beyond the heap allocation.
The second bug was an off-by-one error in the NVMe deallocate loop. Its 4,096-byte buffer could hold 256 descriptors of 16 bytes each, but the loop continued while descriptorCount <= 256. If the requested LBA range still had work remaining, iteration 257 began at offset 4,096 and attempted to write bytes 4,096 through 4,111, beyond the buffer’s valid indices of 0 through 4,095.
The third bug was in the NVMe supported-format path. The affected code used the low nibble of the namespace’s FLBAS field as an index into an array whose allocated length depended on the number of formats reported elsewhere by the device. A malicious device could report one available format while selecting index one. The code did not compare that index with the allocated count before setting currentFormat, producing a one-byte out-of-bounds write.
| Input that governed memory | What went wrong | Result |
|---|---|---|
| SCSI defect count | 32-bit allocation product wrapped | Heap out-of-bounds write and possible reads |
| NVMe descriptor count | Inclusive loop admitted one extra iteration | 16-byte out-of-bounds write |
| NVMe format index | Index was not checked against allocated entries | One-byte out-of-bounds write |
What the fixes have in common
Seagate fixed the three paths by restoring a direct relationship between logical values and physical memory:
- allocation math now uses a wider type and checks for overflow;
- the descriptor loop stops before capacity and checks its byte offset;
- the decoded format index must exist in the allocated array.
These changes are small because the missing guarantees were small. Their placement matters. A protocol-valid count or index is still unsafe if the corresponding bytes do not exist in the current process.
The vulnerabilities require local, privileged access. Two also depend on inconsistent or malicious responses from a connected device, while the deallocate issue requires an extreme requested range. The published evidence does not establish remote code execution. Seagate scored the findings 1.8 Low, 4.6 Medium, and 1.8 Low.
Seagate’s public product-security page credits Cantina and its autonomous AppSec agent for all three. As of August 25, they remain the only CVEs dated 2026 listed there.
Teams using openSeaChest should upgrade to version 26.03.2 or later.
Find the next target in your environment
Apex investigates codebases like an attacker would, reproduces findings, and produces evidence and remediation guidance your team can act on. See how Apex works or book a demo.
