AI coding assistants are becoming a hacker’s back door, right inside the developer’s IDE

Security teams spent the last decade turning laptops into locked-down fortresses, EDR agents everywhere, hardened configs, tight inventories, nonstop malware hunting. Now researchers say attackers are slipping in through a door many companies barely monitor: the developer’s coding environment.

At RSA Conference 2026 in San Francisco, Check Point Software’s chief technologist Oded Vanunu warned that AI-powered coding assistants, and the plugins, “hooks,” and automation they rely on, can be abused to run commands and move data in ways that look legitimate to endpoint defenses. Several high-severity flaws discussed at the conference have since been patched by vendors, but the bigger takeaway remains: the IDE is no longer just a text editor. It’s an orchestrator with real power on a machine that often holds the keys to the kingdom.

The new weak spot: “legit” developer workflows that don’t look like malware

The core shift is simple. Attackers don’t always need to drop a sketchy executable like “malware.exe” to get code running on a developer’s machine. Instead, they can target configuration files, plugin systems, automation scripts, and AI prompts, mechanisms that development tools are designed to trust.

That creates a nightmare for security operations centers. When a command is launched by an approved dev tool inside a normal workflow, it can blend into the noise. Even strong EDR products are tuned to spot suspicious artifacts and behavior patterns; “expected” scripts running in a developer context can look routine, especially in fast-moving teams.

Check Point’s warning at RSAC: the IDE is now a prime attack surface

Vanunu framed it as a new era of client-side attacks driven by “agentic” AI tools, assistants that don’t just suggest code, but can modify files, interact with repositories, pull dependencies, and trigger actions on the local system.

His point wasn’t that one brand is uniquely risky. Tools from major players, Anthropic (Claude Code), OpenAI (Codex), and Google (Gemini), share a common direction: deeper integration with plugins and connectors that expand what the assistant can do. The more power you add, plugin marketplaces, MCP servers, shell hooks, the more you expand the attack surface.

This also reinforces a growing argument in application security: scanning after the commit isn’t enough when AI can compress the time between suggestion and deployment to minutes. Some vendors, including Checkmarx, are pushing security controls directly into the IDE, where risky changes are introduced, while acknowledging that concentrating power in the IDE also concentrates risk if governance is weak.

A “swap attack” in Cursor shows how approvals can be gamed

One of the most concrete examples highlighted wasCVE-2025-54136, a high-severity remote code execution (RCE) issue in Cursor, an AI coding platform. The vulnerability centered on how a developer’s approval was handled for a command coming from an MCP server.

Researchers described a “swap attack” scenario: an attacker first submits a harmless command that’s likely to get approved. After the user grants permission, the attacker updates or replaces the plugin with a malicious payload, without forcing the developer to repeat the same level of scrutiny.

The lesson is a classic integrity problem. If approvals are tied to a plugin name or a broad “intent,” rather than a content hash or similarly strong binding to what was actually reviewed, the final executed code can diverge from what the user thought they approved.

That’s especially dangerous on developer machines, which often have elevated privileges and access to sensitive assets, API tokens, signing credentials, build systems, and sometimes cloud keys. Even a good EDR may struggle if the activity rides along inside a trusted toolchain and looks like normal automation.

Claude Code hooks and a trust dialog that can arrive too late

Another high-severity issue discussed wasCVE-2025-59536inClaude Code. Researchers said an attacker could trigger execution of malicious code embedded in a projectbeforethe user accepted the tool’s “startup trust dialog”, the prompt meant to act as a safety gate.

The vector involvedClaude Code Hooks, user-defined shell commands designed to run automatically. In many dev environments, hooks are a convenience feature, formatting, tests, code generation, repetitive tasks. But if a project includes booby-trapped hooks, or if an assistant can be manipulated into activating them, the resulting execution can look like standard developer automation.

Check Point’s broader point about EDR applies here: when execution happens through expected scripts in a developer context, defenders can face overwhelming background noise. Teams often respond by loosening rules to keep developers productive, creating blind spots attackers can exploit.

Prompt injection and supply-chain risk: the blast radius can extend to customers

AI coding assistants don’t operate in a vacuum. They ingest context from README files, issue trackers, comments, snippets pasted from the web, and dependency documentation. That’s whereprompt injectionbecomes practical: text inside a project, or inside a dependency, can steer the assistant to ignore rules, change priorities, or recommend risky actions.

Then there’s the supply-chain problem. Even if the vulnerabilities discussed at RSAC haven’t triggered a headline-grabbing mass compromise, they map cleanly onto how modern software spreads: shared libraries, copied patterns, reused pipelines. A compromise in a widely used tool or workflow can ripple downstream to many organizations.

Adoption is already near-universal, while oversight lags. According to Black Duck,95%of organizations now use AI tools in software development.76%say they review AI-generated code for security risk, but only24%conduct full evaluations that also cover quality, licensing, and intellectual property. That gap isn’t just technical. It’s organizational: companies are industrializing output faster than they’re industrializing guardrails.

What defenders are pushing: real-time controls inside the IDE, not just after the fact

Endpoint security isn’t going away, but vendors argue it has to adapt. Palo Alto Networks has promoted AI-assisted endpoint defenses, next-gen antivirus and EDR enhanced with behavioral analytics, to spot weak signals and suspicious chains of events faster, sometimes automatically.

But the key question is where you’re watching. If the attack starts inside the IDE, waiting for post-commit checks or CI/CD scans can mean the risky change has already spread across branches, builds, and environments. Checkmarx and others are pushing protections “at the moment risk is introduced,” including monitoring plugin activity, analyzing AI suggestions, and intercepting suspicious changes before they harden into production code.

In practice, that can mean integrity checks for plugins, tighter authorization policies for MCP servers, alerts when an assistant attempts to run shell commands, and better correlation between IDE telemetry and endpoint signals. The bigger implication for enterprises is uncomfortable but clear: if AI assistants are allowed to act like operators on developer machines, organizations need to govern them like operators, not like autocomplete.