Last Week in AppSec for 12. Feb 2026

An overview

Two themes stood out last week in AppSec: developers as a direct target (via package registries and IDE tooling), and trust boundaries shifting (AI assistants and “skills” ecosystems creating new places where untrusted content becomes instructions).

• Malicious dYdX packages hit npm + PyPI and targeted developer/ops wallet credentials. Teams that pulled the malicious packages into build/automation flows or installed them locally are directly affected. But AppSec and related teams should understand this type of attack even if they weren’t impacted this time.

• BeyondTrust pre-auth RCE (OS command injection) in Remote Support / Privileged Remote Access. This is a “patch now” remote compromise class issue for orgs exposing these services (especially self-hosted).

• “Memory poisoning” and recommendation poisoning for AI assistants. Attackers who can inject content into an assistant’s long-term memory can steer future actions and recommendations—this is a governance + product-security problem, not just “prompt injection.”

• Malicious “skills” / agent add-ons: prompt-injection rates and outright malicious entries. The risk isn’t only bad answers—skills can become a bridge to credentials, tools, and execution if your agent environment is permissive.

• Docker Desktop for Windows local privilege escalation (incorrect permissions). Local privesc issues are frequently dismissed—don’t. On developer workstations they’re often the missing step after phishing/infostealers.

Get updates like this one in your Inbox

Subscribe to Checkmarx Zero

Never Miss Checkmarx
Zero Research Updates. Subscribe today!

By submitting my information to Checkmarx, I hereby consent to the terms and conditions found in the Checkmarx Privacy Policy and to the processing of my personal data as described therein. By clicking submit above, you consent to allow Checkmarx to store and process the personal information submitted above to provide you the content requested.

Featured item: Malicious dYdX packages show why registry trust is not enough

Socket’s Threat Research Team reported a supply-chain attack that published malicious packages across both npm and PyPI targeting the dYdX system for trading cryptocurrency and derivatives. While organizations not engaging with dYdX aren’t at risk, this targeted attack is another example of how important it is for organizations to answer a very specific question: how quickly can your organization detect that a normal dependency update introduced malicious code to your systems?

What the issue is

The attacker followed a common compromise pattern to compromise dYdX client libraries across npm and PyPI simultaneously:

• Upload a new package update to a legitimate package using compromised credentials of a legitimate maintainer.

• Include a payload that attempts to harvest secrets (mainly wallet credentials in this case) and exfiltrate them

• Those secrets are then usable by the attacker whenever they wish.

Other similar attacks have been known to seek out some combination of CI tokens, deployment keys, cloud service credentials, signing keys, and production credentials; however, in this case the attackers focused on seed phrases and device fingerprints that enable access to cryptocurrency wallets.

The package uploaded to PyPI also included a Remote Access Trojan (RAT) that gives attackers on-demand access to the developer’s workstation (or build system) where the package is downloaded.

We don’t know the attackers’ motives for sure, but it’s good bet they targeted these clients because they’re involved in accessing between $200 million and $540 million worth of transactions daily. Financial gain is a common and compelling motivator for attackers to make significant effort investments.

Why this matters to AppSec and developer teams

If a malicious dependency runs during install, build, or test, you are no longer in “vulnerability management” mode—you’re in incident response mode. Unlike a vulnerability, this isn’t something you can just shrug off. Risks of this type of attack include:

• credential reuse into CI/CD and cloud
• tampering with build outputs
• persistence via tokens, SSH keys, and org access

What to do (minimally disruptive, high impact)

1. Triage exposure fast

   • Identify any developer machines and CI runners that installed the malicious packages (dependency lock seeps into places you don’t expect). Checkmarx SCA’s Global Inventory can assist in this.

   • Assume secrets present on those hosts may be exposed until proven otherwise.

2. Rotate secrets from a known-clean environment

   • Prioritize: repo/CI tokens, cloud credentials, package publishing tokens, signing keys, and any wallet/private-key material used by automation.

3. Add guardrails that scale

   • Enforce allow-lists / scoped registries for sensitive environments (CI runners, release pipelines).

   • Block lifecycle scripts by default where feasible (or run them only in hardened sandboxes).

   • Use SCA with an MPP capability, not just a CVE detector

   • Use a proactive defense tool like Checkmarx MPIAPI to block known malicious packages

For more detail (including IOCs and package identifiers), use Socket’s original report

BeyondTrust pre-auth RCE is a “patch now” for remote access infrastructure

BeyondTrust disclosed a critical OS command injection leading to remote code execution affecting Remote Support and certain versions of Privileged Remote Access. The reported severity and pre-auth nature make this an urgent item for teams with internet-exposed instances.

Scope: users of affected BeyondTrust RS/PRA versions, particularly self-hosted deployments that are not automatically updated.

Impact: unauthenticated remote attackers may run commands and compromise the system.

Action: patch immediately; validate whether the instance was exposed, and review logs for anomalous process execution around the vulnerable service.

Source for more information: TechRadar (referencing the vendor advisory).

Memory poisoning is becoming a real control boundary problem for AI assistants

Microsoft described “AI Memory Poisoning” as injecting unauthorized instructions or “facts” into an assistant’s memory, which then influences future responses and actions.

Scope: any workflow where assistants store durable preferences, “remembered” instructions, or long-lived notes across sessions.

Impact: subtle and persistent steering—recommendations, policy decisions, and tool-use can drift in attacker-chosen directions without an obvious one-time prompt injection event.

Action: treat memory as a governed datastore:

• limit what can be written to memory (and by whom/what content sources)
• require user confirmation for memory writes in higher-risk contexts
• log and review memory changes like you would configuration changes

Source for more information: Microsoft Security blog.

Malicious “skills” ecosystems are turning into an AppSec problem (not just AI safety)

Snyk reported large-scale issues in agent “skills” ecosystems (including prompt injection prevalence and identification of malicious entries), reinforcing a pattern: once an agent can call tools, a poisoned skill can become an execution path.

Scope: teams adopting agent platforms that load third-party skills/connectors, especially where skills can reach CI, repos, ticketing, or cloud APIs.

Impact: time-shifted prompt injection, logic-bomb behavior, and tool misuse—often without a traditional exploit.

Action: apply supply-chain rules to skills:

• pin versions, require provenance, and review permissions
• isolate tool credentials per-skill (least privilege)
• block network egress from skill runtimes unless explicitly required

Source for more information: The Hacker News

Docker Desktop for Windows local privesc: don’t dismiss workstation privilege bugs

Trend Micro’s ZDI published an advisory for Docker Desktop for Windows involving incorrect permission assignment leading to privilege escalation.

Scope: Windows developer endpoints running affected Docker Desktop configurations.

Impact: local privilege escalation can be the step that turns “developer got phished” into “attacker owns the workstation and steals keys/tokens/signing material.”

Action: patch Docker Desktop promptly on developer fleets, and ensure endpoint hardening policies treat developer tooling as high-value software.

Source for more information: ZDI advisory ZDI-26-068.