Horse & Hound Forum 2017 Associated Dataset

It is not presented as a verified security incident. No Horse & Hound notice was found that binds the inspected archive to a specific incident, so isVerified=false is required. January 1, 2017 is only the technical representation of month-level precision and does not assert that an incident occurred on that exact day. The number of unique affected people is unknown, so pwnCount remains null.

The event association comes from two separate public catalogues. BreachEra lists Horse and Hound, horseandhound.co.uk, the year 2017, a scope of 95,337 records, and the classes email addresses, IP addresses, usernames, and passwords in one row. Leak-Lookup reports 95,338 records for the same domain and lists username, email address, IP address, password, and salt columns in its statistics schema. The one-record difference between those catalogues is fully explained by one non-data preamble record in the sealed source. No data was selected or expanded merely to approach a catalogue total.

The inspected HorseAndHound_BF.7z archive is 4,529,396 bytes and is sealed with SHA-256 ee05e8…5352. A complete 7z integrity test passed. Its principal member is named Forums-secure.horseandhound.co.uk_vb_January_2017.txt, is 8,868,144 bytes, and has SHA-256 b69419…7ca2. The source contains 95,338 physical records: one preamble and 95,337 data records. A separate 441-byte generic distribution note has no row-level email field and was closed as non-email metadata rather than being used to widen the source.

The principal source is not an ordinary CSV with an explicit header. Its records resemble a colon-delimited vBulletin representation with variable widths because usernames can themselves contain colons. The review used the sole 32-character hexadecimal password digest in each data record as a structural anchor and measured the email-shaped field two positions before that anchor. The rule is structurally available for every one of the 95,337 data records. Nevertheless, field authority is inferred instead of named by a header, so the safety policy applies a higher admission threshold.

Two independent compiled Go parsers processed the same complete member set using separate implementations and produced byte-identical occurrence and canonical streams. Both reported 94,917 accepted occurrences, 94,876 unique canonical results, 41 duplicate occurrences, 390 rejected nonblank values, and 30 blank slots. Coverage of the selected field is about 99.56 percent, while the strongest alternative email-shaped field contains only 90 candidates. These measurements support a strong inference, but mapping-admission v3 requires at least 100,000 accepted occurrences for an inferred mapping.

The observed 94,917 occurrences are 5,083 below that mandatory minimum. The gate therefore closed with INFERENCE_OCCURRENCES_TOO_SMALL. The threshold was not reduced, other fields were not added to fit a catalogue count, and the 94,876 canonical results were not published as a count of affected people. This metadata record does not mean that any email relationship was imported: canonicalEmailCount is null, importedRecordCount=0, and processing remains pending. No READY package, import job, or Mongo email relationship may be created unless mapping admission later succeeds.

A live global comparison was performed only as an audit. Of the inferred canonical set, 73,670 values already existed in the global email index and 21,206 did not; the matches were distributed across 798 breach identifiers. That distribution did not identify one existing record as the owner of the Horse & Hound source, and no previous import job was bound by the same source key, archive SHA, canonical SHA, or filename identity. An overlap does not independently prove that an address belongs to this forum. It shows only that the same canonical value appears in other datasets.

Wayback CDX metadata, checked without downloading archived page content, confirms successful captures for the secure forum subdomain during 2017. The current official Horse & Hound domain also supports the service identity. In contrast, no exact entry was found in a public breach source or NiamonX, and no first-party incident disclosure was identified. Those negative checks are not proof of absence; they define the verification boundary. The record therefore keeps attribution cautious, makes no whole-event completeness claim, and should be reassessed if a first-party notice or an explicit source schema becomes available.