CVE-2026-103988

Executive Summary

CVE-2026-103988 is an improper authorization vulnerability (CWE-284) in FileRise, a self-hosted web-based file manager, affecting versions prior to 3.23.0. An authenticated, non-administrator user who owns a source folder can move that folder tree beneath another user's existing folder or into the root namespace, because the /api/folder/renameFolder.php endpoint fails to independently authorize the changed destination parent. This results in unauthorized cross-tenant file relocation and integrity/confidentiality impact scored at CVSS 5.4, though victim files cannot be overwritten and the destination must be unused.

Technical Analysis

FileRise exposes a folder-management API surface through renameFolder.php. Per the NVD description, the vulnerable operation is a folder rename/move that accepts both a source folder and a changed destination parent. The authorization model has a scoping defect: the endpoint validates the caller's rights against the source folder and requires a valid CSRF token, but does not independently authorize the changed destination parent. Because authorization is scoped only to the source, the destination-side trust boundary is never enforced.

The attacker profile is specific and constrained:

• Authenticated user (any account, not necessarily administrator).
• Must be a "non-folder-scoped, non-administrator" user.
• Must own the source folder being moved.
• Must present a valid CSRF token bound to the source folder operation.

When these conditions are met, a qualifying user can move an owned folder tree beneath another user's existing folder or into the root namespace. Critically, the operation "rekeys the moved ownership and ACL records to the new path" — meaning the moved tree's ownership and access-control metadata are rewritten to reflect the new destination path. This is the core integrity impact: data that logically belonged to one user's namespace is relocated and its ACL model is re-anchored under a path the attacker controls or can influence.

Two constraints limit the blast radius:

1. The destination must be unused.
2. Existing victim files cannot be overwritten.

A secondary information-disclosure vector is present: "Distinct pre-fix errors reveal whether a specifically guessed destination path exists, but disclose no directory listing or file contents." This is an oracle-style existence check — an attacker can enumerate the existence of specific destination paths by observing differential error responses, but gains no listing capability or file content. This is consistent with the C:L (Limited Confidentiality) and I:L (Limited Integrity) subscores in the CVSS vector; availability is unaffected (A:N).

No public proof-of-concept, exploit code, or Nuclei template was identified in the provided intelligence. Attack chain details below are inferred at the vulnerability-class level, not from a published exploit.

Exploitation Scenarios

1) Reconnaissance / Target Identification. The attacker identifies a reachable FileRise instance (self-hosted file managers are frequently internet-exposed, though exposure depends on deployment). The attacker holds or obtains a low-privileged authenticated account. Because a valid CSRF token scoped to the source folder is required, the attacker first establishes a session and creates/owns at least one source folder.

2) Triggering the Flaw Class. This is a broken access control / improper authorization issue (CWE-284). The attacker invokes the folder move operation against renameFolder.php, supplying a source folder they own and a destination parent that they are not authorized to target. The endpoint checks authorization against the source (which passes) and CSRF validity (which passes) but omits the destination-parent authorization check. The request therefore proceeds despite the destination being outside the attacker's authorized scope.

3) Execution Method (Class-Level). The attacker attempts to relocate the owned folder tree under another user's existing folder or into the root namespace. Per the description, the destination must be unused and existing victim files cannot be overwritten, so the attacker targets empty/unoccupied destination parents. The move rekeys ownership and ACL records to the new path. No specific payload, function name, or parameter name beyond renameFolder.php is disclosed, and none is assumed here.

4) Post-Exploitation Impact. Successful exploitation yields unauthorized relocation of a folder tree into another user's namespace (or root), with ownership/ACL metadata rewritten to the new path. This can disrupt victim namespace organization and alter access-control anchoring. Additionally, the differential error behavior can be used as a path-existence oracle to probe whether specific destination paths exist — an information-gathering primitive that supports further targeted moves, but does not expose directory listings or file contents.

No public PoC available; attack chain is inferred from vulnerability class.

Impact Assessment

The CVSS v3.1 base score is 5.4 (Medium), vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N. Reading the subscores:

• AV:N (Network) — exploitable remotely over the web interface.
• AC:L (Low) — no special conditions beyond holding a qualifying account and CSRF token.
• PR:L (Low) — requires an authenticated, low-privileged user.
• UI:N (None) — no victim interaction required.
• S:U (Unchanged) — impact is confined to FileRise's own security scope.
• C:L / I:L — limited confidentiality (path-existence oracle) and limited integrity (unauthorized move and ACL rekeying).
• A:N — no availability impact; overwrite is prevented.

Business impact centers on multi-tenant file-manager deployments where per-user folder isolation is a security expectation. A broken cross-user folder boundary undermines namespace and access-control integrity, which can be a compliance concern in regulated environments that depend on logical data separation. Blast radius is bounded by the requirement that the attacker own the source folder and that the destination be unused; mass overwrite of victim data is not possible per the description.

Detection Guidance

Sigma Rule

title: FileRise Unauthorized Cross-User Folder Move (renameFolder.php)
id: 3f9a1c2e-filerise-2026-103988-sigma
status: experimental
description: Detects move/rename operations on FileRise renameFolder.php where the destination parent differs from the source scope, indicating CVE-2026-103988 improper authorization.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-103988
author: SOC Threat Intelligence
date: 2026/01/01
logsource:
  category: webserver
  product: generic
detection:
  selection_endpoint:
    cs-uri-stem|endswith: '/api/folder/renameFolder.php'
  selection_method:
    cs-method: 'POST'
  selection_dest:
    cs-uri-query|contains:
      - 'destination'
      - 'dest'
      - 'parent'
  condition: selection_endpoint and selection_method and selection_dest
fields:
  - c-ip
  - cs-username
  - cs-uri-query
falsepositives:
  - Legitimate user reorganizing their own folders within their own namespace
level: medium

YARA Rule

rule FileRise_CVE_2026_103988_FolderMove_Authz
{
    meta:
        description = "Detects FileRise renameFolder.php handling consistent with CVE-2026-103988 improper destination authorization"
        author = "SOC Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-103988"
        date = "2026-01-01"
        severity = "medium"
    strings:
        $ep        = "renameFolder.php" ascii wide nocase
        $src       = "source" ascii wide nocase
        $dst       = "destination" ascii wide nocase
        $acl       = "ACL" ascii wide nocase
        $rekey     = "rekey" ascii wide nocase
        $apipath   = "/api/folder/" ascii wide nocase
    condition:
        uint16(0) == 0x3C3F or $ep or $apipath and
        (2 of ($src, $dst, $acl, $rekey))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-103988 FileRise renameFolder.php Unauthorized Destination Move Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/api/folder/renameFolder.php"; nocase; http.request_body; content:"destination"; nocase; http.request_body; content:"source"; nocase; classtype:attempted-user; reference:cve,CVE-2026-103988; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-103988; sid:2026103988; rev:1;)

Elastic Detection

sequence by user.name with maxspan=2m
  [ network where url.path == "/api/folder/renameFolder.php" and http.request.method == "POST" and
      url.query contains "destination" ]

Splunk SPL Query

index=web sourcetype=access_combined
| search uri_path="/api/folder/renameFolder.php" method=POST
| eval dst_provided=if(match(uri_query,"destination|dest|parent"),1,0)
| where dst_provided=1
| stats count values(uri_query) as queries by src_ip user
| where count >= 2
| sort - count

Wazuh OSSEC Rule

<group name="filerise,web,cve-2026-103988,">
  <rule id="103988" level="8">
    <if_sid>31100</if_sid>
    <id>^/api/folder/renameFolder.php</id>
    <match>POST</match>
    <description>CVE-2026-103988: FileRise folder move request to renameFolder.php - possible unauthorized cross-user destination move.</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>access_control,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED (no patch evidence from any tracked source). The NVD description states the issue "is fixed in version 3.23.0," but no patch source is confirmed by tracked feeds and no vendor advisory is available. Treat as unpatched until a verifiable fixed release is obtained from the vendor.

1) Immediate mitigations

• Restrict network reachability of FileRise instances; do not expose the folder-management API to untrusted networks. Place it behind authentication-aware reverse proxies or VPN.
• Enforce strict per-user namespace isolation at the proxy or application tier if configurable.
• Audit and monitor renameFolder.php POST requests, especially those where the destination parent is outside the caller's own namespace (see detection rules above).
• Log and alert on differential error responses that could serve as a destination-path existence oracle.

2) Patch/upgrade steps

• Deploy FileRise 3.23.0 or later once a vendor-verifiable release is available, and confirm the fix independently (no patch source is currently tracked).
• After upgrade, validate that destination-parent authorization is enforced by testing a cross-user move attempt with a low-privileged account.
• Reconcile folder ownership and ACL records to detect any unauthorized rekeying that occurred prior to remediation.

3) Long-term hardening

• Apply least privilege to accounts; minimize the number of principals able to own/move folders.
• Adopt a centralized authorization model that validates both source and destination scopes for every move/rename operation.
• Enable comprehensive audit logging of folder ownership and ACL changes, with periodic reconciliation reviews.
• Maintain an inventory of self-hosted file managers and track their exposure; subscribe to vendor security advisories.

References

• NVD — CVE-2026-103988: https://nvd.nist.gov/vuln/detail/CVE-2026-103988
• NVD CVSS v3.1 Calculator / Vector Reference: https://nvd.nist.gov/vuln-metrics/cvss
• MITRE CWE-284 — Improper Access Control: https://cwe.mitre.org/data/definitions/284.html
• MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
• CISA Known Exploited Vulnerabilities Catalog (check for CVE-2026-103988): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No CISA KEV listing, no public PoC, no exploit code, no Nuclei template, and no threat-actor campaign tied to CVE-2026-103988 were identified in the provided intelligence. The vulnerability is not yet scored by FIRST.org (EPSS unavailable).