Security Bulletins

This page documents security vulnerabilities identified in past Fractum releases, the conditions required to exploit them, and the fixes introduced in each patching release.

Bulletins are addressed to all Fractum users. Releases are cumulative: upgrading to the patched version resolves every issue listed for prior versions.

Bulletin FSB-2026-01 — Fractum v1.3.0

Published: 2026-06-30
Patched in: Fractum v1.3.0
Severity: Medium (cryptographic correctness) / Low (operational impact under realistic conditions)
Affected versions: All Fractum releases prior to v1.3.0

Summary

Fractum v1.3.0 corrects three security issues identified during an internal audit of the CLI source code. All three require an attacker to have direct access to your machine, your encrypted files, or your share archives — they cannot be triggered remotely. No known exploits of these issues exist in the wild.

Shares and encrypted files produced by v1.3.0 and later are safe. No re-encryption is required.

FSB-2026-01-A — Share files exposed a fingerprint of the protected data

Severity: Medium
Component: Share archive metadata
Required attacker position: Possession of one or more share files (physical access, storage theft, or filesystem access)

What was the issue

Before v1.3.0, each share archive embedded a SHA-256 hash of the original plaintext file. This hash was stored in cleartext in the share's metadata, alongside the share index and threshold.

A single share, held below the recovery threshold, is cryptographically insufficient to decrypt the protected file. However, the embedded hash acted as a fingerprint: an attacker who obtained even one share could determine whether two or more shares came from the same encryption operation, or could compare the hash against a known file to confirm that a specific document had been protected with Fractum.

This did not allow decryption. It did allow passive identification of file identity.

Exploitation context

Exploitation requires direct access to at least one share archive — through physical access to a storage device, theft of a backup medium, or compromise of a file system. Remote exploitation is not possible. If your share distribution practices ensure that no single location or person holds more share archives than are needed for an authorised recovery, the exposure is further limited.

Fix in v1.3.0

The plaintext hash has been removed from share metadata. Share archives produced by v1.3.0 no longer carry any information that links the share to the original file identity.

FSB-2026-01-B — Encrypted file header metadata was not cryptographically authenticated

Severity: Medium
Component: Encrypted file format (.enc)
Required attacker position: Write access to the encrypted file

What was the issue

Fractum encrypts file contents with AES-256-GCM, which provides both confidentiality and authenticated integrity. Before v1.3.0, the file header — which records the original filename, Shamir threshold, and total share count — was stored alongside the ciphertext but was not included in the AES-GCM authentication tag computation.

This meant that an attacker with write access to an encrypted file could silently modify the header fields (for example, changing the recorded filename or threshold) without Fractum detecting the tampering during decryption. The ciphertext itself remained protected, but the surrounding metadata was not.

Exploitation context

Exploitation requires write access to the encrypted .enc file. The attacker must be able to modify bytes on disk — a remote attacker cannot do this without prior compromise of the storage system. In most deployment models, the encrypted file is kept under access controls that already prevent arbitrary writes. If the encrypted file is stored on a shared or network-accessible location without integrity controls, the risk is higher.

A successful modification of the header metadata would cause the decryptor to display incorrect file information. In specific scenarios it could be used to mislead the operator during a recovery operation.

Fix in v1.3.0

The full header metadata is now passed as Additional Authenticated Data (AAD) to AES-256-GCM. Any modification to the header — even a single byte — causes decryption to fail with an authentication error before any output is written.

FSB-2026-01-C — Encryption key material was not reliably cleared from process memory

Severity: Low
Component: In-process memory handling
Required attacker position: Code execution on the same machine, or post-session access to memory (swap, crash dump, cold-boot)

What was the issue

Before v1.3.0, the 32-byte AES encryption key could remain in Python process memory after the encryption or decryption operation completed. Python's garbage collector does not guarantee prompt erasure of sensitive buffers.

An attacker with the ability to read process memory (via a debugger, /proc/mem, a crash dump, or OS-level swap) could potentially recover the key material from a completed Fractum session.

Exploitation context

Exploitation requires either active code execution on the same machine during or after a Fractum operation, or access to persistent memory residue (swap files, hibernation images, crash dumps). This is not an over-the-network attack. Physical possession of a machine used for Fractum operations — after the fact — could allow extraction if the machine has swap enabled and was not wiped.

Fix in v1.3.0

Key buffers are now explicitly overwritten before release and, where the operating system permits, locked in RAM to prevent paging to swap. This is defence in depth: it substantially reduces the window and probability of key material appearing in memory residue, without guaranteeing zero-trace operation (a guarantee that Python's runtime cannot provide at a fundamental level, as documented in the security architecture).

Additional improvements in v1.3.0

The following lower-severity items were corrected in the same release:

Are my existing shares and encrypted files safe?

Yes. If you have already created share sets or encrypted files, no emergency action is required.

The cryptographic material — your AES-256-GCM ciphertext and your Shamir key shares — is not weakened by any of these issues. The vulnerabilities above affect metadata handling and in-memory behaviour, not the underlying encryption or the secret-sharing mathematics. Recovering a file protected with any version of Fractum requires the full threshold of compatible shares, and that requirement is unchanged.

Shares produced by v1.3.0 are safe and carry no residual exposure from the issues above. The only visible change to share archives is the removal of the plaintext hash from share metadata; the share values and all recovery-relevant material are preserved.

Recommended actions

To verify your installed version:

fractum --version

To verify the release binary signature before upgrading, follow the software verification guide.

Fractum security bulletins are published on this page. For questions or responsible disclosure of new issues, contact the Katvio team through the official channels listed in the project repository.