Trending Topics
Malicious npm Package ambar-src Shows Fast Moving Supply Chain Risk
Tenable research reported that a malicious npm package named ambar-src reached roughly 50,000 downloads before removal, showing how quickly supply chain threats can spread across developer environments. The package appears to have been built for abuse from the start, with no legitimate use case, and a later version introduced malicious code on February 16, 2026, after earlier versions helped build trust and download volume. The main danger is that the malware runs during installation via an npm preinstall script, meaning a system can be compromised during npm install even if the package is never imported or executed by the developer. Tenable found detection-evasion methods that included hex-encoded command strings, multiple benign versions before weaponization, and the inclusion of legitimate code to reduce suspicion during review. Once triggered, the package fetches and runs additional payloads from remote infrastructure, tailoring the infection chain to Windows, Linux, or macOS. This makes the incident more than a simple package issue because it creates a direct path from routine development activity to full host compromise. The cross-platform payload behavior increases the severity because each operating system receives a different loader and malware chain, including Windows binaries, Linux scripts, and ELF payloads, as well as a macOS JavaScript payload tied to a capable open-source post-exploitation framework. Tenable also observed command-and-control traffic traversing Yandex Cloud services after the initial download stage, which can make malicious traffic blend into normal web traffic and reduce the likelihood of quick blocking. Their assessment is clear: any host with ambar-src installed should be treated as fully compromised, and removing the package alone is not enough, as follow-on malware may remain on the system with broader access. The package was removed from npm within hours of the malicious version being published, and a GitHub advisory was issued, but the reported download count shows the exposure window was still large enough to pose real enterprise risk. This incident reinforces that npm installation activity is a high-risk execution point and that dependency trust decisions can become security incidents before application code is ever run. Organizations should immediately hunt for ambar-src and the listed IOCs across endpoints and cloud workloads, isolate affected systems, rotate all secrets from a clean device, review outbound connections to the identified domains and URLs, and tighten package controls through dependency allowlisting, lifecycle script monitoring, and stronger developer workstation protections.
Malicious Next.js Repos Are Being Used to Compromise Developers
Microsoft reported an ongoing campaign in which attackers publish fake Next.js projects that appear to be legitimate codebases or recruiting assignments, then wait for developers to open and run them in routine workflows. The campaign blends into trusted tools and habits by using Visual Studio Code and Node.js activities instead of a traditional malware installer, making the initial execution easier to miss. Microsoft began the investigation after seeing repeated outbound connections from Node.js processes and traced the activity to malicious repositories, including job-themed projects and cloned project families with shared naming patterns and reused files. The researchers found three repeatable execution paths that all end in the same result: attacker-controlled JavaScript pulled at runtime and executed in memory. One path abuses VS Code workspace automation to run code when a folder is opened and trusted, another hides loader code in trojanized project files that run when developers start the app, and a third places loader logic in backend routes that run during server startup. During server startup, the malicious code can decode hidden endpoints from environment variables, send environment variables to the attacker, and execute the returned code within the Node.js process, potentially exposing cloud credentials, database secrets, and API tokens. After initial execution, all three paths converge on the same staged backdoor design with a first stage that registers the host, polls for instructions, and can run more code in memory, followed by a second stage that operates as a longer-lived controller for tasking, file discovery, and exfiltration. Microsoft telemetry showed the second stage using command polling, detached Node interpreters, directory-browsing endpoints, and staged file uploads, confirming this is an operator-driven campaign built for persistence and controlled data theft rather than a one-time script. This matters beyond developer laptops because those systems often store source code, environment secrets, build access, and cloud sessions, so a single trusted repository can become a path into production resources and business data. The report also shows why this remains an active risk even when teams know to avoid obvious malware, because the trigger can be a normal coding step, such as opening a repo, starting a dev server, or launching a backend service. Microsoft recommends treating developer workflows as a primary attack surface and using endpoint and network telemetry to hunt for unusual Node.js process trees, short interval outbound polling, and Vercel staging connections tied to suspicious Next.js projects. Organizations should keep VS Code Workspace Trust and Restricted Mode enabled for unknown repositories, review automation files and startup code before granting trust, harden endpoint protections against script abuse and dynamic execution, monitor identity risk for token theft, and build detections in Defender and Sentinel for repeated Node.js callbacks and staged upload behavior.
Malicious NuGet Packages Can Still Impact ASP[.]NET Teams After Takedown
Socket reported a coordinated NuGet supply chain campaign built around four malicious packages (NCryptYo, DOMOAuth2_, IRAOAuth2.0, and SimpleWriter_) that targeted ASP.NET developers and the applications they deploy. The package set used a staged design in which NCryptYo acted as the entry point and hid its actual behavior behind heavy obfuscation, while companion packages handled data theft and application abuse via a local proxy on localhost port 7152. The immediate goal was not only to steal identity and permission data from development environments, but also to alter authorization behavior so attackers could create hidden access paths within deployed applications. That matters because the attack can move from a developer machine into production code, turning a dependency issue into a business risk tied to customer access, internal privileges, and trust in application controls. Even though the packages were originally published in August 2024, the risk remains relevant today because malicious dependencies can persist on developer workstations, in CI caches, in internal package mirrors, in template projects, in lock files, and in long-lived applications that have not been rebuilt or fully audited. To clarify, a package published long ago can still be active today if it was copied into internal workflows before takedown and continued moving through builds and deployments. The campaign is especially serious because the companion packages were designed to intercept ASP.NET Identity and authorization operations, collect user and role data, and accept attacker-controlled responses that could change permissions at runtime. That creates a path for hidden privilege escalation inside the application itself, which is far more damaging than a one-time developer endpoint infection because it can persist after release and affect multiple environments. The fourth package, SimpleWriter_, added file write and hidden process-execution behavior under a document-conversion theme, increasing the attacker’s ability to run code and place content on disk during normal application operations. The shared localhost relay pattern, hardcoded credentials, and coordinated package behavior point to an intentional multi-package operation with a clear objective: quietly weaponizing business applications rather than causing noisy, immediate disruption. Organizations should treat any historical or current use of these packages as a potential compromise, review build histories and dependency lock files, inspect deployed applications for unexpected authorization behavior and port 7152 activity, and rotate credentials from a clean device if exposure is confirmed. Teams should also strengthen NuGet governance by verifying package publishers, blocking typosquatted names, scanning package contents before approval, pinning trusted versions, and monitoring for abnormal permission changes in ASP.NET applications after deployment.
Update: SafePay Ransomware Claim Against Conduent Highlights Expanding Third-Party Breach Risk
The SafePay post naming Conduent[.]com as a victim should be treated as a serious extortion indicator, but not as stand-alone proof of the full impact, because leak-site entries mainly confirm a criminal claim and timeline rather than a validated loss count. Independent ransomware tracking shows a SafePay victim entry for Conduent with an estimated attack date of January 9, 2025, and a discovery date of February 20, 2025, which aligns with broader reporting around the incident window. Conduent’s own SEC disclosures state the company discovered a January 2025 cyber event on January 13, 2025, restored affected systems within days or hours, and determined that a threat actor accessed a limited portion of its environment and exfiltrated files tied to a limited number of clients. The same filing also says the stolen files contained personal information tied to client end users, and that client and regulatory notifications began in October 2025 and were expected to continue into early 2026, which explains why this remains an active issue now, even though the intrusion itself began in 2024. Conduent’s relevance is high because it supports business process operations across major sectors and public programs, thereby increasing downstream exposure when a single provider is hit. Additional public records now point to a much larger impact picture than the early “limited environment” wording suggested. Wisconsin’s consumer protection breach page lists Conduent under February 2026, with the incident period of October 21, 2024, through January 13, 2025, notes exposure of personal and health-related data, and reports more than 25 million affected individuals while describing Conduent’s role in state backend services for Medicaid, child support, food assistance, and unemployment programs. Texas also escalated the issue on February 12, 2026, by issuing civil investigative demands to Conduent and Blue Cross Blue Shield of Texas, stating the breach exposed sensitive data of about four million Texans and included Texas Medicaid recipient information. This combination of an extortion claim, a delayed notification cycle, and expanding state-level disclosures makes the event a third-party concentration risk story, not just a single-company ransomware headline. Organizations that depend on Conduent should confirm whether their programs or populations are in scope, review data-sharing and access paths tied to Conduent-managed processes. They should also reassess vendor risk controls by tightening contractual notification requirements, validating segmentation and logging expectations with service providers, and testing contingency plans for critical outsourced services to prevent a similar event from causing prolonged operational and reputational exposure.
