What's Changed

This is a security release on the 3.2.4 line. It fixes six advisories. Four of them are places where a manager or HR manager could act beyond the accounts and folders they administer: folders granted to an account, the root-folder creation right, the folder rights of any account, and the Users list, which plain users could also read. The other two are a folder path returned for any folder id, and administration actions that did not check the session key. The release also makes generic OpenID Connect providers such as authentik and Keycloak work (PR #5445), lets OAuth2 users generate new keys again, and fixes an LDAP first login that ended with an HTTP 500 (issue #5451) and a command-line upgrade that lost its database connection (issue #5450). Upgrading is recommended for all installations, and strongly recommended for those where managers or HR managers administer accounts.

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 or 3.2.4.1 are not sent back through the upgrade wizard.

🔒 Security fixes

• Managers and HR managers can only grant folders within their own scope (GHSA-vrhq-38vx-9vjp, reported by @fernandobortotti) — account creation, the user edit form and the rights propagation limited the roles to the caller's scope, but stored the Allowed folders and Forbidden folders exactly as the browser sent them. A folder granted directly gives write access, and a new account receives a key for every shared item, so a manager could create an account, grant it any shared folder and read that folder's items through it. For a non-administrator, both lists are now reconciled with the caller's own accessible folders, minus personal folders and the folders denied to the caller. A folder outside that scope is dropped. A folder already on the account is kept, so saving the form never revokes it. Every 3.x release before 3.2.4.2 is affected.
• Every administration action requires the session key (GHSA-7wvw-wxqx-v364, reported by @carfeii) — ten administration requests never compared the key sent with the request against the session key. Four of them change something: enabling or disabling the REST API, deleting logs older than 90 days, and starting or stopping the WebSocket server. The other six only read data or write a log line. A forged request carrying only an administrator's cookie could trigger them. The session cookie is SameSite=Lax, so the attacker needs a same-site position. Each action now refuses a missing or wrong key first, like the rest of the handler, and a test checks every action of the handler so a new one cannot skip the check. Every 3.x release before 3.2.4.2 is affected.
• The Users list is limited to users who may open the Users page (GHSA-5cwc-6hfp-2mr7, reported by @Artur12555) — the request that fills the table of the Users page checked the Items page right, which every user holds. A plain or read-only user holding a role that administers other accounts could list those accounts: last IP address, MFA, lock and passkey state, privilege level and roles. Sorting on hidden columns also let them work out colleagues' e-mail addresses. The request now checks the Users page right, and only the displayed columns can be sorted. Every 3.x release before 3.2.4.2 is affected.
• The folder rights of an account are only shown to the people who administer it (GHSA-28mq-vx4v-72h8, reported by @Artur12555) — the folder-rights view of the Users page read its target account from a field the generic target check never looked at. A manager or HR manager could therefore read the folder-rights map of accounts they do not administer: folder titles, the access level on each folder, the roles granting it, and the account's login and name. The target is now checked like every other user administration request, and an unknown account is refused.
• Only administrators grant the root-folder creation right (GHSA-57ww-wx2c-hx7x, reported by @Artur12555) — the rights propagation copied the source account's Can create root folder flag to every destination, and its check on privileged flags left that one out. A manager or HR manager could therefore give root-folder creation to the accounts they administer. When a non-administrator propagates rights, each destination now keeps its own flag. Account creation clears the flag whenever the creator is not an administrator, where a creator holding the right could previously grant it. The user edit form was already administrator-only. Every 3.x release before 3.2.4.2 is affected.
• The folder list no longer returns the path of a folder you cannot access (GHSA-5mff-6g7v-9v6v, reported by @fernandobortotti) — the request that lists the items of a folder built the folder's path before checking access, and returned it along with the refusal, for any folder id. Any signed-in user could read the title and full path of every folder, including forbidden folders and other users' personal folders. The path is now returned only when one of the user's folders lies below the requested one, which is the greyed-out ancestor the folder tree already shows. Any other folder gets an empty path. Every 3.x release before 3.2.4.2 is affected.
• Account creation checks the administrating role — a manager creating an account could set its Administrated by role to any role. It must now be a role the caller may grant, as the user edit form already required.

✨ New features

• Generic OpenID Connect providers (authentik, Keycloak…) (PR #5445, @Silver-Golden) — TeamPass uses its generic OpenID Connect client whenever the Authorization Endpoint of the OAuth page is not a login.microsoftonline.com address. That client sent the scopes comma-separated, which providers reject, so in practice only Microsoft Entra ID worked. The scopes are now space-separated, and the claims returned by the provider are mapped: sub and preferred_username are required, email and the names fill a new account, and groups and Keycloak realm roles are matched against role titles. A provider that omits a required claim is refused with a message naming it. The authentication documentation has a new generic provider section, with an authentik walk-through and the rules to follow on the provider side.

🛠️ Improvements

• Chinese and German translations updated — 489 Chinese strings translated on POEditor, which 3.2.4.0 and 3.2.4.1 did not carry yet, now ship with the release, along with 3 German ones. Every language file now carries all the strings of the English file. The strings nobody has translated yet still display in English, as before.

🐛 Bug fixes

• OAuth2 users could not generate new keys or rebuild their keys — the Generate new keys and build keys dialogs computed the account's key password from a browser value that is removed during the sign-in. Every OAuth2 account, Microsoft Entra ID included, sent the same constant and was refused with "bad credentials". The server now derives that password from the identity kept in the session, for the signed-in account only.
• An LDAP account without a key pair got an HTTP 500 at its first login (issue #5451, reported by @Javimix5) — an account written into the users table without encryption keys, typically by an external directory sync, had no private key to load, and the login stopped on a PHP type error. The login now generates the keys of such an account as it does for a new one: the user is told the keys are being generated and signs in again a moment later, and the key generation also gives the account access to the shared items.
• The command-line upgrade failed with "MySQL server has gone away" after a long backup verification (issue #5450, reported by @jawierG) — with a low wait_timeout, the database closed the idle connection while the backup was being verified. The first query of the verify phase failed, the automatic revert failed on the same connection, and the run was left revert_failed although every upgrade step had succeeded. The script now reconnects after 10 seconds of inactivity. An unexpected error during verification leaves the run resumable, where resume runs only the verification again, instead of reverting a complete upgrade. A revert that never started no longer marks the run revert_failed.

⬆️ Upgrade notes

• Schema. No schema change. Installations on 3.2.4.0 or 3.2.4.1 are not sent through the upgrade wizard. Installations on an earlier line go through it as usual.
• Manager and HR manager grants. Existing grants are left as they are, and the upgrade revokes nothing. From now on, a folder outside the caller's scope is silently dropped when a manager saves an account or propagates rights, and non-administrators can no longer give the Can create root folder right. Administrators may want to review the folders and rights that managers granted on earlier versions.
• Generic OpenID Connect provider. Set Scopes to openid,profile,email on the OAuth page: the default value holds Microsoft-specific scopes. Before opening the access, read the provider-side rules in the authentication documentation. Usernames must be controlled by the provider's administrators, because at the first SSO sign-in an existing local or LDAP account whose login matches preferred_username is switched to OAuth2.
• Back up your database before upgrading, as always.

Full Changelog: 3.2.4.1...3.2.4.2

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.