What happened
Security researchers at Socket Software Security Research identified nine malicious packages published on the NuGet ecosystem under the developer name shanhai666. These packages, which appear to include largely legitimate .NET code, embed a hidden payload that triggers between August 8, 2027, and November 29, 2028.
The packages target three major database providers (SQL Server, PostgreSQL, SQLite) and, in one critical case (package “Sharp7Extend”), they impersonate the well-known library Sharp7 (used with Siemens S7 PLCs) to terminate processes, corrupt PLC writes, and disrupt industrial control systems.
The delisting of the developer’s packages occurred after nearly 9,500 downloads, but the threat actors may have already gained traction.
Who is affected
- Organizations using .NET applications via NuGet packages that rely on the affected package names (e.g., SqlUnicorn.Core, SqlDbRepository, SqlLiteRepository, MyDbRepository, MCDbRepository, Sharp7Extend) are vulnerable.
- Industrial enterprises that use Siemens S7 PLCs and the Sharp7 communication library/library derivative are at particularly high risk due to the embedded sabotage routines in Sharp7Extend.
- DevOps and software supply-chain teams that integrate NuGet dependencies into CI/CD pipelines may inadvertently bring in malicious packages, especially those that mimic legitimate package names (typosquatting or extension naming).
- Because the malicious behavior is delayed and probabilistic (with a 20% trigger chance under certain conditions), the impact may surface later, making detection and response more complex.
Why CISOs should care
This incident underscores multiple supply-chain threats for CISOs:
- The attack leverages trusted ecosystem dependencies (NuGet), which many teams assume to be safe. That assumption is now less reliable.
- The delay trigger (2027-2028) indicates that organizations may already be compromised and unaware, necessitating proactive detection now rather than after an incident.
- Industrial control systems (ICS) are targeted, bridging enterprise IT and OT environments, meaning a single malicious package can have broad physical-world operational impacts (e.g., PLC commands failing, safety systems not engaging).
- It emphasizes the need for holistic supply-chain risk management, extending beyond typical phishing/endpoint controls, dependencies, build pipelines, and CI/CD artifacts must also be scrutinized.
- For CISOs responsible for strategic risk, this increases the threat surface: not only servers and endpoints, but also the code libraries teams consume and reuse globally within the organisation.
3 Practical Actions for CISOs
- Audit your NuGet (and other package managers) dependencies.
-
- Ask development and DevOps teams to run an inventory of all NuGet packages in use, including their version history and publisher names.
- Specifically search for the nine identified malicious packages (SqlUnicorn.Core, SqlDbRepository, SqlLiteRepository, SqlUnicornCoreTest, SqlUnicornCore, MyDbRepository, MCDbRepository, SqlRepository, Sharp7Extend) as well as any packages published under “shanhai666”.
- Remove or replace any instance of these packages and validate whether they were used in production builds.
- Introduce behavioral monitoring and “time-bomb” detection.
-
-
- Set up detection mechanisms for anomalous dependencies (e.g., packages that have very few downloads, mimic a popular library name, or whose publisher cannot be validated).
- Monitor application logs and PLC/ICS communication logs for signs of write corruption, unexpected terminations, or safety system failures, especially in ICS/OT environments. The malicious payload has functions that terminate processes and corrupt PLC writes after delays (30-90 minutes) with an 80% chance.
- Integrate this into threat hunting routines for supply-chain risks, not just endpoint or network threat hunting.
-
- Strengthen your software supply-chain governance.
-
- Enforce strict policies around third-party package usage: require developer sign-off, approval for new dependencies, and use of only vetted packages.
- Use package manager governance tools (e.g., allowlists/denylists, publisher verification, internal mirrors) to restrict package sources to known good publishers.
- Ensure CI/CD pipelines include dependency scanning (for malicious code, typosquatting, unusual publisher names) and require builds to fail when suspicious packages are detected.
- For OT/PLC-connected environments, coordinate with ICS/OT teams to register library dependencies and implement stricter change management and auditing for code and libraries used in control systems.
Being proactive now is far easier than responding after a large-scale disruption runs its course. For CISOs overseeing software-heavy or industrial operations, this is a reminder that dependency risk is real, and the clock may already be ticking.