Skip to content

File Browser: Proxy auth auto-provisioned users inherit Execute permission and Commands

High severity GitHub Reviewed Published Apr 4, 2026 in filebrowser/filebrowser • Updated Apr 8, 2026

Package

gomod github.com/filebrowser/filebrowser/v2 (Go)

Affected versions

< 2.63.1

Patched versions

2.63.1

Description

Summary

The fix in commit b6a4fb1 ("self-registered users don't get execute perms") stripped Execute permission and Commands from users created via the signup handler. The same fix was not applied to the proxy auth handler. Users auto-created on first successful proxy-auth login are granted execution capabilities from global defaults, even though the signup path was explicitly changed to prevent execution rights from being inherited by automatically provisioned accounts.

Confirmed on v2.62.2 (commit 860c19d).

Root Cause

auth/proxy.go createUser() applies defaults without restriction:

user := &users.User{
    Username:     username,
    Password:     hashedRandomPassword,
    LockPassword: true,
}
setting.Defaults.Apply(user)
// No restriction on Execute, Commands, or Admin

Compare with http/auth.go signup handler (lines 170-178):

d.settings.Defaults.Apply(user)
user.Perm.Admin = false
// Self-registered users should not inherit execution capabilities
// from default settings, regardless of what the administrator has
// configured as the default.
user.Perm.Execute = false
user.Commands = []string{}

The commit message for b6a4fb1 states: "Execution rights must be explicitly granted by an admin." Users auto-created via proxy auth are also automatically provisioned (created on first login without explicit admin action), and the admin has not explicitly granted them execution rights.

PoC

Tested on filebrowser v2.62.2, built from HEAD.

# Configure with proxy auth, default commands, and exec
filebrowser config set --auth.method=proxy --auth.header=X-Remote-User \
  --commands "git,ls,cat,id"

# Login as admin and verify defaults have execute=true, commands set
ADMIN_TOKEN=$(curl -s http://HOST/api/login -H "X-Remote-User: admin")

# Auto-create new user via proxy header
PROXY_TOKEN=$(curl -s http://HOST/api/login -H "X-Remote-User: newproxyuser")

# Check permissions
curl -s http://HOST/api/users -H "X-Auth: $ADMIN_TOKEN" | jq '.[] | select(.username=="newproxyuser") | {execute: .perm.execute, commands}'

Result:

{
  "execute": true,
  "commands": ["git", "ls", "cat", "id"]
}

The auto-created proxy user inherited Execute and the full Commands list. A user created via signup would have execute: false and commands: [].

Impact

In proxy-auth deployments where the admin has configured default commands, users auto-provisioned on first proxy login receive execution capabilities that were not explicitly granted. The project established a security invariant in commit b6a4fb1: automatically provisioned accounts must not inherit execution rights from defaults. The proxy auto-provisioning path violates that invariant.

This is an incomplete fix for GHSA-x8jc-jvqm-pm3f ("Signup Grants Execution Permissions When Default Permissions Includes Execution"), which addressed the signup handler but not the proxy auth handler.

Preconditions

  • Proxy auth enabled (--auth.method=proxy)
  • Exec not disabled
  • Default settings include non-empty Commands (admin-configured)

Suggested Fix

Apply the same restrictions as the signup handler:

setting.Defaults.Apply(user)
user.Perm.Admin = false
user.Perm.Execute = false
user.Commands = []string{}

Update: Fix submitted as PR #5890.

References

@hacdias hacdias published to filebrowser/filebrowser Apr 4, 2026
Published by the National Vulnerability Database Apr 7, 2026
Published to the GitHub Advisory Database Apr 8, 2026
Reviewed Apr 8, 2026
Last updated Apr 8, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(23rd percentile)

Weaknesses

Improper Privilege Management

The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor. Learn more on MITRE.

CVE ID

CVE-2026-35607

GHSA ID

GHSA-7526-j432-6ppp

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.