YGGtorrent Hacked: 6.6 Million Accounts Exposed in a Massive Data Breach

On February 26, 2026, a massive data breach hit YGGtorrent, the largest French-speaking torrent tracker. The toll is heavy: 6.6 million user accounts, hundreds of thousands of financial transactions, the platform's complete source code and 19 GB of sensitive data exfiltrated. The attack, documented in detail by the leak's authors, reveals a particularly methodical compromise chain that exploits basic infrastructure flaws.

Beyond the YGGtorrent case itself, this incident illustrates fundamental security problems: services exposed without authentication, plaintext passwords in configuration files, and a lack of network segmentation. Mistakes that are still found far too often in production, including in far more critical infrastructures.

The scale of the leak: 19 GB of sensitive data

The YGGtorrent compromise is not limited to a simple database leak. The attacker gained access to the entire infrastructure, enabling the systematic exfiltration of every layer of the system.

User accounts: 6.6 million records

The main database contains 6,629,484 accounts with the following information for each user:

• Email addresses associated with the accounts
• Password hashes in SHA-512 for recent accounts, and in MD5 for legacy accounts (incomplete migration)
• Login IP addresses
• Detailed activity logs

The presence of unmigrated MD5 hashes is particularly worrying. MD5 has been considered broken for years, and tools like Hashcat can crack millions of MD5 hashes per second on a modern GPU. Even SHA-512 hashes, without proper salting, remain vulnerable to dictionary attacks.

Financial data: 249,703 orders

The financial side of the leak is just as significant:

• 249,703 orders recorded in the payment system
• 148,485 completed transactions
• Estimated revenue between 5 and 8.5 million euros for the year 2025
• December 2025 revenue: €341,422
• January 2026 revenue: €490,289
• 13+ payment processor API keys compromised
• 36+ proxy domains used for payment obfuscation

Internal data and source code

• 25,000+ private staff messages on the XenForo forum
• 1.3 million moderation actions
• 89,000+ WooCommerce orders with customer PII
• 4,173,645 tracked users via browsing logs (scooby.csv file) recording timezone, browser languages and timestamps
• Complete source code of the tracker, the API and several ongoing rewrite projects
• 170+ build cycles detected for the rewrite projects

The attack chain: from Shodan scan to total control

The most instructive aspect of this leak is the detailed documentation of the compromise chain. Each step exploits a basic but critical flaw, forming a methodical escalation from the initial scan to total control of the infrastructure.

Step 1: Reconnaissance via Shodan

The entry point is not a sophisticated zero-day vulnerability. The attacker simply used Shodan to search for servers associated with YGGtorrent via their favicon hash. This fingerprinting technique makes it possible to identify servers tied to an organization even when they are not directly public.

# Shodan search by favicon hash
# The favicon hash identifies servers
# sharing the same visual identity

# Result: discovery of a staging server
# IP: 188.253.108.198 (exposed non-production server)

This search revealed a staging server at the address 188.253.108.198, exposed on the Internet without any access restriction. A pre-production server that should never have been publicly accessible.

Step 2: Unauthenticated SphinxQL exploitation

On this staging server, the SphinxQL search engine was exposed on port 9306 without any authentication. SphinxQL is a full-text search engine often used to index large databases. Its syntax is SQL-compatible, which makes it easy to exploit.

The critical flaw: the CALL SNIPPETS function with the load_files=1 option enabled. This configuration allows it to read any file on the system accessible by the Sphinx process.

-- Exploiting SphinxQL to read system files
-- The CALL SNIPPETS function with load_files=1
-- allows arbitrary file reading

-- Principle: CALL SNIPPETS loads a local file
-- and returns it as a query result
-- Equivalent to a Local File Inclusion (LFI)

This is a classic but devastating misconfiguration. SphinxQL should never have been exposed without authentication, and the load_files option should have been disabled in production.

Step 3: Plaintext credentials in Sysprep

Thanks to file reading via SphinxQL, the attacker enumerated the server's configuration files. They discovered a Sysprep unattend.xml file containing the administrator password in plaintext.

Sysprep files are used for automated Windows deployment. They frequently contain plaintext credentials for the initial system configuration. This is a well-documented attack vector, notably in CTFs and Windows infrastructure audits, but one that remains far too often exploitable in real-world environments.

<!-- Example of a vulnerable Sysprep structure -->
<!-- Plaintext credentials in unattend.xml -->
<!-- are a classic attack vector -->

<!-- The file should be deleted after -->
<!-- the initial system deployment -->

<!-- Remediation: delete unattend.xml, -->
<!-- rotate all passwords, -->
<!-- use a vault for secrets -->

Step 4: Lateral movement via SMB

With the recovered administrator credentials, the attacker accessed the server's C$ SMB share. The administrative C$ share grants access to the entire Windows file system, an open door to the server's full configuration.

On this share, the attacker found FileZilla credentials stored in plaintext in the FTP client's configuration files. These credentials pointed to the production servers, thereby completing the lateral movement from staging to production.

Step 5: Persistence and exfiltration

Once on the production servers, the attacker deployed several persistence mechanisms:

• Webshells on the web servers
• Backup administrative accounts created within the applications
• SSH keys added for persistent access

The exfiltration covered 4 compromised servers and totals roughly 19 GB of data: database dumps, source code, crypto wallet information and configuration files.

Analysis of the flaws: avoidable mistakes

What is striking about this attack is that every step exploits a basic misconfiguration. No zero-day, no sophisticated exploit. The entire chain rests on:

1. Exposure of internal services

A staging server accessible from the Internet, with a SphinxQL engine open on port 9306 without authentication. The rule is simple: every internal service must sit behind a VPN or a firewall, no exceptions.

# Check the ports exposed on a server
# From the outside:
nmap -sV -p- your-server.com

# Ports to NEVER expose publicly:
# 9306 - SphinxQL
# 3306 - MySQL
# 5432 - PostgreSQL
# 6379 - Redis
# 27017 - MongoDB
# 445 - SMB
# 9200 - Elasticsearch

# Firewall: block everything except HTTP/HTTPS/SSH
# iptables or nftables depending on the distribution

2. Plaintext secrets in configuration files

Admin password in Sysprep, FTP credentials in FileZilla. This sensitive data should have been in a secrets manager (Vault, AWS Secrets Manager) or at the very least encrypted and deleted after use.

3. Lack of network segmentation

The pivot from staging to production via SMB and FTP credentials reveals a total absence of segmentation. The staging and production environments shared the same credentials and the same networks, allowing trivial lateral movement.

4. Obsolete password hashes

The presence of unmigrated MD5 hashes shows a failure to manage security technical debt. A gradual migration to bcrypt or Argon2id should have been implemented long ago, for example at each user's login.

// Gradual hash migration at login
// Recommended pattern to upgrade legacy hashes

function verifyAndUpgradePassword(
    string $password,
    string $storedHash,
    int $userId
): bool {
    // Detect the hash type
    $isMd5 = (strlen($storedHash) === 32);
    $isSha512 = (strlen($storedHash) === 128);

    if ($isMd5) {
        // Verify old MD5 hash
        if (md5($password) !== $storedHash) {
            return false;
        }
        // Migrate to Argon2id
        upgradeHash($userId, $password);
        return true;
    }

    // Modern hash: standard verification
    return password_verify($password, $storedHash);
}

function upgradeHash(int $userId, string $password): void
{
    $newHash = password_hash(
        $password,
        PASSWORD_ARGON2ID,
        [
            'memory_cost' => 65536,
            'time_cost' => 4,
            'threads' => 3,
        ]
    );
    // UPDATE users SET password_hash = ? WHERE id = ?
}

Lessons for system administrators

This compromise is a textbook case that reminds us of fundamental principles too often neglected:

• Asset inventory: every exposed server must be cataloged and audited regularly. Forgotten staging servers are a prime target
• Zero Trust Network: never trust the internal network. Every service must authenticate its clients, even on the intranet. A Zero Trust architecture would have blocked the lateral movement
• Secrets management: no plaintext passwords in configuration files. Use a vault, rotate credentials regularly, and delete deployment files after use
• Network segmentation: staging and production must be isolated. No shared credentials, no direct routes between environments
• Hash migration: MD5 and unsalted SHA-512 are no longer acceptable. Migrate to bcrypt or Argon2id with a gradual strategy
• Access monitoring: alerts on unusual SMB connections, abnormal SphinxQL queries or SSH access from new keys could have detected the intrusion quickly

Impact and consequences

For the 6.6 million users affected, the risks are manifold:

• Credential stuffing: the email/password combinations will be tested against other services (Gmail, Facebook, Amazon, etc.)
• Targeted phishing: email addresses associated with a torrent tracker can be used for blackmail or contextualized phishing
• Legal exposure: the IP addresses tied to downloading activity are out in the wild
• Financial fraud: the 89,000 WooCommerce customers whose PII leaked are exposed to identity theft

For the platform's operators, the leak of the source code and payment processor API keys means the entire infrastructure must be considered compromised and rebuilt from scratch.

Verification checklist for your servers

In response to this kind of incident, here is an immediate checklist to run on your own infrastructures:

# 1. Scan exposed ports
nmap -sV your-server.com

# 2. Verify that no DB service is exposed
ss -tlnp | grep -E '3306|5432|6379|9306|27017|9200'

# 3. Look for Sysprep/unattend files
find / -name "unattend.xml" -o -name "sysprep.xml" 2>/dev/null

# 4. Look for plaintext credentials
grep -rn "password\|passwd\|secret\|api_key" /etc/ 2>/dev/null

# 5. Check SMB shares
smbclient -L localhost -N 2>/dev/null

# 6. Audit authorized SSH keys
find /home -name "authorized_keys" -exec wc -l {} \;

# 7. List potential webshells
find /var/www -name "*.php" -newer /var/www -mtime -7 2>/dev/null

The security of an infrastructure is only as strong as its weakest link. In the YGGtorrent case, a forgotten staging server with an unauthenticated service was enough to compromise an entire platform of several million users. A brutal reminder that the basics of system security — firewalling, secrets management and network segmentation — remain the non-negotiable foundations of any serious infrastructure.