AeroFTP follows a defense-in-depth security model across six layers. For the complete architecture with trust boundary diagrams and protocol-level details, see the Security Overview on the documentation site.

All sensitive data (server passwords, OAuth tokens, API keys, application configuration) is stored in an encrypted vault (vault.db) using AES-256-GCM with per-entry random nonces. The vault key is derived via HKDF-SHA256 from a 512-bit CSPRNG passphrase.

The vault never falls back to plaintext storage. File permissions are hardened to 0600 (Unix) / owner-only ACL (Windows).

For the complete credential lifecycle, import/export, and OS keyring integration, see Credential Management.

AeroFTP uses encryption at multiple layers:

Key derivation parameters exceed OWASP 2024 minimums (128 MiB vs 47 MiB, 4 iterations vs 1). AeroVault v2 is available as the standalone aerovault crate on crates.io.

AeroFTP also documents compatibility workflows for existing rclone crypt remotes. This is separate from AeroVault because the format and threat model are defined by rclone, not by AeroFTP.

• AeroVault and the AeroFTP crypt overlay are AeroFTP-native encryption layers
• rclone crypt support is about browsing and decrypting already encrypted rclone-backed storage

See the public docs for details:

• rclone Bridge
• rclone crypt interoperability

For the full encryption architecture, cipher comparison tables, and AeroVault v2 format specification, see Encryption.

AeroFTP supports 7 transport protocols and 20+ native provider integrations with appropriate transport security:

Plain FTP connections display a prominent insecure warning badge. WebDAV supports RFC 2617 Digest Authentication with automatic detection. SFTP uses Trust On First Use host key verification with visual fingerprint dialog and MITM change detection.

AeroAgent (52 tools) operates under backend-enforced security controls:

• Grant system: Mutative tools require a cryptographic grant verified by the Rust backend
• Native OS confirmation: Grant approval triggers an operating system dialog that cannot be bypassed by web frontend compromise or prompt injection
• Credential isolation: AI models never receive raw credentials; the backend authenticates internally
• Shell denylist: 35 regex patterns block dangerous commands
• Path validation: Null bytes, traversal, and system paths blocked at the backend level

For the complete AI security model with grant properties, tool classification, and agent modes, see AI Security.

All release artifacts are signed with Sigstore Cosign via GitHub Actions OIDC keyless signing:

• Client-side verification: The app verifies .sigstore.json bundles against the CI workflow identity before installing updates
• Linux hardening: The privileged update helper re-verifies SHA-256 before executing dpkg/rpm
• Plugin registry: Remote installation disabled until cryptographic registry authentication is implemented (fail-closed)

• Aikido Security: SAST, SCA, secrets detection, IaC scanning - daily automated scans
• Socket.dev: Supply chain SCA monitoring on every push - dependency risk scoring, typosquatting detection
• Snyk: Continuous vulnerability scanning for npm and Cargo dependencies with automated fix PRs

For Sigstore verification commands and CI/CD security controls, see Supply Chain Security.

• zeroize and secrecy crates clear passwords, keys, and tokens from memory after use
• All provider credentials wrapped in SecretString across every provider integration
• Rust ownership model prevents use-after-free and buffer overflows
• Passwords are never logged or written to disk in plain text
• Activity log and UI credential masking: usernames, emails, and access keys are masked at the source (maskCredential) before reaching log entries or display subtitles, preventing accidental exposure in bug reports and screenshots

Optional RFC 6238 TOTP second factor for vault access with exponential rate limiting (5 failures to 15-minute lockout cap). Setup requires initial code verification before enforcement activates.

For the complete TOTP implementation, rate limiting table, and security properties, see TOTP 2FA.

AeroFTP collects no telemetry, sends no analytics, and makes no network requests beyond user-initiated connections. All credential storage is local. No cloud accounts or external services are involved in authentication or settings.

For the complete privacy model, data storage locations, and deletion instructions, see Privacy.

Cumulative: 300+ findings identified across 9 audits, all critical and high findings remediated. For the complete audit history with finding details, see Security Audits.

The March 2026 Aikido Security audit verified compliance against the following frameworks with 0 open issues:

• OWASP Top 10 - injection prevention, XSS mitigation, credential isolation, path validation
• ISO 27001 - encryption controls, access management, credential lifecycle
• CIS Benchmarks - file permission hardening, transport security, supply chain controls
• NIS2 Directive - incident response readiness, supply chain security, encryption at rest and in transit
• GDPR - no telemetry, no analytics, no third-party data sharing, local-only storage, no cloud account required

These are verified compliance checks, not formal certifications.

Do not report security vulnerabilities through public GitHub issues.

Report via GitHub Security Advisories. We respond within 48 hours.

For the full disclosure policy, bug bounty scope, and Security Hall of Fame, see Vulnerability Disclosure.

AeroFTP v3.6.8 - 28 April 2026