← ARCHIVE / CASE-20200811-SHOCKGOR
CASE FILE CASE-20200811-SHOCKGOR

ShockGore

shockgore.com
CRITICAL SENSITIVE
73,944 ACCOUNTS
AUG 2020 BREACH DATE
6 DATA TYPES
17mo DARK PERIOD

EVIDENCE FILE

CASE CONTEXT

This TRACED record summarizes the public breach profile for ShockGore. The file tracks the known incident date, the date the breach surfaced publicly, the estimated account exposure, and whether Have I Been Pwned currently marks the case as verified. It is written for quick risk review, source attribution, and follow-up checks by people who need a plain-English view of what was exposed.

The reported data classes include Email addresses, Genders, IP addresses, Passwords. If the case includes passwords, reused credentials should be treated as compromised and replaced anywhere they were used. The password checker on TRACED uses the Have I Been Pwned k-anonymity range API so the full password is never sent off the device.

Each case page is intentionally narrow: it separates the public incident record from account recovery advice, keeps the source data visible, and avoids collecting visitor identifiers. Use it as a starting point for reviewing exposure, then confirm account-specific impact with the affected service and your password manager.

RISK REVIEW

The affected data classes for ShockGore are listed as Email addresses, Genders, IP addresses, Passwords, Private messages, Usernames. TRACED repeats those fields in plain language because the practical response depends on the type of information exposed. Email addresses and usernames can support phishing or account enumeration, profile data can help with impersonation, and financial or government identifiers require a more careful fraud review.

Have I Been Pwned currently marks this breach as verified, which means the service has reviewed the incident record against its source standards. The breach date is recorded as AUG 2020, and the exposure estimate is 73,944 accounts. Those numbers describe the public incident record, not a guarantee that a specific visitor had an account in the service or that every exposed record contained the same fields.

Because this breach includes password data, reused passwords should be replaced anywhere they appear. A unique password manager entry and multi-factor authentication are the safest follow-up steps. HIBP marks this breach as sensitive. TRACED keeps the public facts readable while avoiding collection of visitor identifiers, passwords, or account lookups tied to a person. For personal cleanup, start with password reuse, two-factor settings, recovery email security, and alerts from the affected service. For research, use the case file as a source pointer and compare it with the original HIBP entry before citing exact impact.

DISCOVERY GAP

DISCOVERY GAPTime between breach occurrence and public disclosure
BREACH OCCURREDAUG 2020
1 year, 5 months dark
DATA SURFACEDJAN 2022

Nearly 1 year elapsed before this breach surfaced publicly.

REDACTED EVIDENCE

PASSWORD DATA CLASSIFIED
████████████ ████████ ████████████████
████████████████████ ████████████ ████████

If this breach included passwords, treat them as compromised. If they were reused anywhere else, change them there too.

RELATED CASES - 2020