Important: please report any potential security issues to the email below rather than opening public issues.

--

Security is very important to us. We truly appreciate the security community and responsible researchers who report issues, your findings help us improve AliasVault for everyone.

We investigate all reported issues and work with researchers on responsible disclosure. Certain vulnerabilities, especially those impacting confidentiality, integrity, authentication, or core protection mechanisms, may qualify for a CVE (Common Vulnerabilities and Exposures) identifier. Others may still result in fixes or defense-in-depth improvements.

During the public beta we only support the latest major and minor release. On the current 0.x line, that means the latest minor only. Security fixes are only applied to the latest supported version: make sure to upgrade frequently to stay supported.

Email: security@aliasvault.com

Please include:

1. Description of the issue
2. Steps to reproduce
3. Affected component(s)
4. Security impact (what an attacker could achieve)
5. Prerequisites for exploitation
6. Suggested remediation (optional)

We acknowledge reports within 48 hours. Please do not publicly disclose issues before coordinated resolution.

We value good-faith security research and review every report, even those that do not qualify for CVE assignment. Reports classified as Class 2 or Class 3 (see below) may still result in fixes or defense-in-depth improvements in future updates. We will credit reporters where applicable (with permission) when fixes are released.

---

AliasVault is a zero-knowledge, end-to-end encrypted password and email alias manager.

Note: We only request CVEs for vulnerabilities that breach the encryption/access control boundary (defined in Section 2.1). Post-compromise scenarios — issues that assume an attacker has already compromised the user's device, runtime environment, or account through external means — are not considered CVE-worthy, though we may still address them as defense-in-depth improvements.

The primary security boundary (also referred to as the encryption/access control boundary) in AliasVault is the end-to-end encryption and access control layer that protects user secrets. Concretely, this boundary guarantees that only authorized users can decrypt or access their vault secrets.

• Vault data is encrypted client-side using keys derived from the user's master password.
• The server never has access to plaintext vault data.
• Network interception, server compromise, or API token leakage must not expose decrypted secrets.

A vulnerability is considered a Class 1 security boundary failure if it allows crossing this boundary without the user's informed and specific authorization of the relevant device, session, or security-sensitive operation.

---

The following represent device compromise scenarios and are outside AliasVault’s primary security boundary:

• Rooted or jailbroken devices
• Kernel-level or runtime instrumentation (Frida, Xposed, debuggers)
• Malicious accessibility services
• Memory dumping of a running process
• Forensic extraction of device storage or backups
• Malware operating with equivalent privileges to the user

AliasVault implements defense-in-depth protections in these areas, but issues that require these conditions are classified as local hardening, not core security boundary failures.

---

This section defines how reported issues are categorized.

---

Class 1 issues are considered eligible for CVE assignment under AliasVault's vulnerability disclosure policy. These represent vulnerabilities that breach AliasVault's encryption/access control boundary (see Section 2.1).

A report must:

• Affect a released version on the supported release line
• Be reproducible
• Have a concrete security impact
• Not depend on full device compromise

• Recovery of plaintext vault data without the master password
• Key derivation or encryption flaws weakening confidentiality
• SRP (Secure Remote Password) implementation flaws enabling credential recovery or offline password attacks

• Access to another user’s vault or metadata
• Privilege escalation
• Authentication bypass
• Flaws in client or session validation in authentication flows (e.g., passkey or token verification bypass)

• Remote code execution from malicious input
• Injection leading to cross-user data access (e.g., XSS, SQL injection, or similar attacks that result in cross-tenant data exposure)
• Server-side request forgery (SSRF) reaching internal or restricted systems

• Decrypted secrets exposed via logs, APIs, or unintended channels
• Server-side plaintext exposure
• Backend returning sensitive internal resources to an attacker

---

These are security improvements but not typically CVE-eligible. Such issues may still be addressed in future updates as defense-in-depth improvements, even though they typically will not receive a CVE or security advisory.

Issues that only arise or can only be exploited after an attacker has fully compromised the user's device or runtime environment. For example, issues requiring:

• Root/jailbreak
• Runtime instrumentation
• Memory inspection of a live process
• OS-level data extraction

Social engineering or phishing attacks where the application accurately presents the security-sensitive action and its material consequences, and the user intentionally approves that action, are out of scope for CVE assignment.

This exclusion does not apply where an application flaw causes the approval UI to misrepresent, obscure, substitute, or fail to bind the action being approved to the action actually performed.

• Clipboard clearing
• Screen recording protections
• Autofill edge cases
• UI redaction improvements

• Token leakage that does not allow vault decryption
• Metadata visibility inherent to system design

• Speculative attack chains
• No working proof of concept
• Attacks requiring unrealistic assumptions

---

These are not treated as security vulnerabilities.

• UI inconsistencies
• Logic errors without security impact

• Social engineering
• User misconfiguration
• Third-party service compromise outside AliasVault control

• Missing HTTP headers without exploit path
• Rate-limit suggestions
• Denial-of-service without data compromise

---

We will request or pursue a CVE ID only if an issue meets all of the following criteria:

1. The issue impacts confidentiality, integrity, or authentication
2. It crosses the encryption/access control boundary without the user's informed and specific authorization of the relevant device, session, or security-sensitive operation (as defined in Section 2.1)
3. It affects a released version
4. It is reproducible
5. It does not rely on full device compromise

CVE eligibility also requires that the issue does not fall within an out-of-scope category defined in Sections 3.3 or 5.

Issues that do not meet these criteria will still be reviewed and may result in fixes, but they will be announced as regular updates rather than security advisories and are tracked as hardening or quality improvements. Every report is valued regardless of classification.

---

In scope:

• AliasVault server (API, Admin, SMTP)
• Web client
• Browser extensions (Chrome, Firefox, Edge, Safari)
• Mobile apps (iOS, Android)
• Core cryptographic libraries

Out of scope for CVE assignment by this project:

• Third-party dependency CVEs: the upstream maintainer or a central authority is responsible for issuing CVEs for their own code; AliasVault will promptly upgrade dependencies or apply patches when such issues arise
• Device OS vulnerabilities
• Hardware compromise
• Phishing, social engineering, or other attacks that rely solely on deceiving the user rather than exploiting the application, except where an application flaw misrepresents, obscures, substitutes, or fails to bind the security-sensitive action being authorized, as described in Section 3.2.2

---

Stage	Target
Acknowledgment	48 hours
Initial assessment	7 days
Fix & release goal	30 days

These are target timelines; complex issues may require adjustment in coordination with the reporter. We follow coordinated disclosure.