Skip to content
SimpleTools24

UUID v1 and MAC Addresses: The Privacy Risk Explained

By SimpleTools24Published 4 min read

A version 1 UUID can contain the MAC address of the network interface on the machine that generated it, in its last 12 hex digits, together with a precise timestamp of when it was created. Anyone who sees the UUID can therefore learn roughly when it was made and, potentially, which device made it. RFC 9562 recommends that implementations use a random node value instead, marked by setting the multicast bit, and that new systems prefer v4 or v7, which contain no hardware identifiers.

In this guide

Where the MAC Address Lives

text
f81d4fae-7dec-11d0-a765-00a0c91e6bf6
                         ^^^^^^^^^^^^
                         node: 00:a0:c9:1e:6b:f6

The final 48 bits of a v1 UUID are the node field. The original design used the IEEE 802 MAC address of a network card, because MAC addresses are intended to be globally unique, which helped guarantee unique UUIDs without coordination.

The first three bytes of a real MAC address identify the manufacturer (the OUI). So the node can reveal the hardware vendor, and, combined with other data, the specific machine.

What Else a v1 UUID Reveals

  • Creation time, to 100-nanosecond precision, from the timestamp fields. How to get the timestamp from a UUID shows how to read it.
  • Generation order and rate: UUIDs from the same machine share a node and have increasing timestamps, so a sequence can reveal how busy a system is.
  • Linkability: IDs from different documents or systems can be tied back to the same computer.

A Well-Known Example

The privacy issue isn't theoretical. In 1999, investigators tracing the Melissa macro virus used identifiers embedded in Microsoft Word documents, which were derived from the author's computer, as one of the clues that helped connect the virus to its creator. After this, Microsoft changed how such identifiers were generated, and later Windows APIs moved away from MAC-based GUIDs by default.

Real MAC or Random Node?

Modern implementations often avoid using the real MAC address. RFC 9562 allows a random 48-bit node value with the multicast bit set (the least significant bit of the first byte). Real MAC addresses assigned to network cards don't have that bit set, so it distinguishes random nodes from hardware addresses:

Telling a random node from a hardware address
First node byteMulticast bitLikely meaning
Even (e.g. 00, a4)0Possibly a real MAC address
Odd (e.g. 01, a5)1Random node, as RFC 9562 recommends

The UUID decoder reports this: for v1 and v6 UUIDs it shows the node and clock sequence, and notes when the multicast bit indicates a random node. Treat an even first byte as "possibly a MAC" rather than proof; some generators produce random values without setting the bit.

Which Libraries Use the MAC Address?

Behaviour varies, so check your platform's documentation:

  • Python: uuid.uuid1() uses the hardware address from uuid.getnode() when it can find one, and otherwise a random value with the multicast bit set. You can pass your own node argument.
  • JavaScript (uuid package): v1() uses a random node by default rather than reading the MAC.
  • Databases and older systems: some still produce MAC-based v1 values.

Safer Alternatives

  • UUID v4: entirely random; reveals nothing about time or machine. See what is UUID v4.
  • UUID v7: time-ordered but with random bits instead of a node; reveals creation time but not hardware. See UUID v4 vs UUID v7.
  • UUID v6 with a random node: for systems that need v1-style timestamps in sortable form.

What to Do About Existing v1 UUIDs

  • Audit where they're exposed: URLs, public APIs, file names, documents shared externally.
  • Stop generating new v1 values for anything public; switch to v4 or v7.
  • Keep old IDs stable if they're stored as references; changing primary keys is costly. Consider adding a new public identifier instead.

Generating Privacy-Friendly IDs

The UUID v4 generator and UUID v7 generator create IDs in your browser with no hardware identifiers. UUID versions explained summarises the trade-offs between all versions.

How to Check Your Own Systems

  1. Find where v1 UUIDs are generated: search code for uuid1, v1(, NEWSEQUENTIALID or older library defaults.
  2. Decode a few real IDs and look at the node field and its multicast bit.
  3. Compare node values across IDs: the same node in many IDs from one server suggests a fixed hardware-derived value.
  4. Trace where those IDs are visible: URLs, emails, exported files, public APIs.

If you find hardware-derived nodes in public IDs, switch generation to v4 or v7 for new records and decide whether existing exposed IDs need replacing.

Frequently Asked Questions

Does every UUID v1 contain a MAC address?

No. Many implementations use a random node. Check the multicast bit as a hint.

Can a UUID v4 reveal my MAC address?

No. Version 4 is random apart from its version and variant bits.

Does UUID v7 contain a MAC address?

No. It contains a timestamp and random data.

Is it safe to share v1 UUIDs internally?

Usually, within trusted systems. The concern is exposing them to the public or third parties.

Summary

v1 UUIDs can expose a hardware address and an exact creation time. Check the node's multicast bit, avoid v1 for public IDs, and prefer v4 or v7 for new systems.

Sources