Use of SHA1 Weak Hash Algorithm

HIGH

Detects use of SHA1 (crypto/sha1) which has a proven collision (SHAttered, 2017) and is deprecated by NIST for all applications through 2030.

Rule Information

Language
Go
Category
Security
Author
Shivasurya
Shivasurya
Last Updated
2026-04-13
Tags
gosecuritycryptosha1weak-hashshatteredcollision-attackCWE-328OWASP-A02
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 golang/GO-CRYPTO-002 --project .
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
rule.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Cross-file analysis: 3 files

About This Rule

Understanding the vulnerability and how it is detected

SHA-1 was broken in practice by the SHAttered attack (February 2017), produced by Marc Stevens (CWI Amsterdam) and Google Research. The attack found two distinct PDF files with identical SHA-1 digests using 9.2 × 10^18 SHA-1 computations — equivalent to 6,500 CPU-years and 100 GPU-years, at a cost of roughly $110,000 on cloud hardware.

NIST announced in December 2022 that SHA-1 is being deprecated for ALL applications (not just digital signatures). The deadline is December 31, 2030, after which any FIPS 140-validated module listing SHA-1 as an approved algorithm moves to the historical list.

All major browser vendors (Chrome, Firefox, Edge, Safari) stopped trusting SHA-1 TLS certificates by January–March 2017. The CA/Browser Forum banned issuance of SHA-1-signed TLS certificates effective January 1, 2016.

Git still uses SHA-1 for object naming (commit/tree/blob hashes), and migration to SHA-256 is in progress since Git 2.29 (2020). The SHAttered team noted that crafting a colliding Git object is harder than generic collision due to format constraints, but the technical feasibility is established.

**SHA-1 in HMAC (edge case)**: HMAC-SHA1 is not directly affected by SHA-1 collision attacks because HMAC's security proof relies on PRF properties, not collision resistance. HMAC-SHA1 remains used in OAuth 1.0a. However, HMAC-SHA256 is universally supported and preferred for all new implementations.

Security Implications

Potential attack scenarios if this vulnerability is exploited

1

Forged TLS Certificates

A SHA-1 collision enables certificate forgery. In the 2008 rogue CA attack (Sotirov et al.), researchers used MD5 collisions to create a rogue CA certificate. The same attack class applies to SHA-1. Browser vendors removed SHA-1 trust precisely to prevent this.

2

Code Signing Bypass

If a build system or software distribution pipeline verifies code signatures using SHA-1, an attacker who can produce a colliding binary passes the integrity check. The SHAttered PDFs demonstrate the collision is real and producible with nation-state resources.

3

Git Repository Poisoning

In Git's SHA-1-based object model, a commit/tree/blob hash acts as both the object ID and its integrity proof. A SHA-1 collision attack against Git objects could theoretically insert malicious content while preserving the expected hash, though the attack is more complex than generic file collisions due to Git object format requirements.

How to Fix

Recommended remediation steps

  • 1Replace sha1.New() and sha1.Sum() with sha256.New() and sha256.Sum256().
  • 2For SHA-512 where larger output is needed: use crypto/sha512.
  • 3Audit stored SHA-1 hashes and plan migration to SHA-256 for all security-relevant uses.
  • 4For HMAC, prefer HMAC-SHA256 over HMAC-SHA1 in all new code.
  • 5Note output size change (20 bytes → 32 bytes) — update any fixed-width columns.
  • 6For password hashing, use bcrypt or argon2id — not any variant of SHA.

Detection Scope

How Code Pathfinder analyzes your code for this vulnerability

Detects all calls to crypto/sha1 package methods (New(), Sum()). Flags any use regardless of context — sha256 is a drop-in replacement with no meaningful performance penalty for application code.

Compliance & Standards

Industry frameworks and regulations that require detection of this vulnerability

NIST SP 800-131A Rev 2 (2019)
SHA-1 is disallowed for digital signature generation. Legacy verification only. Deprecated through December 31, 2030 for all remaining uses (NIST Dec 2022 announcement). URL: https://csrc.nist.gov/pubs/sp/800/131/a/r2/final
CA/Browser Forum Baseline Requirements
SHA-1 TLS certificates banned effective January 1, 2016.
PCI DSS v4.0
Requirement 4.2.1 — Strong cryptography required for data in transit
OWASP Top 10
A02:2021 — Cryptographic Failures

References

External resources and documentation

Similar Rules

Explore related security rules for Go

Frequently Asked Questions

Common questions about Use of SHA1 Weak Hash Algorithm

SHA-1 was broken in practice by the SHAttered attack (February 2017), produced by Marc Stevens (CWI Amsterdam) and Google Research. The attack found two distinct PDF files with identical SHA-1 digests using 9.2 × 10^18 SHA-1 computations — equivalent to 6,500 CPU-years and 100 GPU-years, at a cost of roughly $110,000 on cloud hardware. NIST announced in December 2022 that SHA-1 is being deprecated for ALL applications (not just digital signatures). The deadline is December 31, 2030, after which any FIPS 140-validated module listing SHA-1 as an approved algorithm moves to the historical list. All major browser vendors (Chrome, Firefox, Edge, Safari) stopped trusting SHA-1 TLS certificates by January–March 2017. The CA/Browser Forum banned issuance of SHA-1-signed TLS certificates effective January 1, 2016. Git still uses SHA-1 for object naming (commit/tree/blob hashes), and migration to SHA-256 is in progress since Git 2.29 (2020). The SHAttered team noted that crafting a colliding Git object is harder than generic collision due to format constraints, but the technical feasibility is established. **SHA-1 in HMAC (edge case)**: HMAC-SHA1 is not directly affected by SHA-1 collision attacks because HMAC's security proof relies on PRF properties, not collision resistance. HMAC-SHA1 remains used in OAuth 1.0a. However, HMAC-SHA256 is universally supported and preferred for all new implementations.
Use Code Pathfinder to scan your codebase: pathfinder scan --ruleset golang/GO-CRYPTO-002 --project .
This vulnerability is rated as HIGH severity.
Yes! Code Pathfinder allows you to customize rules. Modify detection patterns, adjust severity levels, add custom sanitizers, and configure the rule to fit your organization's security policies.

New feature

Get these findings posted directly on your GitHub pull requests

The Use of SHA1 Weak Hash Algorithm rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.

See how it works