The trojanized Newtonsoft.Json fork campaign highlights how attackers are abusing developer trust, fake coding tests, and open-source familiarity to deliver malware.

Newtonsoft.Json is a widely known .NET library used for JSON handling. Because developers recognize the name, a malicious fork or lookalike project can appear less suspicious than a completely unknown repository. That familiarity is exactly what attackers exploit. They do not need to invent a new brand when they can hide behind one developers already trust.

The campaign used fake coding-test repositories as the delivery mechanism. This is especially dangerous because job candidates, freelance developers, and engineers often expect to clone repositories, run sample projects, install dependencies, and execute code as part of technical screening. Attackers are abusing that normal hiring workflow to get victims to run malware themselves.

The reported malware was hidden in SVG flag images inside the project. That detail matters because images are often treated as harmless project assets. A developer reviewing source files may focus on C# code, package references, scripts, and build files, while ignoring image assets. Attackers understand this blind spot and use it to hide payload material where people are less likely to inspect carefully.

Once the victim runs the project, the infection chain can deliver multiple capabilities, including browser credential theft, cryptocurrency wallet theft, file theft, remote access, and clipboard stealing. This turns a fake coding assessment into full endpoint compromise.

For developers, the risk is serious because development machines often contain valuable secrets. These may include GitHub tokens, cloud credentials, SSH keys, API keys, package-registry tokens, environment files, browser sessions, password-manager access, cryptocurrency wallets, and private source code. A compromised developer laptop can become a path into repositories, CI/CD systems, cloud infrastructure, and production environments.

For companies, the concern is not limited to individual job seekers. Internal recruiters, engineering teams, outsourced developers, contractors, and interview platforms may all handle sample repositories. If a malicious test project enters a corporate machine, it can expose business credentials and internal access. Apparently, even the interview process now needs malware screening, because criminals found yet another workplace ritual to ruin.

Organizations should warn developers never to run unknown coding-test projects directly on their primary machines. External assignments should be tested inside isolated virtual machines, disposable containers, or sandbox environments with no access to real credentials, internal networks, browser sessions, SSH keys, or cloud tokens.

Recruiters and hiring teams should also verify that coding assignments come from legitimate company domains, known contacts, and official hiring platforms. A coding test sent through an unusual channel, personal email, messaging app, or unfamiliar GitHub account should be treated with suspicion.

Security teams should monitor for suspicious behavior after developers run unknown repositories. This includes unexpected child processes from IDEs, .NET projects launching scripts, unusual outbound connections, access to browser profile folders, attempts to read wallet files, clipboard monitoring, persistence creation, and unknown remote-access traffic.

Developers should inspect not only source code but also project assets, build events, dependency declarations, scripts, configuration files, embedded resources, and binary blobs. SVG files, images, test data, and localization files should not be blindly trusted simply because they appear non-executable.

Organizations should also improve controls around developer endpoints. Application control, EDR, restricted scripting, protected credential storage, least-privilege accounts, and monitored outbound access can reduce the impact of a malicious repository execution.

If a suspicious coding-test project has already been run, the response should include isolating the device, checking process and network history, reviewing persistence locations, scanning for malware, and rotating credentials that may have been exposed. Password changes should be performed from a clean device, and active cloud and SaaS sessions should be revoked.

GitHub, cloud, npm, NuGet, PyPI, and other development tokens accessible from the infected system should be considered at risk. SSH keys and API credentials should also be rotated if they were stored locally or reachable through environment variables.

The key lesson is that source-code repositories are not automatically safe because they look professional or reference familiar libraries. A coding assignment can be a malware delivery package wearing a hiring costume.

Developers should treat unknown repositories the same way security teams treat unknown executables: isolate first, inspect carefully, and never run them in a trusted environment. Open-source trust, hiring urgency, and developer curiosity are all useful to attackers. Defenders need to remove the easy path between “clone this repo” and “compromise this machine.”

Cybersecurity researchers have discovered a NuGet typosquat that's unlike the typical information-stealing malware distributed via package registries: usual info-stealers: it's designed to rig live game results on Digitain. The package, named "Newtonsoftt.Json.Net," masquerades as the Newtonsoft.Json library and is a trojanized fork. Seven versions of the package have been published to the

Source: Trojanized Newtonsoft.Json Fork Hides Game-Rigging Code in a Working Library via The Hacker News — published 22 Jul 2026.