Report security concerns without sending the secret you are protecting

Capture the smallest reproducible, sanitized example

Before preparing a report, identify the affected public route or feature, browser version, approximate date and time, expected behavior, and what actually occurred. Where possible, reproduce with a deliberately synthetic test account or test-only authenticator seed that is not enrolled to any real service. Include a concise sequence of actions that a maintainer could follow without receiving your credentials, personal data, or access to someone else's encrypted Vault.

If an issue concerns unauthorized data exposure, do not continue exploring additional accounts or copy information beyond what is necessary to recognize the problem. Avoid disruptive traffic, persistent access, data modification, service degradation, or attacks on unrelated infrastructure. A read-only observation and a clear description are often more useful for triage than repeated exploitation.

Remove secrets and identities from every attachment

Redact Base32 seeds, complete otpauth setup URIs, migration QR screenshots, raw QR payloads, current verification codes, passphrases, recovery keys, session cookies, OAuth tokens, local storage blobs containing credentials, and decrypted backups. Screenshots should omit account identifiers unless a synthetic identifier is necessary to explain a UI problem. A screenshot that visually resembles a harmless QR may contain an entire long-lived credential.

For network issues, describe the endpoint path, HTTP status, and safe error class rather than copying authorization headers or request bodies. For a possible sync conflict, state the revision behavior with synthetic item identifiers rather than pasting ciphertext tied to a real user. Remove location metadata and unrelated browsing content from attached images or recordings.

Explain severity through practical impact

An effective report says which trust boundary might be crossed: a guest secret appearing in a network request, a logged-in user retrieving another user's encrypted records, an unauthorized session revocation, a QR import accepting unsupported profiles, or a script able to read an unlocked Vault. Describe preconditions and likely effects separately from assumptions about what an attacker could eventually achieve.

Be precise about what you observed. A local reproduction is not proof of a production exploit, and a static code observation is not an executed browser attack. State whether the result is a reasoned hypothesis, a synthetic test, or a directly observed outcome, without claiming independent testing that never occurred.

Use a verified private destination when one is published

Security disclosures should reach an operator-controlled private channel rather than be posted with actionable details in a public comment, repository issue, or social network. The current application materials do not establish a verified public security-reporting address, contact form, legal operator identity, or response service-level commitment. Until an operator-approved destination is published and tested, this page cannot truthfully direct reports to a particular email inbox.

If you encountered an active compromise, prioritize the safety of your affected accounts: secure the Google sign-in, review original website sessions, and rotate any potentially exposed TOTP seeds. Preserve only sanitized evidence. Do not send sensitive material to a guessed address formed by adding a common mailbox name to the website's domain.

Coordinated next steps require an acknowledged contact

Once a real owner-verified reporting channel exists, a responsible exchange can confirm receipt, establish a safe test scope, clarify affected versions, and discuss a reasonable public-disclosure timeline. Those steps require actual communication with an authorized maintainer; they cannot be replaced by a marketing promise or a fabricated security policy. Do not assume permission to run broad vulnerability scans, access private data, or test production accounts solely because a disclosure guide exists.

For issues involving your own ability to generate or restore authenticator codes, first review the troubleshooting and support guides. Those explain error classes and self-help checks without asking for passwords, seeds, current OTPs, or recovery keys. A product-use problem and a vulnerability report may require different evidence and different handling once contact channels are verified.

May I email a screenshot of my Google Authenticator export QR?

No. That QR can reveal long-lived secrets for multiple accounts. Use synthetic data and a redacted description instead.

What is the official 2FASync security inbox?

No operator-verified public security reporting address has yet been established in the reviewed release materials. Do not guess an address from the domain; use a verified channel only when it is published.