v3.33.0

Changes 09/30/2026 (v3.33.0)

release(v3.33.0): harden share passwords and Windows storage boundaries

Fixed

• File creation and upload paths now reject NTFS alternate-stream syntax before extension and reserved-name policy checks.
• Password-protected file and folder shares now limit repeated verification attempts and return a retry interval when the limit is reached.

Security and deployment

• Clarified the exclusive-writer requirement for FileRise data directories and the supported Linux manual-server environment.

Upgrade notes

• No account, file, permission, encryption-key, or configuration migration is required.
• New filenames containing a colon are rejected; existing files are not renamed or deleted.

v3.33.0

Full Changelog

v3.32.0 → v3.33.0

SHA-256 (zip)

d5f533d8278a3127c6b4932e0d0e68d8e287471224d1b56eeed482bca634feed  FileRise-v3.33.0.zip

v3.32.0

Changes 09/29/2026 (v3.32.0)

release(v3.32.0): harden archive and first-run security boundaries

Fixed

• 7-Zip archive downloads now treat selected file names literally, preserving folder ACL and own-file boundaries for names containing wildcard characters.
• Initial administrator creation now consumes first-run setup atomically, so overlapping requests cannot replace the account that completed setup.
• Container startup now rejects unsafe persisted path state before privileged permission changes and process launch.

Upgrade notes

• No account, file, permission, encryption-key, or configuration migration is required.

v3.32.0

Full Changelog

v3.31.0 → v3.32.0

SHA-256 (zip)

3fe7305ce0ababade1b46b59ba5c55eadd777993fe2e9bc96441c5b862640667  FileRise-v3.32.0.zip

v3.31.0

Changes 09/21/2026 (v3.31.0)

release(v3.31.0): align session roles and correct WebDAV subpath destinations

Fixed

• Established browser sessions now follow the current local account role on subsequent requests.
• Legacy session permission flags remain consistent with the current account role.
• WebDAV MOVE and COPY now handle public Destination URLs behind reverse proxies that strip a configured subpath (#122), while preserving root and retained-prefix deployments.

Upgrade notes

• No account, file, encryption-key, or persistent-token migration is required. Existing users remain signed in with their current permissions.
• OIDC role synchronization still occurs at login; the existing Allow demote setting and its default are unchanged.
• Manual upgrades that retain a customized config/config.php must merge the updated session-bootstrap and authentication-cleanup blocks while preserving their installation settings.

v3.31.0

Full Changelog

v3.30.0 → v3.31.0

SHA-256 (zip)

5e5934a0a5c6626ee0ec7b63f50eb25df3df290829b66faf5081eb89ee2c2d9c  FileRise-v3.31.0.zip

v3.30.0

Changes 09/19/2026 (v3.30.0)

release(v3.30.0): refine proxy address handling and local storage path checks

Fixed

• Client address resolution now follows the configured trusted proxy chain for forwarded requests.
• Direct connections and supported single-address proxy headers retain their normal behavior.
• Local file listings and download path checks consistently respect the selected storage root, including linked paths.

Upgrade notes

• No account, storage, encryption-key, or configuration-file migration is required.
• Links resolving within a local storage root, including a linked root directory, remain supported. Links resolving outside that root are no longer available through file listings or download path resolution.
• Multi-proxy deployments should list each trusted proxy hop in FR_TRUSTED_PROXIES; unlisted intermediaries become the attributed client address.
• Custom single-IP headers must contain one valid address. Malformed forwarded chains fall back to the immediate peer when the client cannot be established safely.
• Existing rate-limit entries and external fail2ban bans retain their current expiry and are not reset by this update.

v3.30.0

Full Changelog

v3.29.0 → v3.30.0

SHA-256 (zip)

85a8ac00ec2f34b3e727ce72b7af96d8cb0bf5f9438ca5cb0db9615713942c9a  FileRise-v3.30.0.zip

v3.29.0

Changes 09/17/2026 (v3.29.0)

release(v3.29.0): align ONLYOFFICE permissions and correct File Request picker handling

Fixed

• ONLYOFFICE document access and editing permissions are now evaluated against the selected storage source.
• ONLYOFFICE save callbacks now check edit permissions in the document's storage source.
• File Request file and folder buttons now open only their intended picker once per activation, removing duplicate picker calls associated with the reported Safari selection issue (#118).
• Keyboard activation of File Request picker buttons no longer also triggers the surrounding dropzone's file picker.

Upgrade notes

• No account, ACL, document, storage, Docker volume, or configuration migration is required.
• Authorized document editing and the signed download URLs used by the ONLYOFFICE Document Server retain their existing behavior.

v3.29.0

Full Changelog

v3.28.0 → v3.29.0

SHA-256 (zip)

a5ad0ad5e01712c2d55a99c6ca36e42a52c7188b7dd46f7dbb959500afcb409c  FileRise-v3.29.0.zip

v3.28.0

Changes 09/16/2026 (v3.28.0)

release(v3.28.0): refine WebDAV request handling

Fixed

• Improved consistency of WebDAV request handling across client configurations.

v3.28.0

Full Changelog

v3.27.0 → v3.28.0

SHA-256 (zip)

30ee220209d5d46e54de1b04b67fee548d9ee911c86a9c0e1edcc655eced4d7f  FileRise-v3.28.0.zip

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