Slack Nebula through 1.1.0 contains a relative path vulnerability that allows a low-privileged attacker to execute code in the context of the root user via tundarwin.go or tunwindows.go. A user can also use Nebula to execute arbitrary code in the user's own context, e.g., for user-level persistence or to bypass security controls. NOTE: the vendor states that this "requires a high degree of access and other preconditions that are tough to achieve."

Impact

When using P256 certificates (which is not the default configuration), it is possible to evade a blocklist entry created against the fingerprint of a certificate by using ECDSA Signature Malleability to use a copy of the certificate with a different fingerprint.

In order for this to affect a user or network, all of the following must be true: CURVEP256 certificates are being used There are one or more entries on the blocklist The certificates for those entries are signed by a trusted CA and not expired An attacker has a copy of the private key, and corresponding certificate, for one of those blocklist entries

Patches

See attached

Workarounds

If full copies of each certificate on the existing blocklist are available, it is possible to compute their opposite-chirality signature, and then the appropriate second fingerprint to list in the blocklist.

Rotating out all CAs that have signed hosts on the blocklist will also prevent exploitation of this vulnerability.

WP SlackSync plugin through 1.8.5 for WordPress leaks a Slack Access Token in source code. An attacker can obtain a lot of information about the victim's Slack (channels, members, etc.).

Slack Nebula before 1.9.7 mishandles CIDR in some configurations and thus accepts arbitrary source IP addresses within the Nebula network.

Okay so before I start, let me tell you why I even did this. There is a lot of content going around about AI agent security that mixes real verified incidents with half-baked stats and some things that just cannot be traced back to any actual source. I went through all of it properly. Primary sources, CVE records, actual research papers. Let me tell you what I found.

Single agent attacks first, because you need this baseline

Black Hat USA 2025 — Zenity Labs did a live demonstration where they showed working exploits against Microsoft Copilot, ChatGPT, Salesforce Einstein, and Google Gemini in the same session. One demo had a crafted email triggering ChatGPT to hand over access to a connected Google Drive. Copilot Studio was leaking CRM databases. This is confirmed, sourced, happened. The only thing I could not verify was the specific "3,000 agents actively leaking" number that keeps getting quoted. The demos are real, that stat is floating without a clean source.

CVE-2025-32711, which people are calling EchoLeak — this one is exactly as bad as described. Aim Security found that receiving a single crafted email in Microsoft 365 Copilot was enough to trigger automatic data exfiltration. No clicks required. CVSS 9.3, confirmed, paper is on arXiv. This is clean and verified.

Slack AI in August 2024 — PromptArmor showed that Slack's AI assistant could be manipulated through indirect prompt injection to surface content from private channels the attacker had no access to. You put a crafted message in a public channel and Slack's own AI becomes the tool that reads private conversations. Fully verified.

The one that should genuinely worry enterprise people — a threat group compromised one chat agent integration, specifically the Drift chatbot in Salesloft, and cascaded that into Salesforce, Google Workspace, Slack, Amazon S3, and Azure environments across 700 plus organizations. One agent, one integration, 700 organizations. This is confirmed by Obsidian Security research.

Anthropic confirmed directly in November 2025 that a Chinese state-sponsored group used Claude Code to attempt infiltration of roughly 30 global targets across tech, finance, chemical manufacturing, and government. Succeeded in some cases. What made it notable was that 80 to 90 percent of the tactical operations were executed by the AI agents themselves with minimal human involvement. First documented large-scale cyberattack of that kind.

Browser Use agent, CVE-2025-47241, CVSS 9.3 — confirmed. But there is a technical correction worth noting. Some summaries describe this as prompt injection combined with URL manipulation. It is actually a URL parsing bypass where an attacker embeds a whitelisted domain in the userinfo portion of a URL. Sounds similar but if you are writing a mitigation, the difference matters.

The Adversa AI report about Amazon Q, Azure AI, OmniGPT, and ElizaOS failing across model, infrastructure, and oversight layers — I could not independently surface this report from primary sources. The broader pattern it describes is consistent with what other 2025 research shows, but do not cite that specific stat in anything formal until you have traced it to the actual document.

Why multi-agent is a completely different problem

Single agent security is at least a bounded problem. Rate limiting, input validation, output filtering — hard to do right but you know what you are dealing with.

Multi-agent changes the nature of the problem. The reason is simple and a little uncomfortable. Agents trust each other by default. When your researcher agent passes output to your writer agent, the writer treats that as a legitimate instruction. No verification, no signing, nothing. Agent A's output is literally Agent B's instruction. So if you compromise A, you get B, C, and the database automatically without touching them.

There is peer-reviewed research on this from 2025 that was not in the original material circulating. CrewAI running on GPT-4o was successfully manipulated into exfiltrating private user data in 65 percent of tested scenarios. The Magentic-One orchestrator executed arbitrary malicious code 97 percent of the time when interacting with a malicious local file. For certain combinations the success rate hit 100 percent. These attacks worked even when individual sub-agents refused to take harmful actions — the orchestrator found workarounds anyway.

The CrewAI and LangGraph situation needs some nuance

Here is where the framing in most posts gets a bit unfair. Palo Alto Networks Unit 42 published research in May 2025 that stated explicitly that CrewAI and AutoGen frameworks are not inherently vulnerable. The risks come from misconfigurations and insecure design patterns in how developers build with them, not from the frameworks themselves.

That said — the default setups leave basically every security decision to the developer with very little enforcement. The shared .env approach for credentials is genuinely how most people start and it is genuinely a problem if you carry it into production. CrewAI does have task-level tool scoping where you can restrict each agent to specific tools, but it is not enforced by default and most tutorials do not cover it.

Also, and this was not in the original material anywhere — Noma Labs found a CVSS 9.2 vulnerability in CrewAI's own platform in September 2025. An exposed internal GitHub token through improper exception handling. CrewAI patched it within five hours of disclosure, which is honestly a good response. But it is worth knowing about.

The honest question

If you are running multi-agent systems in production right now, the thing worth asking yourself is whether your security layer is something you actually built, or whether it is mostly a shared credentials file and some hope. The 2025 incident list is a fairly detailed description of what the failure mode looks like when the answer is the second one.

The security community is catching up — OWASP now explicitly covers multi-agent attack patterns, frameworks are adding scoping mechanisms. The problem is understood. Most production deployments are just running ahead of those protections right now.

Also seen at https://lists.openssf-vuln.org/g/siren/message/7

----- Forwarded message from "Christopher Robinson via lists.openssf-vuln.org" <christopher.robinson=linuxfoundation.org () lists openssf-vuln org> -----

Subject: [siren] Severity: High – Potential Malicious Campaign Underway Targeting Open Source Developers via Slack To: siren () lists openssf-vuln org From: "Christopher Robinson via lists.openssf-vuln.org" <christopher.robinson=linuxfoundation.org () lists openssf-vuln org> Date: Tue, 07 Apr 2026 18:10:04 -0700 Mailing-List: list siren () lists openssf-vuln org; contact siren+owner () lists openssf-vuln org Reply-To: siren () lists openssf-vuln org,christopher.robinson () linuxfoundation org

Date: April 7, 2026 Severity: High – Potential Malicious Campaign Underway Targeting Open Source Developers via Slack

Overview # The community has received reports of an active social engineering campaign targeting open source developers via Slack (including ToDoGroup and related communities). In the reported incident, an attacker impersonated a well-known Linux Foundation community leader and attempted to lure the victim into following a malicious link: https://sites.google.com/view/workspace-business/join << The link mimics a legitimate Google Workspace flow but redirects users to a fraudulent authentication process. Victims are prompted to enter credentials and then instructed to install a “Google certificate,” which is in fact malicious. This activity represents a multi-stage attack involving impersonation, phishing, certificate spoofing, and malware delivery.

Observed Attack Behavior # - Impersonation: Attacker poses as a trusted community leader in Slack - Phishing Link: Uses a lookalike domain (sites.google.com/...) instead of legitimate Google Workspace domains - Credential Harvesting: Requests email and verification code - Certificate Spoofing: Prompts user to install a fake root certificate impersonating Google

Malware Delivery # - macOS: Script downloads and executes a binary (gapi) from a remote IP (2.26.97.61) - Windows: Prompts installation of a malicious certificate via browser trust dialog

Installing the certificate enables interception of encrypted traffic and credential theft. Executing the binary may result in full system compromise.

What You Should Do # Please take the following precautions immediately: 1. Verify Identities - Do not trust messages based solely on name or profile. - Confirm unusual requests through a separate, known communication channel.

2. Avoid Suspicious Links - Do not click links that look similar to, but are not, official domains. - When in doubt, navigate manually to known trusted sites.

3. Never Install Certificates from Links - Legitimate services do not require users to manually install root certificates. - Treat any such request as malicious unless explicitly verified by your organization.

4. Do Not Run Untrusted Software - Do not execute scripts, installers, or binaries received via Slack or unknown websites. - Avoid commands that download and execute code (e.g., curl | bash).

5. Treat Unexpected Security Prompts as Suspicious - Messages about “expired certificates” or urgent updates should be independently verified

If You May Have Been Affected # If you interacted with the link, installed a certificate, or executed any files: - Disconnect from the network immediately - Remove any newly installed certificates - Run endpoint security scans - Rotate all credentials (GitHub, SSH keys, cloud access, etc.) - Revoke active sessions and tokens - Report the incident to your security team or organization

Community Recommendations # - Enable multi-factor authentication (MFA) on all developer and collaboration accounts - Be cautious of unsolicited outreach, even from familiar names - Establish team practices for verifying sensitive requests - Share this advisory with your teams and contributors

Key Takeaway # This campaign highlights a growing trend: attackers are targeting developer workflows and trust relationships, not just software vulnerabilities. Staying vigilant and verifying before acting are critical to protecting both individual environments and the broader open source ecosystem.

If you have observed similar activity or have additional indicators to share, please report them to your security team or appropriate community channels.

Stay safe,

Christopher "CRob" Robinson OpenSSF | The Linux Foundation Chief Technology Officer | Chief Security Architect

– TLP:CLEAR

----- End forwarded message -----

On Wed, 8 Apr 2026, Solar Designer wrote: Also seen at https://lists.openssf-vuln.org/g/siren/message/7

Subject: [siren] Severity: High – Potential Malicious Campaign Underway Targeting Open Source Developers via Slack Overview # The community has received reports of an active social engineering campaign targeting open source developers via Slack (including ToDoGroup and related communities). In the reported incident, an attacker impersonated a well-known Linux Foundation community leader and attempted to lure the victim into following a malicious link: etc

As listed in this and other recent OSS emails, platforms exploited included Slack, Teams, Google, etc

The method is to create a convincing fake account on the centralized platform.

Is this a weakness that is aggravated by centralized platforms?

Federated protocols like SMTP, Matrix, XMPP, etc would require a deceptive domain name (like the legendary lBM.com of Arial font fame) pubkey with icons and earlier messages that look like a party being impersonated.)

Is this evidence for a general recommendation against centralized platforms for open source development? More to the surprise of my preconceived ideas - are fully decentralized protocols subject to similar social engineering? There is not much difference between a Facebook internal account number and a pubkey for most end users.

The issue with federated protocols is that any trusted CA can forge any TLS cert - a "serial reliability" problem.