Skip to content

[Bug]: sharebymail sends the hashed password instead of the plaintext password in the share-notification email #65926

Closed as duplicate

Description

@davisart

⚠️ This issue respects the following points: ⚠️

  • This is not a troubleshooting question, general support matter, or webserver/proxy problem, but likely a bug (if unsure, ask the Community Help Forum).
  • This issue is not already reported on Github OR solved at the Community Help Forum (I've searched!).
  • I'm using a maintained major version of Nextcloud Server and tested against the latest patch level. (Supported major versions and current patch levels).
  • I agree to follow Nextcloud's Code of Conduct.
  • I've tried my best to provide clear reproduction steps that someone unfamiliar with this bug could use to reproduce it.

Bug description

When creating a share-by-mail with a password set at creation time, the recipient (or the share owner, if "send password by mail" is disabled) receives an email containing what appears to be the
Argon2id hash of the password instead of the actual plaintext password. Example of what is received:
3|$argon2id$v=19$m=65536,t=4,p=1$...$...
This string cannot be used by the recipient to unlock the share.
If the password is instead changed afterwards on an already-existing share, the correct plaintext password is sent correctly in that case.

Steps to reproduce

  1. Share a file via email
  2. Set a password for the share in the same step, during creation
  3. Check the password-notification email received: it contains a hash-like string instead of the password
  4. For comparison: edit the same share afterwards and set/change the password: the email this time contains the correct, usable password

Expected behavior

The password-notification email should always contain the plaintext password, both at share creation and on later password changes

Nextcloud Server version

35

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.5

Web server

Apache (supported)

Database engine version

PostgreSQL

Is this bug present after an update or on a fresh install?

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

  • Default user-backend (database)
  • LDAP/ Active Directory
  • SSO - SAML
  • Other

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    0. Needs triagePending check for reproducibility or if it fits our roadmap35-feedbackbug

    Type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions