Is MD5 Secure in 2026? When You Can (and Can't) Use It

The short answer: MD5 is not secure for any adversarial purpose and hasn't been since 2004. The longer answer is more nuanced, because security isn't binary. MD5 is fine for some specific non-security tasks, and millions of systems still rely on it without immediate consequences. Knowing where the line is is the difference between a working pragmatic choice and a CVE waiting to happen.

What "broken" actually means

A cryptographic hash function should have three properties:

1. Preimage resistance — given h, finding any m such that hash(m) = h should be infeasible.
2. Second preimage resistance — given m₁, finding a different m₂ with hash(m₂) = hash(m₁) should be infeasible.
3. Collision resistance — finding any two different inputs that hash to the same value should be infeasible.

MD5's preimage and second-preimage resistance are still mostly intact. You can't take an arbitrary MD5 hash and reverse it. What's broken — completely, devastatingly broken — is collision resistance. In 2004, Wang and Yu published a method to find MD5 collisions. By 2007 the technique was refined to "chosen-prefix collisions" — the attacker picks two different starting blocks of arbitrary content, and the algorithm appends matching suffixes that make both files hash identically.

This led to real-world attacks: in 2008 a research group used MD5 collisions to forge a signed Certificate Authority certificate. In 2012 the Flame malware exploited a different MD5 collision to impersonate Microsoft's signing infrastructure and spread through Windows Update. Both attacks required a tiny fraction of the computing power available in a typical cloud account today.

What still works (and why)

None of the above attacks help against the simple use case of "I copied this file from server A to server B, did it arrive intact?" That's because:

• The file isn't being attacked — bit-rot, cosmic rays, and flaky network cables don't know how to craft a collision.
• You're checking against your own previously-computed hash, not against a hash an attacker could have influenced.
• The probability of an accidental MD5 collision between two random files is roughly 1 in 2¹²⁸ — vanishingly small.

So if all you want is to detect accidental corruption in a trusted environment, MD5 still does the job. Linux distributions still publish MD5 sums (alongside SHA-256) for exactly this reason — for users on very old systems without modern hashing tools.

Where MD5 fails today

Passwords (catastrophically unsafe)

"md5(password)" was a common pattern in PHP applications throughout the 2000s. Today, a modern GPU can compute ~25 billion MD5 hashes per second. An 8-character lowercase password (26⁸ ≈ 200 billion possibilities) takes about 8 seconds to brute-force. Adding numbers and capitals gets you to a few hours. Rainbow tables for MD5 covering most realistic passwords already exist, freely downloadable.

Even "salted MD5" isn't enough. The salt prevents rainbow tables but does nothing to slow per-password brute force. Use bcrypt or Argon2id — they're designed to be slow on purpose, by a tunable factor.

File downloads where adversaries exist

If you publish a piece of software with an MD5 checksum, an attacker who controls your CDN, your DNS, or any link in the network path can substitute a backdoored binary with a colliding MD5. The user runs md5sum, sees the expected value, and trusts the file. SHA-256 doesn't have this weakness — no one has produced a SHA-256 collision in 25+ years of public research.

Digital signatures and certificates

Every major browser, every modern operating system, every code-signing tool either refuses MD5 outright or warns loudly. If you find yourself wanting to sign anything with MD5 in 2026, stop and ask why.

Where MD5 is fine

• Detecting accidental corruption after cp, scp, rsync, S3 multipart uploads, or any non-adversarial transfer.
• Internal deduplication in storage systems where collisions are tolerated (and where most systems do a byte-level comparison after the hash match anyway).
• Hash-based partitioning ("which shard does this user live on?") — collisions don't matter here.
• ETag generation for caches where you control both ends.
• Legacy interoperability — talking to a system that only speaks MD5. Wrap it carefully: never let MD5 be the only line of defense.

Migrating off MD5

If you have existing MD5 hashes in a database (passwords, file checksums, etc.) you don't have to invalidate them all at once:

• For passwords: rehash on next successful login. Check the MD5; if it matches, immediately compute and store an Argon2id or bcrypt hash, then drop the MD5. Within a few months, active users will be migrated naturally.
• For file integrity records: add a SHA-256 column. New files go in with both. Old files get their SHA-256 computed lazily when next accessed.
• For interop with external systems: support both. Send SHA-256 to systems that accept it; fall back to MD5 only when forced.

So... is MD5 secure?

No, but the answer matters less than understanding why. MD5 is a fine tool for non-security checksumming and a dangerous one for anything where someone might benefit from forging a match. If your use case is "I need to know the file arrived correctly from a server I trust," MD5 is fine. If your use case is "I need to know this file is exactly what the publisher signed," use SHA-256 or stronger.