filebrowser

CVE-2026-116682: CVE-2026-116682: Arbitrary File Read via Improper Symlink Resolution in FileBrowser Quantum CVE-2026-116682: Arbitrary File Read via Improper Symlink Resolution in FileBrowser Quantum > Vulnerability ID: CVE-2026-116682 > CVSS Score: 8.6 > Published: 2026-10-27 FileBrowser Quantum prior to versions 1.5.2-stable and 2.0.1-beta contains an improper link resolution vulnerability (CWE-59) in its file indexing and retrieval subsystems. When processing file read, download, preview, media streaming, OnlyOffice integration, or public share requests, the application resolves symbolic links via Go's filepath.EvalSymlinks without verifying that the canonical target path remains within the configured source root and the user's assigned access scope. Consequently, authenticated users with read access or unauthenticated holders of public share links can read arbitrary server-accessible files outside their designated directory boundaries. TL;DR FileBrowser Quantum fails to validate canonical paths after resolving symbolic links during file read operations. An authenticated user or an anonymous user accessing a public share can exploit an in-scope symbolic link to read arbitrary files from the underlying server filesystem. Upgrading to version 1.5.2-stable or 2.0.1-beta resolves this vulnerability by enforcing strict path containment checks and scoped root file descriptors. --- ⚠️ Exploit Status: POC Technical Details - CVE ID: CVE-2026-116682 (GHSA-mgqf-5mf5-prfj) - Weakness Class: CWE-59 (Improper Link Resolution) / CWE-22 (Path Traversal) - CVSS v3.1 Score: 8.6 High (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N) - Attack Vector: Network (HTTP/HTTPS via authenticated user or anonymous public share) - Security Impact: Arbitrary File Read outside user scope and server source root - Affected Component: backend/pkg/indexing/indexingFiles.go (GetRealPath & resolvePathContext) - Patched Versions: 1.5.2-stable and 2.0.1-beta - CISA KEV Status: Not Listed Affected Systems - FileBrowser Quantum (gtsteffaniak/filebrowser) - FileBrowser Quantum (v1.x series): < 1.5.2-stable (Fixed in: 1.5.2-stable) - FileBrowser Quantum (v2.x beta series): >= 2.0.0-beta, < 2.0.1-beta (Fixed in: 2.0.1-beta) Code Analysis Commit: 4126ede fix GHSA-mgqf-5mf5-prfj (#2795) - Enforces symlink containment within source root and user scope for v1.5 branch Commit: 3c8c024 Beta/v2.0.1 (#2800) - Enforces symlink containment within source root and user scope for v2.0 branch Mitigation Strategies - Upgrade FileBrowser Quantum to version 1.5.2-stable (for v1.x deployments) or 2.0.1-beta (for v2.x deployments) to enforce canonical path containment checks. - Audit backend storage directories and remove symbolic links that point outside designated user scopes or source roots. - Isolate the FileBrowser Quantum process using containerization or OS mount namespaces so that sensitive host OS files and application databases are not accessible within the same filesystem namespace. - Review and restrict public share links to ensure shared directories do not contain symbolic links. Remediation Steps: 1. Identify the currently deployed version of FileBrowser Quantum across all environments. 2. Scan all configured source roots for existing symbolic links using find /path/to/source -type l -ls and remove any unauthorized or out-of-scope links. 3. Pull the patched binary or container image corresponding to v1.5.2-stable or v2.0.1-beta from the official gtsteffaniak/filebrowser repository. 4. Restart the FileBrowser Quantum service and verify that attempts to access out-of-scope symlinks return HTTP 403 Forbidden. References - Official CVE Record: CVE-2026-116682 - National Vulnerability Database (NVD): CVE-2026-116682 - GitHub Security Advisory: GHSA-mgqf-5mf5-prfj - GitHub Fix Commit (v1.5 Branch): 4126edeb07a015c3809a89249b283e07a4e50c38 - GitHub Fix Commit (v2.0 Branch): 3c8c02414eefd3351ffe437fa39ff6eb150ffa67 - GitHub Pull Request #2795 (v1.5 Fix) - GitHub Pull Request #2800 (v2.0 Fix) - FileBrowser Quantum Release v1.5.2-stable - FileBrowser Quantum Release v2.0.1-beta - CVE List v5 Repository Entry: CVE-2026-116682 --- Read the full report for CVE-2026-116682 on our website for more details including interactive diagrams and full exploit analysis.

自分のファイル管理を、ブラウザから使える形にしたい？ FileBrowser Quantumはself-hosted web file manager。複数sourceのinclude/exclude、検索、preview/edit、OIDCやLDAPなどの認証を備えます。 gtsteffaniak/filebrowser

FileBrowser Quantum: The best free self-hosted web-based file manager (8.7k stars) What it does All text below is quoted directly from the project README. >FileBrowser Quantum: The best free self-hosted web-based file manager. >FileBrowser Quantum provides an easy way to access and manage your files from the web. It has a modern responsive interface that has many advanced features to manage users, access, sharing, and file preview and editing. >This version is called "Quantum" because it packs tons of advanced features into a tiny and easy-to-run file. Unlike the majority of alternative options, FileBrowser Quantum is simple to install and easy to configure. >The goal for this repo is to become the best open-source self-hosted file browsing application that exists -- all for free. This repo will always be free and open-source. >v2.0.0 is now stable! How its different: >FileBrowser Quantum is a massive fork of the file browser open-source project with the following changes: 1. Better source configuration - multiple sources, include/exclude rules, and more 2. Login support for OIDC, LDAP, JWT, password + 2FA, and proxy. 3. Beautiful, Responsive, and Customizable user interface. 4. Streamlined configuration via config.yaml config file. 5. Efficient search - Real-time search results as you type. - Real-time monitoring and updates in the UI. - Search supports file and folder sizes, along with various filters. 6. Better listing browsing - Thumbnails support includes office, video, and album artwork, and 3D models. - Faster and more responsive views with animations. - Folder sizes are displayed and support thumbnails - Navigating remembers the last scroll position. - WebDAV support - Granular permissions 7. Highly configurable and customizable sharing options - share expiration time - users who can access share (including anonymous) - styling and themes - file viewing, editing, and uploading permissions 8. Access control that can be scoped to user or group and source path. 9. Developer API support - Ability to create long-lived API Tokens. - A helpful Swagger page is available at /swagger endpoint for API enabled users. >Notable features that this fork does not have (removed): - shell commands are completely removed and will not be returned. >FileBrowser Quantum differs significantly from the original version. Many of these changes required a significant overhaul. Creating a fork was a necessary process to make the program better. There have been many growing pains, but a stable release is planned and coming soon. The UI: >The UI has a simple three-component navigation system: 1. (Left) Multi-action button with slide-out panel. 2. (Middle) The powerful search bar / title 3. (Right) The view change toggle / overflow menu >All other functions are moved either into the action menu or pop-up menus. If the action does not depend on context, it will exist in the slide-out action panel. If the action is available based on context, it will show up as a pop-up menu. Repository gtsteffaniak/filebrowser Repository stats |Metric|Value| |:-|:-| |Stars|8,705| |Forks|477| |Last release|v2.0.1-stable (2026-10-13)| |Languages|Go 51.1%, Vue 28.7%, JavaScript 9.7%| |Contributors|86| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|claude (11 commits), cursoragent (6)| |AI co-authored commits|Claude: 11, Cursor: 6, Copilot: 1| Main contributor |Field|Value| |:-|:-| |Name|Henrique Dias| |GitHub|@hacdias| |Commits to this repo|1,500 (top contributor)| |Company / Location|Netherlands| |Followers|1k|

🔥 Поиск по файлам на Mac, файлы NAS в браузере и ещё 1 - находки GitHub #shorts #github #opensource Больше полезных находок каждый день - в Telegram: t.me Подборка интересных находок с GitHub за 12.10.2026: ARahim3/DigUp, gtsteffaniak/filebrowser, docker/docker-agent. Сохраняй, чтобы не потерять 💾 ARahim3/DigUp: ARahim3/DigUp Приложение для macOS в строке меню: семантический поиск по содержимому файлов - фото, PDF, записей, видео и кода. Всё работает локально на устройстве на базе EmbeddingGemma 2, так что подойдёт тем, кто хочет искать по своим данным, не отправляя их в облако. gtsteffaniak/filebrowser: gtsteffaniak/filebrowser Веб-интерфейс для управления файлами на сервере: просмотр, загрузка и редактирование через браузер. Это форк File Browser на Go и Vue, подойдёт тем, кто self-host'ит файлы на домашнем сервере или NAS. docker/docker-agent: docker/docker-agent Конструктор и рантайм AI-агентов от инженеров Docker, написанный на Go. Пригодится разработчикам, которые хотят собирать и запускать своих агентов в привычной контейнерной экосистеме. #shorts #dev #github #useful #opensource гитхаб, гитхаб подборка, лучшее на гитхаб, новое гитхаб, гитхаб бесплатно, гитхаб ии, гитхаб мсп, гитхаб репы, гитхаб репозитории, лучшие репозитории, рейтинг гитхаб, github ai, best github, new github

Filebrowser Quantum v2.0.0-stable release is ready! Hey everyone, it has been over 1 year since my last post on this subreddit about my fork of filebrowser. Since then, the OG filebrowser github has been archived and my fork has hit both v1.0.0-stable -- and now v2.0.0-stable! It's called FileBrowser Quantum -- I have been working on this repo for almost 4 years and is still actively and officially maintained by myself and Kevin. We both handle issues and make changes nearly every day on the repository. The vast majority of code is unique to my repo, this is not a simple fork. Everything has been refactored with standards and security in mind -- none of the vulnerabilies of the original exist anymore. v2.0.0 is now available in stable! It does take a little effort to migrate over to if you are currently on a v1.x track, but it lays the groundwork for some of the biggest features to come. The progress on this repository is growing faster every day. There's lots of changes and features planned, you can see them on my github issues github.com/gtsteffaniak/filebrowser/issues which is where I would like everyone to post suggestions and issues they find. Reddit is great for visibility but I don't add feature requests or troubleshoot issues here -- open an issue on github for official support. For general questions, github discussions are still a good place as well. Some third-party installations like truNAS, unRAID, homeassistent plugins may need time to get updated to support the v2.0.0 config format. I would love to have the communities help to identify and open issues with those repositories to help everyone make this transition smoother. v2.0.0 sets the stage for so many features to come. Stable is a great place to start, I recommend beta only to those willing to experience some bugs and want to be involved in github. I hope FileBrowser Quantum finds a home on your server -- there has never been a better time to self host your own software. See you on github! Also quick PSA: Using archived/unmaintained software connected to the internet is extremely dangerous. The security risks are higher than they have ever been in the past. Web-based file applications like this are especially dangerous. I take security very seriously and I would recommend everyone to take a close look at how frequently applications are updated and how often the maintainers accept security advisories. Many maintainers reject AI submissions. We review every security report carefully, including automated and AI-assisted ones and validate fixes before merge.

Securely sharing media from OpenMediaVault with FileBrowser Quantum and Cloudflare Tunnel --- title: Securely sharing media from OpenMediaVault with FileBrowser Quantum and Cloudflare Tunnel published: true date: 2026-10-11 13:23:32 UTC tags: selfhosted, homelab, cloudflare, tutorial canonical_url: baqueano.hashnode.dev --- Context Recently I've had the opportunity to work on a few long-form media projects. These projects required us to collect what I would consider a fair bit of media for what are relatively small theatre companies that wanted to try their hand at increasing their social media exposure for shows. To give you an idea, one project required multiple photo shoots, which resulted in hundreds of photos, and then required full recordings of a tech run and a final recording of the full show on closing night. The stills and video needed to be processed like normal, but the videos needed to be taken further to create trailers and social media content, and also cut into clips so that actors could show off their performances in their portfolios. To give you a sense of how the data scaled, a single 3-hour show run in 4K ProRes 422 HQ comes to roughly 800GB. Multiply this by two because we have to do closing night too, and we have ~1.6TB of footage. The 600 Fuji RAW files then add another ~10GB. After a few days of editing we can shrink this down to a few ~25GB renders, each with different colour grades and feels, and about 4GB of stills. This is great, that's a lot of space saved. Final project files end up being ~80GB give or take. Oh, and those renders are H.265. Yes, I know AV1 exists, but we have to stay compatible with client hardware. And nobody is building new PCs with the current price of hardware. !cdn.hashnode.com The problem Typically my projects don't require 3 hours of straight recording, so I've been able to get away with juggling cloud services. If the final render is under 15GB I can just use Google Drive and let Google handle security and links. If not, maybe we need to split project files and put the stills on Dropbox to make it all work. But free tiers only go so far, and growing them 500MB at a time with referrals isn't a plan. And what happens when a client asks for the raw footage? If you've made it this far, thank you, and you can probably guess where this is going: how do I get these files to clients without mailing or lending out my 2TB NVMe? The obvious answer is yet another monthly subscription for 1–2TB of cloud storage. The _responsible_ answer might be Azure Storage, handing out SAS URLs to blobs, and wrapping everything in password-protected zips. But that's boring, and I've got a Dell R730xd under my desk that's spent far too long as a footrest. Part 1 - The setup The server I received already came with ESXi installed and a few TBs that are managed through an internal RAID controller. I won't go into too much detail about the server itself, since the same result can be achieved on bare metal, a VM or containers. The main requirement is a place you can install OpenMediaVault (OMV) and a big storage pool. I was lucky enough that the server came with an HDD1 store of 12TB, and I've added HDD2 and HDD3 as supplementary storage for apps, config backups and other things. !cdn.hashnode.com !cdn.hashnode.com I've chosen to separate the data by using HDD1 as the main storage location for FileBrowser Quantum and HDD2 for Docker components and any other configs, because I prefer the physical boundary. You don't have to do it this way. You may well only have one giant pool; you'll still be able to separate the locations using OMV's shared folder functionality. Installing the OS - * * OMV has a lot of useful documentation, and the installation process is pretty straightforward with their installer. You burn the ISO to a USB and boot into the installer. If you're on Windows, Rufus is the tool I use; otherwise Etcher or dd can be used on Linux. Through ESXi we can skip all that and upload the ISO image directly to one of our datastores, so that we can bind it to the VM during the creation step. We then run through the VM creation steps, choosing Linux as the guest OS family, Debian as the OS version, and binding the ISO. !cdn.hashnode.com > Another great tweak is to enable the VM to start on boot, so if the server restarts or something happens the VM automagically comes back online. You should now be able to follow the standard installation guide from OMV and end up with a similar-looking terminal displaying an IP that hosts the web frontend, and some credentials to use on the login page. !cdn.hashnode.com Install done. Configuring OpenMediaVault - * * At this stage you should be able to log in to OMV through your browser and click around to familiarise yourself with the interface. I would also strongly recommend you check for updates under System -> Update Management -> Updates so that you have the latest security fixes and features. Oh, and make sure all your disks show up under Storage -> Disks We should now be able to start creating Shared Folders and set up SMB. I will create three Shared Folders: 1. DockerAppData - Where we store our Docker compose files 2. FileBrowserShares - Where we store what we want to share 3. Media1 - The original location of all our data (optional) !cdn.hashnode.com > I have Media1 here because I was already using OMV for storing the giant RAW footage. Everything can work off a single share, but then all of it will be exposed to the container. Now we just need to enable a way to move files over the network to OMV. Personally I picked SMB for this, since NFS permissions are IP-based and file ownership uses user IDs. Rsync is also a really good option for large files. Head down to Services -> SMB/CIFS -> Settings and enable it there. You should now be able to create SMB shares under Services -> SMB/CIFS -> Shares Another optional step is to create a user or a group if you want to limit actions. You should only need one or two shares depending on your setup. Point them at the correct Shared Folders from the previous step: 1. FileBrowserShares - Where we drop our final render 2. Media1 - Where we store the raw footage !cdn.hashnode.com !cdn.hashnode.com Add it to your file browser of choice or your fstab file and test. Setting up OMV Docker - * * With OMV Shared Folders done and SMB set up, we now need to set up Docker and omv-extras, a set of community-maintained packages that add extra functionality. In a terminal, either directly or through SSH, we need to run the install script. wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | bash You should now have a new option in your sidebar under System -> omv-extras Tick the Docker repo box and click the big blue Save button. Then run apt clean and wait until it says done. With omv-extras enabled we should now be able to install openmediavault-compose, which will let us create our Docker containers from compose files. Install the plugin under System -> Plugins and refresh the page. If you get a connection lost message, it's because OMV restarts its web UI server; just refresh the browser. !cdn.hashnode.com !cdn.hashnode.com In your sidebar you should now see a new Services -> Compose -> Settings page, which we will need to set up. The first thing you'll want to change is your compose files shared folder. Point this to your DockerAppData shared folder and hit Save. Then hit Install or Reinstall Docker. !cdn.hashnode.com > DON'T FORGET TO HIT INSTALL OR REINSTALL DOCKER AT THE BOTTOM Part 2 - Installing FileBrowser and cloudflared At this point you should have OMV installed with SSH or direct terminal access, a few Shared Folders set up, SMB or some other way to sync files over the network, and omv-extras with Docker enabled and configured for compose files. One hard requirement for this second part is a domain using Cloudflare DNS (the free plan is fine), which gives you access to Cloudflare Zero Trust tunnels. With that said, we're going to start this section by getting the tunnel set up before continuing with OMV. So go ahead and open a new tab or browser window. We're going to start by creating a tunnel through the Cloudflare dashboard. You should be able to find the option under Protect and Connect -> Zero Trust This should redirect you to a new page with a different nav bar that should have Networks -> Tunnels Here you should be able to create a new tunnel of type Cloudflared, then for your connector make sure you select Docker. !cdn.hashnode.com > IMPORTANT: Save the token displayed on this page, as it will be used in our compose file later. Finally, at the publish step you should be able to set a subdomain and a path. I've chosen files as my subdomain, so I get files.[my-domain].com. The other crucial step here, if you want to narrow access to just the generated links, is to set the Path field to ^/public/.*. This stops intruders from spamming your login page and scraping anything that's outside of FileBrowser's public folder. The tradeoff is that you also won't be able to access the login page or application externally. For me this isn't an issue, as 90% of the time I will be accessing it locally. Lastly, the service section is the connection between our cloudflared container and FileBrowser Quantum container. We want to set the type to HTTP because FileBrowser serves plain HTTP and this hop never leaves the VM. Visitors still get HTTPS via Cloudflare, and the tunnel itself is encrypted. Set the URL to filebrowser:80 (we can use the container names here since Docker provides name resolution between containers; alternatively you could use [server-ip]:8080). !cdn.hashnode.com !cdn.hashnode.com With the tunnel all set up, we can go back to OMV and start writing our compose file! Final steps - Back to OMV - * * OK, we're nearly done. Hopefully you haven't run into any issues! With the tunnel all set up, we can write our configs and compose files and try to spin up our containers! For this step, make sure you have that tunnel connector token handy. First we're going to create the FileBrowser config file, so that when the container spins up it's ready to go. This typically lives under a /data folder in FileBrowser. We're also going to create a separate volume in our container called /deliveries that will be the publicly exposed directory. Create a new folder under DockerAppData/filebrowser/data: mkdir -p "/srv/dev-disk-by-uuid-[disk-uuid]/DockerAppData/filebrowser/data" Now create a new config.yaml file inside this folder using a text editor such as nano or vim. Make sure you set your external URL correctly. http: externalUrl: "https://files.[domain].com" trustProxyHeaders: true disableWebDAV: true server: cacheDir: /home/filebrowser/data/tmp sources: - path: /deliveries name: Deliveries config: defaultEnabled: true frontend: name: "MySiteName" description: "Client video delivery" > The path here needs to match the compose file's volume from our next step, so take note. Lastly, we need to set the owner to the container's user so it can read and write to its database. chown -R 1000:1000 "/srv/dev-disk-by-uuid-[disk-uuid]/DockerAppData/filebrowser/data" Now for our compose file. Back in OMV's web UI we can create compose files directly by navigating to Services -> Compose -> Files You should get a form where you can copy and paste the following YAML, substituting your disk UUIDs and your token from Cloudflare's tunnel setup. services: filebrowser: image: ghcr.io/gtsteffaniak/filebrowser:2.0-stable container_name: filebrowser restart: unless-stopped ports: - "8080:80" volumes: - /srv/dev-disk-by-uuid-[disk-uuid]/FileBrowserShares:/deliveries:ro - /srv/dev-disk-by-uuid-[disk-uuid]/DockerAppData/filebrowser/data:/home/filebrowser/data cloudflared: image: cloudflare/cloudflared:latest container_name: cloudflared restart: unless-stopped command: tunnel --no-autoupdate run --token [MyBigToken] depends_on: - filebrowser !cdn.hashnode.com You'll notice here that we mount /deliveries and /data from our previous step. The rest of the YAML is pretty self-explanatory. Hit that Save button. > The :ro at the end of the /deliveries volume mounts it read-only. FileBrowser can show and share your files, but it can never modify or delete them, even if something goes wrong. I've done this because I'm testing and didn't want to accidentally delete files. Once you're happy you can remove this Back in the main list you should be able to see a new row containing the new FileBrowser compose file. Select the row and click the "Up" button in the toolbar. This will download the images and spin up our containers! !cdn.hashnode.com Part 3 - The fun part! - * * If everything went well, you should see a green "Up" status and the bound ports on the right. You can click the URLs or navigate to your server's IP on port 8080 and see a login screen! !cdn.hashnode.com You'll need to grab the credentials from the Docker logs, as they are auto-generated by default. You can do this in the terminal using: docker logs filebrowser 2>&1 | grep -i password Log in as admin using that password (you'll be asked to set a new one straight away), and you should be greeted with an empty dashboard! You can now prep some files and drag them through SMB, or whatever network method you chose before, into your FileBrowserShares shared folder and they will appear! !cdn.hashnode.com Back in Cloudflare Tunnels you should now be able to see a Healthy status and one active connector, which confirms everything is hooked up correctly. !cdn.hashnode.com Testing Links - * * The final step is to right-click a directory or file and hit Share to generate a link! Give it an expiration time and a password and test it internally. You can then send it to someone, or test it on your phone, to make sure it works externally. You should also test that hitting files.[domain].com directly results in a 404, as we don't want direct traffic. If you've reached the end, everything should be working, and your FileBrowser instance should be tunnelled and only allow publicly served content and links in and out. Conclusion This was quite a journey, I'm not going to lie. It was my first time working with Cloudflare and its many features, and frankly I'm not convinced it's the absolute best solution to my problem. Maybe blob storage in a cloud provider would have been way easier, who knows. But it was an interesting mini project that taught me a lot, and I'll be testing it out for a few months. Ive heard Cloudflare could potentially throttle this solution since serving large video is restricted and has to be routed through their paid services like Stream or R2 but the writing on the wall is that it only applies to 'disproportionate' usage. it will be interesting to see if this applies to my case of a few files a month. If anybody knows of any other similar solutions, let me know! I'd love to see how other people have solved this. - * * References - openmediavault.org - docs.openmediavault.org - gtsteffaniak/filebrowser - forum.openmediavault.org - cloudflare.com - blog.cloudflare.com