Notifications
Clear all
Topic starter
06/06/2026 1:58 am
TL;DR: A malicious backdoor in the postmark-mcp npm package, downloaded about 1,500 times per week, BCCed every outgoing email to an external address and exposed invoices, password resets, and internal correspondence, according to Oasis Security. The breach shows that trusted automation can become a data-exfiltration path when MCP tools sit outside normal inventory and approval controls.
NHIMG editorial — based on content published by Oasis Security: Lessons from the MCP Breach and Shadow AI exposure
By the numbers:
- A malicious backdoor in an npm package called postmark-mcp was downloaded roughly 1,500 times per week.
- The attack affected version 1.0.16 after earlier versions had already earned trust.
Questions worth separating out
Q: What breaks when an MCP tool is compromised inside an automation workflow?
A: A compromised MCP tool can still appear functional while duplicating or rerouting sensitive data through legitimate permissions.
Q: Why do shadow AI tools complicate IAM governance?
A: Shadow AI tools complicate IAM because they can hold real privileges without appearing in normal inventory or review processes.
Q: How can security teams reduce exfiltration risk in MCP-enabled workflows?
A: Security teams should split high-risk actions, log all delegated tool use, and require approval for integrations that can move sensitive content.
Practitioner guidance
- Inventory every MCP endpoint and AI tool path Map each MCP server, package, and automation workflow that can send mail, query data, or call APIs.
- Restrict outbound content privileges by default Separate message composition from message delivery so a compromised tool cannot silently duplicate sensitive content.
- Review package updates for privileged automation paths Require release-level checks before new versions of MCP libraries enter unattended workflows.
What's in the full analysis
Oasis Security's full blog covers the operational detail this post intentionally leaves for the source:
- How the postmark-mcp package was identified and how the malicious version changed behaviour
- What Oasis says its AI Endpoint Discovery can inventory across endpoints and automation paths
- How reputation intelligence is used to flag risky MCP servers before damage spreads
- The remediation context for identifying owners, endpoints, and affected workflows
👉 Read Oasis Security's analysis of the MCP breach and shadow AI exposure →
MCP breach shadow AI lessons and the governance gap teams miss?
Explore further
06/06/2026 3:22 am
Shadow AI becomes an identity governance problem the moment a tool can act with delegated privileges outside inventory. The breach shows that discovery is not a housekeeping task, it is the boundary that tells IAM whether an automation path exists at all. When an MCP server can send emails, query data, or invoke APIs without being catalogued, governance has already failed. Practitioners should treat invisible MCP tools as unmanaged identities with unresolved ownership.
A few things that frame the scale:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: What should organisations do when an AI automation package changes behaviour?
A: Organisations should suspend trust in the changed package until the new behaviour is reviewed, the owner is confirmed, and the connected workflows are revalidated. Any package that can influence email, data, or API access needs the same lifecycle discipline as other privileged non-human identities.
👉 Read our full editorial: Shadow AI in the MCP breach exposed trust in automated email workflows
