v3.27.0

Changes 08/25/2026 (v3.27.0)

release(v3.27.0): harden authentication, authorization, and rendering

Fixed

• The ONLYOFFICE editor-configuration endpoint now requires an authenticated FileRise session before evaluating folder permissions or creating signed document capabilities.
• Unauthenticated requests can no longer fall back to the ACLs of a local account named anonymous.
• Existing authenticated ONLYOFFICE users and the sessionless, short-lived signed download URLs used by the Document Server retain their existing behavior.
• Portal form submissions now require upload authorization for the selected portal's configured folder before a submission is stored or an automation event is emitted.
• Authenticated users can no longer change the submitted portal slug to create records in portals outside their folder ACLs.
• Portal entry listings now enforce per-file uploader ownership when the signed-in user has read_own rather than full read access.
• Portal counts, pagination, and complete-file arrays are now calculated after the ownership filter, preventing other users' filenames, sizes, and modification times from being disclosed.
• Storage-originated folder names are now HTML-encoded in the shallow folder strip and FileRise Pro's Storage → Top Folders view before template rendering.
• Existing folder names, navigation targets, storage enumeration, disk-usage snapshots, and FileRise's Content Security Policy remain unchanged.

Upgrade notes

• No account, ACL, file, folder, ONLYOFFICE, Docker volume, storage, or configuration migration is required.
• Existing portal users, administrators, and group members with upload access to a portal folder retain their current intake-form workflow.
• Portal users with full read access retain complete listings; read_own users now see only files attributed to their account in folder metadata.
• Existing folder names containing Unicode, punctuation, or HTML-significant characters continue to display and navigate normally; those characters are treated as text rather than markup.

v3.27.0

Full Changelog

v3.26.1 → v3.27.0

SHA-256 (zip)

f3f209f0733b64e7cc91746d76375eae54362589ac511463f4c22268e21b5ea5  FileRise-v3.27.0.zip

v3.26.1

Changes 08/07/2026 (v3.26.1)

release(v3.26.1): enforce file-only copy operations

Fixed

• Same-source copyFiles operations now explicitly require each selected object to be a file before invoking the active storage adapter, matching the existing move, delete, and cross-source copy invariants.
• Directory names submitted to file-copy operations are refused consistently instead of relying on adapter-specific copy behavior.
• File-delete type-refusal messages no longer contain doubled trailing punctuation.

Upgrade notes

• No account, ACL, file, folder, metadata, Pro license, Docker volume, storage source, or configuration migration is required.
• Normal file copies retain their existing behavior. Directory copies continue through the dedicated folder-copy workflow.

v3.26.1

Full Changelog

v3.26.0 → v3.26.1

SHA-256 (zip)

73a99b46ed368a3be1536776601407628604c77f4d83404b03c9c43b707cf286  FileRise-v3.26.1.zip

v3.26.0

Changes 08/06/2026 (v3.26.0)

release(v3.26.0): harden persistent authentication and Pro storage rendering

Fixed

• File and folder metadata shown in FileRise Pro's Storage → Top Files table is now HTML-encoded before rendering, preventing uploaded file names from being interpreted as markup in an administrator's browser.
• Existing file names, disk-usage snapshots, storage sources, deletion controls, Pro bundle installation, and FileRise's Content Security Policy remain unchanged.
• Successful self-service password changes and administrator password resets now revoke every remember-me token belonging to the affected account.
• Remember-me tokens belonging to other accounts and the password-changing user's current authenticated session remain unchanged.

Upgrade notes

• No account, ACL, file, folder, metadata, Pro license, Docker volume, storage, or configuration migration is required.
• Existing names containing Unicode, punctuation, or HTML-significant characters continue to display and operate normally; the characters are displayed as text instead of being interpreted as HTML.
• Upgrading alone does not expire remember-me tokens or sign out existing users. Remembered devices are asked to sign in again only after that account's password is subsequently changed or reset.

v3.26.0

Full Changelog

v3.25.0 → v3.26.0

SHA-256 (zip)

69ffef2249c2a6bb31b522b56f1bb5801c4e1ca613d5a5e39d64104d27a538f5  FileRise-v3.26.0.zip

v3.25.0

Changes 08/01/2026 (v3.25.0)

release(v3.25.0): authorization and archive containment hardening

Fixed

• The administrator-controlled account Read-only flag is now enforced as a hard ceiling over folder ownership, direct ACLs, inherited ACLs, and Pro group grants.
• Read-only accounts can no longer create, upload, overwrite, rename, move, copy, delete, extract, or otherwise edit files through direct API requests.
• Same-source folder moves, WebDAV writes, ONLYOFFICE edits, portal-user uploads, and background transfer paths now apply the same account restriction.
• Existing view, download, ownership, and separately authorized sharing behavior remains available to read-only accounts.
• Archive extraction now retains the original private workspace as its immutable containment boundary, preventing extracted links or redirected paths from redefining the trusted source root.
• File-only move and delete operations now reject directories before mutation, preventing file-level permissions from relocating protected folder trees or moving them to Trash.
• Upload folder paths now use one validated logical representation from authorization through storage, and invalid paths fail closed instead of falling back to the storage root.
• Folder and resumable uploads now authorize the effective relative destination and its nearest existing folder before creating directories, writing files, or disclosing existing-file details.
• Trash restoration now treats stored records as untrusted, rejects unsafe original folders and names, and resolves every destination inside the active upload root before creating directories or moving data.

Upgrade notes

• No account, ACL, folder, storage, Docker volume, or configuration migration is required.
• Existing writable accounts retain their current behavior and ACLs.
• Accounts already marked Read-only will begin enforcing the documented view/download-only restriction across direct API and WebDAV access immediately after upgrade.
• Disabling Read-only later restores the account's existing folder and group permissions because the update does not rewrite ACL records.
• Existing ZIP, 7z, and RAR workflows require no configuration or data migration; ordinary archive extraction behavior remains unchanged.
• Existing file operations require no migration; integrations that move or delete directories must use the corresponding folder endpoints and folder-level authorization.
• Existing browser, folder, resumable, shared, and portal upload workflows require no migration. API clients should pass the logical folder value and rely on the HTTP transport to encode it rather than embedding an additional percent-encoding layer in multipart or JSON values.
• Existing valid Trash records restore normally and require no migration; malformed or tampered records remain in Trash and are refused.
• The Pro bundle directory, users volume, license storage, activation behavior, and bootstrap_pro.php loading path are unchanged.

v3.25.0

Full Changelog

v3.24.0 → v3.25.0

SHA-256 (zip)

993876e3af04cf4f71cd4d7889a10fce86be5317d936b2a62753c27148978adb  FileRise-v3.25.0.zip

v3.24.0

Changes 07/26/2026 (v3.24.0)

release(v3.24.0): require authentication for portal details

Fixed

• The FileRise Pro portal-detail endpoint now requires an authenticated session before returning internal folder, client-contact, form, or upload-policy metadata.
• The deliberately public portal metadata endpoint remains available for anonymous portal-login branding and continues returning only its curated public fields.
• Existing administrators and dedicated non-admin portal users retain access after signing in.

Upgrade notes

• No configuration, portal, account, Docker volume, or stored-data migration is required.
• Integrations that directly requested /api/pro/portals/get.php without an authenticated FileRise session must use /api/pro/portals/publicMeta.php for public branding fields or authenticate before requesting full portal details.

v3.24.0

Full Changelog

v3.23.1 → v3.24.0

SHA-256 (zip)

ab0b88b47324c910000cc3c301bb318c139c073f1d9d3396236356e158997886  FileRise-v3.24.0.zip

v3.23.1

Changes 07/25/2026 (v3.23.1)

release(v3.23.1): correct PHP coding-standard violations

Fixed

• Corrected PHP coding-standard formatting in the TOTP attempt limiter and OIDC authentication flow so the release quality checks complete successfully.
• No application behavior, configuration, storage, authentication policy, or upgrade procedure changed from v3.23.0.

v3.23.1

Full Changelog

v3.23.0 → v3.23.1

SHA-256 (zip)

e2e21188e03e6051dd5c8cc34552b8c0269dcb4946972e1f3f66d34718c6c95a  FileRise-v3.23.1.zip

v3.23.0

Changes 07/25/2026 (v3.23.0)

release(v3.23.0): authentication and authorization hardening

Commit message

release(v3.23.0): authentication and authorization hardening

- security(auth): harden TOTP verification and account settings
- security(oidc): bind accounts by immutable provider identity
- security(files): enforce upload, callback, and path boundaries

Fixed

• TOTP verification now enforces persistent account-wide and source-wide attempt budgets across all pending-login verification paths, and the alternate auth handler now resolves the shared TOTP verifier correctly, so changing sessions or client addresses cannot reset the second-factor limit.
• Successfully accepted TOTP time steps are now claimed atomically per account and authenticator secret, preventing the same still-valid code from completing authentication more than once.
• Successful TOTP verification clears the account budget without counting ordinary successful logins against shared-network failure limits.
• TOTP enrollment now remains pending until a valid code confirms the new authenticator, and enrollment, disablement, and recovery-code rotation require a recent full authentication.
• OIDC logins now bind the validated issuer-and-subject identity to a local account, ignore unverified email for naming, and cannot attach a mutable username claim to an existing local account.
• Upload and rename validation now rejects trailing-dot filenames across regular, resumable, shared, and WebDAV write paths so filesystem or web-server normalization cannot bypass blocked executable names.
• Logical folder paths now reject raw or encoded . and .. segments before ACL evaluation or storage access; local writes use boundary-aware containment before directory creation, and WebDAV operations cannot escape the configured source root.
• ZIP, 7z, and RAR extraction now occurs in a private temporary workspace on the same local storage volume, and validated regular files are placed atomically only through real in-root destination directories; pre-existing destination symlinks can no longer redirect extraction or cleanup outside the storage root.
• ONLYOFFICE save callbacks now require a valid HS256 JWT from the configured Document Server; omitting the callback JWT no longer falls back to trusting the unsigned request body.
• Cross-parent folder renames now enforce destination move rights and matching ownership boundaries, preventing a folder owner from moving their tree into another user's folder or the admin-controlled root.

Upgrade notes

• Breaking security change for existing OIDC deployments: OIDC identities created before v3.23.0 do not have an issuer/subject binding and cannot continue matching an existing local account automatically.
• ONLYOFFICE callback security change: Before upgrading, ensure the Document Server has outgoing/outbox JWTs enabled and uses the same secret configured in FileRise. Correctly configured deployments require no data migration.
• Older or misconfigured Document Servers that omit callback JWTs will be unable to save until their outgoing JWT configuration is corrected. ONLYOFFICE_ALLOW_UNSIGNED_CALLBACKS=1 is available only as a temporary, explicitly unsafe recovery measure; remove it immediately after confirming a signed document save.
• After five failed TOTP submissions, that account waits up to 15 minutes before another verification attempt.
• Sessions whose full authentication is more than five minutes old must sign in again before changing TOTP security settings; remember-me restoration alone does not satisfy this check.
• Existing non-OIDC users, TOTP secrets, sessions, Docker volumes, and deployment configuration require no migration.
• Before upgrading an OIDC deployment, verify a working local administrator login and back up the users directory.
• On the first OIDC login for an existing account, FileRise presents a one-time guided link prompt for that account's local password and, when configured, TOTP. This confirmation works even when ordinary form login is disabled.
• New OIDC identities whose proposed username does not collide with an existing local account continue to auto-provision normally when OIDC auto-provisioning is enabled; they are bound to the validated issuer and subject immediately and do not receive the guided link prompt.
• OIDC-only users without a known local password require an administrator-assisted password reset or account migration. Complete this preparation before upgrading any deployment whose only administrator uses OIDC.
• See docs/wiki/oidc sso.md under Upgrading existing OIDC accounts to v3.23.0 for the complete migration procedure.

v3.23.0

Full Changelog

v3.22.0 → v3.23.0

SHA-256 (zip)

f68043b9bf39a30f5a529e24cb539725c186e0a69137882fc233821ee129f886  FileRise-v3.23.0.zip

v3.22.0

Changes 07/13/2026 (v3.22.0)

release(v3.22.0): generate unique keys for pristine manual installs

Fixed

• Pristine manual installs now generate and persist a unique persistent-tokens key instead of beginning with the published legacy fallback.
• Existing environment keys, persisted key files, Docker source hints, and installations with existing state retain their current key behavior for upgrade compatibility.
• Concurrent first requests coordinate key creation so every worker uses the same persisted key, and Docker now stops with an actionable error if a pristine key cannot be persisted.

Upgrade notes

• Existing legacy installs are not rotated automatically; the Admin Panel warning and controlled rotation workflow remain available.
• Back up metadata/persistent_tokens.key with the rest of the metadata directory.

v3.22.0

Full Changelog

v3.21.0 → v3.22.0

SHA-256 (zip)

c28c6b6bd4175538c203a43981e72987dc8b7270ddacfc4ffa226344ce50633e  FileRise-v3.22.0.zip

v3.21.0

Changes 07/05/2026 (v3.21.0)

release(v3.21.0): authentication and public config hardening

Commit message

release(v3.21.0): authentication and public config hardening

- security(auth): enforce disabled login methods server-side
- security(auth): add source-wide failed-login throttling
- security(config): sanitize public footer branding HTML server-side

Fixed

• Login method policy hardening

  • Form login, Basic Auth login, and OIDC login now enforce the configured disabled-login-method flags on the server.
  • Direct requests to disabled login endpoints now return 403 Forbidden before credential validation or OIDC flow setup.

• Login throttling hardening

  • Login throttling now keeps the existing per-source-and-username limit and also applies a source-wide failed-attempt limit.
  • Rotating usernames from the same source no longer grants unlimited fresh login-attempt budgets.

• Public branding config hardening

  • Public site configuration now sanitizes footer branding HTML server-side before returning it to clients.
  • Existing safe footer text, inline formatting, and safe links are preserved.

Upgrade notes

• Deployments that intentionally disabled a login method in the Admin Panel must now re-enable it before direct API use of that method will work.
• Deployments behind reverse proxies should verify trusted proxy/IP header settings so login throttling uses the real client IP instead of the proxy address.
• Footer branding now permits safe text, inline formatting, and safe links; unsupported active or embedded HTML is stripped.

v3.21.0

Full Changelog

v3.20.0 → v3.21.0

SHA-256 (zip)

453fea2c671916366d9517547833a6f39bcd3f3bab7bc1f8a579b63c930d6e92  FileRise-v3.21.0.zip

v3.20.0

Changes 07/03/2026 (v3.20.0)

release(v3.20.0): file preview hardening

Commit message

release(v3.20.0): file preview hardening

- security(file): require authentication before snippet preview access

Fixed

• File preview hardening
  • File snippet previews now require an authenticated session before any ACL, path, or file-content handling.
  • Unauthenticated snippet requests now return 401 Unauthorized.

v3.20.0

Full Changelog

v3.19.0 → v3.20.0

SHA-256 (zip)

84930a4ad83346285f0f513fccadce7366beb025f5d3ea68e53ee9e556609909  FileRise-v3.20.0.zip