Between August 13 and October 10, 2025, a package named "Newtonsoftt.Json.Net" appeared on NuGet. It mimicked Newtonsoft.Json, a popular JSON library in .NET, but it was a trojan targeting the Digitain betting platform. About 1,200 developers downloaded it.
This attack was targeted. The malicious code activated only when JsonConvert.DefaultSettings was assigned, a pattern common in Digitain's codebase. If you weren't using Digitain's software, the package seemed normal. No alerts, no suspicious behavior.
Timeline
August 13, 2025: First version of Newtonsoftt.Json.Net published to NuGet.
August 13 - October 10, 2025: Six more versions released, maintaining the trojan while appearing legitimate.
October 2025: Package identified as malicious after 1,200 downloads.
Post-disclosure: NuGet removed the package.
Which Controls Failed
Dependency verification: Teams didn't verify the package name against their intended dependency. The extra "t" in "Newtonsoftt" should've been a red flag, but manual review or automated tools missed it.
Package integrity checks: No one verified the package publisher, signature, or download count. Newtonsoft.Json has millions of downloads; this package had hundreds. That's a red flag that went unnoticed.
Behavioral analysis in CI/CD: The malicious code activated under specific runtime conditions. Static analysis wouldn't catch this. Dynamic testing in environments mirroring production configurations didn't happen.
Repository-level controls: NuGet allowed a package name similar to a popular library. While repositories can't predict intent, they can implement similarity detection and require extra verification for packages resembling high-profile projects.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates annual training for software development personnel in secure coding techniques. Supply chain attacks through dependency confusion fall under "common coding vulnerabilities."
PCI DSS v4.0.1 Requirement 6.4.3 requires protection of public-facing web applications through security testing. This principle extends to any code accepting external input, including third-party packages. Verify what you're pulling into your build.
NIST 800-53 Rev 5 Control SA-12 (Supply Chain Protection) requires organizations to employ supply chain protection measures, including defining security requirements for developers and integrators. Document which packages you use, where they come from, and how you verify their authenticity.
ISO/IEC 27001:2022 Control 8.30 (Outsourcing) covers risks associated with external dependencies. If you're using third-party code, you need a process to assess and monitor the security of those dependencies throughout their lifecycle.
These standards emphasize having a process. This incident shows what happens when that process is missing or not enforced.
Lessons and Action Items
Automate dependency verification in your CI/CD pipeline. Tools like Dependabot, Snyk, or Socket can flag packages with suspicious names, low download counts, or recent publication dates. Configure them to block builds that pull in unverified packages. Don't rely on developers to notice an extra letter in a package name.
Require package lock files and review dependency changes. Your packages.lock.json or equivalent should be committed to version control. When someone adds or updates a dependency, that change should go through code review. A new package in a pull request is an opportunity to ask: "Why this package? Did you verify the publisher?"
Audit your current dependencies. Run dotnet list package or your language's equivalent. Look for packages with names that are slight variations of popular libraries. Check publication dates and download counts. If something looks off, investigate before your next deployment.
Configure your package manager to use signed packages only. NuGet supports package signing. If your organization publishes internal packages, sign them. If you're consuming external packages, configure your NuGet client to require valid signatures from trusted publishers.
Test in production-like environments. This trojan activated only under specific configuration patterns. Your staging environment should mirror production closely enough that conditional malicious behavior would trigger. If you're setting JsonConvert.DefaultSettings in production but not in staging, you're creating a blind spot.
Document your approved package sources. Maintain an internal registry of approved packages and publishers. If a developer needs to add a new dependency, it goes through a security review first. This adds friction, but friction prevents 1,200 downloads of a trojanized library.
Monitor for typosquatting attempts targeting your dependencies. Services like TypoWatch or custom scripts can alert you when new packages appear on public repositories with names similar to your critical dependencies. You want to know about "Newtonsoftt" before your developers do.
The attacker here understood how developers work: they copy package names from documentation, they trust repositories to filter out malicious content, and they don't have time to verify every dependency. Your controls need to account for that reality, not ignore it.
