DEV Community: Biya Paul

Two and a half months with an intruder in our repositories

Biya Paul — Fri, 11 Sep 2026 00:32:19 +0000

On 6 September 2026, an antivirus quarantined a 32 KB "font file" in one of our projects. That file was a trojan. It had been running on our workstation since 22 June, had rewritten commits in eighteen repositories, and had spread to a collaborator's machine. Here is what happened, what we did, and what we are keeping from it.

An ordinary morning, two details that did not add up

It started with two observations that, taken separately, would have worried nobody. On opening the machine, every one of our repositories showed a pending pull we could not account for. And every one of them had triggered an automatic deployment on GitHub overnight, which had failed.

An hour later, the antivirus reported that it had quarantined a file named fa-solid-400.woff2 in the public/fonts folder of a marketing site. A Font Awesome font. Except that a font by that name weighs more than 100 KB and starts with the binary signature wOF2. This one weighed 32,874 bytes and started with several hundred spaces, followed by unreadable JavaScript.

A real font starts with "wOF2". The fake one starts with spaces, then code.

What we found when we dug

We spent the afternoon examining, read-only, our whole workspace: about sixty repositories. The picture that came out was far wider than the one flagged file.

Eighteen repositories affected, across three GitHub organisations, including client projects.
A first injection on 22 June, in a marketing site. Seventy-seven days before detection.
A signature in the git history: in every affected repository, the last commit had been copied verbatim, same message, same author date, but with a truncated committer name and a -0700 timezone, the US west coast. Those copies had been force-pushed with our own SSH key.
A collaborator's workstation carried the same signature from late August: they had cloned an already infected repository.
A last malicious push the day before, at 15:21. The malware was still active while we were looking for it.

Seventy-seven silent days, then fifteen projects hit in ten days.

The mechanism itself fitted in three files. A .vscode/tasks.json declared a hidden task that ran the fake font with Node.js as soon as the folder was opened in VS Code. A .vscode/settings.json enabled automatic tasks so the editor would not ask. And in one variant, the same code was appended after a long run of spaces at the end of tailwind.config.js, vite.config.js or eslint.config.mjs, to run on every build, including in our pipelines and Docker images. We go through all of it in a second, more technical article.

What the malware had within reach

A trojan of this kind is not trying to break anything. It is after credentials. For two and a half months it had access to everything on the workstation of an independent developer working for several clients:

SSH keys, without a passphrase, that opened both GitHub and the production server;
the .env files of thirteen projects, with their payment, AI, email, storage and database keys;
passwords saved in the browser and open sessions;
deployment secrets, exposed in the pipelines its own pushes had triggered.

None of that was encrypted by anything other than the Windows session. That is the hardest lesson of this story: cleaning the machine is only the beginning. The real remediation is making everything that was copied worthless.

What we did, in order

1. Cut off access

Before anything else, from a phone rather than the affected workstation: delete every SSH key on the GitHub account, change the password, sign out all sessions, revoke access tokens and authorised applications. Without a key, the malware cannot push anything, wherever it is.

2. Clean the workstation

We chose an in-place clean-up over a reinstall, for lack of a backup drive that day, and accepting the residual risk. Quarantine of the files dropped in the temp folder, removal of stored keys and credentials, deletion of the malware's files and decoys across the eighteen repositories, purge of forty gigabytes of installed dependencies, hardening of VS Code, then a full re-test: no marker left, no process, no persistence, no suspicious connection.

3. Regenerate every secret

This is the longest job. We inventoried the variable names of twenty-seven .env files and the secrets of nineteen pipelines, then applied the same rule to each: create the new one at the provider, put it in place, verify, and only then revoke the old one. In that order, otherwise the application goes down while everything is put back.

4. Audit the server

SSH login logs since June, authorised keys, users, scheduled jobs, services, Docker images built during the period. A new deployment key, separate from the personal key. Rebuild of every image from the cleaned repositories.

5. Clean the repositories and tell people

Removal of the malware from the branches still infected on GitHub, force-push protection, mandatory signed commits, a guard workflow that fails if a signature reappears. Then a message to every collaborator and every client whose secrets had been on our workstation. Saying it quickly protects the relationship; staying silent exposes it.

What we are keeping

The antivirus did not save us. A failed push and an unexplained pull did.

VS Code runs code when you open a folder. The task.allowAutomaticTasks setting exists for that, and the malware set it to on in every project. We now force it to off in our user settings, with workspace trust enabled. Opening an unknown repository is not a harmless gesture.

One key for everything is one leak for everything. The same SSH key, without a passphrase, opened GitHub and production. Today: a personal key with a passphrase for GitHub, one deployment key per server that lives only in the pipeline's secrets, and never one in place of the other.

npm install scripts are a way in. ignore-scripts=true in ~/.npmrc costs a few pnpm rebuild a year and closes an entire class of attacks.

Git history is a free audit log. A single command, run weekly, would have revealed the rewritten commits on 22 June. We now run it every Monday:

git log --all --format='%h|%ad|%cd|%an|%cn|%s' --date=iso \
  | awk -F'|' '$3 ~ /-0700/ || $4 != $5' | grep -v GitHub

An incident is handled with a plan, not with adrenaline. We wrote ours down as four procedures: detect and remove on a workstation, on a server, in the repositories, then the actions to take after an infection. They were useful the very next day, to walk the affected collaborator through the same steps.

If you build with Node.js and VS Code

Do these four things this week. They take less than an hour.

In VS Code: task.allowAutomaticTasks set to off, security.workspace.trust.enabled checked.
In ~/.npmrc: ignore-scripts=true.
A passphrase on your SSH keys, and a deployment key separate from your personal key.
Search your projects for a fa-solid-400.woff2 file of 32,874 bytes, and a tasks.json containing folderOpen. If you find one, do not open it: read the technical analysis and start by cutting off your access.

This campaign targets developers, often through fake job interviews or fake freelance assignments that come with a repository "to run". We have not yet identified our own entry point. If you have been through the same thing, write to us: comparing traces helps everyone.

How to create an awesome Github Profile README ?

Biya Paul — Mon, 25 Apr 2022 11:51:14 +0000

If you take a look of my GitHub profile, you’ll notice that it contains Github statistics, social network links and some more content, which makes my GitHub profile look more descriptive.

In this article, we’ll learn how to create a GitHub profile README, add impressive content and make a cron job to refresh it every (x) hours.

What is Github profile README

GitHub that allows users to use a Markdown file named README to write details about theirself, skills, social life and increase visibility. It’s shown at the top of your GitHub home page, above the pinned repositories. Here are some examples of information that visitors may find interesting, fun, or useful in your profile README.

An "About me" section that describes your work and interests
Contributions you're proud of, and context about those contributions
Guidance for getting help in communities where you're involved

Create a Github profile README

GitHub will display your profile README on your profile page if all of the following are true.

You've created a repository with a name that matches your GitHub username.
The repository is public.
The repository contains a file named README.md in its root.
The README.md file contains any content.

Add Awesome content to your Github profile

First, Open your repository with a modern Text Editor like VsCode

Now open a terminal to its directory and create a new npm project

npm init

We are going to use Mustache, which allows us to create a template and easily replace tags with data we will provide later.

npm i mustache

Create a mustache template
We are going to create a new mustache file in the directory.

touch index.mustache

Let's add some small content

My name is {{full_name}} and you can see my works <a href="https://bpmartdesign.tk">here.</a>

Notice the {{___}} tag? That’s how Mustache recognizes something can be placed there.

Generate README from mustache file template

First, create a index.js file, where we will write the code to parse data.

const Mustache = require('mustache');
const fs = require('fs');
const MUSTACHE_MAIN_DIR = './index.mustache';

/**
  * DATA is the object that contains all
  * the data to be provided to Mustache
  * Notice the "full_name" property.
*/
let DATA = {
  full_name: 'BIYA Paul'
};

/**
  * A - We open 'index.mustache'
  * B - We ask Mustache to render our file with the data
  * C - We create a README.md file with the generated output
  */
function generateReadMe() {
  fs.readFile(MUSTACHE_MAIN_DIR, (err, data) =>  {
    if (err) throw err;
    const output = Mustache.render(data.toString(), DATA);
    fs.writeFileSync('README.md', output);
  });
}
generateReadMe();

With that, you can now run node index.js in your terminal and it should generate a brand new README.md file in the same directory:

// Generated content in README.md
My name is BIYA Paul and and you can see my works here.

Commit and push everything. Now, you can see that your README.md displayed on your Profile page has been updated.

Add a CRON Job to generate your README periodically

So, finally you have increase your visibility by creating an awesome README.md file.
But you will surely not have the time to commit and push every day to make your profile up to date.

So, Github Actions has been done for us with a lot of function to automate our process.

With Actions, you can create workflows to automate tasks. Actions live in the same place as the rest of the code, in a special directory: ./.github/worflows.

$ mkdir .github && cd .github && mkdir workflows

In this ./workflows folder, create a ./main.yaml file that will hold our Action.

$ cd ./workflows && touch main.yaml

Be sure your branch name is master instead of main if not, please rename your principal branch to master

If its Okay, now you can fill your main.yaml file with this content

name: README build

on:
  push:
    branches:
      - master
  schedule:
    - cron: '0 */6 * * *'

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout current repository to Master branch
        uses: actions/checkout@v1
      - name: Setup NodeJs 13.x
        uses: actions/setup-node@v1
        with:
          node-version: '13.x'
      - name: Cache dependencies and build outputs to improve workflow execution time.
        uses: actions/cache@v1
        with:
          path: node_modules
          key: ${{ runner.os }}-js-${{ hashFiles('package-lock.json') }}
      - name: Install dependencies
        run: npm install
      - name: Generate README file
        run: node index.js
      - name: Commit and Push new README.md to the repository
        uses: mikeal/publish-to-github-action@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Congratulations

You did it, Now you have a professionnal Github README profile, and it will be up to date every 6 hours

Remember, you can change the period by updating the line
- cron: '0 */6 * * *' by replacing 6 to x desired hours

What is Next ?

As you have seen, you can add more dynamic contents in your Github profile like
badges, github statistics and more.

Badges
The most important badge provider I recommend is Shield.io. There you can customize, build and redesign the provided badge according to your own design.

I am using them in mine like this

<h3>Things I code with ...</h3>
<p>
  <img  height="20" alt="React" src="https://img.shields.io/badge/-React-45b8d8?style=flat-square&logo=react&logoColor=white" />
  <img  height="20" alt="Vue Js" src="https://img.shields.io/badge/Vue.js-35495E?style=for-the-badge&logo=vue.js&logoColor=4FC08D" />
  [...]
  <img  height="20" alt="Laravel" src="https://img.shields.io/badge/Laravel-FF2D20?style=for-the-badge&logo=laravel&logoColor=white" />
</p>

Links and more
If you want to add links, images, tables and anything else, you can just update your index.mustache as template according to what you need as HTML Content (Without CSS style).

Github statistics
You can also show your Github statistic related to a repository, organization or profile there. Below is an example of github statistic card I use on my github page

<img alt="bpsmartdesign's GitHub stats" src="https://github-readme-stats.vercel.app/api?username=bpsmartdesign&count_private=true&show_icons=true&theme=onedark" />

You can get more details here.

References

Github doc
Thomas Guilbert Article
Supritha Ravishankar Article

Thank you for reading! 🙌

Share your amazing GitHub profile in the comments down below for the world to see! :)
My Github | My Portfolio