mSecure 7.1.0
Technical Security Report

1. Executive summary

Yes. The examined mSecure build contains weaknesses that make plaintext exposure of mSecure Cloud vault contents possible after a server-side incident. The implementation does not provide robust zero-knowledge protection against a compromised or malicious server.

The most important confirmed facts are:

1. The mSecure Account Password is transmitted to mSeven's server. During ordinary sign-in, it is placed in the query string of an HTTPS GET request. TLS protects the request on the network, but the plaintext password is available to the service and may be exposed through URL/request logging.
2. The app also transmits the Account Password-encrypted Account Key to a Parse Cloud function named generatePdfForKey. A system retaining both the Account Password and this encrypted key can recover the Account Key offline and then decrypt an mSecure Cloud vault.
3. The Account Key itself is generated using C's deterministic random(), seeded with srandom(time(NULL)), rather than a cryptographically secure random-number generator. This substantially undermines the claimed strength of the 46-character Account Key.
4. Password-based wrapping uses 10,000 PBKDF2-SHA1 iterations, which is weak by contemporary standards for offline password guessing.
5. Changing the Account Password does not rotate the Account Key or re-encrypt the vault in the examined build.
6. Record contents are encrypted before upload, but several sensitive metadata fields—including login URLs, app names, tags, template names, and device names—are uploaded as ordinary Parse values.

These findings establish credible exposure paths. mSeven's subsequent support email confirms that an unauthorized actor acquired an encrypted database belonging to current and former mSecure Cloud users, but there is still no public confirmation that vault plaintext was accessed or decrypted. The exact database contents, incident timeline, and any exposed authentication/key material remain undisclosed.

Until mSeven publishes a technically specific incident report and corrective release, users should treat cloud-synchronized vaults as potentially compromised and should not regard merely changing the mSecure Account Password as sufficient remediation.

2. Artifact identification and provenance

The following artifact was examined:

The valid signature and Mac App Store assessment establish that the bundle is an authentic signed distribution artifact, not an obviously modified local copy. They do not establish that its security design is sound.

3. Incident background and communication history

3.1 Initial notice and absence of public answers

mSeven's initial notice, as quoted by CyberInsider, stated that the company had learned of “suspicious activity associated with the mSecure password management application,” begun an investigation, taken mitigation steps, and engaged external cybersecurity experts. It recommended protecting confidential information, potentially by changing passwords, resetting or re-enrolling two-factor authentication, and removing passkeys.[1]

The initial notice did not publicly identify the affected systems, incident timeline, data involved, or affected synchronization configurations. It also did not say whether the recommendations were precautionary or based on confirmed exposure.

The following two mSecure support-discussion pages were reviewed during the initial assessment:

• Important Security Notice Nov 3, 2026 — page 3
• Important Security Notice 2026-11-03 — page 5

At capture time, these pages contained numerous customer questions and complaints but no visible substantive mSeven staff response on the reviewed pages. Commenters expressly noted the absence of official acknowledgement, clarification, or status updates. This observation describes the reviewed pages at that time; it does not prove that mSeven had ceased operations or that any forum theory was correct.

3.2 Follow-up email confirming encrypted-database acquisition

A subsequent mSeven support email with the subject Re: Data breach was sent on 2026-11-04 at 06:49:18 UTC. Its headers record DKIM, SPF, and DMARC passes for msevensoftware.com, supporting its authenticity as a message from mSeven's support system. These authentication results validate the sending domain, not the accuracy or completeness of the message's technical claims.[10]

The follow-up materially updates the incident history by stating that:

• “Yesterday,” mSeven learned that an unauthorized actor had acquired an encrypted copy of a database containing information belonging to current and former mSecure users;
• mSeven had no evidence that the actor had accessed the confidential information stored within that database;
• The issue only pertains to users who were synchronizing with mSecure Cloud;
• mSeven continued to recommend changing the master password and vital stored passwords, resetting 2FA, replacing passkeys, and protecting other sensitive information;
• mSeven had taken unspecified steps to bolster security and had “no evidence that mSecure is not currently safe for use.”

This message narrows the stated affected population to mSecure Cloud users and confirms acquisition of an encrypted database. It does not establish that the database cannot be decrypted. An attacker can retain and attack the stolen copy offline without generating further server-side evidence.

The follow-up leaves important technical questions unanswered, including:

• The database schema and whether it includes userHeuristicsKey or other encrypted Account Key material;
• Whether Account Passwords, Account Keys, encrypted Account Keys, session tokens, URLs, request bodies, or logs were exposed;
• The exact incident timeline and affected systems;
• Which security controls were changed, and whether the PRNG, KDF, and key-rotation weaknesses identified in this report were addressed; and
• How mSeven determined that the application remains safe for newly rotated credentials.

Accordingly, the follow-up changes the known incident facts but does not alter the report's binary findings F-01 through F-07. The report's earlier observation about the absence of public answers should be read together with this later, more specific support email.

4. Scope and limitations

4.1 Work performed

• Verified the application version, hash, entitlements, code signature, and Gatekeeper status;
• Inspected embedded strings, Objective-C metadata, symbols, and imported cryptographic/network APIs;
• Disassembled and decompiled relevant account, authentication, encryption, backup, and synchronization routines;
• Traced Account Password, Account Key, encrypted Account Key, vault record, and metadata flows;
• Checked the public cloud endpoint's HTTP/HTTPS behavior without using real credentials;
• Reviewed mSeven's public security documentation, Heroku's router-logging documentation, the RNCryptor v3 specification, and the German BSI's password-manager study.

Tools used included macOS codesign, spctl, plutil, otool, nm, and strings, plus Rizin 0.9.1 and Ghidra 12.2. Temporary analysis files were removed after the review.

4.2 Limitations

• This was a focused review, not an exhaustive audit of every feature, bundled library, extension, or platform.
• No real mSecure account or user password was used.
• No live authenticated login, account creation, or vault synchronization was performed.
• No server-side configuration, Heroku feature flags, Parse Cloud Code, application logs, router logs, databases, or incident-response evidence was available.
• No user CSV or mSecure backup exports were opened or read during the review.
• The findings directly describe the examined macOS 7.1.0 (1127) build. The separate BSI finding describes Android 6.1.5. Neither result should automatically be generalized to every historical or current platform release.
• Absence of an identified plaintext-upload path for a particular field is not a guarantee that no such path exists elsewhere in the application.

5. Expected security architecture

mSeven's public security model states that:

• Vault information is encrypted locally before leaving the device;
• A randomly generated 46-character Account Key encrypts the data;
• The Account Key is not stored on mSeven's servers or transmitted in readable form;
• The Account Password protects the Account Key; and
• mSeven cannot access customer information.[4] [5]

A useful zero-knowledge design must remain safe when the server is compromised. In particular, the server should not receive both:

1. A vault-decryption key or its password-encrypted wrapper; and
2. The same password needed to unwrap it, or a practical way to guess that password/key.

The reviewed implementation fails that requirement in several ways.

6. Detailed findings

time(NULL) -> srandom(...) -> random() -> GeneratePassword -> Account Key

7. Combined attack paths

7.1 Server/log compromise with retained authentication and QR-generation data

A technically viable chain is:

1. Obtain Account Passwords from authentication processing or URL/request logs.
2. Obtain encryptedKey values from Parse Cloud Code processing, application logs, or other retained request data.
3. Decrypt the Account Key offline using the Account Password.
4. Obtain the encrypted mSecure Cloud records.
5. Decrypt record fields, notes, TOTP secrets, attachments, and passkey material using the Account Key.

This path does not require breaking AES-256. It follows from the credentials and key material made available to the service by the client design.

7.2 Ciphertext-only offline PRNG attack

Even without plaintext Account Password logs:

1. Obtain the cloud heuristics ciphertext and encrypted vault data.
2. Estimate account-creation time and candidate PRNG call positions.
3. Generate Account Key candidates from time-seeded random() output.
4. Test candidates against the known plaintext protected by heuristics.
5. Use a recovered Account Key to decrypt the vault.

Feasibility depends on information available to the attacker and implementation-specific PRNG state uncertainty. The fundamental issue is that the key space is based on predictable PRNG state rather than cryptographic entropy.

7.3 Weak-password offline attack

1. Obtain an encrypted Account Key from QR-generation traffic, a backup, or another store.
2. Use the embedded salts and HMAC to test password guesses at 10,000 PBKDF2-SHA1 iterations per candidate.
3. Recover the Account Key and decrypt associated vault data.

A long, unique Account Password materially increases the cost of this attack; it does not correct F-01 or F-03.

7.4 Metadata-only exposure

A database breach limited to ordinary Parse fields can expose login URLs, tags, app names, template names, and device names without any cryptographic attack.

8. Positive controls verified

The review also confirmed several controls that should not be overlooked:

• The app bundle has a valid Apple/Mac App Store signature.
• The configured production Parse endpoint uses HTTPS.
• Record field payloads, notes, and passkey JSON have dedicated encrypted-data paths before cloud upload.
• RNCryptor uses AES-256-CBC with HMAC-SHA-256.
• Encryption salts and IVs use SecRandomCopyBytes.
• The plaintext Account Key was not directly inserted into the examined Parse user object.

These controls reduce some risks but do not eliminate the combined credential/key-exposure paths described above.

9. Independent corroboration: German BSI study

Germany's Federal Office for Information Security (BSI) evaluated mSecure 6.1.5 for Android, released on 23 April 2024, in its December 2025 password-manager study.[8]

The BSI reported:

• “Access is theoretically possible while the device is in use.”
• “Technical information is sent to the manufacturer, enabling them to access the contents of the password manager.”
• “Overall, the concept does not meet the usual expectations for password managers.”
• mSeven responded that it did not store the secrets transmitted to it.
• mSeven did not respond to the BSI's technical questions.

The BSI's version and platform differ from the artifact examined here, so this is corroboration rather than direct proof about macOS 7.1.0. The independent binary review presented here establishes that the underlying server-compromise concern remains technically relevant to the examined Mac build.

10. Incident-risk assessment

Overall conclusion: mSecure Cloud data must be regarded as meaningfully at risk, not as inherently safe merely because it is described as encrypted. Acquisition of the encrypted database is confirmed by mSeven; actual plaintext compromise remains unconfirmed.

11. Recommended user actions

11.1 Immediate priorities

1. Do not rely solely on changing the mSecure Account Password. The examined build does not rotate the Account Key.
2. Rotate the most consequential stored credentials first:
   • Primary and recovery email accounts;
   • Apple, Google, Microsoft, and other identity providers;
   • Banking, payment, and financial services;
   • Domain registrars, DNS providers, hosting, and cloud administration;
   • Password-manager recovery accounts and administrator accounts.
3. Re-enroll two-factor authentication secrets stored in the vault. Changing a site's password does not replace its TOTP seed.
4. Remove and recreate passkeys stored in mSecure, following each service's official procedure.
5. Continue through remaining stored credentials according to sensitivity and reuse.
6. Use official apps or manually entered official websites for rotations. Be alert for follow-up phishing that exploits the public incident.

11.2 Vault migration

• Prefer migrating to a different, well-reviewed password manager until mSeven supplies a technical explanation and corrective release.
• Creating a new mSecure account may generate a different Account Key, but in this build the replacement key would still use the time-seeded PRNG; therefore, account creation alone is not a complete technical remedy.
• Verify imported records before deleting the old vault.
• Preserve a secure, offline backup during migration.

11.3 Export and backup files

Plaintext CSV exports should be stored only with strong protection and securely deleted after a successful migration has been verified.

Treat mSecure backup files as highly sensitive. The reviewed backup serialization includes the password-encrypted Account Key.

12. Questions mSeven should answer publicly

Incident scope

1. Which systems, versions, platforms, and synchronization methods were affected?
2. When did suspicious activity begin, and when was it contained?
3. What exact records, database fields, and encryption/key material did the confirmed exfiltrated database contain?
4. Were Account Passwords, Account Keys, encrypted Account Keys, session tokens, QR data, or Cloud Code parameters accessed?
5. Are the recommendations precautionary, or based on confirmed exposure?

Logging and infrastructure

6. Was Heroku http-router-no-log-query enabled for every production app serving mSecure authentication?
7. Were full URLs, query strings, request bodies, or Cloud Code parameters logged by Heroku, Parse, Express, monitoring tools, support tools, or log drains?
8. Were generatePdfForKey parameters or generated QR/email artifacts retained? For how long, and by whom?
9. Which subprocessors could access authentication and QR-generation request data?

Cryptography and remediation

10. Why does Account Key generation use random() seeded with time instead of SecRandomCopyBytes or another CSPRNG?
11. Will mSeven migrate password wrapping to a modern, appropriately configured KDF?
12. Will password changes support actual Account Key rotation and vault re-encryption?
13. Can users create a genuinely fresh vault/key and invalidate all older key material?
14. Which releases fix these implementation issues, and have those fixes been independently audited?

13. Final conclusion

The examined mSecure 7.1.0 macOS build has multiple, independently confirmed weaknesses:

• Passwords in GET URLs;
• Password-encrypted Account Keys sent to the service;
• Time-seeded, non-cryptographic Account Key generation;
• A low-cost legacy KDF;
• No Account Key rotation on password change; and
• Cleartext cloud metadata.

The most severe issue is architectural: the service can receive both the password and the encrypted key needed to recover vault contents. A separate weakness allows offline prediction attempts against the Account Key itself. Consequently, mSeven's zero-knowledge assurances should not be relied upon as protection against a compromised production service.

mSeven's follow-up email confirms that an unauthorized actor acquired an encrypted mSecure Cloud database, while stating that there is no evidence of confidential-information access. That narrows the stated affected population to mSecure Cloud users but does not demonstrate that the stolen ciphertext is undecryptable or that the weaknesses documented here have been fixed. Credential rotation, 2FA/passkey replacement, and migration away from the affected vault therefore remain prudent risk-reduction measures. Merely changing the mSecure Account Password does not rotate the Account Key or protect the stolen copy.