CVE-2026-31839: Striae Integrity Bypass in Digital Confirmation Workflow

Striae versions prior to 3.0.0 contain an integrity validation bypass in the digital confirmation workflow. The application relies on a hash-only validation mechanism for exported forensic packages without utilizing cryptographic signatures or message authentication codes. This design flaw aligns with CWE-354: Improper Validation of Integrity Check Value.

The vulnerability allows an unauthenticated attacker to manipulate forensic evidence contained within exported ZIP archives. Because the validation metadata resides within the same trust boundary as the evidence files, the system cannot detect unauthorized modifications. This compromises the forensic chain of custody and permits the introduction of falsified data into the examiner's workflow.

The underlying weakness stems from trusting self-referential integrity checks. Without a mechanism to authenticate the origin and integrity of the manifest itself, the software provides false assurance of data authenticity.

The forensic export process generates a FORENSIC_MANIFEST.json file that is included in the root of the exported ZIP archive. This manifest contains SHA-256 hashes for the main case JSON data and a map of filenames to hashes for all associated images. It also includes a self-referential manifestHash representing the contents of the manifest itself.

During the import process, the application recalculates the hashes of the files present in the ZIP archive and compares them against the values in the manifest. The fundamental flaw is the absence of an external or secret-dependent root of trust. The verification mechanism assumes the manifest is authoritative simply because it is present in the archive.

Because the attacker controls the entire ZIP archive, they control both the data and the validation metadata. The application fails to authenticate the origin of the FORENSIC_MANIFEST.json file, treating any mathematically consistent manifest as legitimate regardless of who generated it.

Exploitation requires the attacker to intercept or obtain a legitimate Striae digital confirmation ZIP package. The attacker extracts the archive and modifies the underlying case data or image files to alter the forensic findings.

After altering the evidence, the attacker recalculates the SHA-256 hashes for the modified files. The attacker then updates the corresponding entries in the FORENSIC_MANIFEST.json file and computes a new manifestHash to match the updated manifest payload.

The attacker repacks the files into a new ZIP archive and delivers it to the target user. When the user imports the manipulated package, the Striae software reads the attacker-controlled manifest, validates the hashes against the attacker-modified files, and reports successful integrity verification. The user relies on the falsified evidence, completing the attack chain.

The primary impact of this vulnerability is a complete localized bypass of the forensic evidence integrity controls. An attacker successfully exploiting this flaw can seamlessly alter critical case data, including examiner names, confirmation timestamps, and comparative image evidence.

This manipulation directly undermines the chain of custody required for digital forensics. The application provides false assurance to the examiner by displaying a "Complete integrity verified" status for a tampered package. This allows falsified evidence to be admitted or relied upon in subsequent investigations or legal proceedings.

The CVSS v3.1 base score of 8.2 reflects the high severity of the integrity and confidentiality impacts. While the attack requires user interaction to import the malicious file, the lack of required privileges and the direct compromise of the application's core security function drive the high severity rating.

Version 3.0.0 addresses the vulnerability by implementing asymmetric digital signatures using RSASSA-PKCS1-v1_5-SHA-256. The export process now routes the manifest through a secure server-side worker (data-worker.ts) that signs a canonicalized version of the manifest using a private key (MANIFEST_SIGNING_PRIVATE_KEY).

The manifest structure was updated to version 2.0, appending a signature object that includes the algorithm, key identifier, timestamp, and a Base64-encoded signature. The import orchestrator (orchestrator.ts) and hash utility (hash-utility.tsx) were modified to enforce a strict verifyForensicManifestSignature step using the corresponding public key (MANIFEST_SIGNING_PUBLIC_KEY).

The application now operates on a fail-closed policy, rejecting any package lacking a valid signature or utilizing an unrecognized key identifier. New utilities (createManifestSigningPayload and normalizeImageHashes) guarantee deterministic JSON representation during both the signing and verification phases, preventing canonicalization bypasses.