Supply Chain Attacks: How I Found Malicious Project on a Freelance Portal in Minutes

In a world where even Vercel can be compromised by a Roblox script, no developer is too technical to be a target. I decided to see how easy it is to find these threats in the wild. In less than 10 minutes on a popular freelance portal, I found a $60 bounty that looked like easy money. Hidden beneath the surface was a sophisticated supply chain attack designed to harvest sensitive information.

This article was written purely as learning material, and all exploration was conducted by me for research purposes. I took full responsibility for any risks resulting from this research, with a complete understanding of the potential impact. Rather than attempting to replicate these tests, you can stay safe by simply following the Freelancer Checklist provided in the conclusion.

The High Cost of Human Trust

In the past month, security breaches have dominated global media headlines, including on LinkedIn. Three incidents stand out: the Trivy Security Scanner compromise in March 2026, the Axios NPM package attack in March 2026, and the Vercel/Context.ai breach in April 2026.

The Axios and Vercel breaches illustrate that even sophisticated supply chain attacks often begin with traditional social engineering rather than technical exploits. In both cases, attackers leveraged human psychology to harvest sensitive information from victims. These incidents remind us that the most dangerous entry point is still human trust.

One might never imagine that a massive enterprise like Vercel could be compromised through something as simple as a Roblox cheat script. But these recent events demonstrate a clear shift in tactics. Attackers are targeting software developers and engineers more aggressively than ever, and it is no longer just non-technical people who are in the crosshairs.

My quick research pointed to recurring vectors: CI/CD pipeline infiltration, package manager hijacking, SaaS vulnerabilities, and exposed environment variables. The pattern is obvious. The attacker only needs one weak trust decision to turn routine development work into a breach.

Hunting for Malware in the Wild

As someone with limited security knowledge, I was curious whether these attacks could be found in our daily lives as software developers. I remembered seeing LinkedIn posts about suspicious project opportunities shared through direct messages, where victims discovered hijacked packages and malicious logic only after opening the codebase.

If those dangerous projects could spread privately through social media, I assumed I could find one spreading publicly on a freelance portal. So I logged into my old Freelancer.com account and started exploring the Contest section. I chose the Contest section because most entries there are open to the public, unlike standard projects where you must bid before you can inspect the codebase.

From an attacker perspective, this area is ideal. Victims come willingly, attracted by a reward and the chance of winning. The attacker does not need to pressure them much, because the target is already motivated to download, run, and submit something quickly.

The surprising part is how fast it happened. I found a suspicious contest in less than 10 minutes of exploring.

The Bait: A $60 "Light Theme" Request

The project was titled Add Light Theme to Simple React Project, with a $60 reward for the winner. The description sounded harmless: an existing React app needed a professional light theme added alongside the current dark one, with a toggle in the header and styled pages.

As a frontend developer with more than five years of experience, I knew this could be finished in an hour or two manually, or even faster with AI assistance. That is exactly what made it effective bait. It was plausible, specific, and cheap enough to feel routine.

Then the red flags started stacking up. The source code was attached as a RAR file. The deliverable asked for a screenshot, which is suspicious because it implicitly confirms the victim actually ran the code. The client uploaded a RAR but demanded a ZIP in return. Their payment was not verified, and their profile had zero rating history.

If I were an attacker, $60 plus platform fees would be a tiny cost compared to what could be harvested: email credentials, GitHub access, session cookies, Web3 wallet keys, and more. And not from one victim, but from many.

I downloaded the RAR, used an online extractor to unpack it, and began exploring the project. Because the task was clearly frontend-oriented, the presence of backend complexity already felt off.

The first file I checked was the .env file. That alone violated one of the most basic rules in software delivery: never commit sensitive environment variables into a repository or bundle.

Digging deeper, I found a half-baked application. The backend entry point was completely empty. Most routes had no authentication integration even though Supabase logic and a users table were present. It looked less like a real project and more like a lure assembled just enough to appear legitimate.

AI-Assisted Triage

Not stopping there, I spun up a fresh session in my coding environment and asked Mimo v2 Pro to scan the project for malware patterns and hacking scripts. The model immediately began checking for common indicators: process execution, base64 decoding, shell behavior, suspicious dependencies, and known abuse patterns.

My prompt was intentionally simple:

Find whether the codebase contains malware or hacking scripts.

Its first result was telling. It found references that suggested obfuscation and shell-related activity, then attempted to inspect suspicious dependencies that were supposed to exist under node_modules. It also noted that the expected package directories were missing from the extracted project, which pushed the investigation toward the NPM registry metadata instead.

In practical terms, the scan walked through the exact kinds of patterns a careful reviewer would want to see checked first: dangerous execution functions, encoded or obfuscated payloads, and suspicious shell-oriented strings. From there, the analysis pivoted into dependency inspection and registry lookups.

The next step was checking the NPM registry for packages that looked unusual. Two names stood out: cache_mng and streamlyx. The pattern was classic typosquatting and impersonation. One package claimed to be associated with a respected open-source maintainer, but its actual metadata pointed elsewhere.

Findings: Supply Chain Attack Detected

Mimo concluded that this was a supply chain attack using recently published impersonation packages. cache_mng had been created only days earlier, claimed a familiar open-source identity, and linked to what looked like a fake GitHub repository. streamlyx followed the same pattern and formed a dependency chain underneath it.

The red flags were unusually strong. One package presented itself as if it were tied to a famous NPM author, yet the actual maintainer information pointed to an unrelated identity. The homepage reference also appeared misleading. Taken together, this looked less like a mistake and more like a deliberate impersonation setup.

The secondary package repeated the same pattern. More importantly, it sat directly in the dependency chain of the first package, which strongly suggested the pair had been planted together intentionally rather than introduced accidentally through routine development.

I then tried to trace the project and maintainer references back to GitHub. That led nowhere: the profiles and repository claims did not line up in a credible way, which only reinforced the suspicion that the metadata had been crafted to borrow trust from legitimate open-source names.

The most damning evidence was how the package appeared in the codebase. The controller imported the cache package, initialized it with test data, logged it once, and never used it in any real business logic. In other words, the code existed only to force the dependency to load and execute at runtime.

That detail matters because dead code with no business value is often one of the clearest signs that a dependency exists for side effects rather than for product functionality. Here, the dependency was not solving a real application need; it was simply being pulled into the runtime path.

That is the hallmark of planted malicious code. When npm install runs and the backend starts, arbitrary code can execute inside the victim's environment and potentially exfiltrate JWT secrets, Supabase keys, session data, and other sensitive assets.

At that point, I stopped caring about any claimed documentation and focused instead on package behavior, dependency metadata, and analysis tooling like Socket. That was enough to confirm the real nature of the project.

That was effectively the finish line of my exploration. I did not need a fully detonated payload to understand the pattern. The combination of social bait, suspicious archive handling, fake maintainer claims, dead-code imports, and dependency chaining was already enough to treat the project as hostile.

Conclusion: The Freelancer's Survival Guide

Supply chain attacks are clearly becoming more frequent, and the targets are changing. Attackers are no longer focused only on people with weak technical literacy. By compromising a developer, they open the door to much more valuable information, including access keys, secrets, wallet credentials, and privileged business systems.

If you are a freelancer, here is the checklist I recommend:

Prepare a sandbox environment. Use Docker or Podman to maintain a clean image containing only the minimum stack you need, whether that is Node, Go, Python, or another runtime.

Scan before you work. Once a client gives you access to a codebase, inspect it in the sandbox first instead of on your day-to-day machine.

Run your AI agent. Ask your model to review the full codebase for suspicious logic, malware patterns, dependency abuse, and credential exposure.

Monitor the runtime. If the scan looks clean enough to continue, run the project while watching processes, network behavior, and any unexpected execution paths.

Verify and proceed. Only after those checks should the work move forward on the assumption that the project is legitimate.

We will likely see more major breaches throughout 2026. Attackers will use AI to amplify their methods, malicious projects will spread to more platforms, and SaaS providers will continue upgrading their vulnerability scanning tools. The fight will intensify on both sides.

In parallel, we should expect fake and malicious projects to spread across more mainstream platforms, not fewer. The same pattern seen in high-profile breaches applies here too: one believable request, one rushed trust decision, and one compromised environment can open the door to a much larger downstream incident.

The lesson is simple: do not confuse technical confidence with immunity. In modern software work, caution is now part of the job description.