Snowflake is a popular cloud-based data warehouse, and it’s used by thousands of businesses daily. Integrations and automations are often built using the Snowflake Connector for Python, which allows developers to connect their Python applications directly to Snowflake's data platform.

But in June 2024, an important vulnerability—CVE-2025-24795—was discovered and fixed by the Snowflake team. This vulnerability could lead to temporary Snowflake credentials being stored insecurely on Linux systems, exposing sensitive information to unauthorized users. In this post, we’ll walk through what happened, why it’s a risk, how to identify affected versions, and what the fix is.

What is CVE-2025-24795?

CVE-2025-24795 is a vulnerability affecting the Snowflake Connector for Python, specifically when temporary credential caching is enabled. The connector would write these credentials into a local file *with permissions that allowed any user on the system to read them*—that is, they were “world-readable.”

On a multi-user Linux system, any user could read another user's cached Snowflake credentials, which could be leveraged to access sensitive data or disrupt business operations.

How Does the Vulnerability Work?

When the Snowflake connector was configured to cache credentials (for smoother login and token management), it would cache those credentials *unencrypted* in a temporary file.

Crucially, the permissions of that file were “world-readable”—meaning that any user on the server, not just the owner, could read those cached credentials and use them to impersonate the victim user.

Example of the Problematic Code

Below is a simplified snippet to show the pattern of insecure file handling (not the exact code from the connector):

cache_path = "/tmp/snowflake_cache.txt"
with open(cache_path, "w") as f:
    f.write(str(temporary_credentials))
# By default, this file will have 644 permissions (rw-r--r--)

On Linux, this default behavior means -rw-r--r--, so *any* user can read this file.

If a user’s temporary credential looks like

{
  "token": "abc123token",
  "expires_in": 360,
  "user": "alice"
}

then any user could run

cat /tmp/snowflake_cache.txt

and instantly get Alice’s access credentials.

Exploit Scenario

Let’s say “Alice” and “Bob” both have user accounts on the same Linux server, and Alice connects to Snowflake using the vulnerable Python connector.

1. The connector caches Alice’s temporary credentials in /tmp/snowflake_cache.txt with *world-readable* permissions.

`bash

cat /tmp/snowflake_cache.txt

`

3. Bob sees Alice’s token and uses it in his own script to connect as Alice (or to do something malicious).

Technical Details

- The problem occurred only when *temporary credential caching* was enabled (not the default for all installations).

Linux file permissions default to allowing all users to read files unless set otherwise.

- The connector did not use Python's os.chmod() or the open(..., "w", opener=...) trick to create the file with 060 (owner-only) permissions.

Secure Fix

In v3.13.1, the fix was simple but effective. The connector now creates the cache file with permissions set to 600 (read/write only for the user):

import os

cache_path = "/tmp/snowflake_cache.txt"
with os.fdopen(os.open(cache_path, os.O_WRONLY | os.O_CREAT, o600), "w") as f:
    f.write(str(temporary_credentials))
# Now, only the owner can read or write the file.

`bash

find /tmp -name 'snowflake_cache.txt' -exec ls -l {} \;

References

- Snowflake Connector for Python Docs
- Snowflake Release Notes
- GitHub Issue and Patch (if public)
- NVD Entry for CVE-2025-24795 (when published)

Final Thoughts

CVE-2025-24795 is a classic example of how file permissions can make or break security, especially on systems with multiple users. If you maintain servers or automation that use the Snowflake Connector for Python, it’s essential to update your package, check your files, and stay aware of how sensitive data is being cached and stored.

Stay patched. Stay secure!

*Original research and explanation by your friendly security blog. Feel free to share or quote this post, giving credit and helping others stay protected!*

Timeline

Published on: 01/29/2025 21:15:21 UTC