What's Changed

This is a security release on the 3.2.4 line. It fixes six advisories. Four of them are places where the per-item restriction was not applied: item history, one-time codes, attachment previews, item details, exports and item creation. The other two concern sessions that survived a password change, and a key generation request that reset the caller's own password without asking for it. The release also updates two Symfony components that had published fixes, makes the import target folder list work for non-admin users again (issue #5446), and moves the pre-upgrade backup of the command-line upgrade to the On-the-fly tab. Upgrading is recommended for all installations.

This release is code only: no ALTER TABLE, no schema change and no new data migration. UPGRADE_MIN_DATE is deliberately left at its 3.2.4.0 value, so installations already running 3.2.4.0 are not sent back through the upgrade wizard.

🔒 Security fixes

• Item history and one-time codes now respect the per-item restriction (GHSA-75qw-h7p8-ppr3, reported by @tsurutanmen, also found by @Artur12555) — the item history and the TOTP code requests only checked that the folder was visible to the user. That check ignores the item's own restriction, and it also lets administrators through on every shared folder. A folder member excluded from an item could therefore read its previous passwords, its previous custom-field values and its current one-time code. Both requests now require read access to the item itself, and a disabled one-time code is no longer served. Every 3.x release before 3.2.4.1 is affected.
• Attachment previews check access to the attachment (GHSA-jxj9-mcx4-h34j) — the image preview only checked that the user held a decryption key for the file. Every user holds one for the attachments of shared items, so any signed-in user could read any shared attachment through the preview. The preview now checks access to the attachment's item before decrypting it.
• Role restrictions apply to the item details and to the exports (GHSA-h66m-8w9q-86r2) — the item details request ignored an item restricted to roles only, and returned its TOTP seed to folder members holding none of those roles. The four export formats checked the user restriction but never the role restriction. Both now apply the same decision as the item card and the REST API. The export handler also enforces the Export permission itself: until now only the Export menu and page did, so any signed-in user could export by posting to the handler directly (see the upgrade notes).
• Creating an item can no longer put a role restriction on another item (GHSA-jgmv-3gr2-fjpw, reported by @Artur12555) — item creation saved its role restriction under the item id sent by the browser instead of the id of the item it had just created. Any user allowed to create an item could therefore add role restrictions to any existing item: hide an item from the users who rely on it, or give their own role access to an item restricted to other users. The restriction is now attached to the new item. Every 3.x release before 3.2.4.1 is affected.
• A password change now ends the sessions opened before it (GHSA-p84q-3h9h-qvh6, reported by @wyx200612) — the password change dialog, the e-mail password recovery and an administrator's key generation for another user all replaced the password but kept the existing web session and API sessions valid. A copied session cookie kept working after the change, and after a change made in the dialog it still decrypted the user's items. A change made by the user now renews the session id of the current browser and revokes the account's API sessions. A recovery, or a key generation by an administrator for another user, ends every session of the account. The session extension, which had no upper limit, is now capped at the maximum session duration set by the administrator.
• Key generation no longer replaces your own password without the current one (GHSA-2vf9-2qw7-8hmr) — the key generation request, sent without a target account and asking for a generated password, reset the caller's own password without checking the current one, then returned the new password. Anyone holding the session, for instance through a stolen cookie or an unattended browser, could take the account over. A generated password is now only issued for another account the caller manages. On the caller's own account the current password is always checked, and the older profile password change does the same before writing anything. Releases from 3.1.2 to 3.2.4.0 are affected.
• Symfony components updated to 6.4.49 — symfony/http-foundation fixes a ReDoS reachable through the Cache-Control request header (CVE-2026-108082, GHSA-r925-mgvr-h9cc). symfony/mime fixes an e-mail header injection through non-token characters in parameter names (CVE-2026-45070, GHSA-vqc8-7275-q272).

🛠️ Improvements

• The command-line upgrade keeps its pre-upgrade backup in the On-the-fly tab — the backup taken by app/scripts/upgrade-cli.php was stored as storage/backups/scheduled-pre-upgrade-*.sql, where the retention of scheduled backups could delete it. It is now written to storage/onthefly/pre-upgrade-*.sql, listed under Administration → Backups → On the fly, and kept until an administrator deletes it. It is still encrypted with the instance key: a key icon flags it, and it restores without typing a decryption key. Backups taken by 3.2.4.0 (scheduled-pre-upgrade-*) stay in the Scheduled tab.

🐛 Bug fixes

• Non-admin users got an empty target folder list when importing from another password manager (issue #5446, reported by @Tenta-dev) — the Bitwarden, LastPass, 1Password and KeePassXC importers share one target folder list, and that list was never filled for non-admin users, who could not import. Administrators were not affected. The server-side folder write check was already in place, so this had no security impact.
• A role restriction chosen when creating an item is saved again (issue #4715) — on PHP 8 the role restriction set in the creation form was never stored: the save failed after the item itself was created. The fix of GHSA-jgmv-3gr2-fjpw also resolves this.

⬆️ Upgrade notes

• Schema. No schema change. Installations on 3.2.4.0 are not sent through the upgrade wizard. Installations on an earlier line go through it as usual.
• Exports follow the Export permission on the server. The export handler now applies the rule of the Export menu (Settings → Options: exports enabled, and the user holds one of the allowed roles). Administrators and users without an allowed role are refused, including scripts that posted to the handler directly. Exports also leave out the items restricted to roles the user does not hold, so an export can contain fewer items than before.
• Items created with a role restriction before 3.2.4.1 have none. The restriction chosen in the creation form was never saved (see the bug fix above). Owners who rely on it should set it again from the edit form.
• Password changes sign other sessions out. After a user changes their password, any copy of their previous session cookie stops working, and API clients such as the browser extension sign in again. A password recovery, or new keys generated by an administrator, signs the user out everywhere. A session can no longer be extended beyond the maximum session duration.
• Back up your database before upgrading, as always.

Full Changelog: 3.2.4.0...3.2.4.1

Important

• Requires at least PHP 8.2

Languages

Please join Teampass v3 translation project on Poeditor and translate it for your language.

Installation

Follow instructions from Documentation.

Upgrade

Follow instructions from Documentation.

Ideas and comments

Are welcome ... please use Discussions.

Help others find TeamPass

If TeamPass serves your team well, a ⭐ on this repository, a like on AlternativeTo or a short review on SourceForge helps other administrators find it.