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 ch

What's Changed

This release opens the 3.2.4 line. It adds a command-line upgrade that backs up the database, runs the upgrade in maintenance mode and restores the backup if a step fails. The item view and the item edit form are redesigned: one page with foldable sections, a sticky action bar, an icon picker and tags edited as chips. Users get an inventory of their active Secure Send links, and administrators are reminded to save a Recovery Package. The release also fixes folder, favourite and Knowledge Base names stored with HTML entities (O'Brien instead of O'Brien), makes searches match the displayed text again, and repairs several upgrade paths: maintenance mode in the web wizard, the data clean-ups in Docker, and background tasks that ran against an older schema. It closes a High severity flaw that let a session opened on the installer before the setup rewrite settings.php on a live instance (GHSA-6x8j-28p6-mmfm), and several HTML injection and information disclosure paths in the item view, the tag suggestions and the command palette. Upgrading is recommended for all installations, and strongly recommended for instances installed with 3.2.3.1 to 3.2.3.3: delete or lock down their public/install directory if it is still reachable.

This release does not change the database schema: no new table, no new column, no data migration. UPGRADE_MIN_DATE keeps its 3.2.3.3 value. Because the version moves to a new line (3.2.3 → 3.2.4), every installation still goes through the upgrade once, through the web wizard, the new command line or the Docker entrypoint. The upgrade only records the new release.

🔒 Security fixes

• The installer no longer accepts a pre-install session after the setup (GHSA-6x8j-28p6-mmfm, High, reported by @kta1kri) - on instances installed with 3.2.3.1 to 3.2.3.3, a session opened on install.php before the setup finished kept every installer step usable after go-live, including the one that rewrites app/config/settings.php: someone holding such a session could point the instance at their own database or replace its encryption key. Once settings.php exists, the steps now refuse every install session except the one that wrote it, which may only finish step 6 while the file is unchanged. The install grant is revoked when the installation completes, and the key file name written into settings.php must be a plain file name. Upgraded instances were never exposed. The advisory lists indicators of compromise.
• Tags can no longer run script in the item view - the tag badges were built as HTML with an inline onclick handler, so a crafted tag ran script for every user opening the item. They are now built as text, and the click handler is bound in JavaScript.
• Knowledge Base labels are rendered as text in the item view - a double-encoded label survived the server-side purifier and was turned back into live markup by the client decoding. The chips are now built with text-only DOM operations, as the tags and the Knowledge Base page already were.
• Tag suggestions only offer the tags of items the user can read - the tag field of the item form suggested every tag of the instance, which revealed the tags of folders and items the user has no access to.
• The command palette no longer reveals the names of inaccessible parent folders - the path shown next to a result listed every ancestor folder, including folders the user cannot see. Only folders within the user's search scope are now shown (PR #5444, @guerricv).
• Knowledge Base item suggestions respect item restrictions - linking an item to an article offered items restricted to other users or roles in folders the user can see (PR #5444, @guerricv).

✨ New features

What's Changed

This is a maintenance release on the 3.2.3 line. It fixes an attachment authorization flaw (GHSA-r6r4-5mr3-rppm), several upgrade paths that stopped or silently skipped migrations (2.x → 3.x wizard, the 3.1.5 unique index, Docker images coming from 3.2.2.6 or earlier), and an unusable TP account key that silently left users without access when their keys were generated. It also ships two contributions from @guerricv: disaster recovery onto a fresh server, and experimental QR pairing for external devices (off by default). Upgrading is recommended for all installations.

This release changes the database schema. UPGRADE_MIN_DATE is raised, so every installation goes through the upgrade wizard once. Docker containers apply the upgrade on their own at start-up.

🔒 Security fixes

• Attachments now require the edit right, and a new item only receives the files its own session uploaded (GHSA-r6r4-5mr3-rppm, reported by @NotAFlightRisk) — deleting an attachment only checked that the folder was visible to the user, which read-only folders grant: a read-only member could permanently delete any attachment in the folder, including those of items restricted to others. Triage found a more severe flaw in item creation: new_item attached every file stored under the staging identifier sent by the browser, so a user could move another item's attachments onto an item of their own and read them. Uploads are now recorded in the user's session, and creating an item or confirming attachments only takes the files that session uploaded. The upload refuses a staging identifier that designates an existing item, and checks the edit right whenever it targets an existing item. Every 3.x release before 3.2.3.3 is affected.

✨ New features

• Disaster recovery on a fresh server (PR #5439, @guerricv) — a new installer assistant (/install/recovery.php) and its CLI (app/scripts/disaster-recovery.php) restore a complete encrypted .tpbackup and its original .tprecovery Recovery Package without running a normal installation first. The assistant imports into an empty dedicated database and verifies the original key chain and document references. It then replays the shipped 3.2.2/3.2.3 migrations in isolated processes and checks item decryption. Only after that does it publish a newly generated configuration, in maintenance mode. The operator is then guided through file permissions, installer removal and scheduler restoration. Restored sessions, tokens, device credentials and Secure Send links are invalidated, and backup schedules and LAPR stay disabled until an administrator reviews them. Supported sources: 3.2.2.x and 3.2.3.x, complete backups taken with Include documents, no downgrade. Read the Disaster recovery guide, and rehearse a restore before you need one.
• Experimental QR pairing for external devices (PR #5437, @guerricv) — off by default, enabled in Settings → API → Mobile application. Once it is on, a user pairs a compatible client from the External devices tab of their profile. The QR code only carries the instance URL and a short-lived invitation; the user compares a six-digit code on both screens and approves the exact device, and a dedicated Personal Access Token is then delivered encrypted to the device's ephemeral key. Device credentials expire (90 days by default) and each one can be revoked by its owner. Administrators can inspect and revoke them from the same settings tab, and revoking a credential ends its API sessions. Pairing requires HTTPS. No client is published yet: the feature targets client developers, with the protocol in [docs/api/device-pairing.md](https://documentation.teampass.net/#/api/dev

What's Changed

This is a corrective release on the 3.2.3 line. TeamPass 3.2.3.1 cannot be installed from scratch: the database step of the web installer stops on 35 tables (GHSA-pxjv-6qgf-xhcg). 3.2.3.2 fixes the installer, verifies the certificate of the SMTP server, shows creation and modification dates in the knowledge base, and displays the licence dates in the date format of the instance. Upgrading is recommended for every installation, and 3.2.3.2 is the version to use for any new installation. Do not fall back to 3.2.3.0 or an earlier release to get a working installation: they are exposed to the two critical vulnerabilities fixed in 3.2.3.1.

This release changes the database schema. The kb table gains two columns for the article dates, so UPGRADE_MIN_DATE is raised and every installation goes through the upgrade wizard once.

🔒 Security fixes

• Fresh installations work again (GHSA-pxjv-6qgf-xhcg, Low, found and fixed by @guerricv) - the GHSA-8xp7-fh3p-5pcr fix of 3.2.3.1 replaced the dynamic dispatch of the installer with a list of allowed actions, but the list for step 5 stopped at user_private_keys. The 35 tables created after it were refused with Action not recognized, the installation stopped at step 5 and no usable instance was produced, from the archive and from the Docker image alike. Existing and upgraded installations were not affected. The list now holds every table the installer creates, and a test compares it with the installer's schedule so a new table can no longer be left out. The issue is not exploitable; it has an advisory because the obvious workaround, installing an older release, exposes the new instance to GHSA-8xp7-fh3p-5pcr and GHSA-988j-pf6f-2m2r. After a failed 3.2.3.1 installation, the database holds no user data yet: drop and recreate it, or empty it, then run the installer of 3.2.3.2.

• The certificate of the SMTP server can be verified - TeamPass disabled the verification of the mail server certificate unconditionally: with SSL or TLS the connection was encrypted but not authenticated, so anyone on the network path to the relay could impersonate it and read the SMTP credentials and every email TeamPass sends. The new option Verify the SMTP server certificate (Admin → Emails) is enabled on new installations. On an upgraded installation it is off, so a relay with a self-signed or internal certificate keeps working, and the administrator dashboard recommends enabling it while an SSL/TLS relay is not verified. If the test email then fails with certificate verify failed, add the certificate authority of the relay to the trust store of the TeamPass server. See Security hardening.

✨ New features

• Creation and modification dates in the knowledge base (PR #5435, @guerricv) - an open article shows its creation date and its last modification date next to its category, comments and author; the article list shows the last modification date, or the creation date when no modification is recorded, with the full timestamp on hover. Dates follow the date and time formats and the timezone of the instance. Changes to the article, its associated items or its attachments update the modification date; reading, commenting and saving without changes do not, and deleting then restoring an article keeps its dates. The dates are stored with the article, so purging the activity logs no longer loses them. See Knowledge base.

🐛 Bug fixes

• Licence dates follow the date format of the instance (PR #5434, @guerricv) - the expiry tile of Statistics → Licence and the Browser Extension ti