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.

Each bulletin is named after the release that fixes it. FSB-2026-02 describes issues present in v1.4.1 and earlier, fixed in v1.4.2. Releases are cumulative: upgrading to the latest version resolves every issue on this page.

What to do

None of these issues weakens the encryption or the secret sharing. Existing shares and encrypted files remain valid after an upgrade, and no re-encryption is needed.

To verify your installed version:

fractum --version

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

FSB-2026-02: fixed in v1.4.2

Published: 2026-10-23
Patched in: Fractum v1.4.2
Severity: Medium (local exposure of share material) / Medium (supply-chain verification inoperative)
Affected versions: v1.4.0 and v1.4.1 for the share exposure issues; v1.4.1 only for the verification issue; all versions before v1.4.2 for FSB-2026-02-D

Fractum v1.4.2 corrects four issues found during a line-by-line audit of the CLI source. Three of them left share material readable on the local machine. The fourth meant the package signature check shipped in v1.4.1 never actually ran, and prevented installation entirely by both documented paths.

FSB-2026-02-D was found after the first three, by re-running the same question against the whole write surface rather than the three sites already fixed.

None of these are remotely exploitable. All require an account on the machine where Fractum was run, or possession of a release archive.

Shares and encrypted files produced by earlier versions remain cryptographically sound. No re-encryption is required. If you ran a decryption that failed on a bad share, see FSB-2026-02-A for a cleanup step.

FSB-2026-02-A: shares left in the temporary directory

Severity: Medium
Component: Share archive extraction during decryption
Required attacker position: A local account on the machine where decryption was attempted

What was the issue

When decrypting, Fractum extracts each share_N.zip into a temporary directory. The cleanup that removed that directory sat at the end of the processing loop, so it was reached only when a share was processed successfully. Two error paths bypassed it: an invalid share, which raised and left the loop, and an unreadable share, which skipped to the next file.

A single failed decryption therefore left a directory such as /tmp/fractum_share_xxxxxxxx containing the extracted share value. When the archive had been created with --bundle-encrypted, the encrypted file sat in the same directory, next to the share.

Exploitation context

Exploitation requires read access to the system temporary directory, which on a default Unix installation means any local account. A single leftover share is below the recovery threshold and reveals nothing on its own. The concern is accumulation: repeated failed attempts with different shares, which is exactly what someone does when troubleshooting a bad archive, can leave enough fragments in one place to reach the threshold, together with the ciphertext they unlock.

Fix in v1.4.2

Cleanup moved into a finally block, so the temporary directory is removed on every path, including both error paths.

If you are affected

Check for and remove any leftovers from earlier versions:

ls -d /tmp/fractum_share_* 2>/dev/null && rm -rf /tmp/fractum_share_*

FSB-2026-02-B: output files readable by other users

Severity: Medium
Component: File output for shares, encrypted files, and recovered plaintext
Required attacker position: Any other account on the same machine

What was the issue

Fractum set no permissions on the files it created, so the process umask decided them. On a default configuration that produces -rw-r--r--, readable by every user on the system. This applied to the share archives, to the .enc file, and to the recovered plaintext written by decrypt.

The last of those is the most direct: the recovered file is the secret itself, in the clear, on disk, readable by anyone with an account on the machine.

Exploitation context

Any unprivileged local account can read the affected files for as long as they exist. On a single-user workstation the exposure is limited to processes running as other service accounts. On a shared or multi-tenant machine it is direct. Fractum is designed to run on an isolated machine, which reduces but does not remove the exposure.

Fix in v1.4.2

Share archives, encrypted files, and recovered plaintext are now created with mode 0600, owner-only, at creation time rather than after writing.

If you are affected

Tighten the permissions of files produced by earlier versions:

chmod 600 your-file.enc shares/*.zip

FSB-2026-02-C: package signature never checked

Severity: Medium
Component: Offline package verification, Docker image build, bootstrap scripts
Required attacker position: None for the availability impact. Supply-chain substitution for the assurance impact.

What was the issue

v1.4.1 added a GPG signature over the checksums of the bundled Python wheels, packages/CHECKSUMS.sha256.asc. Its presence switched on a verification branch in the Dockerfile that had been guarded by a file-existence test and had therefore never executed once since it was written.

It failed on first execution. The base image contains no gpg binary, so the build aborted immediately. The native path failed differently: the bootstrap scripts called gpg --verify without ever importing the public key, so on any machine without that key already in its keyring, gpg exited with No public key and the script aborted the installation.

Separately, the public key published for verification could not be imported at all. It was missing the blank line that the OpenPGP armor format requires between the header line and the base64 body, and gpg rejected it with invalid armor header.

The combined effect is that from v1.4.1 the Docker image could not be built, the native installation aborted for most users, and no user could verify the signature over the bundled packages.

Exploitation context

The primary impact is availability and assurance rather than a direct compromise. The bundled wheels were never unverified in substance: their SHA-256 checksums were, and remain, correct, and the signature over those checksums is valid. What failed was every mechanism a user had to check that for themselves.

Fix in v1.4.2

The build installs gnupg, imports the bundled key, verifies the signature, then removes gnupg within the same layer so it is absent from the final image. The public key is shipped in the repository and in the published source archive. The bootstrap scripts import it before verifying. When gpg is not installed on the machine, they now state explicitly which check was skipped and fall through to the SHA-256 verification instead of aborting, since Fractum is intended to run on air-gapped machines where installing gnupg may not be possible. The published key file has been repaired.

FSB-2026-02-D: plaintext share files exposed

Severity: Medium
Component: Share generation during encryption
Required attacker position: A local account on the machine where the shares were generated

What was the issue

fractum encrypt writes each share to a plaintext JSON file, archives that file into share_N.zip, then deletes it. Two problems affected that window.

The share file was created without setting any permissions, so the process umask decided them, giving -rw-r--r-- on a default configuration. The file contains the share value in the clear. This is the same defect as FSB-2026-02-B, at a fourth site that the earlier fix did not cover because the file is opened in text mode rather than binary.

The deletion was placed inside the archiving loop. Any error raised while archiving left every plaintext share file on disk, not just the one being processed. On a default run that means the whole set, which is by definition above the reconstruction threshold, sitting next to the encrypted file.

Exploitation context

Reproduced without any mocking, by making the destination directory read-only after its creation so that archiving fails partway through: three shares out of three remained on disk, mode 0644, each containing its share_key value. Any local account could read them for as long as they were there.

An archiving failure is not an exotic condition. A full disk, a permission problem on the output directory, or an interrupted run all reach it.

Fix in v1.4.2

Share files are created with mode 0600, set at creation before anything is written. The deletion moves into a finally block that walks every generated share, so no plaintext share survives an archiving error.

If you are affected

Check the directory where you ran fractum encrypt for share files left by an interrupted or failed run, and remove them:

ls share_*.txt 2>/dev/null && shred -u share_*.txt

The share archives themselves (shares/*.zip) are the intended output and should be kept. Only the loose share_*.txt files are leftovers.

Hardening in v1.4.2

Two further changes reduce what a crash or a memory read on the machine can expose. They do not correspond to an exploitable issue in earlier versions and are listed here for completeness.

Share values and the reconstructed AES key are now held in mutable buffers and overwritten after their last use. Before, the code called its secure-clear routine on share values held in an immutable buffer, so only a copy was overwritten. That routine now refuses immutable buffers instead of silently doing nothing.

Core dumps are disabled at startup, before any command runs. On Linux the process is also marked non-dumpable. A crash while the key is in memory can no longer write it to a core file. On platforms without this control, Windows in particular, Fractum prints a warning and continues.

FSB-2026-03: fixed in v1.4.1

Published: 2026-10-23
Patched in: Fractum v1.4.1, released 2026-07-15
Severity: Low (availability)
Affected versions: all versions before v1.4.1

v1.4.1 added a size check on share archives before extracting them. Before it, a crafted archive placed among the shares could fill the temporary directory during a decryption. The fix shipped in v1.4.1 without a bulletin. This one documents it.

It does not expose any secret. Shares and encrypted files are not affected, and no re-encryption is required.

FSB-2026-03-A: no size limit on share archives

Severity: Low
Component: Share archive extraction during decryption
Required attacker position: The ability to put a file in the shares directory used for a decryption, for example a shareholder who hands back a crafted archive instead of their share

What was the issue

When decrypting, Fractum extracts every .zip archive in the shares directory into a temporary directory, before checking that it contains a valid share. Nothing limited how much an archive could write. A compressed archive can declare an uncompressed size about a thousand times larger than its own size.

Exploitation context

Reproduced with v1.4.0: a 1 MB archive that expands to 1 GiB, named share_0.zip and placed next to three valid shares. With /tmp limited to 200 MB, the extraction filled it and stopped with No space left on device. Fractum then skipped the archive, decrypted the file with the three valid shares, and removed the partial extraction.

On a machine where the temporary directory shares a disk with other data, or sits in RAM, the archive fills that space while the decryption runs. Other processes on the machine can fail during that time. The decryption itself still succeeds if enough valid shares are present.

Fix in v1.4.1

Before extracting, Fractum reads the sizes declared in the archive. It refuses any entry compressed more than 200:1, and any archive that would expand to more than 10 GiB in total. The 10 GiB limit stays high because an archive made with --bundle-encrypted carries the encrypted file, which can be large. On the same test, v1.4.2 refuses the archive with suspicious compression ratio (1029:1), writes nothing to /tmp, and decrypts the file.

If you are affected

No action is needed beyond upgrading. In v1.4.0 the partial extraction is removed after the error. To check for leftovers from other failed decryptions, follow the cleanup step in FSB-2026-02-A.

FSB-2026-01: fixed in v1.4.0

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

Fractum v1.4.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.4.0 and later are safe. No re-encryption is required.

FSB-2026-01-A: shares revealed a hash of the file

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.4.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.4.0

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

FSB-2026-01-B: file header not 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.4.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.4.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: key not cleared from 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.4.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.4.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).

Other fixes in v1.4.0

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

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.