CVE-2026-89039: k6 MCP could read files outside the project

CVE-2026-89039, published on 5 October, describes file reads through k6 MCP’s convert_playwright_script prompt. A caller could obtain files readable by the process account outside the project. The description covers releases from 0.3.0, with earlier disclosure on 10 September.

Breachroad recommends assessing access to MCP alongside process permissions. Establish who can invoke integration functions and which files its account can see. Build this map before considering the deployment confined to one project.

Connect the code fix to the actual deployment

The project merged change #191 on 5 October. It removes automatic interpretation of ordinary text as a file path and strengthens file-access controls. Merging a fix does not establish that a deployed image or executable already includes it.

In the fixed implementation, file references go through os.Root, anchored to the working directory. File extensions and symlink targets are checked; reads are also blocked when the working directory is the user’s home directory. We do not assign a safe release number without evidence: identify the package containing this change and verify its deployment.

Who should perform the assessment

Teams using k6 MCP should review assistant configuration, local processes, container images and any shared service. The project documentation describes stdio and HTTP transports. For remote deployments, it notes the absence of built-in authentication and the need to protect access.

Breachroad recommends defining the boundary through the process account, visible directories and permitted clients. Calling an integration a performance-testing tool does not automatically limit the files its process can read. Record which secrets are within reach and who owns that configuration.

Actions for the team

1. Establish the running state. Identify the deployed package or image, working directory and process account. Do not stop at the configuration saved in a repository.
2. Restrict access during remediation. If the fix has not been verified, disable the exposed function or integration. For a shared service, establish who can invoke it.
3. Reduce file visibility. Expose only the necessary project. Remove unnecessary directory mounts and access to the user’s private credentials.
4. Verify the fixed behaviour. Use harmless reference files in an isolated environment. Confirm denial of reads outside the project, including through a symlink, alongside correct handling of an allowed script.
5. Assess earlier use. If evidence suggests a secret was read, invoke the incident process, establish who received the response and plan credential replacement. Keep its contents out of further tickets.

This is Breachroad’s proposed procedure. Perform access checks without real production keys or tokens. Reports should distinguish possible access from confirmed disclosure.

Training scenario: an integration running like the editor

In our fictional scenario, a developer adds MCP to an editor. The process sees broad areas of the user’s directories even though the task needs only test scripts. The team must identify who owns the permissions and how to establish that an outside file cannot appear in a response.

A good answer covers process scope, verification of the fix and storage of results. Asking the assistant to avoid secrets does not replace technical access controls. The exercise can use a configuration description without reproducing an attack.

Cybersecurity and secure AI training for organisations helps teams define integration approval and data-disclosure response procedures. Our MCP security guide provides the foundations.

Sources and Breachroad conclusions

The CVE record describes the flaw; the repository and linked implementation confirm the code fix. Project documentation covers transport and remote deployment protection. The action plan and fictional example are Breachroad recommendations. These sources alone do not establish an incident at a particular organisation.