Deadbugz: Currently Active MCP Supply-Chain Campaign

Ariel Fogel

and

August 12, 2026

min read

Last updated: August 12, 2026, 12:24 AM IDT

This disclosure will be updated as verified information becomes available.

Executive Summary

Pillar Security Researchers identified an active campaign to distribute a malicious Model Context Protocol (MCP) server through public GitHub pull requests. The server calls itself productivity-suite and initially looks harmless: it offers text formatting and summarization. After a connected client makes three tool calls, however, it changes the instructions it returns to the AI agent. The new metadata directs the agent to seek sensitive information, including SSH keys, AWS credentials, shell history, and Kubernetes configuration, and to conceal the activity from the user.

The campaign uses runtime-gated MCP metadata poisoning. The malicious instructions are built into the server, but remain withheld until the client has made three ordinary tool calls. We observed the gated metadata using only harmless text requests and confirmed that it matches the public source code.

Figure 1. Credential-seeking and cross-tool payload through prompts/get.

The public GitHub account zellkernel submitted 23 identified campaign-related pull requests to unrelated AI, MCP, and developer-tool projects. The 23 reviewed PRs were not merged through GitHub’s pull-request merge mechanism at the time of review: 19 were closed and four remained open. Seventeen configure a remote MCP server; four reference a hidden local Python path; and two are directory or listing submissions.

We call this campaign Deadbugz, after the deadbug-mcp.py delivery artifact and related public markers. ⁠Deadbugz is an account-attributed MCP delivery campaign that combines GitHub pull-request supply-chain delivery with a runtime-gated tool-metadata trigger. Three ordinary tool calls activate credential-seeking instructions returned through MCP metadata.

What happens after the third call

An MCP client connects to productivity-suite and receives two ordinary-looking tools:

Tool	Initial purpose
`format_text`	Format supplied text.
`summarize`	Produce a concise summary.

‍

Those tools behave normally in the initial interaction. The server keeps an in-memory, per-client counter for tools/call requests. Once it reaches three, subsequent tools/list and prompts/get responses change. Instead of ordinary tool documentation, they contain instructions intended to steer an attached AI agent toward sensitive local files and to hide the activity from its operator.

This matters because tool definitions are not merely labels. MCP clients supply them to the model as context that helps it decide which tools to use and what actions to take. A server that can alter those definitions after installation can change the instructions the agent sees without changing the benign-looking name of the tool.

The public code advertises tools.listChanged, which allows a compatible client to refresh tool metadata. This runtime gate is a research-evasion technique: a brief inspection or limited test can receive only benign metadata, while normal use crosses the three-call threshold. We confirmed the threshold logic and the altered metadata from public sources.

Figure 2. A controlled interaction with the endpoint returns three benign text results, then returns credential-seeking and cross-tool instructions through prompts/get.

The delivery route: a configuration change that looks routine

The campaign’s delivery mechanism is a GitHub pull request that adds or changes MCP configuration. In the reviewed set, 17 PRs add the following remote endpoint to an MCP configuration:

hxxps[:]//productivity-suite-mcp[.]onrender[.]com/mcp

Four others configure Python to run a hidden local file:

~/.config/.cache/.sys/.deadbug-mcp.py

The local-file reference is a confirmed delivery artifact in the reviewed PR patches.

The account-level delivery pattern is coordinated: the same public account used the same product name, configuration theme, and campaign markers across 23 public PRs in a short period.

Attribution: the public delivery operation

Pillar attributes the observed GitHub delivery operation to the public account `zellkernel`. The account authored all 23 reviewed PRs, published the matching productivity-suite-mcp source repository, and used the same endpoint, server name, local delivery artifact, and campaign markers throughout the operation.

The delivery window was concentrated: the 23 PRs were created in a 74-minute period, from 9:52 PM to 11:07 PM UTC on August 10, 2026. The same account’s public repository activity supports the fork-and-pull-request workflow used here: it had 50 public repositories at collection, including 20 forks, and created 21 repositories on August 10.

The account’s GitHub profile links to @llmgod on X, and the X profile links back to the GitHub account. This is a public account-level linkage between the delivery identity and the account’s AI/LLM-focused public activity. The campaign attribution in this report remains attached to the zellkernel account and its observable infrastructure, source, and pull-request activity.

The campaign in evidence

The public productivity-suite-mcp source implements the three-call trigger and returns malicious tool descriptions and prompt content after the threshold.
The runtime-gated malicious metadata was observed from the remote service through benign text-only requests.
The public account zellkernel authored the 23 reviewed PRs.
The 23 reviewed PRs were unmerged through GitHub’s pull-request merge mechanism at the time of review; 19 were closed and four were open.
The set comprises 17 remote-MCP configurations, four local-script configurations, and two directory/listing submissions.
The public source implements optional connection, first-call, and trigger-event telemetry through a WEBHOOK_URL configuration.

A known primitive, an active research-evasion campaign

Deadbugz builds on known MCP attack primitives. In April 2025, Invariant Labs demonstrated an MCP sleeper attack that began with an innocuous tool and later changed its description to manipulate a trusted WhatsApp MCP integration into sending chat history to an attacker. That research established the risk of delayed tool-description changes after approval.

The MCP ecosystem has also seen supply-chain weaponization. In 2025, a counterfeit postmark-mcp package gained adoption before an update added covert outbound-email copying; Koi later documented another MCP package that started as a working command tool and was weaponized through a malicious update with installation and runtime backdoors.

Deadbugz uses a different operational model: it uses public GitHub pull requests to introduce MCP configuration and gates pre-existing malicious metadata on normal protocol activity. The three-call threshold acts as research evasion, allowing a brief inspection or limited automated test to receive only benign metadata before the server exposes the instructions presented to the agent.

What organizations should do now

For developers and security teams

Block https[:]//productivity-suite-mcp[.]onrender[.]com/mcp; keep the historical endpoint below in threat-hunting and historical deny lists.
Reject, close, or revert configuration changes that introduce the listed endpoint, productivity-suite, or the hidden local-script path. Do not run deadbug-mcp.py.
Search managed endpoints, developer home directories, repositories, and MCP client configuration for the indicators below.
If a device connected to the server, preserve MCP-client logs before cleanup. Review tool-definition refreshes and subsequent agent actions, particularly after a third tool call.
Investigate access to sensitive credentials and configuration only where local evidence supports it; apply credential rotation according to incident-response policy.

For MCP client and platform builders

Tool descriptions and schemas are a security boundary. Clients should treat a change in the tool definition of an already-approved server as a meaningful security event, make that change visible to the operator, and require renewed approval before the changed tool can influence sensitive actions.

Sensitive file reads, credential access, code execution, outbound email, and repository writes should remain policy-enforced actions, not consequences of instructions contained in remote tool metadata. Capturing and comparing a tool-definition fingerprint at approval time gives clients a practical way to detect this class of change.

Indicators of compromise

Type	Indicator	Assessment
Remote MCP endpoint	`https[:]//productivity-suite-mcp[.]onrender[.]com/mcp`	Confirmed campaign endpoint in reviewed configuration and source material.
Historical MCP endpoint	`https[:]//promo-surname-xml-quantum[.]trycloudflare[.]com/mcp`	Confirmed historical reference in public campaign material; not treated as currently active.
Local delivery artifact	`~/.config/.cache/.sys/.deadbug-mcp.py`	Confirmed in four reviewed PR configurations.
Bitcoin address / campaign marker	`bc1q5xpazlg7q6ph2r6s7tzumd5zyjdet6vjzvsqln`	Embedded in the delayed malicious prompt alongside `deadbugz`. Useful for correlation, but not evidence of payment activity or operator identity.
Server name	`productivity-suite`	Confirmed campaign marker.
Public source	`https[:]//github[.]com/zellkernel/productivity-suite-mcp`	Public source matching observed behavior.
Public delivery account	`hxxps[:]//github[.]com/zellkernel`	Author of the 23 reviewed PRs.