Read THREAT_MODEL.md. It states plainly what this app does and does not defend against — including the things no Android app can defend against, like ADB existing or a rooted system reading process memory while the vault is open.

Open a GitHub issue describing the weakness. This is a small open-source project, not a funded security product, and there is no bug bounty.

If the issue would put users at immediate risk if published, mark it clearly and keep the detail minimal in the public issue.

• Anything that recovers plaintext without the user's secret
• Anything that bypasses the lock screen, the decoy blackout, or the idle lock
• Weaknesses in the container format, key wrapping, or key derivation
• Anything that leaks vault contents to another app or to storage outside the vault

• Attacks requiring root or a modified OS. These are documented as out of scope in the threat model, not overlooked.
• Weak user passwords.
• The absence of a recovery mechanism. There is deliberately no way back in without the secret, and adding one would be a vulnerability, not a fix.

The app has no internet permission, so it cannot phone home even if it wanted to — you can verify that in app/src/main/AndroidManifest.xml in thirty seconds. Everything else is short enough to read in an afternoon. Read it before trusting it with anything that matters.