Privilege Abuse

This is an academic arXiv paper proposing a formal authorization model for AI agents that change over time (learning skills, delegating, gaining tools), addressing when a user's original permission grant should still be considered valid. It is a defensive/theoretical contribution, not a description of an active exploit or vulnerability in a deployed system, so severity is low. It is nonetheless relevant background for understanding privilege-abuse risks in evolving agentic systems.

Updated Jul 28, 2026

SiYuan before v3.7.2 exposes 31 MCP tools via the /mcp kernel endpoint with only a superficial auth check that fails to enforce admin or role restrictions. When the Publish server runs in anonymous mode, a remote unauthenticated attacker can reach this endpoint, steal plaintext secrets from the config file, and write a malicious plugin that achieves code execution on the victim's desktop app at next launch. This is a critical, fully remotely exploitable vulnerability enabling complete administrator takeover.

Updated Jul 25, 2026 · CVSS 10

A flaw in the AWS API MCP Server causes it to silently disable its user-configured security policy enforcement if initialization of that policy fails at startup, rather than failing closed. This allows AWS API calls that should have been denied or gated to execute unrestricted for the life of the process, effectively granting the full scope of the underlying IAM credentials.

Updated Jul 23, 2026 · CVSS 7

AgentGPT versions up to 1.0.0 fail to verify ownership of an agent run before attaching a task to it, letting any authenticated user who guesses or obtains another user's run_id inject tasks into that run. This can corrupt the victim's task history and exhaust their per-run task budget, indirectly driving up their LLM usage costs. It is a classic insecure direct object reference / broken object-level authorization bug rather than a novel agentic attack technique.

Updated Jul 23, 2026 · CVSS 4.2

A validation/runtime mismatch in n8n's workflow automation platform lets an authenticated user without the `externalSecret:list` permission smuggle external secret references into credential fields that bypass static checks but still resolve at execution time. This allows unauthorized users to indirectly exfiltrate secret values they should not have access to, undermining the platform's Advanced Permissions model. Severity is moderate since it requires authenticated access with credential-editing rights and a specific configuration (external secrets provider plus Advanced Permissions enabled).

Updated Jul 23, 2026

A vulnerability in n8n allows authenticated users with only project editor access to read plaintext external secrets by referencing them directly in node expressions, bypassing the intended secrets access permission model. This affects instances that have the external secrets feature configured, potentially exposing sensitive credentials to users who should not have access to them. The issue has been patched in n8n 2.27.4 and 2.28.1.

Updated Jul 23, 2026

A logic flaw in n8n's workflow automation platform allows an authenticated user to craft a request that associates their newly created workflow with a folder belonging to a different, unauthorized project. The workflow itself stays private to the attacker's project and no cross-project data is exposed, limiting the impact to a database-level integrity issue in folder structure. This is a traditional web application IDOR/authorization bug rather than an AI-agent-specific exploit, though n8n is increasingly used to orchestrate AI agent workflows.

Updated Jul 23, 2026

n8n's GraphQL node failed to enforce the 'Allowed HTTP Request Domains' restriction that is applied to HTTP-based credentials, unlike its HTTP Request node counterpart. An authenticated user with workflow editing rights could exploit this gap to point the GraphQL node at an attacker-controlled server and exfiltrate credentials that were supposed to be domain-restricted. This is a moderate-severity authorization bypass affecting multi-tenant or shared-credential n8n deployments, fixed in recent releases.

Updated Jul 23, 2026

LiteLLM's /health/test_connection endpoint could be used by a privileged proxy administrator or authorized caller to read arbitrary local files by supplying an oidc/file/ reference in litellm_params. Exploitation requires existing privileged access to the proxy's model-testing functionality, so the practical impact is limited to a defense-in-depth weakness rather than a cross-tenant or unauthenticated bypass. The issue is fixed in version 1.83.10-stable.

Updated Jul 23, 2026

This advisory is a withdrawn duplicate of GHSA-x5vx-c2c8-m3w9, describing a real privilege escalation flaw in n8n's AI Agents feature. A user with only Project Viewer permissions could exploit a missing authorization check in the node-execution tool by chatting with an AI agent, causing it to execute arbitrary nodes and expose credential secrets they should not have access to.

Updated Jul 22, 2026

This advisory is a withdrawn duplicate of GHSA-9r8p-h6cc-6qhm, describing an n8n bug where the full Google Service Account PEM private key was mistakenly written into the JWT header's 'kid' field instead of a key identifier. Since JWT headers are only Base64-encoded (not encrypted), anything that logs or inspects the token could recover the private key, allowing impersonation of the associated Google Cloud service account. Impact is limited to n8n instances configured with Google Service Account credentials, and the issue is fixed in versions 1.123.64, 2.29.8, and 2.30.1.

Updated Jul 22, 2026

n8n's OAuth 2.1 consent flow for MCP Server Trigger workflows fails to verify that the requesting user actually owns or has access to the workflow they are authorizing. A low-privileged member-level user can register an OAuth client, self-approve consent for another user's workflow, and obtain a valid token that runs the victim's workflow using the victim's stored credentials. This breaks project/user isolation and lets an attacker read outputs and manipulate tool inputs of an MCP agent tool they should never have access to.

Updated Jul 22, 2026

A vulnerability in n8n's AI Agents feature allows a low-privileged 'Project Viewer' user to escalate privileges by simply chatting with an agent that has node tools enabled. Missing authorization checks on the node-execution tool let the attacker run arbitrary workflow nodes and access stored credential secrets they should not have access to.

Updated Jul 22, 2026

This is an academic survey paper (arXiv cs.CR) analyzing how 21 proposals and 5 commercial AI agent products handle user-level permissions, rather than a report of an active vulnerability or exploit. It highlights that most agentic systems apply uniform, product-level security policies instead of customizable per-user permissions, and identifies gaps in interface design, policy derivation, and runtime enforcement. No specific exploit, CVE, or actively exploited flaw is described; this is foundational research useful for informing future defenses.

Updated Jul 21, 2026

NextCRM's MCP server exposes product catalog management tools (create, update, archive, delete) without enforcing the same role-based restrictions applied to the normal web application. Any authenticated low-privileged user who can obtain an MCP Bearer token can tamper with the shared CRM product catalog, an action normally reserved for managers and admins. This is a broken access control flaw surfaced through an agent-facing tool interface, not a novel AI-specific attack.

Updated Jul 21, 2026 · CVSS 7.1

AgenticMail's task API let any authenticated low-privileged agent enumerate and hijack tasks belonging to other agents by guessing/looking up their names and task IDs. This breaks the intended per-agent task isolation, allowing one agent to claim, complete, or fail work assigned to another. The vendor fixed this in version 0.9.64.

Updated Jul 21, 2026

IBM Langflow versions 1.0.0 through 1.10.0 contain a critical vulnerability allowing any authenticated user to escalate privileges to superuser by directly manipulating the underlying database. This grants attackers full control over the Langflow service, enabling arbitrary system command execution and complete system compromise. Given Langflow's role as an agent orchestration/flow-building platform, this is a severe supply-chain and framework-level risk for any AI agent pipelines built on it.

Updated Jul 20, 2026 · CVSS 9.9

IBM Langflow OSS versions 1.0.0 through 1.10.0 contain a vulnerability allowing an authenticated attacker to read arbitrary files on the host, including the JWT signing key used to issue authentication tokens. With this key, an attacker can forge valid tokens and impersonate any user, effectively bypassing authentication controls within the Langflow agent-building platform.

Updated Jul 18, 2026 · CVSS 7.5

IBM Langflow OSS versions 1.0.0-1.10.0 allow unauthenticated attackers to register new user accounts that, under the common NEW_USER_IS_ACTIVE=true configuration, are immediately active without admin approval. This lets attackers authenticate and reach code-execution endpoints, effectively bypassing intended access controls even when AUTO_LOGIN is disabled. Given the critical CVSS score of 9.8, this is a genuine and severe vulnerability requiring urgent patching.

Updated Jul 18, 2026 · CVSS 9.8

This is an academic survey paper analyzing 21 proposals and 5 commercial AI agents for how they handle user-level permissions, not a report of an active vulnerability or exploit. It highlights that most agentic systems apply uniform, product-level security policies rather than customizable per-user permissions, identifying this as a research gap rather than describing a specific attack.

Updated Jul 16, 2026