Threats tagged 'local'

This vulnerability allows local attackers to delete arbitrary files on affected installations of TrendLife Cleaner One Pro. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 5.6. The following CVEs are assigned: CVE-2026-62660.

In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.

This vulnerability allows local attackers to escape the model runner sandbox on affected installations of Docker Desktop for macOS. An attacker must first obtain the ability to execute low-privileged code within the sandbox in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 8.8.

Duplicati v2.3.0.1 has a critical vulnerability allowing local users to execute arbitrary code with SYSTEM privileges if installed outside the default directory. This occurs because the installer does not apply proper access controls to non-default installation directories, enabling attackers to place malicious files that the LocalSystem service loads. Installing Duplicati in the default directory or applying equivalent ACL protections mitigates this risk.

Attackers have shifted from hiding from AI tools to running inside them. By poisoning the config files that govern AI coding assistants, a new worm class achieves silent persistence, evades AI-based scanners, and spreads across an organization's repositories through developers' own tools. Key takeaways AI coding assistant configuration files, such as settings.json hooks, .cursorrules Cursor MDC rules, and similar harness files, are now explicit targets in supply-chain attacks, not collateral damage. These files simultaneously sit at the intersection of three trust relationships: The developer trusts them as config, the integrated development environment (IDE) executes them automatically, and the large language model (LLM) treats them as authoritative instructions, making them a uniquely powerful persistence vector. Defenders should treat harness config files as code that requires mandatory reviews and hash pinning in the CI/CD pipeline; enforce --ignore-scripts on package installs; and flag AI scanner refusals as a suspicious signal rather than a clean result. While analyzing a recent Mini Shai-Hulud campaign and its other variants, Tenable made a discovery: The payload wasn’t just stealing tokens and exfiltrating credentials. It was rewriting the configuration files that tell AI coding assistants what to do every time a developer opens a project. The Mini Shai-Hulud worm, which targets npm, PyPI, and other third-party registries simultaneously, includes a dedicated module that scans the developer’s home directory for configuration files belonging to AI coding tools by name, such as Anthropic’s Claude Code, Google’s Gemini CLI, Microsoft’s GitHub Copilot, SpaceX’s Cursor, OpenAI’s ChatGPT Codex, Cline’s eponymous tool, the open-source tool Aider, and others. For each one it finds, it injects a hook command which helps the malware stay persistent. From that point forward, every time the developer starts an AI coding session, the malware runs silently and automatically, and with the same level of trust the developer placed in their own tools. This is a deliberate architectural choice: The attacker modeled the execution environment, identified the highest-privilege auto-run mechanism available on a developer’s machine, and built the attack specifically for it. Supply-chain attacks used to end at credential theft. Now the AI agent’s harness is both the target and the propagation vector. Why AI agent harness files are a uniquely attractive target For years, defenders have focused supply-chain security on the package itself: Inspect the preinstall script, scan the tarball, verify the checksum. That model assumes the malicious payload lives only inside the installed artifact. The threat described here breaks that assumption: The payload lands in a completely different place. AI coding assistants’ configuration files occupy a structural position unlike any other file in a developer’s working environment. They are simultaneously trusted as developer configuration, so they survive aggressive code reviews focused on business logic; are executed automatically by the IDE, so no user interaction is required after initial compromise; and are treated as authoritative instructions by the AI model itself, so the LLM will act on their content without prompting the user. No other file class has all three properties at once. A malicious package.json script requires execution. A malicious comment in source code requires a developer to act on it. A malicious hook in .claude/settings.json runs every time the developer opens a session. The attack surface is also nearly invisible to conventional scanning. These files are small, structured, and look identical to legitimate developer config. A poisoned settings.json with a malicious SessionStart hook has the same schema and structure as a clean one; the only difference is what the command field points to. Meanwhile, the files are rarely subject to the same review discipline as production code. They live…

This vulnerability allows local attackers to escalate privileges on affected installations of MSI Center. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2026-6102.

This vulnerability allows local attackers to escalate privileges on affected installations of G DATA Total Security. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2026-13268.

This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.8.

This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 8.8.

This vulnerability allows local attackers to create a denial-of-service condition on affected installations of AnyDesk. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 4.7. The following CVEs are assigned: CVE-2026-15681.

The stack is a memory region where a program stores temporary data -&&#x23&#x3b;x26&#x3b;&#x23&#x3b;xc2&#x3b;&&#x23&#x3b;x26&#x3b;&#x23&#x3b;xa0&#x3b;like local variables and return addresses. Think of the stack as a pile of plates in your kitchen: you can only add a new plate to the top, and you can only take one away from the top too. Programs use this same "last in, first out" principle to keep track of what they&&#x23&#x3b;x26&#x3b;&#x23&#x3b;39&#x3b;re doing. Every time a function is called, the program pushes a new plate onto the stack containing things like local variables and the address to return to once the function finishes. When the function is done, that plate is popped off the top, and execution resumes exactly where it left off. This simple mechanism is what allows programs to call functions&&#x23&#x3b;x26&#x3b;&#x23&#x3b;xc2&#x3b;&&#x23&#x3b;x26&#x3b;&#x23&#x3b;xa0&#x3b;within functions, and always find their way back -&&#x23&#x3b;x26&#x3b;&#x23&#x3b;xc2&#x3b;&&#x23&#x3b;x26&#x3b;&#x23&#x3b;xa0&#x3b;but it&&#x23&#x3b;x26&#x3b;&#x23&#x3b;39&#x3b;s also precisely why a stack that grows too large, or gets overwritten with unexpected data, becomes a favorite target for attackers looking to hijack a program&&#x23&#x3b;x26&#x3b;&#x23&#x3b;39&#x3b;s execution flow.

This vulnerability allows local attackers to create a denial-of-service condition on affected installations of AnyDesk. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 4.7. The following CVEs are assigned: CVE-2026-15682.

This vulnerability allows local attackers to escalate privileges on affected installations of Glarysoft Glary Utilities. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.3. The following CVEs are assigned: CVE-2026-15684.

The new OMB logging directive raises the bar on log collection and explicitly ties every maturity milestone to how well agencies know what’s on their networks. Learn why asset visibility is the first problem to solve. Key takeaways M-26-14 rescinds M-21-31 and replaces blanket data-retention mandates with a five-element logging maturity model (levels 0-4) that agencies must progress through on a strict timeline after CISA publishes the logging reference architecture (LRA). Every maturity level is gated by inventory visibility. Specifically, agencies must demonstrate 70%, 80%, 90%, and 95% IT/OT/IoT asset capture at levels 1 through 4, respectively. After all, you can’t claim log coverage for assets you haven’t discovered. OT and IoT devices are explicitly in scope, including systems without native logging capability. This inclusion makes passive asset discovery tools a necessity rather than an add-on. The clock starts when CISA publishes the LRA within 90 days of the memo. Agencies that close asset-inventory gaps now will be positioned to hit the required deadlines, such as reaching level 1 in 120 days and level 3 in 321 days. You can’t log what you can’t see, and you can’t measure logging maturity against an incomplete inventory On May 22, the U.S. Office of Management and Budget (OMB) Director Russell Vought issued Memorandum M-26-14 , titled “Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats.” The directive rescinds M-21-31 and replaces it with a risk-based, prioritized logging framework designed to be both operationally achievable and aligned with today’s threat landscape. For federal cybersecurity leaders, M-26-14 represents a meaningful shift away from blanket data retention mandates and toward measurable, outcome-driven logging maturity. But hidden within its requirements is a foundational dependency that many agencies will need to address before their logging investments can deliver results: complete asset visibility . What M-26-14 requires, and why it’s different from M-21-31 The memorandum organizes logging around two objectives: Continuous event monitoring (CEM): Real-time log ingestion, anomaly detection, and SOC-driven response. Threat hunting, investigation, response, and forensics (THIRF): Centralized retrieval of historical log data to support post-compromise analysis and recovery. Agencies must achieve these objectives across all information systems, explicitly including internet-of-things (IoT) devices and operational technology (OT) systems, whether owned, operated, or managed by third parties. The memo also establishes a logging maturity model with five levels (0–4) that agencies must progress through on a defined timeline, with milestones measured across five elements: Inventory visibility : What percentage of IT/OT/IoT assets are captured in centralized hardware asset management (HWAM)/ software asset management (SWAM) inventories? Collection coverage : Are logs searchable and retrievable for those assets? Collection operations : Do logs generate actionable, tuned alerts? Data retention : Are logs retained for 6 months (searchable) and 12 months (retrievable)? Log management : Are logs encrypted, access-controlled, and properly retired? Agencies must reach level 1 (Basic) within 120 days, level 2 (Intermediate) within 180 days, and level 3 (Advanced) within 320 days of CISA publishing the logging reference architecture (LRA). A critical detail in the maturity model’s design: Overall maturity is calculated based on the lowest watermark across all five elements ( Appendix C footnote 8 ). For example, an agency that achieves level 3 in collection coverage but only level 1 in inventory visibility gets an overall rating of level 1. There is no averaging. This lowest-watermark principle makes inventory completeness the single most consequential element to address first. The denominator problem: Why incomplete inventories break the maturity model Look closely at the maturity model and a pattern emerges: Inventory completeness gates every level . Level 1 requires 70% of IT/OT/IoT assets captured in a centralized inventory Level 2 requires 80% Level 3 requires 90% Level 4 (Optimal) requires 95% The expansive scope of this OMB mandate — spanning on-premises IT, cloud workloads, identity providers, OT, and IoT — creates an immediate challenge: the denominator problem. Because log collection is measured as a percentage of your total inventory, you can’t claim 80% coverage if you only know about 60% of your assets. This operational gap is typically driven by administrative silos, air-gapped networks, and legacy OT/IoT environments that lack native logging or are unsafe to actively scan. Ultimately, managing visibility across this massive footprint comes down to one simple truth: You can’t write a logging plan for assets you haven’t discovered. How Tenable maps to M-26-14’s requirements Tenable has been embedded in the federal cybersecurity ecosystem as an a pproved continuous diagnostics and mitigation (CDM) vendor whose technology acts as the vulnerability management backbone for hundreds of civilian agencies, and increasingly as the platform that unifies visibility across IT, OT, and cloud attack surfaces. With M-26-14’s asset inventory requirements front and center, the foundation that Tenable’s technology provides is directly relevant to compliance milestones agencies must now achieve. The mapping below shows how Tenable capabilities correspond to M-26-14’s five maturity elements. -- Ground truth for the maturity model: Authoritative asset inventory Tenable One Vulnerability Management and Tenable One OT Exposure provide continuous, comprehensive asset discovery across traditional IT, operational technology, and IoT devices. This inventory serves as the ground truth for agencies to measure their maturity model progress, the denominator against which log collection coverage is calculated. -- Already CDM-connected: How Tenable accelerates HWAM/SWAM compliance M-26-14 explicitly directs agencies to use CDM, HWAM, and SWAM data to validate log coverage ( Appendix B, Requirement 4 ). As an established primary data source for federal CDM dashboards, Tenable eliminates the need for new data collection by pre-packing and reporting the inventory details M-26-14 requires. -- The Tenable solution: A phased approach to full visibility Standard IT scanners can crash fragile OT equipment like programmable logic controllers (PLCs). To meet M-26-14 requirements safely, Tenable offers a tiered approach: Phase 1: Baseline (Level 1): If you’re starting from scratch, use the OT Recon scan policy in Tenable Security Center or Tenable One Vulnerability Management. It uses “Safe Active Querying” with native industrial protocols to discover hardware and firmware details without downtime, helping you reach the 70% Level 1 baseline. Phase 2: Optimal Maturity (Level 4): To hit the 95% asset visibility threshold requiring daily updates, deploy Tenable One OT Exposure. By combining passive network monitoring with safe active querying, you gain persistent, real-time visibility into the deepest parts of the industrial network, bridging the gap to Level 4 maturity. -- From inventory to zero trust: Connecting visibility to the CISA Zero Trust Maturity Model Appendix A requires the LRA to align with CISA’s Zero Trust Maturity Model , which defines visibility and analytics as a cross-cutting capability enabling all five zero-trust pillars. The Tenable One Exposure Management Platform provides continuous attack surface visibility and risk quantification that feeds directly into z ero trust analytics, connecting vulnerability, identity, and configuration data into a unified exposure view. -- Beyond log retrieval: Vulnerability history as forensic evidence When investigating a compromise, security operations center (SOC) analysts need more than logs; they need to know which vulnerabilities existed on affected assets at the time of the incident. Tenable’s scan history and vulnerability timeline provide the forensic context required by Appendix B ( items j–k ): determining attack vectors, lateral movement paths, and root-cause analysis. -- AI-driven prioritization: Focusing logging resources where risk is highest Appendix A explicitly states that the LRA will address using AI to enhance CEM and THIRF capabilities. Tenable Hexa AI and Vulnerability Priority Rating (VPR) deliver AI-driven risk context that helps agencies prioritize which assets and vulnerabilities demand the most urgent logging and monitoring attention, directly supporting the “risk-based, prioritized” philosophy of M-26-14. Beyond inventory: Prioritizing logging resources where threat intelligence risk is highest Establishing an authoritative asset inventory provides the necessary compliance foundation, but it immediately introduces an operational challenge: once an agency uncovers thousands of previously unmanaged IT, OT, and IoT assets, where should security teams begin deploying limited logging resources? The same challenge exists across other parts of the modern attack surface. Cloud workloads, identity providers and directories, web applications, APIs, and containerized environments frequently operate in silos with incomplete inventories and inconsistent visibility. These assets can become equally unknown or poorly logged, creating additional blind spots that M-26-14’s risk-based, prioritized framework requires agencies to close. OMB M-26-14 explicitly shifts federal strategy away from legacy, blanket data -retention mandates and toward a “risk-based, prioritized” logging philosophy. However, the directive does not prescribe a formula for that prioritization. Leaving agencies to manually identify high-value assets (HVAs) and determine logging priorities across complex hybrid IT/OT/cloud/identity environments creates compliance bottlenecks. This is where asset discovery must transition into unified exposu

ProtonVPN v4.4.1 - Unquoted Service Path

MEmu Android Emulator 9.2.7.0 - Local Privilege Escalation

Windows Defender (MsMpEng.exe) - Race Condition

The Department of Homeland Security is investigating a cyberattack that compromised the Homeland Security Information Network (HSIN), a sensitive information-sharing platform used by federal, state, local, and private-sector partners. [...]

A variant of DirtyFrag, the flaw allows unprivileged local users to manipulate the Linux page cache and gain root privileges. The post ‘DirtyClone’ Linux Kernel Vulnerability Leads to Root Access appeared first on SecurityWeek .

A stolen session cookie sat in underground markets for seven weeks before attackers used it to poison 32 Red Hat packages in the npm software registry, an example of the industrial approach behind modern supply chain attacks. Key takeaways Miasma is a self-propagating npm worm derived from Mini Shai-Hulud that TeamPCP open-sourced on May 12. The public release of the full weaponized toolchain means any operator can now replicate structurally identical supply chain campaigns. The Miasma campaign compromised 89-plus npm packages across three waves (June 1-5), affecting Red Hat, Vapi.ai, and Microsoft Azure repositories. The worm produced malicious packages with valid SLSA Build Level 3 provenance attestations, defeating the highest tier of supply-chain integrity verification. The root cause was a stolen developer credential that sat in infostealer logs for seven weeks before weaponization. This infostealer-to-supply-chain pipeline is the defining pattern of the Developer Credential Economy. The Miasma campaign’s third wave (June 5) introduced a significant escalation: persistence files that target AI coding assistants (Claude Code, Cursor, Gemini CLI, VS Code), expanding the attack surface from package registries to the developer’s local environment. Relying on execution-layer detection, such as EDR, is insufficient against supply chain threats because EDR tools lack visibility into the ephemeral CI/CD environments where credential theft and weaponization occur. Organizations should treat developer credentials as control-plane infrastructure and adopt a phased Continuous Threat Exposure Management (CTEM) approach: harden the generation layer, neutralize harvested secrets in real time, and enforce human-gated publishing controls. Background on the Miasma worm and npm supply chain attack On June 1, the Miasma self-propagating worm compromised 32 official npm packages under the @redhat-cloud-services namespace, delivering a credential-harvesting payload to an estimated 80,000 to 117,000 weekly downloads. Within five days, the campaign escalated through three distinct attack waves and forced GitHub to disable 73 repositories across four Microsoft organizations . The technical details of the Miasma supply-chain attack are alarming: valid Supply Chain Levels for Software Artifacts (SLSA) provenance attestations on malicious packages; a novel execution technique that bypasses install-script monitoring; and a new persistence mechanism that targets AI coding assistants. But the most important detail is a timestamp. Dark web monitoring firm Whiteintel detected a Red Hat employee’s GitHub credential and session cookie in infostealer logs on April 13. A second sighting appeared on May 15. The credential sat in underground markets for approximately seven weeks before attackers weaponized it on June 1. That seven-week gap is the signature of an emerging threat model that Tenable’s Research Special Operations (RSO) team calls the Developer Credential Economy , and has been tracking since March 2026. The Developer Credential Economy is a structured black market for highly privileged developer credentials where open-source supply chain compromises function as credential generation infrastructure, underground markets serve as the distribution layer, and multiple threat actors with distinct motivations weaponize the harvested access downstream. The Miasma campaign is the clearest example of this model to date, and it validates a pattern that has been accelerating across the npm, PyPI, and GitHub ecosystems throughout 2026. The three-layer economy, explained through Miasma When it first assessed this pattern in March, Tenable RSO built the analysis around the TeamPCP cascading campaign (Trivy, KICS, LiteLLM, Telnyx, and 66+ npm packages) and the Sapphire Sleet/UNC1069 Axios compromise . The thesis identified a three-layer structure: credential generation, distribution, and weaponization. Three months later, the Miasma campaign validates each layer with striking clarity. Layer Actor / group Operational focus Primary targets Miasma validation Generation TeamPCP Bulk credential harvesting via tool exploitation Trivy, KICS, TanStack, Red Hat npm scope Miasma's payload sweeps GitHub tokens, cloud credentials, CI/CD secrets, SSH keys, and .env files from every infected environment Distribution Underground markets, infostealer aggregators Credential brokering and tooling proliferation Stolen developer credentials; open-sourced worm code Red Hat employee credential sat in infostealer logs for seven weeks before weaponization; Shai-Hulud source published May 12 Weaponization Sapphire Sleet (DPRK-nexus), LAPSUS$, Miasma operator, copycat actors State-sponsored exfiltration, data theft, cascading supply chain compromise Axios (npm), Mercor AI, @vapi-ai/server-sdk, Azure/durabletask Each Miasma wave generates A fresh credential pool, feeding the next wave and enabling downstream actors Layer 1: Credential generation The Developer Credential Economy’s first layer is extraction. Threat actors compromise developer tooling and open-source infrastructure not primarily to distribute malware to end users, but to harvest the credentials those environments contain, such as GitHub tokens, npm publishing tokens, cloud provider credentials, CI/CD secrets, SSH keys, and API keys. TeamPCP pioneered this at scale beginning in September 2025 with the original Shai-Hulud worm. Its defining innovation was cascading credential extraction: compromise one trusted tool, harvest the credentials it holds, and use those credentials to compromise the next tool in the dependency chain. The Trivy vulnerability scanner compromise yielded CI/CD runner secrets. Those secrets enabled the KICS compromise . KICS yielded additional cloud credentials. Each link in the chain generated a broader set of privileged access. By May, TeamPCP had refined this into the Mini Shai-Hulud variant, which introduced two capabilities that made the generation layer dramatically more efficient: Wormable propagation : The malware queries the npm registry for every package the compromised identity can publish, and republishes itself across all of them automatically. CI/CD pipeline hijack via OpenID Connect (OIDC) token extraction : Rather than stealing static credentials, Mini Shai-Hulud requests short-lived OIDC tokens through GitHub Actions, enabling it to publish packages with valid cryptographic provenance. In the Miasma supply chain campaign, this generation layer operated through a Red Hat employee’s compromised GitHub account. The worm’s payload swept the infected environment for: GitHub tokens and personal access tokens npm publishing tokens AWS, GCP, and Azure cloud credentials HashiCorp Vault tokens Kubernetes service account tokens SSH private keys Docker registry credentials GPG keys .env files The June variant added dedicated collectors for GCP and Azure cloud identities, going beyond secret extraction to enumerate all cloud access the infected machine holds. Every machine that ran npm install against a compromised @redhat-cloud-services package version became a credential generation node. Layer 2: Distribution The second layer is the marketplace. Stolen credentials flow from the generation layer into underground markets, infostealer log aggregators, and access brokering services, where they become available to any buyer. The Miasma supply chain-attack timeline makes this layer visible in a way previous campaigns did not. Whiteintel detected the Red Hat employee’s GitHub credential and session cookie in infostealer logs on April 13. That credential was not generated by a targeted supply chain attack against Red Hat; a commodity infostealer harvested it, one of 13.2 million infostealer infections that SpyCloud's 2025 Identity Exposure Report documented as producing an average of 50 credentials per infection. The credential entered the distribution layer as one data point among billions: SpyCloud recaptured 5.3 billion credential pairs, 18.1 million exposed API keys and tokens, and 8.6 billion stolen session cookies from criminal underground monitoring in 2025 alone. For seven weeks, the credential sat in the distribution layer before someone acted on it. That dwell time is the systemic gap that the Developer Credential Economy exploits. Organizations that do not monitor underground markets for exposed developer credentials are operating on the assumption that the generation-to-weaponization pipeline does not exist, or that it operates too slowly to matter. Miasma demonstrates that even a seven-week window, which is long by underground market standards, is more than sufficient for weaponization. The distribution layer was further amplified on May 12, when TeamPCP published the complete Mini Shai-Hulud source code on GitHub under an MIT License with the message “Shai-Hulud: Open Sourcing The Carnage.” The release included CI cache-poisoning scripts, the OIDC token extractor, and the credential stealer with its propagation logic. This is the supply chain equivalent of publishing a working exploit framework: the tooling itself became a distribution channel, lowering the barrier to entry for any operator who wants to run a structurally identical campaign. Layer 3: Weaponization The third layer is operational use. Actors with distinct motivations acquire credentials from the distribution layer and weaponize them against specific targets. In March, the RSO team documented at least three distinct actors operating from the same credential pool : TeamPCP harvested at scale: Sapphire Sleet/UNC1069 (DPRK-nexus) operationalized stolen npm tokens for financial gain through the Axios compromise and LAPSUS$ exploited compromised Tailscale VPN credentials from the LiteLLM breach for data theft from Mercor AI. The same credential ecosystem fed all three. Miasma’s weaponization layer continues to evolve, but the trajectory across its three waves demonstrates the pattern: Wave 1 (June 1) used the stolen R