MD5 and SHA-1 Scanner for Source Code

Why MD5 and SHA-1 are broken

MD5 collisions were demonstrated in 2004 and are now computable in seconds on commodity hardware; chosen-prefix collisions make forged certificates and documents practical. SHA-1 followed: the SHAttered attack produced real colliding PDFs in 2017, and chosen-prefix collisions arrived in 2020. Both are banned for signatures by NIST and BSI, and certificates signed with either are rejected by every modern browser and operating system.

Graded by the authorities, not by opinion

A broken-hash finding is not Korthex's opinion. Each hit is graded against the authority baseline channels and carries the framework tags it trips: a single MD5 usage can surface FIPS 140-3 (NIST SP 800-131A), BSI TR-02102, NIS2 and PCI DSS 4.0 at once, and the IETF channel attaches the protocol-level references (RFC 6151 for MD5, RFC 6194 for SHA-1). The scan report and the CBOM show exactly which frameworks each finding affects, with file and line.

Not every MD5 is a vulnerability

Cache keys, content de-duplication and non-security checksums do not become exploitable because MD5 is collision-broken. The problem is telling those apart from the MD5 that hashes a password or verifies untrusted input. Korthex attaches a taint-based verdict to every finding: dataflow across 16 import hops decides whether the digest guards something security-relevant, and the finding is prioritized or de-prioritized accordingly. You burn down real risk instead of chasing every hit.

Where broken hashes hide

• Password hashing: the worst case, and still common in legacy code paths
• Integrity checks of attacker-influenced input: downloads, uploads, webhooks
• Certificate signatures: MD5 or SHA-1 signed certificates in internal PKI
• HMAC-MD5 and HMAC-SHA1: not collision-affected, but deprecated and on every migration list
• Dependencies and binaries: the hash you did not write but still ship
• Git history: removed code that still defines what was exposed
• Databases: MD5() and SHA1() functions in SQL and stored procedures

The migration path

General hashing migrates to SHA-256 or SHA-3; password storage migrates to a dedicated password-hashing function rather than any fast hash; certificates get re-issued with modern signatures. The Korthex migration plan orders every item topologically with file:line, the concrete replacement, an effort estimate and dependency order, so the cleanup is a plan instead of a grep session.

Frequently asked questions

Is MD5 ever acceptable?

For non-security purposes like cache keys or de-duplication of trusted data, MD5 is not exploitable. It is unacceptable wherever an attacker can influence the input or benefits from a collision: passwords, signatures, integrity checks. The Korthex taint verdict makes exactly that distinction per finding.

Is HMAC-SHA1 broken?

No practical break exists for HMAC-SHA1, because HMAC does not rely on collision resistance. It is still deprecated by NIST and BSI guidance and should migrate to HMAC-SHA-256 on the normal schedule rather than as an emergency.

Does the scanner cover more than source code?

Yes: dependencies, compiled binaries, TLS certificates, databases and the full git history, across 18 languages.

How should password hashes be migrated?

Not to SHA-256. Password storage belongs in a dedicated password-hashing function; migrate opportunistically on next login and expire stragglers. Korthex flags fast-hash password paths as their own finding class.

Which compliance frameworks care?

All of them: NIST FIPS 140-3 (MD5 and SHA-1 signatures are non-approved), BSI TR-02102 (SHA-256 minimum), PCI DSS (strong cryptography requirements) and ISO 27001 A.8.24. Each finding carries its mapping.