CWE-367
AllowedTime-of-check Time-of-use (TOCTOU) Race Condition
Abstraction: Base · Status: Incomplete
The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check.
1063 vulnerabilities reference this CWE, most recent first.
GHSA-C3XM-PVG7-GH7R
Vulnerability from github – Published: 2021-05-25 18:44 – Updated: 2021-05-21 19:34Summary
runc 1.0.0-rc94 and earlier are vulnerable to a symlink exchange attack whereby an attacker can request a seemingly-innocuous container configuration that actually results in the host filesystem being bind-mounted into the container (allowing for a container escape). CVE-2021-30465 has been assigned for this issue.
An attacker must have the ability to start containers using some kind of custom volume configuration, and while recommended container hardening mechanisms such as LSMs (AppArmor/SELinux) and user namespaces will restrict the amount of damage an attacker could do, they do not block this attack outright. We have a reproducer using Kubernetes (and the below description mentions Kubernetes-specific paths), but this is not a Kubernetes-specific issue.
The now-released runc v1.0.0-rc95 contains a fix for this issue, we recommend users update as soon as possible.
Details
In circumstances where a container is being started, and runc is mounting inside a volume shared with another container (which is conducting a symlink-exchange attack), runc can be tricked into mounting outside of the container rootfs by swapping the target of a mount with a symlink due to a time-of-check-to-time-of-use (TOCTTOU) flaw. This is fairly similar in style to previous TOCTTOU attacks (and is a problem we are working on solving with libpathrs).
However, this alone is not useful because this happens inside a mount namespace
with MS_SLAVE propagation applied to / (meaning that the mount doesn't
appear on the host -- it's only a "host-side mount" inside the container's
namespace). To exploit this, you must have additional mount entries in the
configuration that use some subpath of the mounted-over host path as a source
for a subsequent mount.
However, it turns out with some container orchestrators (such as Kubernetes -- though it is very likely that other downstream users of runc could have similar behaviour be accessible to untrusted users), the existence of additional volume management infrastructure allows this attack to be applied to gain access to the host filesystem without requiring the attacker to have completely arbitrary control over container configuration.
In the case of Kubernetes, this is exploitable by creating a symlink in a
volume to the top-level (well-known) directory where volumes are sourced from
(for instance,
/var/lib/kubelet/pods/$MY_POD_UID/volumes/kubernetes.io~empty-dir), and then
using that symlink as the target of a mount. The source of the mount is an
attacker controlled directory, and thus the source directory from which
subsequent mounts will occur is an attacker-controlled directory. Thus the
attacker can first place a symlink to / in their malicious source directory
with the name of a volume, and a subsequent mount in the container will
bind-mount / into the container.
Applying this attack requires the attacker to start containers with a slightly
peculiar volume configuration (though not explicitly malicious-looking such as
bind-mounting / into the container explicitly), and be able to run malicious
code in a container that shares volumes with said volume configuration. It
helps the attacker if the host paths used for volume management are well known,
though this is not a hard requirement.
Patches
This has been patched in runc 1.0.0-rc95, and users should upgrade as soon as possible. The patch itself can be found here.
Workarounds
There are no known workarounds for this issue.
However, users who enforce running containers with more confined security profiles (such as reduced capabilities, not running code as root in the container, user namespaces, AppArmor/SELinux, and seccomp) will restrict what an attacker can do in the case of a container breakout -- we recommend users make use of strict security profiles if possible (most notably user namespaces -- which can massively restrict the impact a container breakout can have on the host system).
References
Credit
Thanks to Etienne Champetier for discovering and disclosing this vulnerability, to Noah Meyerhans for writing the first draft of this patch, and to Samuel Karp for testing it.
For more information
If you have any questions or comments about this advisory: * Open an issue in our issue tracker. * Email us at security@opencontainers.org.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.0-rc94"
},
"package": {
"ecosystem": "Go",
"name": "github.com/opencontainers/runc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.0-rc95"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-30465"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-362",
"CWE-367"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-21T19:34:43Z",
"nvd_published_at": "2021-05-27T13:15:00Z",
"severity": "HIGH"
},
"details": "### Summary\n\nrunc 1.0.0-rc94 and earlier are vulnerable to a symlink exchange attack whereby\nan attacker can request a seemingly-innocuous container configuration that\nactually results in the host filesystem being bind-mounted into the container\n(allowing for a container escape). CVE-2021-30465 has been assigned for this\nissue.\n\nAn attacker must have the ability to start containers using some kind of custom\nvolume configuration, and while recommended container hardening mechanisms such\nas LSMs (AppArmor/SELinux) and user namespaces will restrict the amount of\ndamage an attacker could do, they do not block this attack outright. We have a\nreproducer using Kubernetes (and the below description mentions\nKubernetes-specific paths), but this is not a Kubernetes-specific issue.\n\nThe now-released [runc v1.0.0-rc95][release] contains a fix for this issue, we\nrecommend users update as soon as possible.\n\n[release]: https://github.com/opencontainers/runc/releases/tag/v1.0.0-rc95\n\n### Details\n\nIn circumstances where a container is being started, and runc is mounting\ninside a volume shared with another container (which is conducting a\nsymlink-exchange attack), runc can be tricked into mounting outside of the\ncontainer rootfs by swapping the target of a mount with a symlink due to a\ntime-of-check-to-time-of-use (TOCTTOU) flaw. This is fairly similar in style to\nprevious TOCTTOU attacks (and is a problem we are working on solving with\nlibpathrs).\n\nHowever, this alone is not useful because this happens inside a mount namespace\nwith `MS_SLAVE` propagation applied to `/` (meaning that the mount doesn\u0027t\nappear on the host -- it\u0027s only a \"host-side mount\" inside the container\u0027s\nnamespace). To exploit this, you must have additional mount entries in the\nconfiguration that use some subpath of the mounted-over host path as a source\nfor a subsequent mount.\n\nHowever, it turns out with some container orchestrators (such as Kubernetes --\nthough it is very likely that other downstream users of runc could have similar\nbehaviour be accessible to untrusted users), the existence of additional volume\nmanagement infrastructure allows this attack to be applied to gain access to\nthe host filesystem without requiring the attacker to have completely arbitrary\ncontrol over container configuration.\n\nIn the case of Kubernetes, this is exploitable by creating a symlink in a\nvolume to the top-level (well-known) directory where volumes are sourced from\n(for instance,\n`/var/lib/kubelet/pods/$MY_POD_UID/volumes/kubernetes.io~empty-dir`), and then\nusing that symlink as the target of a mount. The source of the mount is an\nattacker controlled directory, and thus the source directory from which\nsubsequent mounts will occur is an attacker-controlled directory. Thus the\nattacker can first place a symlink to `/` in their malicious source directory\nwith the name of a volume, and a subsequent mount in the container will\nbind-mount `/` into the container.\n\nApplying this attack requires the attacker to start containers with a slightly\npeculiar volume configuration (though not explicitly malicious-looking such as\nbind-mounting `/` into the container explicitly), and be able to run malicious\ncode in a container that shares volumes with said volume configuration. It\nhelps the attacker if the host paths used for volume management are well known,\nthough this is not a hard requirement.\n\n### Patches\nThis has been patched in runc 1.0.0-rc95, and users should upgrade as soon as\npossible. The patch itself can be found [here](https://github.com/opencontainers/runc/commit/0ca91f44f1664da834bc61115a849b56d22f595f).\n\n### Workarounds\n\nThere are no known workarounds for this issue.\n\nHowever, users who enforce running containers with more confined security\nprofiles (such as reduced capabilities, not running code as root in the\ncontainer, user namespaces, AppArmor/SELinux, and seccomp) will restrict what\nan attacker can do in the case of a container breakout -- we recommend users\nmake use of strict security profiles if possible (most notably user namespaces\n-- which can massively restrict the impact a container breakout can have on the\nhost system).\n\n### References\n* [commit](https://github.com/opencontainers/runc/commit/0ca91f44f1664da834bc61115a849b56d22f595f)\n* [seclists public disclosure](https://www.openwall.com/lists/oss-security/2021/05/19/2)\n\n### Credit\n\nThanks to Etienne Champetier for discovering and disclosing this vulnerability,\nto Noah Meyerhans for writing the first draft of this patch, and to Samuel Karp\nfor testing it.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [our issue tracker](https://github.com/opencontainers/runc/issues).\n* Email us at \u003csecurity@opencontainers.org\u003e.",
"id": "GHSA-c3xm-pvg7-gh7r",
"modified": "2021-05-21T19:34:43Z",
"published": "2021-05-25T18:44:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/security/advisories/GHSA-c3xm-pvg7-gh7r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30465"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/0ca91f44f1664da834bc61115a849b56d22f595f"
},
{
"type": "WEB",
"url": "https://bugzilla.opensuse.org/show_bug.cgi?id=1185405"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/releases"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/03/msg00023.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/35ZW6NBZSBH5PWIT7JU4HXOXGFVDCOHH"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4HOARVIT47RULTTFWAU7XBG4WY6TDDHV"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202107-26"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210708-0003"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/05/19/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "mount destinations can be swapped via symlink-exchange to cause mounts outside the rootfs"
}
GHSA-C45Q-6FW9-RHWR
Vulnerability from github – Published: 2025-08-12 18:31 – Updated: 2025-08-12 18:31Time-of-check Time-of-use race condition for some Intel(R) Connectivity Performance Suite software installers before version 40.24.11210 may allow an authenticated user to potentially enable escalation of privilege via local access.
{
"affected": [],
"aliases": [
"CVE-2025-20074"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-12T17:15:28Z",
"severity": "HIGH"
},
"details": "Time-of-check Time-of-use race condition for some Intel(R) Connectivity Performance Suite software installers before version 40.24.11210 may allow an authenticated user to potentially enable escalation of privilege via local access.",
"id": "GHSA-c45q-6fw9-rhwr",
"modified": "2025-08-12T18:31:27Z",
"published": "2025-08-12T18:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20074"
},
{
"type": "WEB",
"url": "https://intel.com/content/www/us/en/security-center/advisory/intel-sa-01286.html"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-C4J5-R43R-6PCX
Vulnerability from github – Published: 2022-05-24 17:00 – Updated: 2024-04-04 02:37The malware scan function in Total Defense Anti-virus 11.5.2.28 is vulnerable to a TOCTOU bug; consequently, symbolic link attacks allow privileged files to be deleted.
{
"affected": [],
"aliases": [
"CVE-2019-18644"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-31T00:15:00Z",
"severity": "MODERATE"
},
"details": "The malware scan function in Total Defense Anti-virus 11.5.2.28 is vulnerable to a TOCTOU bug; consequently, symbolic link attacks allow privileged files to be deleted.",
"id": "GHSA-c4j5-r43r-6pcx",
"modified": "2024-04-04T02:37:13Z",
"published": "2022-05-24T17:00:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18644"
},
{
"type": "WEB",
"url": "https://github.com/NtRaiseHardError/Antimalware-Research/blob/master/Total%20Defense/Privileged%20File%20Delete/v11.5.2.28/README.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C4QJ-5GG4-8HWF
Vulnerability from github – Published: 2022-05-24 16:55 – Updated: 2023-03-24 18:30Prior to 0.1, all builds of Eclipse OMR contain a bug where the loop versioner may fail to privatize a value that is pulled out of the loop by versioning - for example if there is a condition that is moved out of the loop that reads a field we may not privatize the value of that field in the modified copy of the loop allowing the test to see one value of the field and subsequently the loop to see a modified field value without retesting the condition moved out of the loop. This can lead to a variety of different issues but read out of array bounds is one major consequence of these problems.
{
"affected": [],
"aliases": [
"CVE-2019-11774"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-09-12T18:15:00Z",
"severity": "HIGH"
},
"details": "Prior to 0.1, all builds of Eclipse OMR contain a bug where the loop versioner may fail to privatize a value that is pulled out of the loop by versioning - for example if there is a condition that is moved out of the loop that reads a field we may not privatize the value of that field in the modified copy of the loop allowing the test to see one value of the field and subsequently the loop to see a modified field value without retesting the condition moved out of the loop. This can lead to a variety of different issues but read out of array bounds is one major consequence of these problems.",
"id": "GHSA-c4qj-5gg4-8hwf",
"modified": "2023-03-24T18:30:21Z",
"published": "2022-05-24T16:55:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11774"
},
{
"type": "WEB",
"url": "https://bugs.eclipse.org/bugs/show_bug.cgi?id=549192"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C5JF-C5PW-3XHJ
Vulnerability from github – Published: 2025-01-10 15:31 – Updated: 2025-01-10 15:31IBM Engineering Requirements Management DOORS Next 7.0.2 and 7.0.3 could allow a remote attacker to bypass security restrictions, caused by a race condition. By sending a specially crafted request, an attacker could exploit this vulnerability to remotely execute code.
{
"affected": [],
"aliases": [
"CVE-2024-41787"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-10T14:15:28Z",
"severity": "CRITICAL"
},
"details": "IBM Engineering Requirements Management DOORS Next 7.0.2 and 7.0.3 could allow a remote attacker to bypass security restrictions, caused by a race condition. By sending a specially crafted request, an attacker could exploit this vulnerability to remotely execute code.",
"id": "GHSA-c5jf-c5pw-3xhj",
"modified": "2025-01-10T15:31:34Z",
"published": "2025-01-10T15:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41787"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7180636"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C65V-CWF9-F69V
Vulnerability from github – Published: 2023-11-08 18:30 – Updated: 2023-11-08 18:30A time-of-check to time-of-use (TOCTOU) bug in handling of IOCTL (input/output control) requests. This TOCTOU bug leads to an out-of-bounds write vulnerability which can be further exploited, allowing an attacker to gain full local privilege escalation on the system.This issue affects Avast/Avg Antivirus: 23.8.
{
"affected": [],
"aliases": [
"CVE-2023-5760"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-08T17:15:07Z",
"severity": "LOW"
},
"details": "A time-of-check to time-of-use (TOCTOU) bug in handling of IOCTL (input/output control) requests. This TOCTOU bug leads to an out-of-bounds write vulnerability which can be further exploited, allowing an attacker to gain full local privilege escalation on the system.This issue affects Avast/Avg Antivirus: 23.8.\n\n",
"id": "GHSA-c65v-cwf9-f69v",
"modified": "2023-11-08T18:30:31Z",
"published": "2023-11-08T18:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5760"
},
{
"type": "WEB",
"url": "https://support.norton.com/sp/static/external/tools/security-advisories.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C6RQ-RJC2-86V2
Vulnerability from github – Published: 2022-02-10 23:33 – Updated: 2021-05-12 20:23A TOCTOU issue in the chownr package before 1.1.0 for Node.js 10.10 could allow a local attacker to trick it into descending into unintended directories via symlink attacks.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "chownr"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-18869"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-12T20:23:29Z",
"nvd_published_at": "2020-06-15T15:15:00Z",
"severity": "LOW"
},
"details": "A TOCTOU issue in the chownr package before 1.1.0 for Node.js 10.10 could allow a local attacker to trick it into descending into unintended directories via symlink attacks.",
"id": "GHSA-c6rq-rjc2-86v2",
"modified": "2021-05-12T20:23:29Z",
"published": "2022-02-10T23:33:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-18869"
},
{
"type": "WEB",
"url": "https://github.com/isaacs/chownr/issues/14"
},
{
"type": "WEB",
"url": "https://github.com/isaacs/chownr/commit/36a93e3f0a220062c47b237cf6ab6d5f55cd79c9"
},
{
"type": "WEB",
"url": "https://github.com/isaacs/chownr/commit/a631d841022880e5c8d694408a7e96d6d576d0ce"
},
{
"type": "WEB",
"url": "https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863985"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1611614"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/npm:chownr:20180731"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Time-of-check Time-of-use (TOCTOU) Race Condition in chownr"
}
GHSA-C77V-CR6C-9FXW
Vulnerability from github – Published: 2024-08-13 18:31 – Updated: 2024-08-13 18:31Windows Kernel Elevation of Privilege Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-38153"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-13T18:15:20Z",
"severity": "HIGH"
},
"details": "Windows Kernel Elevation of Privilege Vulnerability",
"id": "GHSA-c77v-cr6c-9fxw",
"modified": "2024-08-13T18:31:16Z",
"published": "2024-08-13T18:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38153"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38153"
}
],
"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-C788-RMFV-WWR2
Vulnerability from github – Published: 2022-05-14 02:28 – Updated: 2022-05-14 02:28Microsoft Internet Explorer 7 through 11 allows remote attackers to gain privileges via a crafted web site, aka "Internet Explorer Elevation of Privilege Vulnerability," a different vulnerability than CVE-2015-1748.
{
"affected": [],
"aliases": [
"CVE-2015-1743"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2015-06-10T01:59:00Z",
"severity": "MODERATE"
},
"details": "Microsoft Internet Explorer 7 through 11 allows remote attackers to gain privileges via a crafted web site, aka \"Internet Explorer Elevation of Privilege Vulnerability,\" a different vulnerability than CVE-2015-1748.",
"id": "GHSA-c788-rmfv-wwr2",
"modified": "2022-05-14T02:28:46Z",
"published": "2022-05-14T02:28:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-1743"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2015/ms15-056"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/74996"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1032521"
},
{
"type": "WEB",
"url": "http://www.zerodayinitiative.com/advisories/ZDI-15-377"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-C82R-C9F7-F5MJ
Vulnerability from github – Published: 2025-04-28 20:25 – Updated: 2025-04-29 13:10Issue
Snowflake discovered and remediated a vulnerability in the Snowflake Connector for .NET (“Connector”). When using the Easy Logging feature on Linux and macOS, the Connector didn’t correctly verify the permissions of the logging configuration file, potentially allowing an attacker with local access to overwrite the configuration and gain control over logging level and output location.
This vulnerability affects Connector versions 2.1.2 through 4.4.0. Snowflake fixed the issue in version 4.4.1.
Vulnerability Details
When using the Easy Logging feature on Linux and macOS, the Connector reads logging configuration from a user-provided file. On Linux and macOS, the Connector verifies that the configuration file can be written to only by its owner. That check was vulnerable to a Time-of-Check to Time-of-Use (TOCTOU) race condition and failed to verify that the file owner matches the user running the Connector. This could allow a local attacker with write access to the configuration file or the directory containing it to overwrite the configuration and gain control over logging level and output location.
Solution
Snowflake released version 4.4.1 of the Snowflake Connector for .NET, which fixes this issue. We recommend users upgrade to version 4.4.1.
Additional Information
If you discover a security vulnerability in one of our products or websites, please report the issue to Snowflake through our Vulnerability Disclosure Program hosted at HackerOne. For more information, please see our Vulnerability Disclosure Policy.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.4.0"
},
"package": {
"ecosystem": "NuGet",
"name": "Snowflake.Data"
},
"ranges": [
{
"events": [
{
"introduced": "2.1.2"
},
{
"fixed": "4.4.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-46326"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-28T20:25:51Z",
"nvd_published_at": "2025-04-28T23:15:44Z",
"severity": "LOW"
},
"details": "# Issue\nSnowflake discovered and remediated a vulnerability in the Snowflake Connector for .NET (\u201cConnector\u201d). When using the Easy Logging feature on Linux and macOS, the Connector didn\u2019t correctly verify the permissions of the logging configuration file, potentially allowing an attacker with local access to overwrite the configuration and gain control over logging level and output location.\n\nThis vulnerability affects Connector versions 2.1.2 through 4.4.0. Snowflake fixed the issue in version 4.4.1.\n\n# Vulnerability Details\nWhen using the Easy Logging feature on Linux and macOS, the Connector reads logging configuration from a user-provided file. On Linux and macOS, the Connector verifies that the configuration file can be written to only by its owner. That check was vulnerable to a Time-of-Check to Time-of-Use (TOCTOU) race condition and failed to verify that the file owner matches the user running the Connector. This could allow a local attacker with write access to the configuration file or the directory containing it to overwrite the configuration and gain control over logging level and output location.\n\n# Solution\nSnowflake released version 4.4.1 of the Snowflake Connector for .NET, which fixes this issue. We recommend users upgrade to version 4.4.1.\n\n# Additional Information\nIf you discover a security vulnerability in one of our products or websites, please report the issue to Snowflake through our Vulnerability Disclosure Program hosted at HackerOne. For more information, please see our [Vulnerability Disclosure Policy](https://hackerone.com/snowflake?type=team).",
"id": "GHSA-c82r-c9f7-f5mj",
"modified": "2025-04-29T13:10:37Z",
"published": "2025-04-28T20:25:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/snowflakedb/snowflake-connector-net/security/advisories/GHSA-c82r-c9f7-f5mj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46326"
},
{
"type": "WEB",
"url": "https://github.com/snowflakedb/snowflake-connector-net/commit/393aad3cfa81045a05dd488944db45256e861bff"
},
{
"type": "PACKAGE",
"url": "https://github.com/snowflakedb/snowflake-connector-net"
},
{
"type": "WEB",
"url": "https://github.com/snowflakedb/snowflake-connector-net/releases/tag/v4.4.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Snowflake Connector for .NET has race condition when checking access to Easy Logging configuration file"
}
Mitigation
The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check.
Mitigation
When the file being altered is owned by the current user and group, set the effective gid and uid to that of the current user and group when executing this statement.
Mitigation
Limit the interleaving of operations on files from multiple processes.
Mitigation
If you cannot perform operations atomically and you must share access to the resource between multiple processes or threads, then try to limit the amount of time (CPU cycles) between the check and use of the resource. This will not fix the problem, but it could make it more difficult for an attack to succeed.
Mitigation
Recheck the resource after the use call to verify that the action was taken appropriately.
Mitigation
Ensure that some environmental locking mechanism can be used to protect resources effectively.
Mitigation
Ensure that locking occurs before the check, as opposed to afterwards, such that the resource, as checked, is the same as it is when in use.
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.
CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions
This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.