fix(security): remove hidden VS Code folder-open loader task and fake font

[polylane]

Fixes: Hidden VS Code folderOpen task re-infects 18 phoenixdahdev repos with Ethereum-C2 loader

Opening this repository in VS Code silently ran a script that had been committed to look like a web font, started a remote payload on the developer's machine, and re-infected the owner's other projects every time a folder was opened. This change removes the hidden auto-run task, disables the setting that let it run without asking, and deletes the fake font.

flowchart LR
  A["Developer opens the folder in VS Code"] --> B["VS Code reads .vscode/tasks.json"]
  D[".vscode/settings.json: task.allowAutomaticTasks true"] --> C["Task eslint-check, runOn folderOpen"]
  B --> C
  C --> E["node runs public/fonts/fa-solid-500.woff2"]
  E --> F["Loader fetches second stage via Ethereum RPC"]
  F --> G["Detached node process on developer machine"]
  G --> H["Rewrites postcss.config.mjs in other repos"]
  C -.-> X["Task removed by this change"]
  D -.-> Y["Setting set to false by this change"]
  E -.-> Z["Fake font deleted by this change"]

Loading

What caused this

Affected: int_0b2300ad4001ia0oribh5vge

Why this fix

This repository is one of five that carry byte-identical copies of a planted bundle: .vscode/tasks.json (git blob 1a828db9, 799 B) whose only task is eslint-check with runOn: folderOpen, and .vscode/settings.json (blob 934d5554, 786 B) with task.allowAutomaticTasks: true, which is what let that task run without a prompt. The task runs node ./public/fonts/fa-solid-500.woff2. That file is 7,592 bytes of ASCII source that begins with the campaign marker A8-4893-2 and reaches out for a second stage, while the genuine Font Awesome binaries stored beside it are 13 KB to 800 KB and are real font containers.

Identical bytes appear in repositories whose other commits are authored by three different people — h4cker's upstream is a public security reference maintained by another author, and the SwiftUI and Expo projects are other people's as well — so this is not a per-project developer preference: one injector planted the same three files everywhere. Emptying the task list stops the schedule, and flipping the setting to false removes the silent-run condition, so a future planted task cannot run unprompted on a folder open. Deleting the asset is what makes the loader unreachable.

The evidence that nothing else depends on these files is a repository-wide search: git grep fa-solid-500 returns nothing after the change, so no font-face rule, stylesheet, or application import referenced the asset, and both edited JSON files parse. The consequence for a reader is that the folder-open execution path in this repository is gone.

Remaining work is outside this diff: the loader blob is still reachable at older commits, so a clone of a historical commit can still run it, and purging that needs a history rewrite and coordinated re-clones, which is the owner's call. Credential rotation for anything the loader could reach from a developer machine is also the owner's.

3 files changed (+2/-23)

• .vscode/settings.json: modified, +1/-1
• .vscode/tasks.json: modified, +1/-21
• public/fonts/fa-solid-500.woff2: removed, +0/-1

---

Generated by Polylane. You can ask follow-ups by mentioning @polylane in a comment.

[github-actions]

Thank you for submitting your first pull request! 🎉 Your effort and contribution are greatly appreciated. Our maintainers will review your changes soon. In the meantime, please ensure your submission aligns with our Contribution Guidelines Let me know if you have any questions. Welcome aboard! 🙌 | Omar Santos @santosomar

[polylane]

Warning

Polylane could not verify the production impact of this pull request.

Checked h4cker against the whole account: zero deploy edges, no Vercel project builds it, and 54 deploys/72h come from other projects; org code search finds no consumer of the deleted asset. Vercel observability returned nothing (no Observability Plus).

View the full analysis →

Also considered · 4 refuted

• Refuted · Deleting the fake font breaks a site or stylesheet that serves it · The asset had no consumer at HEAD and no deploy target: the repository has no build, no deploy config and zero graph edges, and the account's 54 deployments in the last 72h all originate from other projects, so removing the file changes nothing a production resource reads.
• Refuted · Emptying tasks.json breaks a CI or developer workflow the repository depends on · The removed task body only launched the malicious asset, and the repo's single workflow is a scheduled issue sweeper that never reads .vscode; 20/20 recent runs succeed, so emptying the task list removes no working automation.
• Refuted · Residual runOn:folderOpen entry left in settings.json still auto-runs a command · A developer-machine folder-open path is not a production failure mode, and nothing runnable remains: the task list is empty and automatic task execution is off.
• Refuted · The loader stays reachable from pre-merge commits after this merge · This is a pre-existing condition the diff cannot worsen: history was already infected for every clone made before the merge, and the merge is what stops the folder-open re-infection here.

Analysed against 1 cloud account and 1 repository

• Cloud account: Phoenix's projects
• Repository: phoenixdahdev/h4cker

Polylane could not find the cloud resources this repository manages, so this review looked at the entire cloud account. Connect this repository to its resources and the next review will focus on exactly what this code deploys to.

_{Polylane analysed 8745aa7 for production impact. You can ask follow-ups by mentioning @polylane in a comment.}

Rate this review: 👍 helpful · 👎 not helpful · 😕 confusing

[polylane]

This pull request is waiting on a decision: merge it if the change is still wanted, or close it if the fix is no longer needed. Either one settles it.

It was opened on 2026-09-19 and has had no new activity for a week. If nothing happens on it within a week, Polylane closes it and keeps the branch, so reopening it brings the change back exactly as it stands.

@phoenixdahdev, the change touches what you own, so the review is with you.

[polylane]

This pull request is closing without a merge, and nothing is lost: the branch polylane/autofix/0hilfeodup3q stays in place, reopening the pull request brings the change back exactly as it stands, and Polylane will propose a fresh fix if the problem returns.

It was opened on 2026-09-19, Polylane reminded the maintainers about it on 2026-09-27, and nothing has happened on it since.

@phoenixdahdev, you were asked to review this pull request; reopening it puts it back on your list.