Last Week In AppSec for 08. July 2025 - Checkmarx

New IDC report: How Security Can Catch Up With AI-generated Code 

Get the Report

Last Week In AppSec for 08. July 2025

10 min.

July 8, 2025

A street-art style graphic depicting a newspaper with a SECURITY headline

 

Here are some interesting items from last week’s Application Security news that you might have missed:

  • Anthropic, maker of the Claude Opus LLM, experienced a 0-click data leakage flaw in their now-deprecated Slack MCP server. Researcher wunderwuzzi identified and disclosed this issue; but because Anthropic has archived the server, this issue is unlikely to be patched despite the server being decently popular.
  • IDEs like Visual Studio Code (aka VSCode), IntelliJ IDEA, and Cursor (an AI-driven IDE) have a defect in how they present a “verified” symbol for extensions. Testing by Ox Research shows that this defect allows an adversary to create an extension package (e.g. a VSIX file) that the IDE will claim is verified, even though it is a malicious or otherwise not legitimate package. Essentially, an attacker can spoof verification under some circumstances, putting developers at risk when they install extensions from GitHub or other public sources (but, seemlingly, not the official Marketplace).
  • A vulnerability in the popular Next.js JavaScript framework (CVE-2025-49826) can cause a Denial of Service. Users of 15.x versions prior to 15.1.8 who are using CDNs or similar caching straegies along with two Next.js features (ISR and SSR) may be affected. This combination can result in HTTP 204 (No Content) responses being cached in a way that causes these No Content responses to be delivered even for valid pages, resulting in legitimate users being unable to access desired information. Vercel, maintainer of Next.js, repaired and disclosed the issue based on reports from researchers zhero; and inzo
Don’t miss out on news!
visual

Anthropic Slack MCP has 0-click data leakage

Anthropic, maker of the Claude Opus LLM that has gained some popularity among developers, experienced a 0-click data leakage flaw in their now-deprecated Slack MCP server. Researcher wunderwuzzi identified and disclosed this issue; but because Anthropic has archived the server, this issue is unlikely to be patched despite the server being decently popular.

An MCP Server is a component that’s part of a system that creates an AI agent which connects AI models (like Claude Opus) with context by connecting your internal tools and data with a model in a standard way. The Slack MCP server allows organizations to connect the Claude system with the organization’s Slack channels, providing context and input from Slack messages and a path to interacting with Claude directly in Slack. Since Slack conversations often contain fairly sensitive information and discussions, a data leak could potentiall cause some serious harm, even if it’s constrained to other users in an organization. Imagine a case where discussions about a potential acquisition end up leaking to the entire company!

Additionally, tools like Claude Code and the Slack MCP server can share information in some situations; in fact, this case is what led to discovery of this data-leakage issue. Consider the example used by the reporting researcher:

  1. A malicious actor sends a code file to a developer, perhaps by posting it on an information-sharing site; the developer gets and examines the code with Claude Code
  2. The malicious code file contains a prompt injection for claude. The attacker now has some control of the agent through this malicious prompt
  3. The malicious prompt instructs Claude Code to read a sensitive file from the developer’s desktop, one that contains a secret like an API key
  4. The agent then posts a link to an attacker-controled site to Slack via the Slack MCP Server; the link contains the secret. Slack happily expands the URL, which causes the data to be sent to the attacker

This results in leakage of sensitive data as a result of a developer just doing their day-to-day work, and no one even needs to click on the sketchy-looking link.

The original report contains a step-by-step walkthrough both with text + screenshots and as a YouTube video, as well as information about how to mitigate (not repair!) this issue by adjusting the Slack extension’s configuration.

Malicious IDE extensions can spoof being from verified publishers

IDEs like Visual Studio Code (aka VSCode), IntelliJ IDEA, and Cursor (an AI-driven IDE) have a defect in how they present a “verified” symbol for extensions. Testing by Ox Research shows that this defect allows an adversary to create an extension package (e.g. a VSIX file) that the IDE will claim is verified, even though it is a malicious or otherwise not legitimate package. Essentially, an attacker can spoof verification under some circumstances, putting developers at risk when they install extensions from GitHub or other public sources (but, seemlingly, not the official Marketplace due to a requirement to sign the entire extension before it is published).

The root of this issue appears to be a design flaw in how these IDEs check whether a extension is verified when that extension is being installed outside of marketplaces (such as from GitHub or a local file). A verification message is sent using metadata in the extension package file’s configuration; the verification server responds based on a database match. However, there is little or no integrity checking in place – that is, the IDE does not check to see if the actual content of the extension is known or trusted. This means that copying the metadata from a verified extension and re-using it for a malicious extension will make the IDE show the malicious extension as coming from a verified and trusted provider.

Image from Ox Research showing a malicious package being reported as valid and from microsoft.com

This poses an interesting challenge for security teams. IDE extensions are an important and powerful part of modern developer workflows. While it’s strongly encouraged for developers to only install extensions from the official marketplace (which has some additional saftey features), such policies tend to be very unpopular with developers. Reports like this, though, with clear examples, can help you make the case for tighter control over this aspect of your software supply chain.

Next.js Denial of Service risk

A vulnerability in the popular Next.js JavaScript framework (CVE-2025-49826) can cause a Denial of Service. Users of 15.x versions prior to 15.1.8 who are using CDNs or similar caching straegies along with two Next.js features (ISR and SSR) may be affected. This combination can result in HTTP 204 (No Content) responses being cached in a way that causes these No Content responses to be delivered even for valid pages, resulting in legitimate users being unable to access desired information. Vercel, maintainer of Next.js, repaired and disclosed the issue based on reports from researchers zhero; and inzo

This issue results from using two Next.js capabilities together. ISR (Incremental Static Regeneration) is a feature that allows Next.js applications to rebuild just specific content when it is updated, rather than regenerating a whole site. This allows applications to get the benefits of cached responses for rarely-updated content, while avoiding the performance hit of regenerating a large site to make those updates. SSR (Server Side Rendering) is a feature that asks the server side of an application to render page content instead of asking client-side javascript components to do it. This is often done for SEO reasons (so search engines can see the content more readily), but can also have performance benefits for users.

When those two features – ISR and SSR – are combined in the flawed versions of Next.js, a code path could result in an HTTP 204 code being returned temporarily for some static content when it shouldn’t be. HTTP 204 is usually used on operations like UPDATE where the application wants to inform the client that a request was successful but there’s no content for the client to process. Since many large-scale web applications cache static content requests using a Content Delivery Network (CDN), these incorrect HTTP 204 responses can be cached, leading legitimate users to get empty pages or similar when using an affected site.

HTTP 204 responses contain no content body (image from http.cat)

It’s a bit of an unusual combination of circumstances, and Vercel identified a race condition that could be part of the root cause. Fortunately, thanks to a clear and timely repair and disclosure, affected applications should be able to simply update to 15.1.8 or newer to repair this issue.

Read More

Want to learn more? Here are some additional pieces for you to read.