The Go Snowflake driver (gosnowflake) was assigned CVE-2025-46327 after researchers discovered a Time-of-Check to Time-of-Use (
TOCTOU) race condition in the driver’s
Easy Logging feature that can let a local, low-privilege attacker manipulate logging configuration files and influence log level and output — with downstream impacts for systems that bundle the driver. Snowflake patched the issue in
gosnowflake v1.13.3, and public vulnerability databases quickly cataloged the flaw. Microsoft’s Security Response Center (MSRC) has identified
Azure Linux images as containing an affected component (telegraf packages that vendor in the vulnerable library), and its CSAF/VEX entry makes clear that additional Microsoft products will be updated if further impact is discovered.
Background
The affected component is the Go Snowflake driver,
gosnowflake — the official Go driver used to connect Go programs to Snowflake. The vulnerability arises when the driver’s Easy Logging feature reads a user-supplied logging configuration file and performs a permissions check that is susceptible to a TOCTOU race. In short, the driver checks whether the file is writable only by its owner, but an attacker who can race the check and replace or modify the file can subvert that check and cause the process to load attacker-controlled logging configuration. The practical consequence is that a local attacker with write access to the filesystem path or directory where the config lives could change logging behavior and redirect log output. Snowflake’s own release notes and the upstream security advisory show the fix was shipped in
1.13.3 and that the vulnerability affects driver versions >= 1.7.0 and < 1.13.3. Multiple vulnerability databases (NVD, OSV, GitHub Advisory listings) reflect these same version ranges and classification (CWE-367: TOCTOU). That is the authoritative remediation path: upgrade to
gosnowflake v1.13.3 or later to eliminate the specific TOCTOU check.
Why this matters to WindowsForum readers and enterprise operators
- The issue is local (exploit requires ability to write to a file or directory accessible to the target process), but the impact can be meaningful: log level and destinations can be manipulated to hide activity, exfiltrate data via log sinks, or cause information leakage when logs are redirected to unintended locations.
- gosnowflake is a widely reused open-source driver that appears not only in direct Snowflake client code but also as an indirect dependency in other open-source projects and packaged applications (for example, Telegraf and some data-connectivity stacks have depended on gosnowflake in recent releases). That means vendors and OS-distributors that ship those packages can inadvertently include a vulnerable library in the default images they publish.
Technical analysis — the TOCTOU weakness and attack surface
What a TOCTOU race is, in this context
A
Time-of-Check to Time-of-Use race occurs when a program checks some property of a filesystem object (the check) and later uses that object assuming the property hasn’t changed (the use). If an attacker can modify the object between the check and the use, the original assertion can be invalidated. In this CVE, the driver checks that a logging configuration file is writable only by the file owner; it then proceeds to open or use the file. If an attacker replaces or symlinks the file between those two operations, the driver can end up using a file controlled by the attacker.
Why Easy Logging increases risk
The Easy Logging feature intentionally reads external configuration supplied by users, which is convenient but raises risk when permission checks are insufficient. The more a process trusts external configuration files, the larger the
attack surface available to a local actor who can write to a directory or file. Because logging configuration influences where logs are written and what level of detail is captured, controlling it can be used to both hide malicious activity and capture sensitive application data.
Likely exploitation scenarios
- A local, unprivileged account has write access to /var/log or a shared configuration directory on a multi-tenant host (container host, shared build box, CI runner). If a process running with different user context reads an Easy Logging file from that location, an attacker can attempt a rapid replace or symlink trick to race the check.
- A compromised account that can write to a directory used by another service can try to overwrite the logging config and redirect logs to a location they control.
- On poorly provisioned VMs or images where default file ownership or permissions are permissive, the risk increases.
Note: exploitation requires local file write capability to the target path or directory. It is not a remote code execution vector by design; however, in multi-tenant platforms a local compromise is sometimes feasible and can be escalated into a broader incident.
What Microsoft has said and what their VEX document actually shows
Microsoft published a VEX/CSAF entry for CVE-2025-46327 which states that
Azure Linux images include an affected component and that Microsoft is monitoring for impact to other products and will update the CVE if more are found. The natural reading of Microsoft’s public note is that Azure Linux images are the only Microsoft product currently known to include the vulnerable library — but the machine-readable VEX file expands that picture: the VEX JSON explicitly lists
Azure Linux 3.0 and
CBL Mariner 2.0 (Microsoft’s internal/edge-focused Linux distribution) and identifies specific
telegraf package versions built for those distributions as the affected components. In other words, Microsoft’s published, machine-readable VEX shows more granularity — the inclusion is via the telegraf packages included in these distributions, not necessarily as a stand-alone Microsoft-built gosnowflake. That VEX indicates the components Microsoft marked as
known affected are:
Azure Linux 3.0 — with azl3 telegraf package versions flagged.CBL Mariner 2.0 — with cbl2 telegraf package versions flagged.
Those package-level entries demonstrate how an open-source driver can enter a vendor’s product indirectly via included packages (telegraf in this case) that themselves vendor or depend on the vulnerable library. This matches independent evidence from telegraf changelogs showing the project has updated/bumped its dependency on
github.com/snowflakedb/gosnowflake across releases.
Direct answer: Is Azure Linux the only Microsoft product that includes the library?
No —
Azure Linux is not the only Microsoft product identified in the MSRC VEX. The MSRC machine-readable entry lists both
Azure Linux 3.0 and
CBL Mariner 2.0 products and cites specific
telegraf package versions as components that include the affected gosnowflake dependency. Microsoft’s human-readable wording emphasizes Azure Linux but, when the VEX is inspected, the affected Microsoft product list is broader and precise: the vulnerability comes into Microsoft images through packaged components (telegraf versions bundled with those images). That means multiple Microsoft-distributed Linux images that include the same telegraf packages are considered affected by MSRC’s analysis. Caveat and practical note: Microsoft’s public statement also says that if additional Microsoft products are identified that include the library, the company will update the CVE record. That is a reasonable, cautious stance — many large vendors first publish what they have confirmed and then expand the scope as package-level scans and supply-chain analysis turn up further instances. For the moment, the MSRC VEX is the authoritative list of Microsoft products affected.
Cross-checking Microsoft’s claim with independent signals
Two independent signals help corroborate why telegraf packaged in Microsoft distributions would pull in
gosnowflake:
- Telegraf changelog entries and various RPM package changelogs show explicit dependency bumps referencing
github.com/snowflakedb/gosnowflake in telegraf releases — demonstrating telegraf’s use of the driver in at least some versions. That is the natural mechanism by which gosnowflake becomes present in OS images shipping telegraf.
- Upstream advisories (Snowflake’s release notes and GitHub security advisory) and public vulnerability databases (NVD, OSV) identify the affected version ranges and the fixed version — which clarifies remediation options for any product that bundles the vulnerable library. Multiple independent databases reflect the same vulnerability data.
Taken together, these independent sources corroborate Microsoft’s claim about inclusion via packaging and show the remediation route (upgrade to gosnowflake v1.13.3 or remove the dependency).
Practical remediation and mitigation guidance
For administrators, image maintainers, and engineers who operate Azure Linux, CBL Mariner, or any image that includes telegraf or other components that may depend on gosnowflake:
- Inventory and detection
- Search installed packages for telegraf and inspect the package metadata to determine whether telegraf was built with a gosnowflake dependency.
- Scan images and containers for
github.com/snowflakedb/gosnowflake artifacts (source trees, bundled binaries, or Go modules cached in builds).
- Use your software composition analysis (SCA) tooling to map dependencies and detect versions of gosnowflake in builds and images.
- Remediation
- Upgrade
gosnowflake to v1.13.3 or later wherever it is used directly in projects. Upstream Snowflake’s release notes and the GitHub advisory point to 1.13.3 as the fix.
- If you consume telegraf packages from a vendor/distribution, upgrade telegraf to a release that has bumped its gosnowflake dependency to a fixed version; if package maintainers have published updated telegraf that incorporate the fix, apply those updates to your images.
- If you build your own images, ensure your build pipelines fetch the fixed gosnowflake or adjust go.mod to require >= 1.13.3, then rebuild images.
- Configuration and runtime mitigations (if an immediate upgrade is not possible)
- Restrict file write permissions on directories and config files used by logging; ensure logging configuration files are not writable by unprivileged users or shared groups.
- Avoid storing logging configuration in world-writable or group-writable directories. Use atomic file replacement semantics and immutable file flags where platform permits.
- Where feasible, disable external Easy Logging features or configure logging via safer mechanisms (environment variables, centralized config service with authenticated access) rather than file-based user-supplied config.
- Monitoring and detection of exploitation attempts
- Audit logs for suspicious changes to logging configuration files and monitor for unexpected file ownership or permission changes.
- Alert on unexpected logging destinations or sudden changes in log verbosity from services that use gosnowflake indirectly.
- Consider adding filesystem watches for targeted directories (e.g., inotify on Linux) to catch rapid file replacement attempts.
These mitigations reduce the practical attack surface while you apply the vendor-supplied fixes. The first priority remains upgrading the library in any product that includes it.
Supply-chain and vendor risk considerations
This CVE illustrates a classic supply-chain pattern: an open-source library used by a connector or plugin (Telegraf in this case) becomes present in an operating system image because the image bundles that package. Key takeaways:
- Transitive inclusion: You may not import or call gosnowflake directly, but your systems can still be exposed if you run packages that vendor or depend on it.
- Image builders and maintainers: OS image maintainers (including cloud vendors) need to perform dependency scanning for included packages and their transitive dependencies. Microsoft’s VEX output demonstrates responsible disclosure practice — the vendor published a machine-readable statement flagging which of their images include the vulnerable component.
- Timeliness of patching: Upstream fixes (gosnowflake v1.13.3) need to be propagated into downstream baked artifacts (telegraf, OS packages, container images). Operators must verify not just that a fix exists upstream but that the patched component is actually present in their deployed artifacts.
Evaluating Microsoft’s transparency and the CSAF/VEX approach
Microsoft’s statement (human-readable) coupled with the published CSAF/VEX JSON is a positive sign of transparency. The VEX JSON provides an authoritative product tree and lists the
exact product components Microsoft identified as containing the vulnerable code (for example:
azl3 telegraf 1.31.0-11 and
cbl2 telegraf 1.29.4-17). Machine-readable VEX/CSAF makes it possible for large organizations to automatically ingest vendor impact statements and correlate them with deployed inventories. That reduces guesswork and speeds up remediation across sprawling fleets. Microsoft’s explicit note that they will update the CVE if impact to additional products is identified follows best practice: publish what’s known, and expand scope as new evidence emerges. Caution: a human-readable bulletin that mentions Azure Linux but omits other product names can be misread as “only Azure Linux is affected.” The VEX file is the source of truth for Microsoft’s analysis; the machine-readable listing clarifies exactly which images and package versions were flagged. Operators and downstream consumers should therefore rely on the VEX/CSAF feed for complete information rather than only the free-text human summary.
What to watch next
- Watch for updated OS images from Microsoft that include patched telegraf packages (rebuilt against gosnowflake >= 1.13.3).
- Look for telegraf upstream or distro package updates that explicitly state they have upgraded the gosnowflake dependency.
- Monitor the MSRC CVE page and their VEX/CSAF feed for any expansion of affected products (Microsoft already committed to updating the CVE if additional products are identified).
- Ensure your internal SBOMs (software bills of materials) and SCA tooling ingest MSRC’s CSAF/VEX feeds to automatically correlate vendor disclosures to your inventory.
Final assessment and guidance
- The vulnerability (CVE-2025-46327) is a genuine TOCTOU weakness in the Easy Logging code path of gosnowflake, and the fix is available upstream in v1.13.3. Operators should prioritize upgrades where the library is used directly.
- Microsoft’s public messaging names Azure Linux as an affected product in text, but the machine-readable VEX/CSAF clearly identifies Azure Linux 3.0, CBL Mariner 2.0, and specific telegraf package builds as affected — demonstrating that the library entered Microsoft products via packaged components. This means Azure Linux is not the only Microsoft product flagged; CBL Mariner images and specific telegraf package builds are also included in MSRC’s known-affected list. Operators should treat the VEX JSON as the authoritative list.
- If your environment uses telegraf, images based on Azure Linux or CBL Mariner, or any tooling that pulls the Snowflake Go driver via transitive dependencies, treat this as actionable: inventory, update packages, apply mitigations to configuration file permissions, and monitor for suspicious activity.
The incident is a reminder that even configuration-handling code — often perceived as lower risk compared with direct memory corruption or remote execution bugs — can enable misuse when file-system checks are performed incorrectly. The combination of upstream fixes, distributor VEX statements, and operator-level mitigations gives organizations a clear path to reduce risk.
Source: MSRC
Security Update Guide - Microsoft Security Response Center