Mert

This is Part 2 of an ongoing investigation. Part 1 documented the initial discovery of a coordinated GitHub follow botnet — 8 accounts with Jaccard following-list similarity of 0.99+ across ~29,800 entries each, evading cross-follow detection entirely.

In Part 1, I identified 8 accounts operating as a coordinated follow botnet and showed the statistical fingerprint that exposed them. After publishing, I kept pulling.

Subsequent analysis expanded the cluster to 9 accounts, recovered infrastructure linkage to a specific GitHub identity, and mapped the generation pipeline responsible for all 552 repositories across the cluster. The pipeline left recoverable artifacts in every repository it produced.

Here is what the data shows.

The Cluster Expanded

Running Jaccard similarity analysis against the original 8 accounts and their extended follower graphs surfaced a ninth account: lynewinter.

Jaccard similarity against mariwatts: 0.9898.

The same methodology that identified the original 8 applies here. A similarity coefficient of 0.9898 across ~29,800 following entries does not occur between unrelated accounts. At this scale, unrelated GitHub users do not organically converge on near-identical follow graphs.

The confirmed cluster is now 9 accounts:

canestein, hazexone, domcomit, kylehyne, jaderytm,
vierystein, hanyvert, mariwatts, lynewinter

552 Repositories, One Pipeline, 34 Minutes

Each of the 9 accounts has between 57 and 63 public repositories. Total across the cluster: 552 repositories.

Every repository was created on May 12, 2026. Fetching the first repository per account and extracting an HTML comment embedded in every generated README reveals the exact creation timestamp and a job identifier for each:

2026-05-12 11:10:39  |  hanyvert    |  SwapLink    |  job=48099
2026-05-12 11:18:46  |  jaderytm   |  GasSync     |  job=39412
2026-05-12 11:27:52  |  hazexone   |  BitForge    |  job=63871
2026-05-12 11:30:00  |  canestein  |  BlockLink   |  job=51606
2026-05-12 11:33:07  |  mariwatts  |  MintChain   |  job=82564
2026-05-12 11:35:37  |  vierystein |  HashSync    |  job=20845
2026-05-12 11:38:58  |  kylehyne   |  SmartLink   |  job=38575
2026-05-12 11:42:07  |  lynewinter |  YieldChain  |  job=78012
2026-05-12 11:44:30  |  domcomit   |  ProjectCloud|  job=26977

All 9 accounts provisioned across a 34-minute window. Job IDs are non-sequential, consistent with a job queue system dispatching parallel workers rather than a simple sequential script.

The comment format embedded in every README:

<!-- fallback_BlockLink_20260512113000_51606 -->

fallback_ is a named prefix — consistent across all accounts and repos. The timestamp and job ID vary per generation run. This is a recoverable generator fingerprint present in all 552 repositories.

The central finding of Part 2 follows directly from this: a single automated pipeline provisioned all 9 accounts and generated all 552 repositories in a 34-minute window. Every subsequent finding — the template leak, the commit metadata, the email domain — is evidence of that same pipeline’s operation.

Repo Contents Are Hollow

Fetching file trees and raw content from sampled repositories confirms the repositories contain no functional code.

A representative Python file (blocklink.py, 1,656 bytes):

class BlockLink:
    def run(self) -> bool:
        try:
            self.logger.info("Starting BlockLink processing")
            # Add your main logic here
            self.logger.info("Processing completed successfully")
            return True

The comment # Add your main logic here is the entirety of the implementation. Every repository follows this pattern: a class stub, a logging setup, an argparse entry point, and a test file that imports and instantiates the stub. No logic. No purpose. The repositories exist as props.

Repo names follow a consistent [Word][Suffix] pattern where suffixes are drawn from a fixed set: Core, Chain, Sync, Vault, Forge, Link. Names and descriptions are AI-generated. Stars: zero. Forks: zero, across all 552.

A Template Leak Confirms Shared Generation

The LICENSE section of every generated README contains a hardcoded URL pointing to mariwatts regardless of which account’s repository it appears in:

From canestein/BlockLink:

See the LICENSE file at https://github.com/mariwatts/BlockLink/blob/main/LICENSE

From lynewinter/YieldChain:

See the LICENSE file at https://github.com/mariwatts/YieldChain/blob/main/LICENSE

The account name substitution in the generator did not apply to the LICENSE URL field. mariwatts appears as the base account in the generator template. The substitution pattern replaced account names in repo metadata and README body text but missed this field.

Pipeline Linked to a Single GitHub Account via Authenticated Commit Metadata

Every repository across all 9 accounts contains commits with the following co-author line:

Co-authored-by: Hajigur <66867581+hajigur69@users.noreply.github.com>

The format [email protected] is GitHub’s authenticated noreply scheme. GitHub generates this address from the account’s internal numeric ID. The ID is immutable and assigned at account creation.

Fetching commits from hajigur69‘s own repository (Cloud9, created February 2, 2026) confirms the same identifier:

Author: Hajigur | 66867581+hajigur69@users.noreply.github.com

The same authenticated GitHub ID (66867581) appears both in the cluster commits and in commits authored directly by hajigur69.

hajigur69 is pipeline-linked. GitHub account created June 13, 2020. 903 followers. 679 following. Public bio: lamer.

Pipeline-Associated Infrastructure: carox.tech

Two accounts in the cluster — canestein and lynewinter — use a custom domain in their git commit author fields rather than GitHub’s noreply format:

canestein  →  [email protected]
lynewinter →  [email protected]

These addresses appear in the git author field of every commit on those accounts, recorded at commit time by the pipeline’s local git configuration.

WHOIS on carox.tech:

Creation Date:  2025-07-19
Updated Date:   2025-08-01
Registrar:      Namify Domains Inc
Name Server:    raphaela.ns.cloudflare.com
Name Server:    uriah.ns.cloudflare.com

DNS enumeration:

A record:   none
MX records: route1.mx.cloudflare.net (priority 44)
            route2.mx.cloudflare.net (priority 84)
            route3.mx.cloudflare.net (priority 28)
TXT record: v=spf1 include:_spf.mx.cloudflare.net ~all

No web presence. MX records point to Cloudflare Email Routing — a free service that forwards custom domain email to an external inbox. The domain functions exclusively as an email forwarding layer. The destination inbox is not publicly recoverable.

The 12-day gap between creation and update date is consistent with the time to configure email routing after registration. Beyond that, the domain predates the repo generation by several months — it was in place before the pipeline ran, not stood up alongside it.

Additional Artifact: Malformed Co-Author Address

In addition to the hajigur69 co-author signature, a second co-author line appears on the GOOD commit across 8 of the 9 accounts:

Co-authored-by: v <v@users.noreply.github.com>

GitHub’s authenticated noreply format is [email protected]. The numeric ID prefix is machine-generated by GitHub’s credential system at authentication time — it cannot be produced by typing a username, only by pushing through a properly authenticated git session. The address [email protected] contains no such prefix and does not match the format GitHub generates for any account.

There is a GitHub account with the login v (ID: 627846, created 2011). Its correctly formatted noreply address would be [email protected]. The string present in these commits is not that address.

The most likely explanation is a misconfigured git identity on whichever machine ran the pipeline — a user.email set to [email protected] rather than the proper authenticated format. Whether placeholder or misconfiguration, the effect is the same: it was baked into the pipeline’s commit template and executed across the majority of accounts unchanged. It’s a pipeline artifact, not a deliberate attribution.

What the Repos Are Actually For

The following is inference from the confirmed findings above, not an independently verified claim.

The repositories are not the product. Hollow stubs with no stars and no forks have no value on their own.

The follow botnet from Part 1 is the product. The accounts need to look like real developers for the botnet to work — real developers have repositories. The 552 repos are set dressing: enough surface area to pass a casual profile inspection without requiring the operator to produce anything functional.

The pipeline’s role is to manufacture that surface area at scale and speed. Nine accounts, 552 repositories, 34 minutes. A human doing this by hand would take weeks and produce inconsistent output. Automation produces it uniformly and leaves the fingerprints documented above.

What the inflated follower counts are ultimately used for — social proof laundering for phishing accounts, legitimacy for malicious package distribution, resale of aged accounts — is not established by this data. The confirmed finding is the coordination and the shared infrastructure. The downstream use is an open question.

The follower graph itself appears to be the primary maintained asset. ~29,682 developers curated into a target population, followed across 9 aged accounts. The repos are disposable scaffolding.

Summary of Confirmed Findings

What This Demonstrates

The finding is the pipeline. A single automation system provisioned 9 apparently independent GitHub accounts, generated 552 repositories across all of them in 34 minutes, embedded the same co-author identity in commits across the cluster, and left recoverable fingerprints in every generated file — all while the accounts maintained behavioral patterns designed to evade the most common detection heuristic (cross-following).

Attribution was possible here because of operational mistakes: a hardcoded template account, an unformatted co-author string, and email domain leakage in git config. A pipeline with better hygiene — consistent noreply formatting, template substitution coverage, and throwaway email addresses — would produce the same coordinated behavioral output with substantially less recoverable linkage.

This analysis identifies operational linkage and shared infrastructure; it does not independently establish the real-world identity of the individual operating the pipeline.

The hajigur69 co-author fingerprint that surfaced in this investigation didn’t start here. The same identifier — same numeric ID, same fallback_ generator artifact — appears in an earlier operation running nine months before this botnet was provisioned: a crypto spam network with fabricated commit histories, purchased star services, and 163 active pip install vectors targeting developers through search poisoning.

Part 3 covers that earlier operation and what it tells us about the infrastructure behind both.

Read Part 3 →

When a group of academics started making open-source robotics hardware, a generation of roboticists got years of their lives back. Now, the bigger challenge is getting robots to think—and that’s starting to be open-sourced too.

The shift is still early, but companies including Hugging Face, Nvidia, and Alibaba have all made significant bets on open-source robotics in the last two years, releasing tools and models aimed at the higher-level work of getting robots to reason, decide, and act.

The open source movement that accelerated other AI applications is now being applied to the problem of making robots smarter. If these attempts to bring AI to robotics with open-source platforms succeed, the barrier to building a capable robot could fall as fast as the barrier to building an AI application did.

The world ROS built

Open-source robotics software has been around since the mid-1990s, with early projects like Carnegie Mellon’s Inter-Process Communication package and the Player project in the early 2000s laying the groundwork. But these were often tied to specific research groups, and the field remained fragmented.

The Robot Operating System, ROS, changed that when it made its debut in 2007. By bundling tools and attracting more users, it became the de facto standard. The story of open-source robotics, in many ways, starts there.

Despite its name, ROS is not actually an operating system. Rather, it is a software framework that sits on top of Linux and handles robotic fundamentals like moving data between components, talking to hardware, building maps, planning paths, and supporting developer tools, such as data logging and visualization. Before ROS, every robotics team wrote that infrastructure themselves. It often took a year or two before a lab could get to the research it actually cared about.

Brian Gerkey, who helped build ROS in the mid-2000s, says he was drawn to the project because of how much open source had already changed the world, pointing out that nearly the entire internet is built on it.

“I’m a tool builder, and I like to share everything as openly as I possibly can, because I think that’s where we get the most impact out of what we build,” says Gerkey, Board Chair at Open Robotics and now CTO at Intrinsic, a robotics and AI unit of Google.

As it was developing, the AI community largely took the same approach, sharing research, models, and data openly, and the field accelerated faster than almost anyone predicted. Now some of those same advancements are arriving in robotics.

Open-source AI for robotics

Computer vision, once a hard problem, has advanced dramatically in just a few years, says Spencer Huang, Nvidia’s director of product for robotics. What once required significant expertise can now be done in a few lines of code. Simulation tools have become accurate enough to be useful for training, and access to the tooling that once required a specialized lab is now widely available, much of it open source.

“To get into robotics, you no longer need a Ph.D.,” he says. The result is a much larger pool of people who can contribute, and the field is starting to look less like a specialized discipline and more like a platform that anyone can build on.

Nvidia has built out an open-source robotics stack that covers the full development pipeline. Its Cosmos world models generate synthetic training data and simulate physical environments. Its GR00T models give robots the ability to reason about and execute complex tasks. And its Isaac frameworks handle the orchestration that ties training, simulation, and deployment together. Not everyone needs to train the robots from scratch, Huang says, and most people probably shouldn’t.

“If you gate pre-training, the field just never grows,” he says. “We should be able to provide a high-quality, state-of-the-art pre-trained model that anyone can go and take and fine tune for their own purposes.”

All of Nvidia’s open-source models live on Hugging Face, the open-source AI platform that has become the default place to share models and datasets. Hugging Face launched LeRobot, a community platform for robotics AI, in May 2024. Since its launch, the number of robotics datasets on the platform grew from 1,145 at the end of 2024 to more than 58,000 today, making it the single largest dataset category on the hub.

Hugging Face has also moved into hardware, acquiring robotics company Pollen Robotics. The acquisition came from a realization that software alone was not enough, according to Clement Delangue, Hugging Face’s CEO. The goal, as with the software, was to bring more people in.

The contributors to LeRobot include the biggest names in the industry, academic labs, and hobbyists building robots in their spare time. For instance, Alibaba released RynnBrain earlier this year, an open-source foundation model for physical AI that the company claims outperforms comparable offerings from Google and Nvidia on benchmarks. That diversity of projects, Delangue says, is important.

“It is not just one model or one dataset or one hardware,” he says. “It is a lot of small contributions that everyone can be part of.”

Commercial incentives muddle the field

The stakes, Delangue says, go beyond convenience. A world where only a few proprietary systems control the robots in people’s homes is a concerning one. “Having robots at home that you don’t really understand, that you don’t really control, that a few people in Silicon Valley control is a scary thought,” he says. “Open source gives an alternative path.”

But getting there is not straightforward. The open sourcing happening now looks different from what produced ROS, which emerged largely from academics pooling their work with no commercial stake in the outcome. The biggest contributors today are companies with clear business reasons to want more people building on their platforms. That’s not necessarily a bad thing, says Bill Smart, a professor at Oregon State University who was part of the early open-source robotics community. But the incentives are worth being aware of.

He also worries that the lowered barrier to entry has a downside. Researchers coming from AI without a robotics background are sometimes solving problems the field already solved. A newcomer might spend a week training a neural network to move a robot’s hand from one point to another, unaware that the same task can be accomplished with a few lines of code using decades-old techniques. The incentives are not always pointing in the same direction as the progress.

Smart is not without hope though. Whatever the motives behind the open sourcing, he says, the effect is real. More people are in the field than ever before, the tools are genuinely easier to use, and the community is bigger and more diverse than anything that existed when ROS was getting started.

“Anyone can make a robot move now,” he says. “As an old tech guy, that makes me happy and sad, because I’m no longer special.”