Rule Information
Tags
pythonuuiduuid1information-disclosuremac-addressprivacyCWE-200OWASP-A05
CWE References
Interactive Playground
Experiment with the vulnerable code and security rule below. Edit the code to see how the rule detects different vulnerability patterns.
pathfinder scan --ruleset python/PYTHON-LANG-SEC-100 --project .1
2
3
4
5
6
7
8
rule.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
About This Rule
Understanding the vulnerability and how it is detected
Python's uuid.uuid1() generates a UUID using the current timestamp combined with the host machine's MAC address (or a random node if the MAC address cannot be determined). The MAC address is embedded in bits 48–63 of the UUID and is visible in plain text when the UUID is converted to its canonical string form.
This leaks hardware identity information that can be used to track the physical machine generating UUIDs across different sessions or deployments. In cloud environments, the MAC address may identify the specific VM instance or network interface. In on-premises deployments, it directly identifies physical hardware. When UUIDs are used as session tokens, CSRF tokens, or other security-sensitive identifiers, the MAC address embedded in them also provides attackers with predictability information since the node component is constant.
The safe alternative is uuid.uuid4(), which is generated entirely from cryptographically random bytes with no hardware-derived components, providing both better privacy and better uniqueness properties for security-sensitive use cases.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Hardware Identity Disclosure
The MAC address embedded in uuid1() UUIDs identifies the network interface that generated them. If UUIDs are exposed in API responses, logs, URLs, or database exports, an attacker can extract the MAC address and use it to track the specific machine or container across deployments, identify cloud VM instance types, or correlate activity across sessions.
2
Predictability in Security Tokens
Because the node component (MAC address) of uuid1() is constant for a given host and the timestamp component is sequential, uuid1() output is partially predictable. If uuid1() is used to generate session tokens, password reset tokens, or API keys, an attacker who observes one token can narrow the search space for other tokens generated around the same time.
3
Privacy Regulation Violations
GDPR and other privacy regulations treat hardware identifiers including MAC addresses as personal data when they can be linked to an individual. Embedding MAC addresses in user-visible UUIDs and logging or transmitting them may constitute a privacy violation requiring data protection impact assessment and user notification obligations.
4
Container and Infrastructure Fingerprinting
In containerized environments, the MAC address in uuid1() can help attackers distinguish between different nodes in a cluster, track which node processed a given request, or identify infrastructure layout when combined with other signals. This information assists in lateral movement planning and targeted attacks against specific nodes.
How to Fix
Recommended remediation steps
- 1Replace uuid.uuid1() with uuid.uuid4() for all security-sensitive identifiers including session tokens, API keys, CSRF tokens, and password reset links.
- 2Audit all UUID generation in your codebase and replace uuid1 calls where the MAC address disclosure is unacceptable.
- 3If time-ordering is required, consider UUID v7 (available in third-party libraries) which uses random bytes for the node component instead of the MAC address.
- 4Review API responses, logs, and database schemas for existing uuid1-generated values that may have already leaked MAC addresses.
- 5Document any intentional use of uuid1 where MAC address embedding is acceptable, and add a comment explaining the justification.
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
This rule detects all calls to uuid.uuid1() in Python source code. Every call site is flagged regardless of context because the MAC address is always embedded in the output. The rule matches both the qualified form uuid.uuid1() and any local alias of the uuid module. Calls that pass an explicit node parameter (uuid.uuid1(node=random_node)) are also flagged since even with a random node the temporal predictability concern remains.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
GDPR Article 4
MAC addresses qualify as personal data when linkable to an individual; embedding them in user-visible identifiers requires justification
OWASP Top 10
A05:2021 - Security Misconfiguration covers unnecessary information exposure
NIST SP 800-53
SC-28: Protection of Information at Rest; avoid embedding hardware identifiers in persistent tokens
CWE Top 25
CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
References
External resources and documentation
Similar Rules
Explore related security rules for Python
MEDIUM
Insecure MD5 Hash Usage
MD5 is cryptographically broken and unsuitable for security-sensitive purposes. Use SHA-256 or SHA-3 instead.
MEDIUM
Insecure SHA-1 Hash Usage
SHA-1 is cryptographically weak due to practical collision attacks. Use SHA-256 or SHA-3 for security-sensitive hashing.
MEDIUM
Insecure File Permissions via os.chmod
os.chmod() or os.fchmod() sets overly permissive file permissions that allow unauthorized read, write, or execute access.
Frequently Asked Questions
Common questions about UUID Version 1 Leaks MAC Address
uuid.uuid1() is a low-severity concern rather than an immediate critical vulnerability.
The main risks are information disclosure (MAC address leakage) and partial predictability.
If UUIDs are used for internal database primary keys that are never exposed externally,
the risk is lower. The concern escalates significantly when uuid1() is used for security
tokens such as session IDs, API keys, or password reset links.
The last 12 hexadecimal characters (6 bytes) of a uuid1() string represent the node,
which is typically the host's MAC address. For example in
"550e8400-e29b-41d4-a716-446655440000", the node is "446655440000". This can be
looked up in IEEE OUI databases to identify the hardware vendor and, for cloud
instances, often the specific instance type or provider.
Python first attempts to find a real MAC address using platform-specific methods.
If it cannot determine the MAC address, it falls back to a randomly generated 48-bit
node with the multicast bit set. In many cloud and container environments, Python
successfully finds the virtual network interface MAC address, so the leakage risk
is real in those environments.
Yes, you can pass a random integer as the node parameter: uuid.uuid1(node=random.getrandbits(48)).
However, this still leaves the temporal predictability concern since the timestamp
component is sequential. For security-sensitive use cases, uuid.uuid4() is simpler
and avoids both concerns entirely.
UUID v3 and v5 are name-based and deterministic — they generate the same UUID for
the same input. They do not embed a MAC address, but they are not suitable as random
security tokens. Use them only when you need a stable, reproducible identifier for
a known namespace and name. For unpredictable security tokens, always use uuid.uuid4().
New feature
Get these findings posted directly on your GitHub pull requests
The UUID Version 1 Leaks MAC Address rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.