v3.11.2

Changes 04/16/2026 (v3.11.2)

release(v3.11.2): phpseclib security dependency update

Commit message

release(v3.11.2): phpseclib security dependency update

- deps(composer): upgrade phpseclib/phpseclib to 3.0.51 to pick up the latest upstream security fix

Changed

• Dependency security maintenance
  • Updated phpseclib/phpseclib to 3.0.51 in Composer dependencies to pick up the current upstream security fix in the locked dependency set.
  • This release addresses the upstream advisory covering variable-time HMAC comparison in SSH2::get_binary_packet().

v3.11.2

Full Changelog

v3.11.1 → v3.11.2

SHA-256 (zip)

ab30b6a719d042ba638332d136870449a2f94d9355b85b00e939cb55989909ff  FileRise-v3.11.2.zip

v3.11.1

Changes 03/24/2026 (v3.11.1)

release(v3.11.1): shared-hosting worker fallback and deleted-user session invalidation (closes #110)

Commit message

release(v3.11.1): shared-hosting worker fallback and deleted-user session invalidation (closes #110)

- transfer(shared-hosting): fall back from shell_exec to exec or foreground workers so move/copy/zip jobs stay usable on restrictive hosts (#110)
- compat(shell): degrade ClamAV, archive, and admin diagnostics paths cleanly when PHP command execution is unavailable
- auth(delete-user): invalidate deleted-account sessions and revoke remember-me tokens so removed users cannot regain access on subsequent requests

Fixed

• Shared-hosting transfer compatibility

  • Fixed a case where move/copy jobs could fail with 500 on hosts that disable proc_open() / shell_exec() and similar process-launch functions, leaving folder operations unusable.
  • FileRise now falls back to safer worker-launch paths and foreground execution where appropriate so transfer and ZIP workflows remain usable on more restrictive shared-hosting environments.

• Deleted-account session invalidation

  • Fixed a case where a deleted account could continue using an already-established session until the PHP session expired or the web service was restarted.
  • Deleted users can no longer regain access through remember-me restoration, and user deletion now revokes stored remember-me tokens for that account.

Changed

• Shell-dependent feature degradation
  • Shell-backed features now report clearer host limitations when PHP command execution is unavailable instead of failing with less actionable worker or command errors.
  • ClamAV diagnostics, archive operations, and related admin/runtime checks now degrade more cleanly on locked-down hosts.

v3.11.1

Full Changelog

v3.11.0 → v3.11.1

SHA-256 (zip)

5d3d21169fee0b2c6e6707eeee4cc89b74f7d8392d8a5963eaa71be7fbc81624  FileRise-v3.11.1.zip

v3.11.0

Changes 03/20/2026 (v3.11.0)

release(v3.11.0): snippet ownership enforcement and phpseclib security update

Commit message

release(v3.11.0): snippet ownership enforcement and phpseclib security update

- file(snippet): enforce per-file read_own ownership checks before returning hover-preview snippet content
- file(snippet): align snippet access with the existing single-file read authorization helper path
- deps(composer): upgrade phpseclib/phpseclib to 3.0.50 to pick up the latest upstream security patch

Fixed

• Snippet access control for own-only folders
  • The file snippet / hover-preview endpoint now enforces the same per-file ownership check already used by other single-file read paths when access comes only from read_own.
  • Users with own-only visibility can no longer retrieve snippet content from files uploaded by other users in the same folder.

Changed

• Dependency security maintenance
  • Updated phpseclib/phpseclib to 3.0.50 in Composer dependencies to pick up the current upstream security fix in the locked dependency set.

v3.11.0

Full Changelog

v3.10.0 → v3.11.0

SHA-256 (zip)

a9884226d9bf0f0869de0574da06113bce3f750806e322d5d4ac17234bd475b3  FileRise-v3.11.0.zip

v3.10.0

Changes 03/16/2026 (v3.10.0)

release(v3.10.0): resumable upload hardening and ONLYOFFICE callback authorization tightening

Commit message

release(v3.10.0): resumable upload hardening and ONLYOFFICE callback authorization tightening

- upload(resumable): stop deriving temporary chunk directories from raw client identifiers and switch to hashed internal temp-folder names
- upload(cleanup): require authenticated upload access for resumable temp-folder removal and keep recursive cleanup bounded to the intended staging root
- upload(compat): preserve normal resumable upload flow while making temp-path resolution consistent across probe, write, and cleanup paths
- onlyoffice(callback): issue save callbacks only for editable sessions, bind callbacks to the authorized actor/file, and stop trusting body-supplied editor identities
- onlyoffice(origin): restrict callback fetch URLs to the configured Document Server origin while keeping callback JWT validation compatible with existing deployments

Changed

• Resumable temp-folder naming
  • Resumable upload staging now maps client identifiers to hashed internal temp-folder names instead of using raw identifier values directly in filesystem paths.
  • The same temp-folder mapping is now used consistently for chunk probe, chunk staging, and resumable cleanup operations.

Fixed

• Resumable cleanup guardrails

  • Tightened resumable temp-folder cleanup so recursive deletion stays bounded to the expected staging area.
  • The resumable cleanup endpoint now requires an authenticated session with upload permission for the target folder before removing chunk temp data.

• ONLYOFFICE save authorization

  • View-only ONLYOFFICE sessions no longer receive save-capable callback URLs.
  • ONLYOFFICE save callbacks are now bound to the authorized actor and file, and no longer trust body-supplied editor identities.
  • Save fetches are restricted to the configured ONLYOFFICE Document Server origin before FileRise downloads updated content and writes it back to disk.

v3.10.0

Full Changelog

v3.9.4 → v3.10.0

SHA-256 (zip)

f29143d5ace47f847ac43a1526ba376f16a572e30c5b4fa3127cf5325eebbd61  FileRise-v3.10.0.zip

v3.9.4

Changes 03/15/2026 (v3.9.4)

release(v3.9.4): preserve legacy compatibility path while keeping post-rotation key-file preference

Commit message

release(v3.9.4): preserve legacy compatibility path while keeping post-rotation key-file preference

- crypto(compat): keep legacy default-key fallback behavior for existing installs with encrypted state and no explicit key
- crypto(resolve): continue preferring metadata/persistent_tokens.key after rotation so follow-up requests stop drifting back to the legacy fallback
- docs(changelog): clarify that legacy installs remain supported while the post-rotation request-consistency fix stays in place

Changed

• Legacy compatibility path
  • Clarified that existing installs without an explicit PERSISTENT_TOKENS_KEY still retain the historical legacy fallback behavior for encrypted state compatibility.
  • The legacy fallback remains resolver-driven in config.php, while rotated installs continue preferring metadata/persistent_tokens.key for post-rotation consistency.

Fixed

• Release note accuracy
  • Clarified the persistent-token key compatibility story so the legacy-install behavior and the post-rotation fix are documented together.

v3.9.4

Full Changelog

v3.9.3 → v3.9.4

SHA-256 (zip)

0e840258d73faba60b031d416bd40aae86e0622d2e545d97d7486a6a27f8a7a3  FileRise-v3.9.4.zip

v3.9.3

Changes 03/15/2026 (v3.9.3)

release(v3.9.3): legacy fallback worker-env fix after persistent-token key rotation

Commit message

release(v3.9.3): legacy fallback worker-env fix after persistent-token key rotation

- crypto(startup): stop exporting the legacy fallback key as a process-wide env value on compatibility-path installs
- crypto(resolve): prefer the persisted key file over legacy_default source hints once a rotation has written metadata/persistent_tokens.key
- admin(ui): eliminate post-rotation getConfig/siteConfig failures caused by workers still decrypting with the inherited legacy fallback

Fixed

• Post-rotation request consistency
  • Fixed a case where some Apache workers could keep using the legacy fallback persistent-token key immediately after an in-app rotation, causing transient getConfig.php / siteConfig.php 500 responses until a refresh or restart.
  • Compatibility-path installs no longer export the legacy fallback key as a worker-wide env value, and the key resolver now prefers the persisted key file once rotation has written metadata/persistent_tokens.key.

v3.9.3

Full Changelog

v3.9.2 → v3.9.3

SHA-256 (zip)

752cd4d14acc59e0b65127994048ce115b2dd13fb64a06ed4c64e29a9dc19760  FileRise-v3.9.3.zip

v3.9.2

Changes 03/15/2026 (v3.9.2)

release(v3.9.2): admin config decrypt retry after persistent-token key transitions

Commit message

release(v3.9.2): admin config decrypt retry after persistent-token key transitions

- admin(config): retry adminConfig.json reads once before surfacing decrypt errors after key changes
- admin(ui): avoid transient getConfig failures on the first Admin Panel open after key transitions

Fixed

• Admin Panel first-open stability after key changes
  • Fixed a transient getConfig.php failure where the first Admin Panel open after a persistent-token key transition could return Failed to decrypt configuration. even though a manual refresh succeeded.
  • AdminModel::getConfig() now rereads adminConfig.json once and retries decryption before surfacing a real decrypt error.

v3.9.2

Full Changelog

v3.9.1 → v3.9.2

SHA-256 (zip)

079eb01968fd8979eaa9ee45bc3897b59c0024b473682327cb6346b66a9f839b  FileRise-v3.9.2.zip

v3.9.1

Changes 03/15/2026 (v3.9.1)

release(v3.9.1): post-rotation bootstrap fix and startup script cleanup

Commit message

release(v3.9.1): post-rotation bootstrap fix and startup script cleanup

- admin(startup): tolerate transient adminConfig decrypt fallback during persistent-token key rotation bootstrap
- docker(startup): split persistent-token key file export assignment to satisfy shellcheck

Fixed

• Post-rotation bootstrap stability
  • Fixed a bootstrap path that could white-page the app if adminConfig.json was re-read during a persistent-token key rotation transition and decryption temporarily returned a non-string value.
  • The startup config path now falls back safely instead of fataling during json_decode(...).

Changed

• Startup script shell hygiene
  • Adjusted the persistent-token key file load/export sequence in start.sh so CI shell linting passes without changing runtime behavior.

v3.9.1

Full Changelog

v3.9.0 → v3.9.1

SHA-256 (zip)

ba04ea31cdd3ac2234f224ed495d6e88de32070bcd7cad384f8da1a824375968  FileRise-v3.9.1.zip

v3.9.0

Changes 03/14/2026 (v3.9.0)

release(v3.9.0): persistent-token key lifecycle updates and admin rotation workflow

Commit message

release(v3.9.0): persistent-token key lifecycle updates and admin rotation workflow

- docker(startup): remove baked persistent-token key defaults and auto-generate a unique key for pristine installs
- admin(ui): warn when the instance is still using a legacy or placeholder persistent-token key and expose guided rotation for compatible installs
- admin(crypto): add persistent-token key rotation that re-encrypts stored secrets and expires remember-me sessions
- docs(docker): refresh docker run / compose guidance so metadata-backed generated keys are documented as the default path

Added

• Admin rotation workflow for persistent-token keys
  • Added an admin-only rotation action that generates a new persistent-token key, re-encrypts stored secret-bearing data, writes metadata/persistent_tokens.key, and intentionally expires remember-me sessions.
  • Added an admin warning card with rotation guidance for instances still using a legacy or placeholder persistent-token key.

Changed

• Docker startup behavior
  • Pristine Docker installs now auto-generate and persist a unique persistent-token key in metadata/persistent_tokens.key.
  • Existing installs without an explicit key continue on the legacy compatibility path until the operator rotates them.
• Docker examples and env reference
  • Updated docker run, compose, and env-reference guidance so PERSISTENT_TOKENS_KEY is optional by default and no published placeholder value is documented.

Fixed

• Persistent-token key lifecycle
  • Existing installs can now move off the legacy compatibility key without losing admin config, user-permissions, stored TOTP secrets, or source credentials.
  • Remember-me sessions are explicitly expired during rotation instead of being left in a mixed-key state.

Security

• Install defaults
  • The runtime image no longer ships a baked-in persistent-token key default.
  • New Docker installs now start with instance-unique key material by default as long as metadata/ is persistent.

v3.9.0

Full Changelog

v3.8.0 → v3.9.0

SHA-256 (zip)

f0757584dddccb5bbdd522cc45bf11f6a58d5f5e12666dd25ac56bd4ea9f6e00  FileRise-v3.9.0.zip

v3.8.0

Changes 03/12/2026 (v3.8.0)

release(v3.8.0): share-link admin guards and centralized safe-upload policy

Commit message

release(v3.8.0): share-link admin guards and centralized safe-upload policy

- shares(security): require authenticated admin + CSRF for file share link listing and deletion
- uploads(policy): add centralized safe-upload policy with strict default and code-friendly admin override
- webdav(policy): enforce the shared write-name policy for WebDAV file and folder creation paths
- admin(ui): expose safe upload policy in Admin Panel and persist the normalized config value
- admin(fix): guard partial config updates that omit oidc payloads

Added

• Centralized safe-upload policy
  • Added src/FileRise/Support/UploadNamePolicy.php to centralize write-path filename policy decisions.
  • Added admin-configurable policy modes:
    • strict (default)
    • code_friendly

Changed

• File share admin endpoints
  • getShareLinks.php now requires an authenticated admin session.
  • deleteShareLink.php now requires an authenticated admin session and a valid CSRF token.
  • Updated the generated OpenAPI spec to reflect the authenticated share-link route behavior.
• Write-path filename enforcement
  • Normal uploads, file create/save flows, selected folder write paths, and WebDAV now use the shared write-name policy instead of relying only on the generic filename regex.
  • Added an Admin Panel control under upload settings so operators can switch between strict and code_friendly behavior.

Fixed

• Partial admin config saves
  • Fixed admin config updates failing when the submitted payload omits the oidc object during narrower settings changes.
• WebDAV folder-name validation
  • WebDAV folder creation now rejects invalid path-like names such as empty names, . / .., and names containing path separators.

Security

• Safe-upload defaults
  • New write operations default to strict mode.
  • .htaccess, .user.ini, and web.config remain blocked in all policy modes.
• Share-link guard consistency
  • File share-link listing and deletion now use the same authenticated admin expectations as the rest of the admin share management surface.

v3.8.0

Full Changelog

v3.7.0 → v3.8.0

SHA-256 (zip)

c9a2e45aeb8dc04e9f1b5b093e52aba134841a9d4fb7f51115048c23c1f8b97e  FileRise-v3.8.0.zip