ervik.as
Daily News· September 12, 2026

A Dark Web Marketplace Is Selling 153 Million Driver's Licenses, Including the US Defense Secretary's Own, and GitLab's Newest Critical Flaw Was Exploited Within a Day

A look at the last 24 hours in cybersecurity: identity verification firm IDScan.net confirms hackers accessed its cloud platform after a dark web marketplace called Nexus began advertising more than 153 million US and Canadian driver's licenses — among them, reportedly, Defense Secretary Pete Hegseth's own license. Separately, GitLab patches a perfect-10 path traversal flaw letting unauthenticated attackers read arbitrary files from self-managed servers, with real-world exploitation attempts beginning just one day after the fix shipped.

153 Million Driver's Licenses, Sold Alongside the Defense Secretary's Own

Start with the detail that should make anyone reconsider what they hand over for a routine ID check: a dark web marketplace called Nexus began advertising more than 153 million US and Canadian driver's license scans, and among the sample records used to prove the data was real was the driver's license of US Defense Secretary Pete Hegseth. Investigative journalist Brian Krebs first reported the listing after a source alerted him on August 31 to a post on the Russian-language cybercrime forum Exploit — the seller had offered Krebs's own Virginia driver's license as a free sample specifically to prove the trove was genuine, and Krebs independently confirmed it by searching the database for records belonging to people who'd agreed to be checked.

Identity verification firm IDScan.net, a Louisiana-based company whose technology underpins ID and age checks for car rental companies, retailers, and cannabis dispensaries, confirmed in a September 4 notice that it detected unauthorized access to its cloud platform on or around September 1. The company's language is carefully hedged even in confirmation: an unauthorized third party "may have accessed and/or copied certain customer information," with the investigation still ongoing as of this writing. Nexus itself claims something considerably more alarming than a single point-in-time breach — the operators stated they had been "exfiltrating new data for over a year into our private database," a claim that, if accurate, describes sustained, undetected access rather than a discrete incident with a clean before-and-after. Nexus's own advertised inventory runs well past driver's licenses alone: more than 10 million identification cards, over 3 million travel and international documents, and at least 579,000 medical cards, including marijuana dispensary identification — for a combined claim of documents tied to more than 170 million people across North America. A blank search on the platform reportedly returned roughly 11.5 million pages of results, a figure researchers noted was broadly consistent with the advertised scale rather than an obvious exaggeration.

The exposed data itself goes meaningfully beyond a flat photo of a license. Reports describe the compromised records including front and back scans of documents along with infrared and ultraviolet versions of the same images — the layers of detail specifically captured to defeat counterfeit-detection checks during identity verification, now sitting in the hands of whoever paid for access. The FBI's New Orleans field office has opened a formal inquiry, IDScan.net says it's cooperating, and multiple law firms have already opened investigations into potential class-action litigation. Nexus itself went offline shortly after Krebs's reporting became public, which removes the immediate point of sale but does nothing to un-expose data that's already been sold or downloaded in the interim. If your organization uses any third-party identity verification service for age checks, rental agreements, or account onboarding, this is a useful, uncomfortable prompt to ask a direct question: what does that vendor actually do with the scan after the check completes, and for how long do they keep it? A one-time verification that gets retained indefinitely on a vendor's server is exactly the kind of long-tail liability this incident illustrates — the exposure here reportedly accumulated over more than a year before anyone caught it.

A Perfect-10 GitLab Flaw, Exploited One Day After the Patch

The second story of the day is a clean, fast-moving illustration of just how little runway exists between a patch shipping and real-world exploitation beginning. GitLab released emergency fixes on September 10 for CVE-2026-85706, a maximum-severity path traversal vulnerability in the API that handles repository commit information, affecting self-managed Community Edition and Enterprise Edition deployments. The flaw stems from improper path confinement combined with missing authentication enforcement — an unauthenticated attacker can manipulate a single HTTP request to make the server return files from outside the intended repository path entirely, with GitLab's own advisory noting that files accessible to the GitLab service account, including credentials, secrets, access tokens, SSH keys, and configuration data, may be exposed. Security researcher s3ntago reported the flaw through GitLab's HackerOne bug bounty program; the fix ships in versions 19.1.8, 19.2.6, and 19.3.2, and GitLab.com itself is already running the patched release.

The timeline from here is the part worth genuinely internalizing. Exposure-management firm WatchTowr confirmed it observed the first in-the-wild probing attempts targeting CVE-2026-85706 just one day after GitLab's patch went out — meaning attackers were reverse-engineering the fix and building working exploitation attempts before most self-managed GitLab operators had likely even applied it. CISA added the flaw to its Known Exploited Vulnerabilities catalog on September 11 with a remediation deadline of September 14 for federal civilian agencies, and specifically flagged it as requiring forensic triage under Binding Operational Directive 26-04 — language that reflects a real possibility CISA is taking seriously: vulnerable systems may already have been accessed before anyone got around to patching them, meaning simply applying the fix now doesn't answer whether an attacker got there first. GitLab servers are a genuinely attractive target for exactly this kind of flaw, since they routinely host proprietary source code, CI/CD pipeline configurations, deployment scripts, and access tokens — the kind of access that, once obtained, gives an attacker a foothold into everything that codebase touches downstream, not just the GitLab instance itself.

GitLab didn't stop at the one fix. The same release addressed CVE-2026-87719, a critical insecure deserialization flaw in GitLab Enterprise Edition's GraphQL subscription serializer, letting an authenticated user with Duo Chat access submit a crafted GraphQL argument to bypass serialization controls and potentially expose Advanced Search configurations and sensitive credentials — and a separate high-severity issue allowing authenticated attackers to achieve remote code execution by importing a maliciously crafted project export. None of these require the same trivial, unauthenticated access as the headline flaw, but together they represent a meaningfully broad patch batch for any team running self-managed GitLab to work through at once. If your organization hasn't yet confirmed it's running 19.1.8, 19.2.6, or 19.3.2, treat this as immediate, not queued — WatchTowr's confirmed one-day exploitation window means the theoretical urgency vendors usually attach to a "critical" rating has already become a real, active one for this specific flaw.

The Common Thread

Two stories, different scales and completely different mechanisms, but the same practical lesson sitting underneath both: the gap between when something goes wrong and when anyone notices is often the whole story. IDScan's breach reportedly ran for more than a year before it surfaced, not because nobody was looking, but because a slow, sustained exfiltration doesn't necessarily trip the same alarms a single large breach would. GitLab's flaw compressed that same gap down to about 24 hours specifically because the patch itself became the roadmap attackers needed — a security fix is also, unavoidably, a very precise description of exactly what was broken. Neither story needed a novel category of failure to matter. One needed over a year of undetected access to become genuinely severe. The other needed less than a day.

Share Share
Advertisement