DEV Community: cl0q

The $6.3B Binance Hack Wasn't a Website Hack. The Next Wave Will Be.

cl0q — Fri, 30 Oct 2026 16:11:40 +0000

The $6.3B Binance Hack Wasn't a Website Hack. The Next Wave Will Be.

Final — 30 October 2026. Figures below are from the news reports linked at the end; no specific Binance clone count is claimed in this piece.

On Thursday 29 October, attackers drained an estimated $6.3 billion from Binance, the world's largest crypto exchange, in what is now the largest crypto theft on record — bigger than the $1.5 billion Bybit theft in February 2025.

Binance's preliminary finding, repeated across the reporting, is that a compromised laptop belonging to a DevOps engineer gave an attacker access to a service container, which was then used to submit unauthorized withdrawals. Binance says it found no evidence of a wallet private-key leak. About $3 billion in assets was frozen with industry partners — Tether froze over $1.567 billion in USDT, Circle over $800 million in USDC — while the bitcoin portion, about 18,270 BTC worth roughly $1.4 billion, was split into 19 wallets within minutes and, as of early Friday, had not moved. Bitcoin has no issuer to freeze it; those coins can only be stopped when they reach an exchange, an OTC desk, or a swap service.

Binance has set aside more than $6.34 billion to cover losses and expects withdrawals to resume within about 48 hours. Bitcoin fell to about $76,400, a six-week low, and liquidations jumped to about $1.57 billion.

Let's be honest about what that means for a web search engine like cl0q: cl0q would not have prevented this hack. This was not a website vulnerability. It was access to an internal system that could request withdrawals, with valid-looking signatures. No index of the public web stops a compromised employee laptop, and no one should sell you a tool that claims otherwise.

The hack cl0q can help with is the one that comes next.

The second wave is always websites

Every major exchange incident is followed by the same second wave, and it is already being warned about this time: fake Binance support messages, fake "compensation claim" and "refund portal" pages, and wallet-drainer sites that ask you to connect a wallet and sign a request. Binance support does not contact you first about the hack, and it never asks for your password, your 2FA code, or your seed phrase. Any page that needs your wallet signature, a fee, or your seed phrase to "release" a refund is fake.

It is not hypothetical. On the same day as the Binance drain, Polymarket's international site was drained of about $2.65 million — not through a fake site, but through its real site loading a compromised third-party script, from a page-speed measurement provider, that checked visitors' holdings and emptied them. Separately, researchers this week documented traffer teams selling ready-made fake Polymarket platforms, complete with rigged win rates and fake crowds, to affiliates who bring in the victims. And on the browser side, fake Firefox extensions posing as Phantom, Jupiter, and Bitget wallets were just pulled after stealing credentials.

In other words: after the headline hack, the attack surface moves to the open web — clone sites, lookalike domains, compromised third-party code, and fake apps. That surface is exactly what a search index sees.

What you can check before you connect

cl0q is an independent search engine built on its own crawl of the web — about 50 million domains in its current index. It records, per site, things like its hosting, its server and tech stack, its title, and its favicon. That is not a magic "is this a scam?" button. It is a way to ask questions a normal search engine does not let you ask, before you type a password or connect a wallet:

Is this the site you think it is? Search for the brand and look at the cluster, not just the top result. Clone sites copy the look closely — including the favicon. cl0q has previously found clusters of dozens to hundreds of sites serving the same favicon as a single familiar brand. If a "Binance support" or "refund" page sits in a cluster of lookalikes, that is your warning.
What is it built with, and where does it live? A real exchange's infrastructure looks different from a throwaway drainer page on cheap shared hosting with an outdated, version-exposing stack. cl0q's datasets include domains that expose a PHP version in their Server header — a small, concrete exposure signal, not a verdict, but a reason to walk away from a site asking for your keys.
Does the name match the dossier? Use the address, not the text: search for the domain itself, check its title, hosting, and tech footprint, and compare it with the real site's. A drainer can copy a page in an afternoon. It cannot easily copy a domain's history, hosting footprint, and index presence.

None of that replaces the official app, typed in by hand, or a hardware wallet. It is a pre-click check, and pre-click is where the second wave lives.

The rule that would have saved most victims

If a site asks you to sign an "authorization" to secure, rescue, or unlock your wallet, treat it as a drainer. That authorization mechanism is, in effect, the same class of trick used in the Binance drain itself on Ethereum, where an EIP-7702 delegation turned a hot wallet into a sweeper only the attacker could operate. You do not need to understand the opcode to use the rule: no legitimate refund, support, or recovery flow asks you to sign away control of your wallet.

Binance's users will, by Binance's pledge, be made whole. The people who lose money next will mostly not be Binance's direct victims. They will be worried users who click a convincing link while withdrawals are paused, connect a wallet to a page that looks exactly right, and sign once.

That is a web problem. And web problems are searchable — if you search the web itself, not just its top ten results.

Try it yourself — and if you build on the web, check your own footprint

Search any suspicious domain on cl0q.com before you connect a wallet to it. And if you run a site, an exchange, a wallet project, or a security team, the same index is available as data: start at cl0q.com/datasets.

$9 API credit pack — run your own lookups against the index.
$39 PHP exposure list — domains that expose a PHP version in their Server header, the version-exposing signal described above.
$79 datasets — Hosting Census and Technographic Snapshot, for checking hosting and tech footprints at scale.
$129 bundle — the datasets together.
API subscriptions — ongoing access for teams that need to check new lookalikes as they appear.

All of it is sold through cl0q.com/datasets. No buy link is needed in a post to find it — go to the datasets page and start there.

Sources: CoinDesk on the $6.3B breach and the 18,270 BTC split; CoinDesk/CNN on the frozen $3B and the compromised-laptop finding; 2-Spyware and TechCrier on the fake-support and fake-refund wave; CryptoMediaZone/CNBC reporting on the Polymarket $2.65M third-party-script drain; CybersecurityNews/Recorded Future on fake Polymarket platforms; PiunikaWeb/Socket on fake Firefox wallet extensions.

cl0q does not audit smart contracts, freeze bitcoin, or verify exchange balances. It indexes the public web. Use it as a check, not a guarantee — and only ever reach Binance through its official app or a domain you typed yourself.

PwnEscape (CVE-2026-99999): The VM Escape That Was Never in the Hypervisor

cl0q — Wed, 28 Oct 2026 04:31:55 +0000

Every cloud tenant lives behind one promise: your virtual machine cannot touch the host, and the host cannot be reached by the tenant next door. CVE-2026-99999, nicknamed PwnEscape, breaks that promise, and the break is not where anyone was looking. The flaw is not in KVM. It is in the host kernel's IPv4 networking code, in a checksum optimization that trusted metadata supplied by the guest.

TL;DR

What: A Linux kernel flaw in IPv4 checksum offload handling. A guest VM sends packets with crafted checksum metadata; the host kernel's skb_checksum_help() then writes out of bounds and rewrites an IPv4 header it had already validated (CWE-787).
Impact: Host memory disclosure, host crash, and, demonstrated in the researcher's lab, controlled host-kernel writes and root-level code execution on the host. A guest-to-host escape primitive.
Severity: 9.3 Critical on the CVE.org record; Red Hat scores it 8.8. The disagreement is one CVSS metric (privileges required).
Affected: KVM hosts on unpatched kernels 4.4 through 6.18 that pass guest traffic through virtio-net/TAP. AWS says its managed services (EC2, Lambda, Fargate) are not affected; self-managed KVM is the exposure.
Exploitation status: No public exploit and no reported in-the-wild use as of publication. Red Hat says it is tracking the flaw as an active-exploit case; it is not in CISA's Known Exploited Vulnerabilities catalog (catalog of 2026-10-21, checked 2026-10-22). Those are different statements, and the difference matters.

How a checksum rewrites a header

Checksum offloading exists to save CPU: instead of checksumming a packet immediately, the kernel defers the work and records where the calculation should start and where the result belongs. That metadata travels in the packet buffer (sk_buff) as csum_start and csum_offset.

In a virtualized setup, the metadata arrives from the guest. The host kernel trusted it without checking it against the packet it described.

The sequence is the bug:

A packet arrives from a guest over virtio-net/TAP. The host parses its IPv4 header normally: version 4, header length 20 bytes (0x45). Routing and fragmentation decisions are made on those values.
Later, fragmentation calls skb_checksum_help() to complete the deferred checksum. Working from the guest-supplied csum_start, it writes into memory that overlaps the already-parsed IPv4 header.
In the researcher's demonstration, the first header byte changes from 0x45 to 0x4f. The version nibble is unchanged, so the packet is still IPv4, but the header-length field now reads 15 instead of 5: a 20-byte header is suddenly interpreted as 60 bytes. Fragmentation then treats bytes beyond the real header, bytes the attacker controls, as IPv4 options.

From that primitive, the researchers demonstrated repeated 32-byte disclosures of host memory, a two-packet host crash, controlled writes into host kernel memory, and a chain to root code execution on the host across four cold boots in their own lab. Against Vercel's production sandboxes, the memory-disclosure stage is what was confirmed. Nobody is claiming a production cloud was rooted, and neither are we.

It is a time-of-check/time-of-use shape: state that was validated early is altered later by data that crossed a trust boundary in between. The vulnerable pattern is old; some coverage puts it at roughly 18 years in the tree.

Timeline

August 2026: Paulos Yibelo of pwn.ai finds the flaw during Vercel's $1 million Sandbox security challenge; the initial memory-disclosure report goes to Vercel on August 20.
September 4, 2026: Root cause privately reported to the Linux kernel maintainers.
October 8, 2026: Fix lands in net.git, commit 6785011f8b16 ("ipv4: validate checksum_start before completing checksum").
October 14–15, 2026: Fix reaches mainline; the kernel CVE team announces CVE-2026-99999 publicly on October 15.

The score disagreement, briefly

The CVE.org record scores PwnEscape 9.3 (AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). Red Hat scores it 8.8, differing only on privileges required (Low vs None). Both agree on what matters operationally: the attack is local to a guest, needs no host credentials, and changes scope, meaning the vulnerable component and the impacted component are different machines. On any multi-tenant host, "the attacker must already run code in a guest" describes every tenant you have.

What our index can and cannot tell you

We run cl0q, an independent search engine that maps the public web: 48,321,576 domains and 35,364,497 pages in our current index snapshot (generated 2026-10-26 01:35 UTC, sample-based, approximate).

We cannot see kernel versions from the web, and we will not pretend otherwise. No banner grab tells you whether a host has applied commit 6785011f8b16. Anyone selling you a per-domain "PwnEscape vulnerable: yes/no" list built from web crawling is inventing it.

What the index does show is how concentrated the exposure decision is. Web hosting runs on a small number of networks, and most of them are virtualization-heavy:

Hosting network	Domains in the index
Cloudflare (AS13335)	7,611,200
Amazon (AS16509 + AS14618)	3,472,400
OVH (AS16276)	1,095,550
Google (AS15169)	1,013,150
Squarespace (AS53831)	997,250

The five largest networks alone account for roughly 29% of all domains we index. For most of the web, the question "is my host patched?" is really "has my provider's kernel program shipped the fix?", and it is answered by a handful of operators. If you run your own KVM hosts, on rented bare metal or your own racks, that answer is yours to produce, and the fix is a kernel update, not a config change.

You can look up any domain's dossier on cl0q to see the hosting network it sits on: cl0q.com/site/example.com. That tells you whose patch status your exposure rides on. For bulk work across a portfolio, the same data is in our datasets and API.

What to do

Patch KVM hosts first, guests second. The vulnerable code runs on the host. Update hosts to a kernel carrying commit 6785011f8b16 or your distribution's backport. Amazon Linux has published fixed packages (for example kernel-5.10.269-270.1108.amzn2 and kernel-6.1.188-233.385.amzn2023); Red Hat's fixes were still in progress at disclosure.
Prioritize multi-tenant and sandbox hosts. A single-tenant host you fully control is a different risk from a host running untrusted workloads. Sandboxes, CI runners, and shared hosting are the front of the queue.
Do not wait for a KEV listing. The catalog lags confirmed exploitation routinely; Red Hat is already tracking this as an active-exploit case. Patch on the disclosure, not on the listing.
Know where your sites actually live. Inventory your domains' hosting networks (the dossiers above do this one by one) so a provider's patch advisory maps to your properties immediately.

The lesson worth keeping

Isolation boundaries are not just the hypervisor. They are every optimization that moves data across the boundary on trust: checksum offload today, another offload tomorrow. PwnEscape sat in one of the most-read code paths in computing, packet forwarding, for years, because the metadata about the packet was never treated as hostile. Anything a guest can influence is input. Validate it like input.

cl0q is a free, independent web search engine with its own crawler and index: cl0q.com. Sources for this article, including the Red Hat and AWS advisories, the SOC Prime analysis, and our CISA KEV check, are listed in the research notes we keep with this draft.

We Thought We Had No PHP. We Were Wrong.

cl0q — Thu, 22 Oct 2026 01:36:39 +0000

We Thought We Had No PHP. We Were Wrong.

The first thing we did when the php2shell advisory landed was make the mistake almost everyone makes.

We checked the websites.

That sounds responsible until you remember what php2shell actually is. CVE-2026-109618 and CVE-2026-109619 are critical unauthenticated remote code execution flaws in PHP itself. The vulnerable surface is not one plug-in, one theme, or one badly written upload form. It is the PHP handler sitting between the web server and the code. Apache, nginx, LiteSpeed, FPM, mod_php: if PHP is in the request path and it is not patched, the details of your application may not save you.

So the better question was not, "Do we run a PHP site?"

It was, "Where can PHP execute anywhere on these machines?"

That is where it got uncomfortable.

The box we almost waved through

We run cl0q, a search engine and index of the public web. Our own stack is mostly Go, Postgres, static files, and the usual operational scar tissue. From the outside, our production web box did not look like a PHP target. Probing the public site did not show PHP fingerprints. It would have been easy to write "not affected" in the team channel and move on.

Then the on-box check told a different story.

PHP-FPM was installed and active, wired behind Apache for cl0q and other virtual hosts. Nothing about the public pages screamed PHP, but the handler was there, alive, and able to process requests routed to it. We patched the PHP 8.3 packages to the Ubuntu security backport and restarted FPM. Then we checked the sites again.

That should have been the end of it. It was not.

Our second machine, the one that hosts our database, Gitea, and team chat, was worse. Apache had mod_php loaded. Not installed in a corner. Loaded. Of all the variants in the advisory, mod_php is the one you least want to discover by accident, because PHP runs inside the web server process itself.

We upgraded the PHP 8.1 packages to the jammy-security build and restarted Apache on the patched module.

Two machines. Two different PHP exposure paths. Neither one was obvious from the website.

"But the site does not use PHP"

This is the sentence that gets people hurt during a disclosure like this.

A modern server is not a single app with a tidy label. It is a pile of decisions made over months: a package installed for one test, a handler left enabled after a migration, a default virtual host nobody remembers, a legacy tool that still gets one request a week. Attackers do not care which parts were intentional. They care which parts execute.

That is also why configuration tricks are such a poor comfort blanket here. The guidance around php2shell has been blunt: do not talk yourself into safety with a clever rule or a partial workaround. The fix is the patched PHP release. Upstream fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, with distribution backports doing the same work under different version strings.

Patch the interpreter. Restart the service. Then prove the public site still works.

What the wider web looks like from here

cl0q currently knows about 46.8 million domains and 33.7 million indexed pages. Numbers that large stop feeling real until a day like this turns them into a checklist. Millions of sites advertise Apache, nginx, or LiteSpeed in their server banners. A banner does not prove PHP is present, and it certainly does not prove a host is vulnerable. That distinction matters.

But a banner does tell you where to look first.

That is the practical use of an index like ours during a fast-moving disclosure. You can search and browse the public web by the technology a site exposes, follow a domain into its dossier, and see the shape of its stack before you start asking harder questions. Start with cl0q Explore if you want the wide view. Or pick a known stack and inspect it, the way this LiteSpeed dossier shows what we know about one public site.

None of that replaces checking your own machines. It does stop you from guessing blind.

The checklist we are using now

If you run anything with a web server, steal this order of operations:

Inventory the machine, not the brand of the website. List web servers, PHP packages, FPM services, Apache modules, containers, and old virtual hosts.
Ask where PHP can execute. A package that is merely installed is different from a handler that is loaded or proxied, but you need evidence for either answer.
Patch PHP from your distribution or upstream. Do not settle for a workaround when a fixed build exists.
Restart the actual service that loaded the old code. FPM, Apache, and containers do not magically pick up a patched library by wishing.
Retest from outside and inside. Outside shows what the internet sees. Inside catches the quiet handler that never made it into the brochure.
Write down what you found, even if the answer is boring. Future you will not remember which box had mod_php loaded at 2 a.m.

The uncomfortable takeaway

The scariest part of php2shell for us was not the severity, although unauthenticated RCE is about as bad as a Tuesday gets. It was the gap between the system we thought we were running and the system that was actually switched on.

That gap is normal. It is also measurable.

We built cl0q to make the public web easier to inspect: what a domain runs, where it lives, what changed, and how the pieces connect. Days like this are why that matters. Check your own stack first, patch it, and then come look at the rest of the internet with us.

Start with Explore. If you need the data programmatically, the cl0q API pricing page has the live tiers, including the free starting point and paid plans for higher limits.

And if your inventory starts with "we do not run PHP," go look anyway.

We said that too.

We Open Sourced Our Web Crawler. Here's How to Run a Node.

cl0q — Tue, 06 Oct 2026 01:31:43 +0000

The crawler behind cl0q.com is now public. Anyone can read the code, run a node, and help index the open web.

https://codeberg.org/cl0qsearch/crawler-node

Why open source it?

Search shouldn't be a black box. The big engines don't tell you what they crawl, how they rank, or what they do with the data. We think that's wrong.

cl0q is an independent search engine with its own crawler and index. We've mapped 38.5M domains so far, working toward 100M. Now the crawler itself is open for anyone to inspect, run, or improve.

If you've ever wondered "what does a real web crawler look like under the hood," this is your answer. Every line is readable. No magic.

What it does

The node software discovers websites, fetches their homepages politely, and sends what it finds to cl0q's index. That's it. It doesn't scrape personal data, doesn't follow you around, doesn't build profiles.

Five services, one Postgres database, zero public ports. Everything runs locally on your machine.

It's a good bot (by design, not by promise)

Most crawlers say they respect robots.txt. Ours can't not respect it. The politeness rules are hardcoded:

One honest User-Agent that names your node. It never pretends to be a browser.
Public internet only. It physically cannot connect to private networks, localhost, or cloud metadata endpoints.
robots.txt is checked first, every time. Crawl-delay is obeyed.
At least 1 second between requests to any server. No hammering.
Only fetches homepages, at most once every 120 days per site.

These aren't settings you can turn off. They're in the code.

Run your own node

You need Docker and a machine that's online. That's it.

git clone https://codeberg.org/cl0qsearch/crawler-node.git
cd crawler-node
cp .env.example .env
docker compose build
docker compose run --rm cl0q-node enroll --contact you@example.com
docker compose run --rm preflight
docker compose up -d

The enroll step registers your node with cl0q and gives you a token. The preflight check makes sure everything works before you start crawling.

What's next

This is v0.1.0. Coming up: more repos open sourced, a GitHub mirror, and performance work.

The code is MIT licensed. Fork it, break it, improve it, send PRs.

Run a node. Help index the open web.

I Pointed My Domain Search Engine at Cybercrime — Here's What It Found

cl0q — Wed, 30 Sep 2026 02:55:51 +0000

I Pointed My Domain Search Engine at Cybercrime — Here's What It Found

I build cl0q, a domain search engine (38.5M domains scanned, free API, no tracking). Last night I got curious: what happens when you run threat-intel queries through a general domain index instead of a specialized feed?

Turns out: quite a lot. Here's what three searches returned.

1. "crypto drainer" → 13 results, including live drainer kits

Top hits included infernodrainer.xyz ("Inferno Drainer — best crypto drainer since 2022," advertising "0-day exploits, 120+ wallet support"), exogator.com ("Liquidate all cryptocurrencies and NFTs from any wallet"), purpledrainer.club, and cryptodrainerscript.net selling "multichain crypto drainer scripts."

Each result came with resolved IPs and MX records — immediate pivot points. exogator.com sits on 5.182.209.88; infernodrainer.xyz on 216.198.79.65. That's infrastructure you can feed straight into a blocklist.

2. "stealer log" → a notorious carding market, indexed

russianmarket.work showed up: "The most trusted underground marketplace. Buy CVV, Stealer Logs, RDP, dumps..." — sitting in a general web index, with its IPs (172.67.149.100) and metadata attached. Alongside it: breach-intel platforms, stealer-log search services, and a Turkish hacking forum (spyhackerz.org) dealing in RATs and fresh leaks.

3. "phishing kit" → an active scampage shop

lurez.online — "Spamming Tools, Office 365 Scampages, Bybit & Binance Scampages For Sale," complete with SMTP servers, cracking utilities, and a "complete spamming course." Plus spams.tools ("Spam Tools | Scampages | Checkers | Letters | Email Senders | SMTPs | cPanels") with its MX records exposed.

Why this matters

Threat intel usually means expensive feeds and APIs. But a huge amount of attacker infrastructure lives on the clear web, on cheap domains, behind Cloudflare — indexed like anything else. A domain-level search engine with DNS enrichment (IPs, MX, CNAMEs) turns a hunch into pivotable infrastructure in one query.

The searches are free, the API is free (30 req/min, 1,000/day), and nothing is logged. Try it: cl0q.com

All domains above were live in the index at time of writing. If you're a defender, the IPs and MX records are yours to use.

AI assistance was used in drafting this article.

38.5 million domains on a 2 GB droplet: the honest story of building an open search engine

cl0q — Sun, 27 Sep 2026 21:25:38 +0000

Disclosure: I used AI assistance to help draft this post. The story, the mistakes, and every number below are mine.

In 2025, I started crawling the web.

Not metaphorically. I pointed a crawler at the open internet from a 2 GB VPS and decided to build a search engine — a free, open-source one that doesn't log your searches, doesn't need an account, and that anyone can self-host. The first crawl records date to April 2025. Then things went quiet for a while. Then this June, cl0q took off: 8.5 million domains in a single month.

Today, cl0q knows 38.5 million domains and has indexed 24.8 million pages. The goal is 100 million.

This is the honest version of how that went.

The first million nearly killed the project

The naive approach to crawling is: start with a list of sites, follow every link, repeat. What nobody tells you is that the web has traps. Point a crawler at the open web and it finds Blogspot — about a million subdomains hanging off a single domain — and happily spends a week indexing them while the rest of the internet waits.

Getting to the first million was the hardest part, because I didn't know the right crawl path. Crawl too narrow and you re-walk the same neighborhood forever. Crawl too wide and you fall down a subdomain hole and your index fills up with a million pages from the same blog host.

The fix was treating the known web as a rotating frontier instead of a finished list: keep re-sampling domains you already know and mine their homepages for fresh outbound links. And Certificate Transparency logs turned out to be a goldmine — at peak, they were surfacing around 1,700 new domains a minute. Discovery never ends; it just keeps moving.

Everything broke, mostly because of disk

For most of this project, cl0q ran on that 2 GB VPS. A web crawl is, at its core, a fight against disk space. Every page is a row, every favicon is bytes, every DNS record is overhead, and the crawl never stops growing.

Lots broke. Things crashed, crawls stalled, I ran out of room at the worst moments. These days the storage lives on a remote host connected over Tailscale, which helped enormously — and I'm still fighting storage issues today. If there's one thing I'd tell anyone starting a crawl project: budget ten times the disk you think you need, then double it.

The database has one core, and everything fights over it

Here's something the docs won't tell you: search and the crawler share a single database, a single core, and the same table. When a burst of background jobs stampedes the database, search times out. When the crawler picks its next targets, it eats a big share of DB time doing it.

There's no elegant fix yet — just triage, scheduling, and the occasional 2 a.m. realization that the thing slowing down search is my own crawler. The one part that never touches the database: the stats and drill-down pages, which are served from precomputed files. If the site feels fast while the crawler is hammering away, that's why.

What actually worked

A few decisions paid off:

The pipeline is four small stages — discovery, page crawl, enrichment, serving — each incremental and restartable. Nothing depends on a full rebuild. (That's the simplified version. The real version involves the single-core database above.)
Refusing to index garbage. When a site serves an anti-bot challenge page, lazy crawlers index the text "Checking your browser…" as if it were content. cl0q detects interstitials and throws them out. A search engine is only as good as what it refuses to index.
Favicons turned out to be a superpower. Every icon gets hashed with SHA-256: 16.3 million sites in the index have a favicon, collapsing down to about 7 million distinct icons. Sites sharing an icon are usually related — same operator, same framework, same phishing kit. What started as a storage deduplication trick became one of the most useful OSINT pivots in the index.
Privacy as architecture, not policy. Signed out, cl0q sets no cookies and stores nothing about your searches — there's no per-request log to leak, subpoena, or sell. Accounts are optional and passkey-based, and search history exists only if you turn it on. The code is open source, though I'll be honest: the public mirror is a couple months behind right now, and refreshing it is on my list.

Where things stand

The numbers, measured from the actual database rather than the dashboard: cl0q knows 38.5 million domains — 97% have been attempted, 92% resolve in DNS. It's indexed 24.8 million pages, 24.4 million of them live, across 1,027 TLDs. About 250,000 to 300,000 pages get crawled every day, and re-crawls start October 9 so pages stay fresh instead of going stale.

The road to 100 million

The plan is simple: hit 100 million domains, then open up the API properly. There's a free beta API today and paid tiers are coming — and once the project makes money, the next frontier is depth. Right now cl0q fetches homepages; with real revenue behind it, the crawl goes deeper into sites instead of just wider across them.

If you want to help, you can run a crawler and contribute pages — that's by invitation today, so get in touch — or just try a search at cl0q.com.

A year and a half of crawling, 38.5 million domains, one very tired VPS. On to 100.