AeroVault security audits, round 1 + 2: findings, remediation, and v4 readiness

[axpnet]

AeroVault (the .aerovault encrypted-container engine behind AeroFTP) went through two adversarial security audit rounds. Every finding from both rounds is now fixed and released. The cryptographic core was found sound in both rounds; the issues were in the integration layer and in two extract / atomic-write paths.

The full technical reports are published in the repo, and this is where future audits will live too:

• Index: audit/README.md
• Round 1 (deep audit): audit/2026-05-30_deep-audit/REPORT.md
• Round 2 (dual cross-audit + v4 verdict): audit/2026-06-03_dual-independent/REPORT.md

The two rounds, in short

Round 1 (2026-05-30): deep single-perspective audit. A multi-dimension review with skeptic verification of every raised finding. 47 raised, 45 confirmed: 0 critical, 1 high, 8 medium, plus low / info. The one high was an authentication gap (the TOTP second factor was not enforced in the default vault mode), not a crypto flaw. The mediums clustered into a content-integrity gap (chunk splicing), secret-memory hygiene, a draft-extractor path traversal, atomic-write durability, and Cryptomator-compat hardening. Remediated, including the crate format v3 that binds a per-file id into the chunk AAD.

Round 2 (2026-06-03): dual independent cross-audit. Two reviewers audited the identical commits independently, with separate proof-of-concept work. Both reached NO-GO independently, so the verdict did not rest on any single contested finding. 3 high, ~10 medium, plus low / info. The headline issues:

• Symlink write-through on extract (crate, high): a pre-planted destination symlink could redirect decrypted plaintext outside the extraction root. Found by both reviewers. Fixed in crate 0.4.1 (O_NOFOLLOW plus create_new plus descriptor identity plus canonical containment).
• Reserved-key disclosure (app, high): the credential store enforced its reserved-key filter only on writes, so the public API could read or delete the TOTP secret and read the master password hash. Fixed.
• "Standard" level misrepresentation (app, high): the GUI "Standard" level advertised a strong stack but created a legacy container. Fixed by routing it to the v2 stack.

Round 2 also honestly caught a regression in round 1: the round 1 TOTP throttle persistence had become dead code on the live unlock path. It was re-implemented correctly. The mediums and lows (chunk-length DoS, v3 concurrent-write lost update, headless TOTP replay, keystore peak memory, bridge file permissions, decompression bomb, reserved-header MAC coverage, supply-chain yanked dependency, and the v3-naming contract) are all fixed across crate 0.4.1 / 0.4.2 and the application.

Current state, proven by tests

Post-fix gates (2026-06-03): crate test suite 31 / 0, crate clippy clean, application library suite 2074 / 0, application clippy clean, frontend typecheck clean, cargo audit clean.

The current secure behavior reproduces with the published crate CLI (cargo install aerovault-cli installs the aerovault binary). Captured against 0.4.2 with a 1 MiB random payload (the password prompt is hidden):

Round-trip is byte-identical:

$ aerovault info vault.aerovault
Password:
Version: 3
Encryption: AES-256-GCM-SIV
KDF: Argon2id (128 MiB, t=4, p=4)
...

$ aerovault extract vault.aerovault -o out/
Password:
  1 entries extracted to out/

$ sha256sum secret.bin out/secret.bin
f2944773e59726c8c2b01cf36f75e72608ae7679b6f7d724178bbbcdcc93353b  secret.bin
f2944773e59726c8c2b01cf36f75e72608ae7679b6f7d724178bbbcdcc93353b  out/secret.bin

A wrong password fails closed:

$ aerovault list vault.aerovault
Password:
error: crypto error: key unwrap failed (wrong password?)

The symlink write-through (round 2, AV-001) now refuses. Pre-plant a symlink where the extract output would land, then extract: it fails closed and the external target is untouched, where 0.4.0 would have followed the symlink and overwritten it:

$ ln -s VICTIM.txt out/secret.bin
$ aerovault extract vault.aerovault -o out/ -e secret.bin
Password:
error: I/O error: File exists (os error 17)

$ cat VICTIM.txt
ORIGINAL VICTIM CONTENT

The full reproducible verification, including the automated gate table, is in the round 2 report.

v4 Wrapper-Stack readiness

Starting the v4 Wrapper-Stack (ECC) development line is cleared: GO. The v3 surfaces v4 builds on (pre-decrypt damage detection via a separate cipher hash, clean truncation handling, the extension directory, packing / dedup, profile chunking bounds) are present, hardened, and green under test. The new dispatch validation even de-risks the v4 format evolution by fail-closing on unknown wrapper versions.

One honest reservation for a full "GA, stable without reservations" claim: a live validation matrix (real GUI, real 2FA unlock, multi-GiB round-trips, crash injection, hostile bridge fuzzing) was not executed by either reviewer. That is a validation gap, not a known defect, and it is the gate for leaving Beta, not a prerequisite to start v4. Details in the round 2 report.

Versions

aerovault 0.4.1 (security) and 0.4.2 (metadata) are published on crates.io, with aerovault-cli realigned to 0.4.2. The fixes ship end to end in the next AeroFTP release.

Acknowledgement

@EhudKirsh is a project contributor: he designed the AeroVault wrapper-stack pipeline model (AeroFTP issue #162), co-authored the round 1 remediation, and has provided sustained community testing across releases. This verdict is the green light to open the v4 line he helped shape.

Ehud, inviting you to review the reports and continue the v4 discussion here.

---

Edited to fix paragraph formatting: GitHub Discussions render single line breaks literally, so the original 80-column hard wrap was reflowed into single-line paragraphs. Content unchanged.

[axpnet]

AeroVault Security Audit 2026-06-18: Dual Blind Audit + Remediation + Controaudit (Grade A)

Summary

AeroVault (aerovault crate + the AeroFTP aeroftp_v3 embedder) underwent an independent, dual blind security audit followed by full remediation and a two-round adversarial controaudit. The cryptographic core and the v3 vault-container recovery path were sound and byte-for-byte aligned crate/app from the start. The audit found 1 High, 1 Medium, 3 Low, 4 Info, 0 Critical; every finding is now fixed and verified on both codebases, and the controaudit closed every residual it surfaced. Final grade: A, 0 open findings.

What this means for your data

Short version: your vaults are safe. The encryption that protects an AeroVault file was reviewed and found solid, and nothing the audit found could quietly damage, delete, or unlock the files inside a vault you have already created. AeroVault's self repair is built so it can only succeed or stop with an error: it never replaces a file unless the rebuilt copy matches the original exactly. The fixes in this release are precautions that harden AeroVault against unlikely situations, such as the app being interrupted at the wrong moment or someone who already has access to your computer.

Situation	What could have happened	How likely	Effect on your files
A vault operation was interrupted, or a repair was run on Windows (M1)	An unencrypted temporary copy could be left on your own disk, and on Windows the repair tool could fail to finish	Low, only when something is interrupted or when a repair is actually needed	Nothing lost or changed. At most an unencrypted leftover sits on your own machine, where only someone with access to your computer could open it
Unpacking a vault on a computer that was tampered with in advance (M2)	The unpacked files could be diverted into a different folder than the one you chose	Very low, it needs someone to have already altered your folders beforehand	Nothing lost or changed. The files could be written somewhere you did not intend
The separate recovery file was swapped by someone with access to your computer (M3)	A standalone repair could be pushed toward the wrong content. This is the optional separate recovery file, not the vault itself	Very low, and it never touched the vault, which was already protected	Your vault was never exposed. Only the optional standalone recovery feature
The app crashed at the exact moment of saving a vault (M9)	The next save could be blocked for about 30 seconds and then show an error until a small leftover lock file was removed	Low	Nothing lost or damaged, just a brief block, now cleared automatically

In plain terms: no one could attack your vaults over the internet, and there was no way to silently corrupt or destroy what is inside them. These changes close small gaps that would have needed someone already at your computer or an unlucky crash, and they stop AeroVault from leaving any unencrypted leftovers behind.

How it was audited (methodology)

	Engine A	Engine B	Merge / Phase 2
Model	Claude Opus 4.8 (1M ctx)	Codex (GPT-5)	Claude (reconcile) + Claude Opus 4.8 controaudit
Topology	1 primary + 2 read-only research sub-agents	1 agent	dual adversarial workflows (7 + 4 Opus reviewers)
Scope	opus/ only	codex/ only	both, re-verified vs source

• Blind & parallel: two auditors ran the identical brief at the same time, each writing only to its own folder, never reading the other. Reaching the same boundary independently is what makes the verdict robust.
• Provenance pinned: the audited source was published crates.io aerovault 0.6.1 (git 4c50fde) plus the in-progress M7 convergence; the converged result is now published as aerovault 0.6.2 (git c5bc3f6, tag v0.6.2), which is exactly the artifact the app compiles (registry-checksum pinned in its lockfile). No version skew.
• Library-harness driving (the CLI is rpassword/TTY-only) plus a live matrix run on both targets and diffed: round-trip + byte-identity, scrub, repair (embedded & detached), header/manifest parity recovery, beyond-budget & foreign-sidecar fail-closed, cross-open T5 both directions, standalone .aerocorrect gen/verify/repair, kill-mid-seal, stale-lock, and the M1/M2 PoCs.
• Controaudit (Phase 2): every fix re-verified by independent adversarial Opus reviewers instructed to refute it, plus completeness critics hunting for new findings, iterating fix/test/re-verify to 0 open findings. Static gates: cargo test, cargo clippy -D warnings, cargo audit, all green; regression tests added per finding.

Findings & remediation

ID	Sev	Finding	Fix	Verification
M1	🔴 High	Standalone .aerocorrect repair broken on Windows (target read handle held across persist, giving ERROR_ACCESS_DENIED); the app path also left a decrypted-plaintext .tmp* on the error branch	🟢 Drop the read handle before persist; scrub the temp on the persist-error branch. Fixed in the crate and the app's forked copy (both sites)	2 previously-red crate tests now green; new repair_restores_and_leaves_no_temp_artifact (crate + app) asserts byte-restore and no temp artifact; adversarial pass confirmed all 3 persist sites + no other EC persist holds a target handle
M2	🟠 Medium	v3 extract followed a pre-planted intermediate reparse point (Windows directory junction, no admin) out of the destination root, writing decrypted plaintext into a sibling directory	🟢 Create each path component with create_dir refusing to follow a pre-existing reparse point, then assert the canonical parent stays within the canonical root; applied to extract_all, extract_entry, and extract_file_entry	Junction PoC (mklink /J) contained; 2 regression tests (incl. the single-entry extract_entry subtree path found by the controaudit)
M3	🟡 Low	Bare correct repair reconstructs toward whatever the sidecar declares (integrity, not authenticity); a planted same-length sidecar drives the repair to attacker content	🟢 Added an out-of-band --expect-sha256 authenticity anchor that refuses a sidecar declaring a different hash before any write; wired through the crate lib + CLI and the app lib + CLI + MCP tool (with schema). The vault and AeroSync paths were already higher-layer-authenticated	Anchor refuses a mismatched sidecar before any write on every shipped surface; crate + app tests; adversarial pass confirmed all four surfaces and that bare repair is unchanged
M4	🟡 Low	The header MAC authenticates the extension-directory offset/len but not its JSON bytes (DoS-bounded, recovery re-verifies against authenticated material)	🟢 Reject critical/duplicate/out-of-range extensions at open, hoisted above the manifest-recovery consumption, so a forged directory fails closed before any use	validate_extension_dir_rejects_forged_entries; recovery path independently bounds-checked + AEAD-gated. Residual (full byte authentication) is a version-2 header change, tracked
M5	🟡 Low	App reported EC as "stub (Phase 1)" while shipping live Reed-Solomon EC	🟢 Replaced with the accurate live RS-EC capability string	grep: 0 stub (Phase 1) / Phase 2
M6	Info	Crate save_open_vault is generation-check-only (no cross-process lock)	🟢 Documented the concurrency contract (the embedder, e.g. the app O_EXCL lock, owns cross-process safety)	doc verified vs the app lock
M8	Info	cargo audit: instant 0.1.13 unmaintained (RUSTSEC-2024-0384)	🟢 Documented ignore with corrected attribution: it enters via reed-solomon-erasure 6.0.0 to parking_lot 0.11, not the CLI progress stack, and is not locally fixable (the =6.0.0 pin blocks parking_lot 0.12)	cargo audit clean; no vulnerabilities
M9	Info	A hard crash mid-seal leaves a stale .{name}.lock that blocks the next writer ~30s then hard-errors until manual cleanup	🟢 Reclaim a lock whose recorded owner PID is provably dead; reclaim made atomic (rename-aside, verify-then-drop-or-restore) to remove a double-acquire window, backstopped by the generation check	dead-pid reclaimed, live-owner never stolen; adversarial pass: double-acquire eliminated
doc	n/a	Narrative pipeline order written compression then chunking (reversed vs code/spec)	🟢 Corrected to chunking then compression across CHANGELOG, the RS-erasure evaluation, the telemetry comment, the architecture primer, and the AppStream metainfo	grep over the whole repo: 0 remaining matches (arrow / comma / slash / "to" forms)

Controaudit result

Two adversarial rounds of independent Opus reviewers (each told to break the fix) plus completeness critics. Round 1 confirmed M1/M4/M5/M6/M8 and surfaced genuine residuals: an extract_entry sibling of M2, the M3 anchor not being wired into any shipped surface, a stale-lock reclaim TOCTOU, and comma/"to"-form pipeline-order residue. All were fixed and round 2 re-verified them CLOSED with no regression; the only new items (a Windows triple-race aside-file leak, one AppStream residue) were also fixed. 0 open findings.

A round 3 (2026-06-18) adversarial pass (4 Opus reviewers) then re-verified the M7 convergence (the app's forked standalone EC engine folded onto the crate) and could not refute it: function bodies byte-for-byte identical, the cross-impl golden still byte-for-byte, the M1 fix intact in the single implementation, no forked EC left in the app, and aerocrypt (the separate overlay codec) untouched. 0 correctness findings.

Gates (Windows 11): crate cargo test --workspace 116 lib + integration green (incl. both cross-impl goldens), clippy --workspace --all-targets -D warnings clean, cargo audit clean; app full lib suite 2185 green / 0 failed, lib clippy -D warnings clean, the default-feature lib and the aeroftp-cli bin both build against the converged crate.

Cross-confirmed on Linux (2026-06-18): crate 116 lib + integration green, clippy --all-targets -D warnings clean, cargo audit clean; app lib suite 2223 green / 0 failed / 10 ignored (the 38 over the Windows count are the #[cfg(unix)] tests, including tcp_shutdown, that run on Linux), clippy -D warnings clean. The published crate's own release CI is green on x86_64-linux and x86_64-pc-windows-msvc.

Honest residuals (tracked, not blocking)

• M4: full byte-authentication of the extension directory needs a version-2 header (would break v1 cross-compat); the open-time fail-closed gate bounds it to a clean refusal today.
• M7 (architectural), done and shipped. The app's forked standalone EC engine has been converged onto the crate: the .aerocorrect engine has one audited implementation (crate error_correction), the app's ~3.5k-line fork is deleted and replaced by a logic-free re-export, and an adversarial round-3 controaudit confirmed byte-identical behavior (the cross-impl golden stays byte-for-byte). This is the very duplication that forced the High finding M1 to be fixed twice; the engine is now single-sourced.

Crate to app consumption note

Crate 0.6.2 carries all crate-side fixes (M1 standalone, M2/M4/M6 container) and the M7 convergence (the single .aerocorrect engine plus the new public error_correction::sync API), and is published on crates.io (aerovault 0.6.2 + aerovault-cli 0.6.2, tag v0.6.2). The app now consumes the crate for both its container path (v3) and its standalone / AeroSync error correction; it no longer keeps any forked EC code, and its dependency points at the published 0.6.2 (re-gated green against it). These fixes reach end users in AeroFTP 4.0.7.