[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f3uua9u96y5r58":3},{"success":4,"breach":5},true,{"_id":6,"name":7,"title":8,"slug":9,"domain":10,"breachDate":11,"addedDate":12,"publishedAt":12,"modifiedDate":13,"contentUpdatedAt":14,"source":15,"sourceUrl":16,"sourceUrls":17,"pwnCount":19,"affectedCount":19,"affectedCountStatus":20,"affectedCountLowerBound":19,"affectedCountUnit":21,"hasEnglishDescription":4,"contentLocale":22,"availableLocales":23,"translations":25,"severity":28,"dataClasses":29,"description":36,"seoTitle":37,"seoDescription":38,"logoUrl":39,"isVerified":40,"isSensitive":4,"isSpamList":40,"isMalware":40,"company":41},"2353ae6dd04bafd371d22e06","GhostMarket","GhostMarket.net 2009 Data Exposure Claim","ghostmarket-net-2009","ghostmarket.net","2009-01-01T00:00:00.000Z","2026-08-31T01:52:37.222Z","2026-09-17T19:39:13.825Z","2026-09-17T16:51:43.821Z","Sealed third-party phpBB archive metadata and bounded public incident context","https:\u002F\u002Fwww.theguardian.com\u002Fuk\u002F2011\u002Fmar\u002F02\u002Fghostmarket-web-scam-teenagers",[16,18],"https:\u002F\u002Fweb.archive.org\u002Fweb\u002F*\u002Fhttp:\u002F\u002Fghostmarket.net\u002F",3271,"lower_bound","unknown","en",[22,24],"tr",{"en":26,"tr":27},{"slug":9},{"slug":9},"Low",[30,31,32,33,34,35],"Email addresses","Usernames","IP addresses","Passwords","Forum posts","Private messages","\u003Cp>This record cautiously describes a forum dataset associated with the GhostMarket.net domain and attributed to the year 2009. The archive's internal metadata repeats the entity name as GhostMarket and GhostMarket.net, reports a source scope of 3,331 account records, and supplies only 2009 in its breach-date field. A bounded check of public Guardian archive metadata also supports the operational context of an online crime forum associated with the GhostMarket name during 2009. The public source does not prove the exact day on which this specific archive was obtained, confirm that the GhostMarket.net operator authenticated this dataset, or establish that every archived row came from one event. The record is therefore not presented as a verified first-party breach notice. \u003Ccode>isVerified\u003C\u002Fcode> remains false, and the description deliberately separates sealed archive evidence from broader public context.\u003C\u002Fp>\n\u003Cp>The date is stored with year-only precision. The database value January 1, 2009 is only a technical representation of the year 2009; it does not assert that the event occurred on January 1. Internal metadata labels 2009 as the “date of breach,” while the SQL export header carries a July 2009 generation time. A database dump generation time can indicate when an export was produced and does not independently establish an exposure date. The 2009 references in public metadata corroborate the entity's period of operation but do not fix the private data exposure to a specific day. For these reasons, \u003Ccode>breachDatePrecision\u003C\u002Fcode> is \u003Ccode>year\u003C\u002Fcode>, the exact day remains unknown, and the January 1 representation is explicitly qualified. A future primary source could justify a separate date review.\u003C\u002Fp>\n\u003Cp>The source is a complete 3,728,860-byte 7z archive. Its SHA-256 identity is sealed and a full 7z integrity test passed. All four regular members were extracted and independently bound by size and SHA-256. They consist of a generic Breached_Info metadata file, an Info metadata file containing GhostMarket context and samples, a CSV representation of the phpBB users table, and a MySQL dump containing eight phpBB tables. No nested archive was found, and the source payload was not modified. Explanatory files were assessed through PII-free counters and structural labels rather than being treated as bulk account data. This distinction prevents the fact that a member is readable from being misrepresented as authority to import every token found in it.\u003C\u002Fp>\n\u003Cp>E-mail mapping relies only on explicit schema authority. The MySQL DDL directly identifies \u003Ccode>phpbb_users.user_email\u003C\u002Fcode> and \u003Ccode>phpbb_banlist.ban_email\u003C\u002Fcode> as e-mail fields. Other columns whose names contain “email,” including \u003Ccode>user_email_hash\u003C\u002Fcode>, \u003Ccode>user_emailtime\u003C\u002Fcode>, \u003Ccode>user_allow_viewemail\u003C\u002Fcode>, and \u003Ccode>user_allow_massemail\u003C\u002Fcode>, represent a hash, a timestamp, or preference flags and are not imported as addresses. Ninety-two whole-field values elsewhere in usernames, message subjects, posts, instant-messaging identifiers, and configuration values happen to resemble canonical e-mail addresses, but those fields do not carry account e-mail semantics and are excluded. No catalog-count fitting, target-count tuning, or unrestricted raw-token harvesting was used to choose the mapping. Only the DDL-declared e-mail fields were accepted.\u003C\u002Fp>\n\u003Cp>Two independent compiled readers parsed all 34,014 SQL rows across 505 INSERT statements without structural error. Both produced the same sequence of 3,281 valid e-mail occurrences, the same 71,823 bytes, and the same SHA-256 identity. Row-width mismatches, unterminated statements, scanner failures, and parser errors were all zero. After duplicate occurrences were removed and strict ASCII e-mail validation was applied, 3,271 sorted unique canonical addresses remained. The explicit \u003Ccode>user_email\u003C\u002Fcode> column in the phpBB users CSV independently produced 3,280 occurrences and exactly the same 3,271-address canonical set. The CSV and SQL canonical files are byte-identical. The CSV is not imported again; it is retained as equivalent-representation evidence so that an account is not written twice merely because the same table appears in two source formats.\u003C\u002Fp>\n\u003Cp>The Info metadata member contains two raw e-mail-like tokens. Only one belongs to the explicit account e-mail set. The other appears in metadata or sample text and cannot be bound to an authoritative account e-mail field. The Info member is therefore not selected as an e-mail source and is recorded with a \u003Ccode>NON_AUTHORITATIVE_METADATA_SAMPLE\u003C\u002Fcode> debt. The generic Breached_Info member contains neither an e-mail field nor an at-sign. The CSV representation is bound as \u003Ccode>DUPLICATE_REPRESENTATION_SET_EQUAL\u003C\u002Fcode>. Mapping coverage intentionally remains \u003Ccode>PARTIAL\u003C\u002Fcode> because these classifications do not claim that every piece of text in the archive, or the entire historical event, is complete. The addresses that are admitted are nevertheless fully supported by explicit DDL and independent canonical-set agreement.\u003C\u002Fp>\n\u003Cp>The source includes usernames, IP addresses, password hashes, forum posts, and private-message tables, so those classes are listed as scope context for the record. This LeakData operation imports e-mail addresses only. Passwords, IP addresses, usernames, post content, and private-message content are not written to Mongo relationships by this job. \u003Ccode>totalRecords\u003C\u002Fcode> records the 3,331 source account rows. \u003Ccode>canonicalEmailCount\u003C\u002Fcode> and \u003Ccode>affectedCountLowerBound\u003C\u002Fcode> are 3,271, but that number is not a unique-person count. One person can control several addresses, and an address can be shared or inactive. The exact affected-person population remains unknown, so \u003Ccode>pwnCount\u003C\u002Fcode> is null. The 3,271 figure is solely the lower bound of unique canonical addresses verified in explicit e-mail fields.\u003C\u002Fp>\n\u003Cp>Readers should preserve three distinctions. First, public metadata supports the GhostMarket identity and its 2009 context, but no first-party confirmation of this exact dataset was located. Second, a passing archive integrity test proves stable bytes and readable structure, not the truth of every historical claim in the files. Third, presence of an address in the canonical set does not prove that the person used every other field in the archive or that an account remained active. The record is marked sensitive, retains its unverified status, and is processed with fail-closed e-mail-only rules. If stronger primary evidence later establishes a more precise date, different scope, or different organizational identity, the metadata should be revised through a separate evidence review.\u003C\u002Fp>","GhostMarket.net 2009 Data Exposure Claim (At Least 3,271 Reported Records)","Review the GhostMarket.net 2009 data exposure claim and the 3,271-address lower bound verified only from explicit DDL e-mail fields.","https:\u002F\u002Fwww.google.com\u002Fs2\u002Ffavicons?domain=ghostmarket.net&sz=128",false,{"name":7,"sector":42,"country":43,"website":44,"websiteArchiveUrl":43,"websiteStatus":43,"websiteCheckedAt":45},"Online forum","","https:\u002F\u002Fghostmarket.net",null]