Common Weakness Enumeration

CWE-61

Allowed

UNIX Symbolic Link (Symlink) Following

Abstraction: Compound · Status: Incomplete

The product, when opening a file or directory, does not sufficiently account for when the file is a symbolic link that resolves to a target outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.

270 vulnerabilities reference this CWE, most recent first.

GHSA-9X6C-XP5W-CH33

Vulnerability from github – Published: 2026-06-23 15:32 – Updated: 2026-07-02 21:32
VLAI
Details

pwnlift before d7a9544, in a privileged deployment, contains a symlink following vulnerability in the upload handler in Components/Pages/Home.razor.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-56815"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-23T15:16:40Z",
    "severity": "HIGH"
  },
  "details": "pwnlift before d7a9544, in a privileged deployment, contains a symlink following vulnerability in the upload handler in Components/Pages/Home.razor.",
  "id": "GHSA-9x6c-xp5w-ch33",
  "modified": "2026-07-02T21:32:04Z",
  "published": "2026-06-23T15:32:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56815"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rasta-mouse/pwnlift/commit/d7a95449d9ee1ea09ec1529286685f6187afbbed"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2026/06/23/2"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2026/Jul/10"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C9G9-8P38-4P39

Vulnerability from github – Published: 2024-03-08 03:31 – Updated: 2026-04-02 21:31
VLAI
Details

This issue was addressed with improved handling of symlinks. This issue is fixed in macOS Sonoma 14.4. An app may be able to create symlinks to protected regions of the disk.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-23285"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59",
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-08T02:15:49Z",
    "severity": "HIGH"
  },
  "details": "This issue was addressed with improved handling of symlinks. This issue is fixed in macOS Sonoma 14.4. An app may be able to create symlinks to protected regions of the disk.",
  "id": "GHSA-c9g9-8p38-4p39",
  "modified": "2026-04-02T21:31:38Z",
  "published": "2024-03-08T03:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23285"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120895"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT214084"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214084"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Mar/21"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CCV6-R384-XP75

Vulnerability from github – Published: 2026-06-19 21:18 – Updated: 2026-06-19 21:18
VLAI
Summary
Langflow: BaseFileComponent-based nodes arbitrary file read with RCE exploit
Details

Summary

All components based on BaseFileComponent are vulnerable to the following vulnerability: 1. Docling (DoclingInlineComponent) 2. Docling Serve (DoclingRemoteComponent) 3. Read File (FileComponent) 4. NVIDIA Retriever Extraction (NvidiaIngestComponent) 5. Video File (VideoFileComponent) 6. Unstructured API (UnstructuredComponent)

For clarity, from now on I'll only refer to Read File component.

The Read File node processes user-controlled files. Example scenario is a RAG chatbot - a system that allows users of an organization to ask questions about documents saved in the organizations.

By controlling a files that are digested into the RAG, an attacker can direct the node to read any file on the file-system by absolute path.

Using this vulnerability an attacker can acheive RCE: 1. Upload a file that directs the node to read Langflow's secret_key file containing the JWT token secret. 2. This would allow the attacker then to simply task the Chatbot for the JWT secret. 3. Using this secret, the attacker then crafts a JWT token for any user-id, bypassing authentication. 4. Code execution is then trivial - simply create a new flow with "Python Interpreter" node, fill it with arbitrary Python code and execute it.

Tested on commit 2d67402b1dbaefcbce85a244d4a6cd5e4bda1cfe

Details

The vulnerability is in: langflow/src/lfx/src/lfx/base/data/base_file.py Specifically in _unpack_bundle. This function extracts tar files, which can contain a symlink. This symlink can point to any file in the filesystem. Then, in self.process_files(), the file pointed by the symlink will be parsed and saved into the RAG. This can be done with unlimited number of symlinks in the same tar which can also be useful in some scenarios.

Suggestd fix - iterate over the files and make sure all are regular files or directories.

PoC

Reproduction: 1. Create a flow with Read File (or any other affected components), and connect its output to some storage such as Chroma DB. 2. Create a symlink pointing to any file. For the above exploit, point the symlink to langflow's JWT token file. 3. Compress this symlink with tar. 4. Upload it to the Read File component. 5. Check the database, or ask a Chatbot connected to this vector database for the contents of the file.

Concrete PoC:

  • Flow with RAG ingestion and a Chatbot around it: Vector Store RAG.json
  • Exploit tar: archive.tar.txt (remove .txt, GitHub blocked .tar)
  • Create a file /tmp/trip.docx with any contents in it
  • Ingest the file in the flow above, and ask the Chatbot a question about this file.

A demo showing the attack: https://github.com/user-attachments/assets/af00f700-f13f-4eac-848e-8afd11fb9297 In the demo the attacker steals Langflow secret key used to sign JWTs. The second stage of the attack, not shown in the demo, is using this key to sign a JWT token and executing Python code on the server using the Python code interpreter node.

Impact

Any Langflow user using any of the above mentioned components to ingest user-controlled data is affected. Depending on exact scenario, the user can also be exposed to an RCE risk.

Patches

Fixed in 1.9.2 via PR #12945. BaseFileComponent._unpack_bundle now rejects symlink and hardlink members (and any non-regular entries) during TAR extraction, with additional defensive symlink filtering during directory recursion and after extraction. Upgrade to 1.9.2 or later.

Ori Lahav Security Researcher @ Rubrik Inc.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "langflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55447"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T21:18:24Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Summary\nAll components based on `BaseFileComponent` are vulnerable to the following vulnerability:\n1. Docling (`DoclingInlineComponent`)\n2. Docling Serve (`DoclingRemoteComponent`)\n3. Read File (`FileComponent`)\n4. NVIDIA Retriever Extraction (`NvidiaIngestComponent`)\n5. Video File (`VideoFileComponent`)\n6. Unstructured API (`UnstructuredComponent`)\n\nFor clarity, from now on I\u0027ll only refer to Read File component.\n\nThe Read File node processes user-controlled files.\nExample scenario is a RAG chatbot - a system that allows users of an organization to ask questions about documents saved in the organizations.\n\nBy controlling a files that are digested into the RAG, an attacker can direct the node to read *any* file on the file-system by absolute path.\n\nUsing this vulnerability an attacker can acheive RCE:\n1. Upload a file that directs the node to read Langflow\u0027s `secret_key` file containing the JWT token secret.\n2. This would allow the attacker then to simply task the Chatbot for the JWT secret.\n3. Using this secret, the attacker then crafts a JWT token for any user-id, bypassing authentication.\n4. Code execution is then trivial - simply create a new flow with \"Python Interpreter\" node, fill it with arbitrary Python code and execute it.\n\nTested on commit 2d67402b1dbaefcbce85a244d4a6cd5e4bda1cfe\n\n### Details\nThe vulnerability is in:\n`langflow/src/lfx/src/lfx/base/data/base_file.py`\nSpecifically in `_unpack_bundle`. This function extracts tar files, which can contain a symlink.\nThis symlink can point to any file in the filesystem. Then, in `self.process_files()`, the file pointed by the symlink will be parsed and saved into the RAG.\nThis can be done with unlimited number of symlinks in the same tar which can also be useful in some scenarios.\n\nSuggestd fix - iterate over the files and make sure all are regular files or directories.\n\n\n### PoC\nReproduction:\n1. Create a flow with Read File (or any other affected components), and connect its output to some storage such as Chroma DB.\n2. Create a symlink pointing to any file. For the above exploit, point the symlink to langflow\u0027s JWT token file.\n3. Compress this symlink with tar.\n4. Upload it to the Read File component.\n5. Check the database, or ask a Chatbot connected to this vector database for the contents of the file.\n\n\nConcrete PoC:\n------------\n\n- Flow with RAG ingestion and a Chatbot around it: [Vector Store RAG.json](https://github.com/user-attachments/files/25159960/Vector.Store.RAG.json)\n- Exploit tar: [archive.tar.txt](https://github.com/user-attachments/files/25159954/archive.tar.txt) (remove .txt, GitHub blocked .tar)\n- Create a file `/tmp/trip.docx` with any contents in it\n- Ingest the file in the flow above, and ask the Chatbot a question about this file.\n\nA demo showing the attack:\nhttps://github.com/user-attachments/assets/af00f700-f13f-4eac-848e-8afd11fb9297\nIn the demo the attacker steals `Langflow` secret key used to sign JWTs. The second stage of the attack, not shown in the demo, is using this key to sign a JWT token and executing Python code on the server using the Python code interpreter node.\n\n### Impact\nAny Langflow user using any of the above mentioned components to ingest user-controlled data is affected. Depending on exact scenario, the user can also be exposed to an RCE risk.\n\n\n### Patches\nFixed in **1.9.2** via PR [#12945](https://github.com/langflow-ai/langflow/pull/12945). `BaseFileComponent._unpack_bundle` now rejects symlink and hardlink members (and any non-regular entries) during TAR extraction, with additional defensive symlink filtering during directory recursion and after extraction. Upgrade to **1.9.2 or later**.\n\n\nOri Lahav\nSecurity Researcher @ Rubrik Inc.",
  "id": "GHSA-ccv6-r384-xp75",
  "modified": "2026-06-19T21:18:24Z",
  "published": "2026-06-19T21:18:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/langflow-ai/langflow/security/advisories/GHSA-ccv6-r384-xp75"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langflow-ai/langflow/pull/12945"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/langflow-ai/langflow"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Langflow: BaseFileComponent-based nodes arbitrary file read with RCE exploit"
}

GHSA-CGHW-HVR5-W2M2

Vulnerability from github – Published: 2023-01-12 15:30 – Updated: 2023-01-20 09:30
VLAI
Details

A symlink following vulnerability was found in Samba, where a user can create a symbolic link that will make 'smbd' escape the configured share path. This flaw allows a remote user with access to the exported part of the file system under a share via SMB1 unix extensions or NFS to create symlinks to files outside the 'smbd' configured share path and gain access to another restricted server's filesystem.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-3592"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59",
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-12T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A symlink following vulnerability was found in Samba, where a user can create a symbolic link that will make \u0027smbd\u0027 escape the configured share path. This flaw allows a remote user with access to the exported part of the file system under a share via SMB1 unix extensions or NFS to create symlinks to files outside the \u0027smbd\u0027 configured share path and gain access to another restricted server\u0027s filesystem.",
  "id": "GHSA-cghw-hvr5-w2m2",
  "modified": "2023-01-20T09:30:30Z",
  "published": "2023-01-12T15:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3592"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2022-3592"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2137776"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202309-06"
    },
    {
      "type": "WEB",
      "url": "https://www.samba.org/samba/security/CVE-2022-3592.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CGRX-MC8F-2PRM

Vulnerability from github – Published: 2025-11-05 18:40 – Updated: 2025-11-18 18:38
VLAI
Summary
runc container escape and denial of service due to arbitrary write gadgets and procfs write redirects
Details

Impact

This attack is primarily a more sophisticated version of CVE-2019-19921, which was a flaw which allowed an attacker to trick runc into writing the LSM process labels for a container process into a dummy tmpfs file and thus not apply the correct LSM labels to the container process. The mitigation runc applied for CVE-2019-19921 was fairly limited and effectively only caused runc to verify that when runc writes LSM labels that those labels are actual procfs files.

Rather than using a fake tmpfs file for /proc/self/attr/<label>, an attacker could instead (through various means) make /proc/self/attr/<label> reference a real procfs file, but one that would still be a no-op (such as /proc/self/sched). This would have the same effect but would clear the "is a procfs file" check. Runc is aware that this kind of attack would be possible (even going so far as to discuss this publicly as "future work" at conferences), and runc is working on a far more comprehensive mitigation of this attack, but this security issue was disclosed before runc could complete this work.

In all known versions of runc, an attacker can trick runc into misdirecting writes to /proc to other procfs files through the use of a racing container with shared mounts (runc has also verified this attack is possible to exploit using a standard Dockerfile with docker buildx build as that also permits triggering parallel execution of containers with custom shared mounts configured). This redirect could be through symbolic links in a tmpfs or theoretically other methods such as regular bind-mounts.

Note that while /proc/self/attr/<label> was the example used above (which is LSM-specific), this issue affect all writes to /proc in runc and thus also affects sysctls (written to /proc/sys/...) and some other APIs.

Additional Impacts

While investigating this issue, runc discovered that another risk with these redirected writes is that they could be redirected to dangerous files such as /proc/sysrq-trigger rather than just no-op files like /proc/self/sched. For instance, the default AppArmor profile name in Docker is docker-default, which when written to /proc/sysrq-trigger would cause the host system to crash.

When this was discovered, runc conducted an audit of other write operations within runc and found several possible areas where runc could be used as a semi-arbitrary write gadget when combined with the above race attacks. The most concerning attack scenario was the configuration of sysctls. Because the contents of the sysctl are free-form text, an attacker could use a misdirected write to write to /proc/sys/kernel/core_pattern and break out of the container (as described in CVE-2025-31133, kernel upcalls are not namespaced and so coredump helpers will run with complete root privileges on the host). Even if the attacker cannot configure custom sysctls, a valid sysctl string (when redirected to /proc/sysrq-trigger) can easily cause the machine to hang.

Note that the fact that this attack allows you to disable LSM labels makes it a very useful attack to combine with CVE-2025-31133 (as one of the only mitigations available to most users for that issue is AppArmor, and this attack would let you bypass that). However, the misdirected write issue above means that you could also achieve most of the same goals without needing to chain together attacks.

Patches

This advisory is being published as part of a set of three advisories:

  • CVE-2025-31133
  • CVE-2025-52881
  • CVE-2025-52565

The patches fixing this issue have accordingly been combined into a single patchset. The following patches from that patchset resolve the issues in this advisory:

  • db19bbed5348 ("internal/sys: add VerifyInode helper")
  • 6fc191449109 ("internal: move utils.MkdirAllInRoot to internal/pathrs")
  • ff94f9991bd3 ("*: switch to safer securejoin.Reopen")
  • 44a0fcf685db ("go.mod: update to github.com/cyphar/filepath-securejoin@v0.5.0")
  • 77889b56db93 ("internal: add wrappers for securejoin.Proc*")
  • fdcc9d3cad2f ("apparmor: use safe procfs API for labels")
  • ff6fe1324663 ("utils: use safe procfs for /proc/self/fd loop code")
  • b3dd1bc562ed ("utils: remove unneeded EnsureProcHandle")
  • 77d217c7c377 ("init: write sysctls using safe procfs API")
  • 435cc81be6b7 ("init: use securejoin for /proc/self/setgroups")
  • d61fd29d854b ("libct/system: use securejoin for /proc/$pid/stat")
  • 4b37cd93f86e ("libct: align param type for mountCgroupV1/V2 functions")
  • d40b3439a961 ("rootfs: switch to fd-based handling of mountpoint targets")
  • ed6b1693b8b3 ("selinux: use safe procfs API for labels")
  • Please note that this patch includes a private patch for github.com/opencontainers/selinux that could not be made public through a public pull request (as it would necessarily disclose this embargoed security issue).

    The patch includes a complete copy of the forked code and a replace directive (as well as go mod vendor applied), which should still work with downstream build systems. If you cannot apply this patch, you can safely drop it -- some of the other patches in this series should block these kinds of racing mount attacks entirely.

    See https://github.com/opencontainers/selinux/pull/237 for the upstream patch. * 3f925525b44d ("rootfs: re-allow dangling symlinks in mount targets") * a41366e74080 ("openat2: improve resilience on busy systems")

runc 1.2.8, 1.3.3, and 1.4.0-rc.3 have been released and all contain fixes for these issues. As per runc's new release model, runc 1.1.x and earlier are no longer supported and thus have not been patched.

Mitigations

  • Do not run untrusted container images from unknown or unverified sources.

  • For the basic no-op attack, this attack allows a container process to run with the same LSM labels as runc. For most AppArmor deployments this means it will be unconfined, and for SELinux it will likely be container_runtime_t. Runc has not conducted in-depth testing of the impact on SELinux -- it is possible that it provides some reasonable protection but it seems likely that an attacker could cause harm to systems even with such an SELinux setup.

  • For the more involved redirect and write gadget attacks, unfortunately most LSM profiles (including the standard container-selinux profiles) provide the container runtime access to sysctl files (including /proc/sysrq-trigger) and so LSMs likely do not provide much protection against these attacks.

  • Using rootless containers provides some protection against these kinds of bugs (privileged writes in runc being redirected) -- by having runc itself be an unprivileged process, in general you would expect the impact scope of a runc bug to be less severe as it would only have the privileges afforded to the host user which spawned runc. For this particular bug, the privilege escalation caused by the inadvertent write issue is entirely mitigated with rootless containers because the unprivileged user that the runc process is executing as cannot write to the aforementioned procfs files (even intentionally).

Other Runtimes

As this vulnerability boils down to a fairly easy-to-make logic bug, runc has provided information to other OCI (crun, youki) and non-OCI (LXC) container runtimes about this vulnerability.

Based on discussions with other runtimes, it seems that crun and youki may have similar security issues and will release a co-ordinated security release along with runc. LXC appears to use the host's /proc for all procfs operations, and so is likely not vulnerable to this issue (this is a trade-off -- runc uses the container's procfs to avoid CVE-2016-9962-style attacks).

Credits

Thanks to Li Fubang (@lifubang from acmcoder.com, CIIC) and Tõnis Tiigi (@tonistiigi from Docker) for both independently discovering this vulnerability, as well as Aleksa Sarai (@cyphar from SUSE) for the original research into this class of security issues and solutions.

Additional thanks go to Tõnis Tiigi for finding some very useful exploit templates for these kinds of race attacks using docker buildx build.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.2.7"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/opencontainers/runc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.12.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/opencontainers/selinux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.13.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.3.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/opencontainers/runc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.0-rc.1"
            },
            {
              "fixed": "1.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.4.0-rc.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/opencontainers/runc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.4.0-rc.1"
            },
            {
              "fixed": "1.4.0-rc.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-52881"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-363",
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-05T18:40:40Z",
    "nvd_published_at": "2025-11-06T21:15:42Z",
    "severity": "HIGH"
  },
  "details": "### Impact ###\n\nThis attack is primarily a more sophisticated version of CVE-2019-19921, which was a flaw which allowed an attacker to trick runc into writing the LSM process labels for a container process into a dummy `tmpfs` file and thus not apply the correct LSM labels to the container process. The mitigation runc applied for CVE-2019-19921 was fairly limited and effectively only caused runc to verify that when runc writes LSM labels that those labels are actual procfs files.\n\nRather than using a fake `tmpfs` file for `/proc/self/attr/\u003clabel\u003e`, an attacker could instead (through various means) make `/proc/self/attr/\u003clabel\u003e` reference a real `procfs` file, but one that would still be a no-op (such as `/proc/self/sched`). This would have the same effect but would clear the \"is a procfs file\" check. Runc is aware that this kind of attack would be possible (even going so far as to discuss this publicly as \"future work\" at conferences), and runc is working on a far more comprehensive mitigation of this attack, but this security issue was disclosed before runc could complete this work.\n\nIn all known versions of runc, an attacker can trick runc into misdirecting writes to `/proc` to other procfs files through the use of a racing container with shared mounts (runc has also verified this attack is possible to exploit using a standard Dockerfile with `docker buildx build` as that also permits triggering parallel execution of containers with custom shared mounts configured). This redirect could be through symbolic links in a `tmpfs` or theoretically other methods such as regular bind-mounts.\n\nNote that while `/proc/self/attr/\u003clabel\u003e` was the example used above (which is LSM-specific), this issue affect all writes to `/proc` in runc and thus also affects sysctls (written to `/proc/sys/...`) and some other APIs.\n\n#### Additional Impacts ####\n\nWhile investigating this issue, runc discovered that another risk with these redirected writes is that they could be redirected to dangerous files such as `/proc/sysrq-trigger` rather than just no-op files like `/proc/self/sched`. For instance, the default AppArmor profile name in Docker is `docker-default`, which when written to `/proc/sysrq-trigger` would cause the host system to crash.\n\nWhen this was discovered, runc conducted an audit of other write operations within runc and found several possible areas where runc could be used as a semi-arbitrary write gadget when combined with the above race attacks. The most concerning attack scenario was the configuration of sysctls. Because the contents of the sysctl are free-form text, an attacker could use a misdirected write to write to `/proc/sys/kernel/core_pattern` and break out of the container (as described in CVE-2025-31133, kernel upcalls are not namespaced and so coredump helpers will run with complete root privileges on the host). Even if the attacker cannot configure custom sysctls, a valid sysctl string (when redirected to `/proc/sysrq-trigger`) can easily cause the machine to hang.\n\nNote that the fact that this attack allows you to disable LSM labels makes it a very useful attack to combine with CVE-2025-31133 (as one of the only mitigations available to most users for that issue is AppArmor, and this attack would let you bypass that). However, the misdirected write issue above means that you could also achieve most of the same goals without needing to chain together attacks.\n\n### Patches ###\n\nThis advisory is being published as part of a set of three advisories:\n\n  * CVE-2025-31133\n  * CVE-2025-52881\n  * CVE-2025-52565\n\nThe patches fixing this issue have accordingly been combined into a single patchset. The following patches from that patchset resolve the issues in this advisory:\n\n * db19bbed5348 (\"internal/sys: add VerifyInode helper\")\n * 6fc191449109 (\"internal: move utils.MkdirAllInRoot to internal/pathrs\")\n * ff94f9991bd3 (\"*: switch to safer securejoin.Reopen\")\n * 44a0fcf685db (\"go.mod: update to github.com/cyphar/filepath-securejoin@v0.5.0\")\n * 77889b56db93 (\"internal: add wrappers for securejoin.Proc*\")\n * fdcc9d3cad2f (\"apparmor: use safe procfs API for labels\")\n * ff6fe1324663 (\"utils: use safe procfs for /proc/self/fd loop code\")\n * b3dd1bc562ed (\"utils: remove unneeded EnsureProcHandle\")\n * 77d217c7c377 (\"init: write sysctls using safe procfs API\")\n * 435cc81be6b7 (\"init: use securejoin for /proc/self/setgroups\")\n * d61fd29d854b (\"libct/system: use securejoin for /proc/$pid/stat\")\n * 4b37cd93f86e (\"libct: align param type for mountCgroupV1/V2 functions\")\n * d40b3439a961 (\"rootfs: switch to fd-based handling of mountpoint targets\")\n * ed6b1693b8b3 (\"selinux: use safe procfs API for labels\")\n   - Please note that this patch includes a private patch for `github.com/opencontainers/selinux` that could not be made public through a public pull request (as it would necessarily disclose this embargoed security issue).\n\n     The patch includes a complete copy of the forked code and a `replace` directive (as well as `go mod vendor` applied), which should still work with downstream build systems. If you cannot apply this patch, you can safely drop it -- some of the other patches in this series should block these kinds of racing mount attacks entirely.\n\n     See https://github.com/opencontainers/selinux/pull/237 for the upstream patch.\n * 3f925525b44d (\"rootfs: re-allow dangling symlinks in mount targets\")\n * a41366e74080 (\"openat2: improve resilience on busy systems\")\n\nrunc 1.2.8, 1.3.3, and 1.4.0-rc.3 have been released and all contain fixes for these issues. As per [runc\u0027s new release model][RELEASES.md], runc 1.1.x and earlier are no longer supported and thus have not been patched.\n\n[CVE-2025-31133]: https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2\n[CVE-2025-52565]: https://github.com/opencontainers/runc/security/advisories/GHSA-qw9x-cqr3-wc7r\n[CVE-2025-52881]: https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm\n[RELEASES.md]: https://github.com/opencontainers/runc/blob/v1.4.0-rc.2/RELEASES.md\n\n### Mitigations ###\n\n * Do not run untrusted container images from unknown or unverified sources.\n\n * For the basic no-op attack, this attack allows a container process to run with the same LSM labels as `runc`. For most AppArmor deployments this means it will be `unconfined`, and for SELinux it will likely be `container_runtime_t`. Runc has not conducted in-depth testing of the impact on SELinux -- it is possible that it provides some reasonable protection but it seems likely that an attacker could cause harm to systems even with such an SELinux setup.\n\n * For the more involved redirect and write gadget attacks, unfortunately most LSM profiles (including the standard container-selinux profiles) provide the container runtime access to sysctl files (including `/proc/sysrq-trigger`) and so LSMs likely do not provide much protection against these attacks.\n\n * Using rootless containers provides some protection against these kinds of bugs (privileged writes in runc being redirected) -- by having runc itself be an unprivileged process, in general you would expect the impact scope of a runc bug to be less severe as it would only have the privileges afforded to the host user which spawned runc. For this particular bug, the privilege escalation caused by the inadvertent write issue is entirely mitigated with rootless containers because the unprivileged user that the `runc` process is executing as cannot write to the aforementioned procfs files (even intentionally).\n\n### Other Runtimes ###\n\nAs this vulnerability boils down to a fairly easy-to-make logic bug, runc has provided information to other OCI (crun, youki) and non-OCI (LXC) container runtimes about this vulnerability.\n\nBased on discussions with other runtimes, it seems that crun and youki may have similar security issues and will release a co-ordinated security release along with runc. LXC appears to use the host\u0027s `/proc` for all procfs operations, and so is likely not vulnerable to this issue (this is a trade-off -- runc uses the container\u0027s procfs to avoid CVE-2016-9962-style attacks).\n\n[CVE-2016-9962]: https://seclists.org/fulldisclosure/2017/Jan/21\n\n### Credits ###\n\nThanks to Li Fubang (@lifubang from acmcoder.com, CIIC) and T\u00f5nis Tiigi (@tonistiigi from Docker) for both independently discovering this vulnerability, as well as Aleksa Sarai (@cyphar from SUSE) for the original research into this class of security issues and solutions.\n\nAdditional thanks go to T\u00f5nis Tiigi for finding some very useful exploit templates for these kinds of race attacks using `docker buildx build`.",
  "id": "GHSA-cgrx-mc8f-2prm",
  "modified": "2025-11-18T18:38:01Z",
  "published": "2025-11-05T18:40:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/security/advisories/GHSA-qw9x-cqr3-wc7r"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/security/advisories/GHSA-fh74-hm69-rqjw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52881"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/selinux/pull/237"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/ff94f9991bd32076c871ef0ad8bc1b763458e480"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/ff6fe1324663538167eca8b3d3eec61e1bd4fa51"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/fdcc9d3cad2f85954a241ccb910a61aaa1ef47f3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/ed6b1693b8b3ae7eb0250a7e76fc888cdacf98c1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/db19bbed5348847da433faa9d69e9f90192bfa64"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/d61fd29d854b416feaaf128bf650325cd2182165"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/d40b3439a9614a86e87b81a94c6811ec6fa2d7d2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/b3dd1bc562ed9996d1a0f249e056c16624046d28"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/a41366e74080fa9f26a2cd3544e2801449697322"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/77d217c7c3775d8ca5af89e477e81568ef4572db"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/77889b56db939c323d29d1130f28f9aea2edb544"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/6fc191449109ea14bb7d61238f24a33fe08c651f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/4b37cd93f86e72feac866442988b549b5b7bf3e6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/44a0fcf685db051c80b8c269812bb177f5802c58"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/435cc81be6b79cdec73b4002c0dae549b2f6ae6d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/3f925525b44d247e390e529e772a0dc0c0bc3557"
    },
    {
      "type": "WEB",
      "url": "https://youtu.be/tGseJW_uBB8"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/github.com/cyphar/filepath-securejoin/pathrs-lite/procfs"
    },
    {
      "type": "WEB",
      "url": "https://youtu.be/y1PaBzxwRWQ"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/selinux/releases/tag/v1.13.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/blob/v1.4.0-rc.2/RELEASES.md"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/opencontainers/runc"
    },
    {
      "type": "WEB",
      "url": "http://github.com/opencontainers/runc/commit/a41366e74080fa9f26a2cd3544e2801449697322"
    },
    {
      "type": "WEB",
      "url": "http://github.com/opencontainers/runc/commit/fdcc9d3cad2f85954a241ccb910a61aaa1ef47f3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "runc container escape and denial of service due to arbitrary write gadgets and procfs write redirects"
}

GHSA-CMW6-HCPP-C6JP

Vulnerability from github – Published: 2026-04-01 21:13 – Updated: 2026-04-01 21:13
VLAI
Summary
ONNX: Arbitrary File Read via ExternalData Hardlink Bypass in ONNX load
Details

Summary

The issue is in onnx.load — the code checks for symlinks to prevent path traversal, but completely misses hardlinks, which is the problem, since a hardlink looks exactly like a regular file on the filesystem.

The Real Problem

The validator in onnx/checker.cc only calls is_symlink() and never checks the inode or st_nlink, so a hardlink walks right through every security check without any issues.

Impact

Especially dangerous in AI supply chain scenarios like HuggingFace — a single malicious model is enough to silently steal secrets from the victim's machine without them noticing anything.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.20.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "onnx"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.21.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34446"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-01T21:13:37Z",
    "nvd_published_at": "2026-04-01T18:16:30Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe issue is in `onnx.load` \u2014 the code checks for symlinks to prevent path traversal, but completely misses hardlinks, which is the problem, since a hardlink looks exactly like a regular file on the filesystem.\n\n### The Real Problem\nThe validator in `onnx/checker.cc` only calls `is_symlink()` and never checks the inode or `st_nlink`, so a hardlink walks right through every security check without any issues.\n\n### Impact\nEspecially dangerous in AI supply chain scenarios like HuggingFace \u2014 a single malicious model is enough to silently steal secrets from the victim\u0027s machine without them noticing anything.",
  "id": "GHSA-cmw6-hcpp-c6jp",
  "modified": "2026-04-01T21:13:37Z",
  "published": "2026-04-01T21:13:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/onnx/onnx/security/advisories/GHSA-cmw6-hcpp-c6jp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34446"
    },
    {
      "type": "WEB",
      "url": "https://github.com/onnx/onnx/commit/4755f8053928dce18a61db8fec71b69c74f786cb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/onnx/onnx"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ONNX: Arbitrary File Read via ExternalData Hardlink Bypass in ONNX load"
}

GHSA-FV94-QVG8-XQPW

Vulnerability from github – Published: 2026-04-02 21:23 – Updated: 2026-05-06 19:11
VLAI
Summary
OpenClaw: SSH sandbox tar upload follows symlinks, enabling arbitrary file write on remote host
Details

Summary

SSH sandbox tar upload follows symlinks, enabling arbitrary file write on remote host

Current Maintainer Triage

  • Status: open
  • Normalized severity: high
  • Assessment: Real in shipped v2026.3.28: SSH sandbox tar upload lacked pre-upload symlink escape rejection until 3d5af14984 on 2026-03-31; maintainers already accepted it and the fix is unreleased.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Latest published npm version: 2026.3.31
  • Vulnerable version range: <=2026.3.28
  • Patched versions: >= 2026.3.31
  • First stable tag containing the fix: v2026.3.31

Fix Commit(s)

  • 3d5af14984ac1976c747a8e11581d697bd0829dc — 2026-03-31T19:56:45+09:00

OpenClaw thanks @AntAISecurityLab for reporting.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.28"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.31"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41364"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59",
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-02T21:23:32Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\nSSH sandbox tar upload follows symlinks, enabling arbitrary file write on remote host\n\n## Current Maintainer Triage\n- Status: open\n- Normalized severity: high\n- Assessment: Real in shipped v2026.3.28: SSH sandbox tar upload lacked pre-upload symlink escape rejection until 3d5af14984 on 2026-03-31; maintainers already accepted it and the fix is unreleased.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published npm version: `2026.3.31`\n- Vulnerable version range: `\u003c=2026.3.28`\n- Patched versions: `\u003e= 2026.3.31`\n- First stable tag containing the fix: `v2026.3.31`\n\n## Fix Commit(s)\n- `3d5af14984ac1976c747a8e11581d697bd0829dc` \u2014 2026-03-31T19:56:45+09:00\n\nOpenClaw thanks @AntAISecurityLab for reporting.",
  "id": "GHSA-fv94-qvg8-xqpw",
  "modified": "2026-05-06T19:11:31Z",
  "published": "2026-04-02T21:23:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-fv94-qvg8-xqpw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41364"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/3d5af14984ac1976c747a8e11581d697bd0829dc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.31"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-arbitrary-file-write-via-symlink-following-in-ssh-sandbox-tar-upload"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: SSH sandbox tar upload follows symlinks, enabling arbitrary file write on remote host"
}

GHSA-G2WF-V8Q9-85JJ

Vulnerability from github – Published: 2022-05-24 19:07 – Updated: 2022-08-06 00:00
VLAI
Details

Absolute Path Traversal vulnerability in FileviewDoc in QSAN Storage Manager allows remote authenticated attackers access arbitrary files by injecting the Symbolic Link following the Url path parameter.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-32509"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59",
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-07T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Absolute Path Traversal vulnerability in FileviewDoc in QSAN Storage Manager allows remote authenticated attackers access arbitrary files by injecting the Symbolic Link following the Url path parameter.",
  "id": "GHSA-g2wf-v8q9-85jj",
  "modified": "2022-08-06T00:00:52Z",
  "published": "2022-05-24T19:07:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32509"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-4865-0c967-1.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G6QJ-9F49-6C8C

Vulnerability from github – Published: 2025-04-03 09:32 – Updated: 2025-04-03 09:32
VLAI
Details

UNIX symbolic link (Symlink) following issue exists in FutureNet NXR series, VXR series and WXR series routers. Attaching to the affected product an external storage containing malicious symbolic link files, a logged-in administrative user may obtain and/or destroy internal files.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-30485"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-03T07:15:41Z",
    "severity": "MODERATE"
  },
  "details": "UNIX symbolic link (Symlink) following issue exists in FutureNet NXR series, VXR series and WXR series routers. Attaching to the affected product an external storage containing malicious symbolic link files, a logged-in administrative user may obtain and/or destroy internal files.",
  "id": "GHSA-g6qj-9f49-6c8c",
  "modified": "2025-04-03T09:32:14Z",
  "published": "2025-04-03T09:32:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30485"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/vu/JVNVU92821536"
    },
    {
      "type": "WEB",
      "url": "https://www.centurysys.co.jp/backnumber/common/jvnvu92821536.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:P/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G7VG-VFVV-MR49

Vulnerability from github – Published: 2026-03-10 18:31 – Updated: 2026-03-10 18:31
VLAI
Details

A UNIX symbolic link (Symlink) following vulnerability in Fortinet FortiClientLinux 7.4.0 through 7.4.4, FortiClientLinux 7.2.2 through 7.2.12 may allow a local and unprivileged user to escalate their privileges to root.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-24018"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-10T18:18:17Z",
    "severity": "HIGH"
  },
  "details": "A UNIX symbolic link (Symlink) following vulnerability in Fortinet FortiClientLinux 7.4.0 through 7.4.4, FortiClientLinux 7.2.2 through 7.2.12 may allow a local and unprivileged user to escalate their privileges to root.",
  "id": "GHSA-g7vg-vfvv-mr49",
  "modified": "2026-03-10T18:31:20Z",
  "published": "2026-03-10T18:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24018"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-26-083"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Implementation

Symbolic link attacks often occur when a program creates a tmp directory that stores files/links. Access to the directory should be restricted to the program as to prevent attackers from manipulating the files.

Mitigation MIT-48.1
Architecture and Design

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-27: Leveraging Race Conditions via Symbolic Links

This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.