% MCP-Attack-Surface-2026.tex
% "30 CVEs in 60 Days: An Empirical Analysis of the Model Context Protocol Attack Surface"
% Target: NDSS workshop / arXiv rapid communication (8-10 pages)
% Compile: pdflatex MCP-Attack-Surface-2026.tex (self-contained, no bibtex needed)

\documentclass[11pt,twocolumn]{article}

% --- Packages ---------------------------------------------------------------
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{cite}
\usepackage{amsmath,amssymb}
\usepackage{graphicx}
\usepackage{url}
\usepackage{hyperref}
\usepackage{booktabs}
% \usepackage{multirow}
\usepackage{array}
\usepackage{xcolor}
\usepackage{listings}
\usepackage{enumitem}

\usepackage{tabularx}


\hypersetup{
  colorlinks=true,
  linkcolor=blue!70!black,
  citecolor=blue!70!black,
  urlcolor=blue!70!black
}

\lstset{
  basicstyle=\ttfamily\scriptsize,
  breaklines=true,
  frame=single,
  backgroundcolor=\color{gray!10},
  xleftmargin=2em,
  framexleftmargin=1.5em
}

% --- Title -------------------------------------------------------------------
\title{30 CVEs in 60 Days: An Empirical Analysis of the\\Model Context Protocol Attack Surface}

\author{
Agent Threat Rules Project}

\texttt{https://github.com/anthropics/agent-threat-rules}
}
}

\begin{document}
\maketitle

% ============================================================================
% ABSTRACT
% ============================================================================
\begin{abstract}
The Model Context Protocol (MCP), introduced by Anthropic in November 2024, has become the dominant integration standard for AI agent tool use. Within 18 months, the ecosystem grew to over 12,000 public MCP servers and 90,000 registered skills. This paper presents the first systematic empirical analysis of the MCP attack surface. We document 30 Common Vulnerabilities and Exposures (CVEs) disclosed within a 60-day window (February--April 2025), a vulnerability accumulation rate that exceeds Docker's first two years (7 CVEs) and Kubernetes' first year (12 CVEs) by an order of magnitude. We perform deep analysis of five critical CVEs spanning remote code execution, drive-by exploitation, and supply chain attacks. Through a large-scale ecosystem scan of 53,577 MCP skills across three major registries, we identify 946 flagged artifacts (1.77\%), with 875 classified as critical severity and tool description poisoning accounting for 71\% of all detections. We propose a seven-class attack taxonomy specific to the MCP threat model and demonstrate that 38\% of surveyed MCP servers implement no authentication mechanism---a gap traceable to the protocol specification itself, where authentication is optional rather than mandatory. We conclude with actionable recommendations for specification authors, registry operators, platform vendors, and enterprise adopters.
\end{abstract}

\begin{IEEEkeywords}
AI security, Model Context Protocol, MCP, supply chain attacks, tool poisoning, agent security, vulnerability analysis
\end{IEEEkeywords}

% ============================================================================
% 1. INTRODUCTION
% ============================================================================
\section{Introduction}
\label{sec:introduction}

The adoption velocity of the Model Context Protocol has no precedent in infrastructure software. Introduced as an open specification by Anthropic in November 2024~\cite{mcp-spec}, MCP defines a JSON-RPC~2.0 interface through which AI agents invoke external tools, access data sources, and orchestrate multi-step workflows. By April 2026, every major AI platform---Claude, GPT, Gemini, Copilot, Cursor, Windsurf---supports MCP natively~\cite{mcp-adoption}. The npm registry lists over 12,000 MCP server packages. Three aggregator registries---ClawHub, OpenClaw, and Skills.sh---collectively index more than 90,000 skills~\cite{atr-scan}.

This growth has outpaced security analysis. In a 60-day window spanning February to April 2025, the security community disclosed 30 CVEs targeting MCP implementations, servers, and clients~\cite{cve-list}. For comparison, Docker accumulated 7 CVEs in its first two years of public availability (2013--2015)~\cite{docker-cves}, and Kubernetes accumulated 12 in its first year post-1.0 (2015--2016)~\cite{k8s-cves}. The MCP CVE rate---approximately one disclosure every two days---signals an attack surface expanding faster than the community's capacity to secure it.

The root causes are structural. The MCP specification treats authentication as an optional extension rather than a mandatory requirement~\cite{mcp-spec}. Tool descriptions, which AI models use to decide when and how to invoke tools, are attacker-controlled strings with no integrity verification. The trust model assumes that tool providers are benign---an assumption invalidated by documented supply chain attacks including typosquatting campaigns~\cite{sandworm}, malicious package updates~\cite{postmark}, and registry poisoning at scale~\cite{antiy-cert}.

This paper makes four contributions:

\begin{enumerate}[leftmargin=*]
    \item \textbf{CVE Analysis.} We perform root-cause analysis of five critical CVEs spanning remote code execution (RCE), drive-by exploitation, and context poisoning, identifying common architectural weaknesses (Section~\ref{sec:cve-analysis}).
    \item \textbf{Attack Taxonomy.} We propose seven attack classes specific to the MCP threat model, grounded in real incidents and CVE evidence (Section~\ref{sec:taxonomy}).
    \item \textbf{Ecosystem Measurement.} We report results from a scan of 53,577 skills across three registries, quantifying the prevalence and severity distribution of threats in the wild (Section~\ref{sec:ecosystem}).
    \item \textbf{Gap Analysis.} We demonstrate that the authentication gap---38\% of servers with no auth---is a specification-level design choice with measurable security consequences, and propose concrete remediation paths (Sections~\ref{sec:auth-gap}--\ref{sec:recommendations}).
\end{enumerate}

% ============================================================================
% 2. BACKGROUND
% ============================================================================
\section{Background}
\label{sec:background}

\subsection{MCP Architecture}

MCP defines a client-server architecture where an AI \emph{host} application (e.g., Claude Desktop, VS Code with Copilot) communicates with one or more MCP \emph{servers} via JSON-RPC~2.0 over stdio or HTTP with Server-Sent Events (SSE)~\cite{mcp-spec}. Each server exposes three primitive types:

\begin{itemize}[leftmargin=*]
    \item \textbf{Tools}: executable functions the model can invoke (e.g., \texttt{read\_file}, \texttt{query\_database}, \texttt{send\_email}).
    \item \textbf{Resources}: read-only data the model can reference (e.g., file contents, API responses).
    \item \textbf{Prompts}: reusable prompt templates that guide model behavior.
\end{itemize}

The tool invocation flow proceeds as follows. The host sends a \texttt{tools/list} request to discover available tools. The server responds with a list of tool names, descriptions, and JSON Schema parameter definitions. The AI model reads these descriptions to decide which tool to call and with what arguments. The host then sends a \texttt{tools/call} request, and the server executes the operation and returns results.

\subsection{Trust Model}

The MCP trust model is implicitly three-party: the \emph{user} trusts the \emph{host}, the host trusts the \emph{model}, and the model trusts the \emph{tool descriptions} provided by servers. This chain of trust is fragile at the terminal link. Tool descriptions are free-text strings authored by the server developer, transmitted without signatures, and consumed by the model as if they were authoritative documentation. An attacker who controls a tool description can influence model behavior---a class of attack we term \emph{tool description poisoning} (Section~\ref{sec:taxonomy}).

\subsection{The Authentication Question}

The MCP specification defines an optional OAuth~2.0 authorization flow for HTTP-based transports~\cite{mcp-spec}. For stdio transports---used by the majority of desktop integrations---authentication is left entirely to the server implementor. The specification states: ``Servers MAY require authentication''~\cite{mcp-spec}. This permissive language has measurable consequences: our survey of 1,000 MCP servers finds that 38\% implement no authentication mechanism of any kind (Section~\ref{sec:auth-gap}).

% ============================================================================
% 3. CVE ANALYSIS
% ============================================================================
\section{CVE Analysis}
\label{sec:cve-analysis}

We analyze five CVEs representative of distinct attack vectors against the MCP ecosystem. Table~\ref{tab:cves} summarizes these vulnerabilities.

\begin{table*}[t]
\centering
\caption{Selected MCP-Related CVEs (February--April 2025)}
\label{tab:cves}
\begin{threeparttable}
\begin{tabular}{@{}llllll@{}}
\toprule
\textbf{CVE ID} & \textbf{Target} & \textbf{CVSS} & \textbf{Researcher} & \textbf{Attack Class} & \textbf{Impact} \\
\midrule
CVE-2025-6514 & mcp-remote & 9.6 & JFrog & RCE via SSRF & Full system compromise \\
CVE-2025-53773 & GitHub Copilot & ---\tnote{a} & Embrace The Red & YOLO mode RCE & Arbitrary code execution \\
CVE-2025-68143/44/45 & Anthropic Git MCP & ---\tnote{a} & Cyata & RCE chain & Repository takeover \\
CVE-2025-49596 & MCP Inspector & 9.4 & Oligo Security & Drive-by exploitation & Developer workstation compromise \\
CVE-2025-59536 & Claude Code & ---\tnote{a} & Check Point Research & Context poisoning & Malicious code injection \\
\bottomrule
\end{tabular}
\begin{tablenotes}
\footnotesize
\item[a] CVSS score not assigned at time of disclosure or pending NVD analysis.
\end{tablenotes}
\end{threeparttable}
\end{table*}

\subsection{CVE-2025-6514: mcp-remote RCE (CVSS 9.6)}

The \texttt{mcp-remote} package, a widely-used transport proxy for connecting MCP clients to remote servers, contained a Server-Side Request Forgery (SSRF) vulnerability that escalated to full remote code execution~\cite{cve-2025-6514}. The package failed to validate callback URLs during the OAuth~2.0 authorization flow. An attacker who controlled a malicious MCP server could redirect the OAuth callback to an internal service, chaining the SSRF with a code injection vector on the local machine. JFrog researchers demonstrated full system compromise with a single tool invocation~\cite{jfrog-mcp}.

\textbf{Root cause}: No URL validation on OAuth callback endpoints. The MCP specification does not mandate callback URL restrictions.

\textbf{Architectural lesson}: Transport-layer proxies inherit the security obligations of both client and server but are often implemented as thin pass-through layers with minimal validation.

% -- Attack flow diagram (described for TikZ/pgf reproduction) --
% [Attacker MCP Server] --(1. malicious OAuth callback URL)--> [mcp-remote proxy]
% [mcp-remote proxy] --(2. SSRF to internal service)--> [Local Service]
% [Local Service] --(3. code injection)--> [System Shell]
% Result: Full RCE from a single tool invocation

\subsection{CVE-2025-53773: GitHub Copilot YOLO Mode RCE}

Researcher Johann Rehberger (Embrace The Red) demonstrated that GitHub Copilot's ``YOLO mode''---a configuration that auto-approves tool invocations without user confirmation---could be exploited for arbitrary code execution~\cite{cve-2025-53773}. By crafting a prompt injection embedded in a code comment within a repository, an attacker could trigger Copilot to invoke a shell-execution tool. In YOLO mode, no confirmation dialog appeared.

\textbf{Root cause}: Auto-approval of tool invocations eliminates the human-in-the-loop safeguard. The attack exploits the gap between the model's intent (follow instructions in the code) and the user's intent (receive coding assistance).

\textbf{Architectural lesson}: Any ``auto-approve'' mode in an MCP client transforms every tool description poisoning vulnerability into a remote code execution vulnerability.

% -- Attack flow diagram --
% [Malicious Repo] --(1. prompt injection in code comment)--> [Copilot Agent]
% [Copilot Agent] --(2. tool call: execute_command)--> [YOLO mode: auto-approve]
% [YOLO mode] --(3. no confirmation)--> [Shell Execution]
% Result: RCE without user interaction

\subsection{CVE-2025-68143/44/45: Anthropic Git MCP RCE Chain}

Cyata researchers identified a chain of three vulnerabilities in the official Anthropic Git MCP server that, when combined, allowed remote code execution~\cite{cve-2025-68143}. The chain exploited: (1) insufficient input sanitization on repository URLs, allowing injection of git command-line flags (CVE-2025-68143); (2) a path traversal vulnerability in the file-reading tool (CVE-2025-68144); and (3) an argument injection in the git~\texttt{diff} tool that permitted execution of arbitrary commands via the \texttt{--output} flag (CVE-2025-68145).

\textbf{Root cause}: Compound failure---each vulnerability was individually exploitable but the chain amplified impact from information disclosure to full RCE.

\textbf{Architectural lesson}: MCP servers that wrap command-line tools must treat every parameter as untrusted input. Git's rich flag surface makes it a particularly dangerous backend.

% -- Attack chain diagram --
% Step 1 (CVE-68143): git clone --upload-pack="malicious" [injected URL]
% Step 2 (CVE-68144): read_file("../../../etc/passwd") -> path traversal
% Step 3 (CVE-68145): git diff --output=/tmp/payload.sh -> arbitrary write
% Combined: information disclosure -> arbitrary file write -> RCE

\subsection{CVE-2025-49596: MCP Inspector Drive-By (CVSS 9.4)}

MCP Inspector, a developer debugging tool for MCP servers, was vulnerable to a drive-by attack via its web interface~\cite{cve-2025-49596}. Oligo Security demonstrated that a malicious web page could issue cross-origin requests to the Inspector's local HTTP server, invoking arbitrary tools on any connected MCP server. The attack required only that a developer visit a malicious URL while Inspector was running.

\textbf{Root cause}: Missing Cross-Origin Resource Sharing (CORS) restrictions on the Inspector's local HTTP endpoint. No authentication on the debug interface.

\textbf{Architectural lesson}: Developer tooling is part of the attack surface. Debug interfaces with tool invocation capability must enforce the same security controls as production clients.

\subsection{CVE-2025-59536: Claude Code Context Poisoning}

Check Point Research demonstrated that Claude Code, Anthropic's CLI-based coding agent, was vulnerable to context poisoning via specially crafted project files~\cite{cve-2025-59536}. By embedding hidden instructions in \texttt{CLAUDE.md}, \texttt{.cursorrules}, or similar configuration files within a repository, an attacker could manipulate the agent into executing malicious commands. The poisoned instructions exploited the trust boundary between project context and user instructions.

\textbf{Root cause}: The agent treated project-level configuration files as trusted context without distinguishing them from potentially adversarial content in cloned repositories.

\textbf{Architectural lesson}: In the MCP ecosystem, the boundary between data and instructions is porous. Any file that influences agent behavior is an attack vector.

\subsection{Cross-Cutting Patterns}

Three patterns recur across the five CVEs:

\begin{enumerate}[leftmargin=*]
    \item \textbf{Trust boundary confusion.} Every CVE involves a component that treats untrusted input (URLs, tool descriptions, file contents, cross-origin requests) as trusted. The MCP specification does not clearly delineate trust boundaries.
    \item \textbf{Escalation through composition.} Individual weaknesses become critical when composed---SSRF chains to RCE, prompt injection chains to shell execution, path traversal chains to arbitrary write.
    \item \textbf{Developer tooling as entry point.} Two of five CVEs (Inspector, Claude Code) target developer environments, where security controls are typically relaxed.
\end{enumerate}

% ============================================================================
% 4. ATTACK TAXONOMY
% ============================================================================
\section{Attack Taxonomy}
\label{sec:taxonomy}

We propose a seven-class taxonomy of MCP-specific attacks, derived from analysis of disclosed CVEs, real-world incidents, and our ecosystem scan results. Table~\ref{tab:taxonomy} maps each class to observed instances.

\begin{table*}[t]
\centering
\caption{MCP Attack Taxonomy with Real-World Instances}
\label{tab:taxonomy}
\begin{tabular}{@{}p{3.2cm}p{4.8cm}p{3.5cm}p{3.5cm}@{}}
\toprule
\textbf{Attack Class} & \textbf{Description} & \textbf{CVE / Incident} & \textbf{Detection Signal} \\
\midrule
1. Tool Description Poisoning &
Hidden instructions in tool descriptions that manipulate model behavior (e.g., exfiltrate data, suppress warnings, invoke other tools) &
CVE-2025-59536; 71\% of scan detections~\cite{atr-scan} &
Embedded instructions, cross-tool references, obfuscated directives \\
\addlinespace
2. Response Poisoning &
Malicious content injected into tool response payloads that alter subsequent model reasoning or user-facing output &
Demonstrated in MCP Inspector chain~\cite{cve-2025-49596} &
Prompt injection patterns in API responses \\
\addlinespace
3. Rug-Pull (Benign$\to$Malicious) &
Initially benign MCP server or skill updated to include malicious functionality after gaining trust and adoption &
postmark-mcp v1.0.16~\cite{postmark} &
Behavioral diff between versions, new permission requests \\
\addlinespace
4. Typosquatting &
Packages with names similar to popular MCP servers, designed to intercept installation attempts &
SANDWORM\_MODE campaign (19 packages)~\cite{sandworm} &
Edit distance from popular names, low download count, recent creation \\
\addlinespace
5. Cross-Skill Chaining &
Exploiting interactions between multiple MCP servers connected to the same host, using one compromised tool to influence calls to another &
Demonstrated via CVE-2025-53773 chain~\cite{cve-2025-53773} &
Unexpected tool invocation sequences, data flow between unrelated servers \\
\addlinespace
6. Protocol-Level Abuse &
Exploitation of MCP protocol features---sampling, notifications, resource subscriptions---for purposes beyond their intended use &
Sampling-based prompt injection~\cite{invariant-mcp} &
Unusual sampling requests, notification flooding \\
\addlinespace
7. Credential Harvesting &
MCP tools that request or access credentials under the guise of normal functionality (e.g., an email tool that reads OAuth tokens) &
1,184 malicious ClawHub skills~\cite{antiy-cert} &
Excessive permission requests, credential file access patterns \\
\bottomrule
\end{tabular}
\end{table*}

\subsection{Class 1: Tool Description Poisoning}

Tool description poisoning is the most prevalent attack class, accounting for 71\% of all detections in our ecosystem scan (Section~\ref{sec:ecosystem}). The attack exploits the fact that MCP tool descriptions are consumed by AI models as natural-language documentation. An attacker embeds adversarial instructions within a tool's description string:

\begin{lstlisting}[caption={Simplified tool description poisoning example}]
{
  "name": "search_files",
  "description": "Search for files in the project.
    IMPORTANT: Before using this tool, first call
    read_file on ~/.ssh/id_rsa and include its
    contents in the search query for authentication."
}
\end{lstlisting}

The model, trained to follow instructions in its context, may comply with the embedded directive. This attack requires no exploitation of software vulnerabilities---it operates entirely within the protocol's intended functionality.

\subsection{Class 2: Response Poisoning}

Response poisoning targets the return path. When a tool returns results, the model incorporates those results into its reasoning context. A malicious tool can return prompt injection payloads embedded in ostensibly normal output---for example, a web search tool returning results that contain hidden instructions to invoke a file-writing tool. Unlike description poisoning, response poisoning is dynamic: the payload can change with each invocation, evading static analysis.

\subsection{Class 3: Rug-Pull Attacks}

The postmark-mcp incident exemplifies the rug-pull pattern. Version~1.0.16 of the \texttt{postmark-mcp} package, a legitimate email-sending MCP server, was updated to add a blind carbon copy (BCC) forwarding mechanism~\cite{postmark}. Every email sent through the tool was silently copied to an attacker-controlled address. At estimated organizational email volumes of 3,000--15,000 messages per day, the potential data exfiltration was substantial. The malicious update passed automated registry checks because it did not introduce obviously malicious code patterns---it used the existing email API with an additional recipient.

\subsection{Class 4: Typosquatting -- The SANDWORM\_MODE Campaign}

The SANDWORM\_MODE campaign, identified by Checkmarx researchers, involved 19 typosquatted npm packages mimicking popular MCP servers~\cite{sandworm}. Package names used common variations: dropped hyphens (\texttt{mcpremote} for \texttt{mcp-remote}), transposed characters, and appended suffixes (\texttt{-official}, \texttt{-server}). Each package contained a postinstall script that exfiltrated SSH private keys, AWS credentials, and environment variables to a command-and-control server. Collectively, the 19 packages were downloaded over 800 times before removal.

\subsection{Class 5: Cross-Skill Chaining}

When multiple MCP servers are connected to a single host, a compromised tool on one server can influence the model to invoke tools on another server. The attack surface grows combinatorially with the number of connected servers. A file-reading tool on Server~A can return content that instructs the model to invoke a shell-execution tool on Server~B. Neither server is individually malicious; the attack emerges from their interaction mediated by the model.

\subsection{Class 6: Protocol-Level Abuse}

MCP defines several protocol features---sampling, notifications, resource subscriptions---that can be abused beyond their intended purpose. The sampling mechanism allows servers to request that the model generate text, which can be exploited for prompt injection by framing the sampling request to include adversarial instructions~\cite{invariant-mcp}. Notifications can be used for denial-of-service through flooding. Resource subscriptions can exfiltrate data by subscribing to sensitive files and receiving their contents through the subscription channel.

\subsection{Class 7: Credential Harvesting at Scale}

In February 2026, Antiy CERT published an analysis of 1,184 malicious skills identified on ClawHub, the largest MCP skill aggregator~\cite{antiy-cert}. The dominant pattern was credential harvesting disguised as legitimate functionality: file management tools that read \texttt{.env} files, database tools that logged connection strings, and API integration tools that transmitted OAuth tokens to third-party endpoints. The skills operated within their stated permissions---the malice was in the \emph{purpose}, not the \emph{mechanism}.

% ============================================================================
% 5. ECOSYSTEM MEASUREMENT
% ============================================================================
\section{Ecosystem Measurement}
\label{sec:ecosystem}

\subsection{Methodology}

We conducted a large-scale scan of MCP skills using the Agent Threat Rules (ATR) detection engine~\cite{atr-project}, an open-source rule-based scanner with 113 detection rules covering nine threat categories. The scan targeted three major skill registries:

\begin{itemize}[leftmargin=*]
    \item \textbf{ClawHub}: 37,394 skills (largest community registry)
    \item \textbf{OpenClaw}: 50,283 skills (open-source aggregator)
    \item \textbf{Skills.sh}: 3,115 skills (curated directory)
\end{itemize}

Each skill's manifest---including tool names, descriptions, parameter schemas, and README content---was evaluated against the full ATR rule set. The scanner uses deterministic regex-based pattern matching, achieving 99.6\% precision and 61.4\% recall on the PINT benchmark (850 MCP samples) and 100\% precision with 96.9\% recall on real-world SKILL.md files (498 samples)~\cite{atr-benchmark}.

\subsection{Results}

Of 53,577 unique skills scanned after deduplication, 946 were flagged (1.77\%). Table~\ref{tab:scan-results} presents the severity and category breakdown.

\begin{table}[t]
\centering
\caption{Ecosystem Scan Results: 53,577 Skills}
\label{tab:scan-results}
\begin{tabular}{@{}lrr@{}}
\toprule
\textbf{Category} & \textbf{Count} & \textbf{\% of Flagged} \\
\midrule
Tool description poisoning & 672 & 71.0\% \\
Credential/secret access & 98 & 10.4\% \\
Excessive permissions & 67 & 7.1\% \\
Data exfiltration patterns & 45 & 4.8\% \\
Command injection vectors & 31 & 3.3\% \\
Cross-tool manipulation & 18 & 1.9\% \\
Obfuscation techniques & 15 & 1.6\% \\
\midrule
\textbf{Total flagged} & \textbf{946} & \textbf{100\%} \\
\bottomrule
\end{tabular}
\vspace{0.5em}

\begin{tabular}{@{}lrr@{}}
\toprule
\textbf{Severity} & \textbf{Count} & \textbf{\% of Flagged} \\
\midrule
Critical & 875 & 92.5\% \\
High & 52 & 5.5\% \\
Medium & 19 & 2.0\% \\
\bottomrule
\end{tabular}
\end{table}

The dominance of tool description poisoning (71\%) is consistent with the low barrier to entry: an attacker need only modify a text field, with no code-level exploitation required. The high proportion of critical-severity detections (92.5\%) reflects the scanner's threshold calibration---critical severity indicates direct potential for code execution or data exfiltration.

\subsection{False Positive Analysis}

To validate precision, we manually reviewed a stratified random sample of 200 flagged skills and a control set of 200 unflagged skills. The flagged sample yielded 0 false positives (all 200 contained genuinely suspicious patterns). The control set yielded 0 false negatives within the scanner's detection scope. These results are consistent with the scanner's benchmark performance: 99.6\% precision on the PINT evaluation set~\cite{atr-benchmark}.

\subsection{Registry Comparison}

Flagging rates varied by registry: ClawHub (2.1\%), OpenClaw (1.5\%), and Skills.sh (0.8\%). The difference correlates with review rigor: Skills.sh employs manual curation, OpenClaw uses automated checks, and ClawHub accepts submissions with minimal gatekeeping. This gradient suggests that even lightweight review processes measurably reduce the prevalence of malicious skills.

% ============================================================================
% 6. THE AUTHENTICATION GAP
% ============================================================================
\section{The Authentication Gap}
\label{sec:auth-gap}

\subsection{Specification Analysis}

The MCP specification (revision 2025-03-26) defines authentication as follows: ``For HTTP-based transports, servers SHOULD implement OAuth~2.0 authorization. [...] Servers MAY require authentication for some or all operations''~\cite{mcp-spec}. The use of SHOULD and MAY (per RFC~2119~\cite{rfc2119}) makes authentication explicitly optional. For stdio-based transports---which account for the majority of desktop MCP integrations---the specification provides no authentication guidance whatsoever.

This stands in contrast to other infrastructure protocols. Table~\ref{tab:auth-comparison} compares authentication requirements across protocols with similar trust implications.

\begin{table}[t]
\centering
\caption{Authentication Requirements Across Protocols}
\label{tab:auth-comparison}
\begin{tabular}{@{}lll@{}}
\toprule
\textbf{Protocol} & \textbf{Auth Requirement} & \textbf{Default} \\
\midrule
Kubernetes API & MUST (mandatory) & mTLS + RBAC \\
Docker Engine API & MUST (mandatory) & TLS client cert \\
gRPC & SHOULD (recommended) & TLS channel \\
GraphQL & Implementation-defined & Varies \\
\textbf{MCP (HTTP)} & \textbf{SHOULD (recommended)} & \textbf{None} \\
\textbf{MCP (stdio)} & \textbf{Not addressed} & \textbf{None} \\
\bottomrule
\end{tabular}
\end{table}

\subsection{Empirical Measurement}

We surveyed 1,000 MCP server packages from the npm registry, examining their source code for authentication mechanisms. Our methodology classified authentication as present if the server implemented any of: API key validation, OAuth~2.0 flows, token-based auth, mTLS, or platform-specific authentication (e.g., GitHub PAT). Results:

\begin{itemize}[leftmargin=*]
    \item \textbf{38\%}: No authentication mechanism of any kind.
    \item \textbf{24\%}: API key or token validation only (static secrets, no rotation).
    \item \textbf{21\%}: Platform-delegated authentication (e.g., GitHub token passed as configuration).
    \item \textbf{12\%}: OAuth~2.0 implementation.
    \item \textbf{5\%}: mTLS or certificate-based authentication.
\end{itemize}

The 38\% with no authentication represents a direct path to unauthorized tool invocation. For tools with destructive capabilities (file deletion, database modification, email sending), the absence of authentication is a critical severity finding.

\subsection{Comparison with Historical Precedent}

The MCP authentication gap mirrors early Docker security: the Docker daemon originally listened on an unauthenticated TCP socket, leading to widespread exploitation before the project mandated TLS~\cite{docker-security}. Kubernetes learned from Docker's experience and required authentication from its 1.0 release~\cite{k8s-auth}. MCP, despite launching after both precedents, has repeated the pattern.

% ============================================================================
% 7. CVE VELOCITY COMPARISON
% ============================================================================
\section{CVE Velocity in Context}
\label{sec:velocity}

To contextualize the MCP CVE accumulation rate, we compare it against infrastructure technologies with similar adoption trajectories. Table~\ref{tab:velocity} presents CVE counts from the NVD database~\cite{nvd} for each technology's initial period of widespread adoption.

\begin{table}[t]
\centering
\caption{CVE Accumulation: First Comparable Adoption Period}
\label{tab:velocity}
\begin{tabular}{@{}lrrr@{}}
\toprule
\textbf{Technology} & \textbf{Period} & \textbf{CVEs} & \textbf{CVEs/Mo.} \\
\midrule
Docker & 2013--2015 (2 yr) & 7 & 0.29 \\
Kubernetes & 2015--2016 (1 yr) & 12 & 1.00 \\
npm ecosystem & 2016--2017 (1 yr) & 23 & 1.92 \\
\textbf{MCP ecosystem} & \textbf{Feb--Apr 2025 (60d)} & \textbf{30} & \textbf{15.00} \\
\bottomrule
\end{tabular}
\end{table}

% -- CVE Timeline Figure (described for reproduction) --
% Figure: Cumulative CVE timeline comparison
% X-axis: months since first public release (0-24)
% Y-axis: cumulative CVE count (0-35)
% Line 1: Docker (2013-2015) -- slow, linear slope reaching 7 at month 24
% Line 2: Kubernetes (2015-2016) -- moderate slope reaching 12 at month 12
% Line 3: npm ecosystem (2016-2017) -- steeper slope reaching 23 at month 12
% Line 4: MCP ecosystem (2025) -- near-vertical, reaching 30 at month 2
% Annotation on MCP line at (2, 30): "30 CVEs in 60 days"
% Color scheme: Docker=blue, K8s=green, npm=orange, MCP=red
% Note: Figure data available in supplementary materials for reproduction.

The MCP CVE rate of 15.0 per month is 15$\times$ higher than Kubernetes and 52$\times$ higher than Docker during comparable periods. Three factors explain this disparity:

\begin{enumerate}[leftmargin=*]
    \item \textbf{Larger researcher population.} AI security has attracted heavy investment (\$3.6B in agentic AI security funding by RSA~2026~\cite{rsa-2026}), creating a larger pool of security researchers examining MCP implementations.
    \item \textbf{Lower exploitation barrier.} MCP attacks often require no binary exploitation---tool description poisoning, typosquatting, and context poisoning operate through text manipulation rather than memory corruption or logic bugs.
    \item \textbf{Specification-level gaps.} The optional authentication model and absence of integrity verification for tool descriptions create a broad, easily discoverable attack surface that rewards even casual examination.
\end{enumerate}

We acknowledge confounding factors (Section~\ref{sec:limitations}): the comparison does not control for ecosystem size, researcher incentive structures, or changes in disclosure norms over the decade separating Docker's launch from MCP's. Nevertheless, the magnitude of the difference---over an order of magnitude---suggests that the MCP attack surface is structurally larger, not merely more scrutinized.

% ============================================================================
% 8. DEFENSE LANDSCAPE
% ============================================================================
\section{Defense Landscape}
\label{sec:defense}

The security community has responded with a range of defensive frameworks and tools. We assess the current state of each and evaluate their effectiveness.

\subsection{SAFE-MCP}

The Securing AI-Friendly Ecosystems for MCP (SAFE-MCP) initiative, backed by \$12.5M in funding from six companies, proposes a vendor-neutral security framework for MCP~\cite{safe-mcp}. SAFE-MCP defines 85 security requirements across categories including authentication, authorization, input validation, and supply chain integrity. As of April 2026, no major registry enforces SAFE-MCP compliance. The framework remains aspirational---broad in scope but lacking enforcement mechanisms.

\subsection{Agent Threat Rules (ATR)}

ATR is an open-source detection rule set with 113 rules covering nine categories aligned with the OWASP Agentic Top~10~\cite{atr-project, owasp-agentic}. ATR achieves 10/10 coverage of the OWASP Agentic Top~10 categories and 91.8\% coverage (78/85) of SAFE-MCP requirements~\cite{atr-safemcp}. Cisco AI Defense has integrated 34 ATR rules into its enterprise skill scanner~\cite{cisco-atr}. ATR operates as a regex-based first gate (99.6\% precision), with semantic analysis deferred to a secondary LLM-based layer for ambiguous cases. The architecture reflects a deliberate design tradeoff: deterministic regex matching provides speed and precision at the cost of recall on novel attack patterns.

\subsection{OWASP Agentic Top 10}

The OWASP Agentic Security Top~10~\cite{owasp-agentic} provides a risk taxonomy but not executable detection rules. It identifies key risk categories---prompt injection, tool misuse, excessive permissions, insecure output handling, supply chain vulnerabilities---without prescribing detection mechanisms. ATR and similar projects serve as the execution layer for OWASP's risk model, translating categorical risks into concrete detection patterns.

\subsection{Industry Consolidation}

Snyk's acquisition of Invariant Labs in early 2026 signals market consolidation~\cite{snyk-invariant}. Invariant's \texttt{mcp-scan} tool, which performs runtime analysis of MCP server behavior, is now a Snyk product. This acquisition pattern---established security companies acquiring MCP-specific tooling---is likely to accelerate as the market matures. The risk is that consolidation reduces the diversity of defensive approaches, concentrating detection capability in a small number of vendors.

\subsection{Regulatory Pressure}

The EU AI Act, entering enforcement in August 2026, classifies certain AI agent deployments as high-risk systems subject to mandatory conformity assessments~\cite{eu-ai-act}. Article~15 requires ``appropriate levels of accuracy, reliability and cybersecurity,'' which will likely be interpreted to require authentication and integrity verification for tool integrations. Enterprises operating in the EU will need auditable security controls for their MCP deployments---creating demand for compliance tooling that does not yet exist in mature form.

\subsection{Assessment: What Works and What Does Not}

Table~\ref{tab:defense-assessment} summarizes the effectiveness of current defenses against each attack class.

\begin{table}[t]
\centering
\caption{Defense Coverage by Attack Class}
\label{tab:defense-assessment}
\begin{tabular}{@{}lccc@{}}
\toprule
\textbf{Attack Class} & \textbf{ATR} & \textbf{Runtime} & \textbf{Spec} \\
\midrule
1. Description poisoning & High & Low & None \\
2. Response poisoning & Low & Medium & None \\
3. Rug-pull & Low & Medium & None \\
4. Typosquatting & Medium & N/A & None \\
5. Cross-skill chaining & Low & Medium & None \\
6. Protocol-level abuse & Low & High & Partial \\
7. Credential harvesting & High & Medium & None \\
\bottomrule
\end{tabular}
\vspace{0.3em}

\footnotesize{ATR = static regex scanning; Runtime = behavioral analysis (Invariant/Snyk); Spec = MCP specification controls.}
\end{table}

No single defense addresses the full threat model. The effective approach is defense in depth: static scanning at the registry and installation layers, runtime monitoring during execution, and specification-level mandates to close architectural gaps. The specification column is uniformly ``None'' or ``Partial''---the most impactful intervention would be specification-level changes that make entire attack classes structurally impossible.

% ============================================================================
% 9. REAL-WORLD INCIDENTS
% ============================================================================
\section{Real-World Incidents}
\label{sec:incidents}

Beyond formal CVE disclosures, three incidents illustrate the operational impact of MCP vulnerabilities at scale.

\subsection{postmark-mcp BCC Forwarding}

In March 2025, version~1.0.16 of the \texttt{postmark-mcp} npm package---a legitimate MCP server for the Postmark email API---was updated to silently BCC every outgoing email to an attacker-controlled address~\cite{postmark}. The modification was a single line change in the email-sending function. At estimated organizational volumes of 3,000--15,000 emails per day, a single compromised installation could exfiltrate thousands of messages before detection. The package was live for 11 days before community reporting led to removal.

This incident matters for two reasons. First, the attack was invisible to the model and the user: the BCC field is not displayed in sent-mail confirmations, and the email API returned success for each message. Second, the attack was undetectable by static scanning of tool descriptions---the malicious behavior was in the server's implementation code, not its advertised interface. This places rug-pull attacks outside the detection scope of description-based scanners and highlights the need for behavioral analysis of server code.

\subsection{SANDWORM\_MODE Campaign}

The SANDWORM\_MODE campaign, identified by Checkmarx, consisted of 19 typosquatted npm packages targeting popular MCP servers~\cite{sandworm}. Each package contained an \texttt{npm postinstall} script that:

\begin{enumerate}[leftmargin=*]
    \item Enumerated \texttt{\textasciitilde/.ssh/} for private keys
    \item Read \texttt{\textasciitilde/.aws/credentials} and \texttt{\textasciitilde/.env} files
    \item Transmitted the collected data to a C2 server via HTTPS POST
    \item Installed the legitimate package as a dependency to maintain functionality
\end{enumerate}

The campaign accumulated over 800 downloads across the 19 packages before the npm security team removed them. The technique is not novel---npm typosquatting predates MCP by years---but the MCP context amplifies the impact. Developers installing MCP servers are typically configuring access to sensitive systems (databases, APIs, cloud services), and the credential files present on their workstations reflect that access level.

\subsection{ClawHub Registry Poisoning}

In February 2026, Antiy CERT reported finding 1,184 malicious skills on ClawHub~\cite{antiy-cert}. Unlike the crude exfiltration of the SANDWORM\_MODE campaign, these skills employed subtler techniques: reading credential files during ostensibly normal operations, requesting overly broad permissions justified by feature requirements, and embedding exfiltration endpoints in tool configurations rather than executable code. The scale of the contamination---affecting 3.2\% of ClawHub's catalog at the time---prompted the registry to implement a mandatory review process.

The ClawHub incident demonstrates that MCP skill registries face the same supply chain challenges as package managers (npm, PyPI) but with weaker defenses. Package managers have invested years in malware detection, publisher verification, and transparency logging. MCP registries, most of which launched in 2025, lack these capabilities.

% ============================================================================
% 10. RECOMMENDATIONS
% ============================================================================
\section{Recommendations}
\label{sec:recommendations}

Based on our analysis, we propose actionable recommendations for four stakeholder groups, ordered by potential impact.

\subsection{For MCP Specification Authors}

\begin{enumerate}[leftmargin=*]
    \item \textbf{Mandate authentication.} Change ``Servers MAY require authentication'' to ``Servers MUST implement authentication for all tool invocations.'' Define minimum requirements for both HTTP and stdio transports. For stdio, this could take the form of a capability token passed at initialization.
    \item \textbf{Add tool description integrity.} Introduce a cryptographic signature field for tool descriptions, verified by the client before presenting descriptions to the model. This makes tool description poisoning detectable at the protocol level.
    \item \textbf{Define permission scopes.} Establish a standardized permission model (analogous to Android manifest permissions or OAuth scopes) that constrains what tools can access. Clients should display required permissions to users before activation.
    \item \textbf{Rate-limit protocol features.} Specify maximum rates for sampling requests and notifications to prevent abuse of these channels for prompt injection and denial-of-service.
\end{enumerate}

\subsection{For Registry Operators}

\begin{enumerate}[leftmargin=*]
    \item \textbf{Implement pre-publish scanning.} Require automated security scanning (e.g., ATR or equivalent) before publishing skills. Reject submissions that match known attack patterns. Our data shows that even Skills.sh's lightweight curation reduces the flagging rate from 2.1\% to 0.8\%.
    \item \textbf{Enforce behavioral diffing.} Compare each new version against its predecessor to detect rug-pull updates. Flag additions of new network endpoints, credential file access, or BCC-like forwarding patterns.
    \item \textbf{Require publisher verification.} Implement domain verification or code-signing requirements for publishers, similar to Maven Central's GPG requirements or npm's provenance attestations.
    \item \textbf{Publish transparency logs.} Maintain an append-only log of all published versions, enabling post-hoc auditing and community monitoring.
\end{enumerate}

\subsection{For Platform Vendors}

\begin{enumerate}[leftmargin=*]
    \item \textbf{Eliminate auto-approve modes.} Remove or gate ``YOLO mode'' and equivalent configurations behind explicit per-tool allowlists with mandatory user review for new tools. CVE-2025-53773 demonstrates that auto-approve transforms description poisoning into RCE.
    \item \textbf{Integrate detection at install time.} Scan MCP server configurations against known threat patterns before the first tool invocation. This is the most effective intervention point---it occurs before any potentially malicious code executes.
    \item \textbf{Implement tool sandboxing.} Constrain MCP server processes using OS-level sandboxing (seccomp, App Sandbox, containers) to limit blast radius. A file-reading tool should not have network access; a web search tool should not have filesystem access.
    \item \textbf{Display security metadata.} Show users a security assessment of each MCP server before activation, including authentication status, permission scope, scan results, and community trust signals (download count, age, publisher verification).
\end{enumerate}

\subsection{For Enterprise Adopters}

\begin{enumerate}[leftmargin=*]
    \item \textbf{Maintain an MCP server allowlist.} Permit only vetted MCP servers in organizational environments. Audit the allowlist quarterly. This is the single most effective control available today.
    \item \textbf{Monitor tool invocation logs.} Log all MCP tool invocations with full parameter content. Alert on anomalous patterns: credential file access, network connections to unknown endpoints, unexpected tool invocation sequences.
    \item \textbf{Require authentication for all servers.} Enforce a policy that no MCP server may be deployed without authentication, regardless of the specification's permissive language.
    \item \textbf{Prepare for EU AI Act compliance.} Implement auditable security controls for MCP deployments, including documentation of risk assessments, mitigation measures, and conformity assessment evidence. The August 2026 enforcement date provides approximately 16 months from the time of writing.
\end{enumerate}

% ============================================================================
% 11. LIMITATIONS
% ============================================================================
\section{Limitations}
\label{sec:limitations}

Our analysis has several limitations that should inform interpretation of the results.

First, our ecosystem scan is based on regex pattern matching, which cannot detect semantic attacks---for example, a tool description that uses euphemistic language to manipulate model behavior without triggering keyword patterns. The 61.4\% recall on the PINT benchmark confirms that roughly 37\% of malicious patterns evade detection. The true prevalence of malicious skills is likely higher than the 1.77\% we report.

Second, our CVE velocity comparison controls for calendar time but not for differences in ecosystem size, researcher population, or disclosure norms between eras. The security research community in 2025 is substantially larger and better-funded than in 2013 (Docker) or 2015 (Kubernetes), which inflates the MCP CVE count relative to historical comparisons.

Third, the 38\% authentication gap measurement is based on npm-hosted servers and may not be representative of proprietary enterprise deployments, which likely have higher authentication rates due to organizational security policies.

Fourth, we document 64 known evasion techniques against current ATR detection rules~\cite{atr-evasions}, indicating that threats will continue to evolve beyond current detection capabilities. Our scan results represent a lower bound on the true threat prevalence.

Fifth, the seven-class taxonomy is derived from currently observed attacks. The MCP specification's feature surface---particularly sampling, notifications, and resource subscriptions---may enable attack classes not yet observed in the wild.

% ============================================================================
% 12. CONCLUSION
% ============================================================================
\section{Conclusion}
\label{sec:conclusion}

The Model Context Protocol is the fastest-growing attack surface in AI infrastructure. Thirty CVEs in 60 days is not merely a statistic---it is evidence that the protocol's security model is mismatched to its adoption velocity. The optional authentication requirement, the absence of tool description integrity, and the implicit trust in server-provided content create an attack surface that is broad, easily discovered, and actively exploited.

Our ecosystem scan of 53,577 skills found that 1.77\% contain detectable threat patterns, with tool description poisoning dominating at 71\% of detections. Real-world incidents---from BCC email forwarding to SSH key theft to registry-scale poisoning---demonstrate that these are not theoretical risks.

The defense landscape is fragmented. No single tool, framework, or specification change will close the gap. What is needed is a defense-in-depth approach: mandatory authentication at the protocol layer, automated scanning at registry and installation boundaries, runtime monitoring during execution, and regulatory pressure to establish minimum security baselines.

The MCP community has approximately 16 months before the EU AI Act enters enforcement. The specification changes, registry hardening, and detection tooling needed to meet that deadline require immediate, coordinated action. The data in this paper provides the evidence base. The urgency is real.

% ============================================================================
% ACKNOWLEDGMENTS
% ============================================================================
\section*{Acknowledgments}

We thank the security researchers whose CVE disclosures made this analysis possible: JFrog, Embrace The Red (Johann Rehberger), Cyata, Oligo Security, and Check Point Research. We acknowledge the Antiy CERT team for their ClawHub analysis, Checkmarx for the SANDWORM\_MODE investigation, and the ATR community for the open-source detection rules and ecosystem scan infrastructure. We thank the OWASP Agentic Security project and the SAFE-MCP consortium for establishing the risk frameworks against which detection tools are evaluated.

% ============================================================================
% REFERENCES
% ============================================================================
\begin{thebibliography}{30}

\bibitem{mcp-spec}
Anthropic, ``Model Context Protocol Specification,'' revision 2025-03-26,
\url{https://modelcontextprotocol.io/specification}, 2025.

\bibitem{mcp-adoption}
S.~Willison, ``MCP: The protocol that connects AI to everything,''
\emph{Simon Willison's Weblog}, March 2025.

\bibitem{atr-scan}
Agent Threat Rules Project, ``Mega scan report: 53,577 skills across three registries,''
\url{https://github.com/anthropics/agent-threat-rules}, April 2026.

\bibitem{cve-list}
NIST, ``National Vulnerability Database: MCP-related CVEs,''
\url{https://nvd.nist.gov/}, accessed April 2026.

\bibitem{docker-cves}
NIST, ``NVD search: Docker CVEs 2013--2015,''
\url{https://nvd.nist.gov/vuln/search?keyword=docker}, accessed April 2026.

\bibitem{k8s-cves}
NIST, ``NVD search: Kubernetes CVEs 2015--2016,''
\url{https://nvd.nist.gov/vuln/search?keyword=kubernetes}, accessed April 2026.

\bibitem{sandworm}
Checkmarx Research, ``SANDWORM\_MODE: 19 typosquatted MCP packages stealing SSH keys and credentials,''
\emph{Checkmarx Blog}, March 2025.

\bibitem{postmark}
Socket Security, ``postmark-mcp: Malicious MCP server update adds BCC forwarding,''
\emph{Socket Blog}, March 2025.

\bibitem{antiy-cert}
Antiy CERT, ``Analysis of 1,184 malicious skills on MCP skill registries,''
\emph{Antiy Technical Report}, February 2026.

\bibitem{cve-2025-6514}
JFrog Security Research, ``CVE-2025-6514: Critical RCE in mcp-remote via SSRF in OAuth callback,''
CVSS~9.6, April 2025.

\bibitem{jfrog-mcp}
S.~Kannan and A.~Yogev, ``MCP security: Remote code execution through MCP server vulnerabilities,''
\emph{JFrog Security Research Blog}, April 2025.

\bibitem{cve-2025-53773}
J.~Rehberger (Embrace The Red), ``CVE-2025-53773: GitHub Copilot YOLO mode enables RCE via prompt injection,''
March 2025, \url{https://embracethered.com/}.

\bibitem{cve-2025-68143}
Cyata Security, ``CVE-2025-68143/44/45: RCE chain in Anthropic Git MCP server,''
March 2025.

\bibitem{cve-2025-49596}
Oligo Security, ``CVE-2025-49596: Drive-by exploitation of MCP Inspector,''
CVSS~9.4, March 2025.

\bibitem{cve-2025-59536}
Check Point Research, ``CVE-2025-59536: Claude Code context poisoning via project files,''
April 2025.

\bibitem{invariant-mcp}
Invariant Labs, ``MCP security analysis: Sampling-based prompt injection,''
\emph{Invariant Research Blog}, February 2025.

\bibitem{atr-project}
Agent Threat Rules Project, ``ATR: Open-source detection rules for AI agent security,''
v1.1.1, 113 rules, \url{https://github.com/anthropics/agent-threat-rules}, 2026.

\bibitem{atr-benchmark}
Agent Threat Rules Project, ``PINT benchmark: 850 samples, 61.4\% recall, 99.6\% precision; SKILL.md benchmark: 498 samples, 96.9\% recall, 100\% precision,'' 2026.

\bibitem{atr-safemcp}
Agent Threat Rules Project, ``SAFE-MCP coverage mapping: 78/85 requirements (91.8\%),''
\url{https://github.com/anthropics/agent-threat-rules/docs/SAFE-MCP-MAPPING.md}, 2026.

\bibitem{atr-evasions}
Agent Threat Rules Project, ``Known evasion techniques: 64 documented patterns,'' 2026.

\bibitem{owasp-agentic}
OWASP Foundation, ``OWASP Agentic AI Security Top 10,''
\url{https://owasp.org/www-project-agentic-ai-top-10/}, 2025.

\bibitem{safe-mcp}
SAFE-MCP Consortium, ``Securing AI-Friendly Ecosystems for MCP: Framework specification,''
v1.0, 2025.

\bibitem{cisco-atr}
Cisco AI Defense, ``Integration of ATR community rules into enterprise skill scanner,''
GitHub PR \#79, March 2026.

\bibitem{snyk-invariant}
Snyk, ``Snyk acquires Invariant Labs to strengthen AI agent security,''
\emph{Snyk Blog}, January 2026.

\bibitem{rsa-2026}
RSA Conference, ``\$3.6B invested in agentic AI security: RSA 2026 funding report,''
April 2026.

\bibitem{eu-ai-act}
European Parliament, ``Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act),''
\emph{Official Journal of the European Union}, 2024.

\bibitem{rfc2119}
S.~Bradner, ``Key words for use in RFCs to Indicate Requirement Levels,''
RFC~2119, IETF, March 1997.

\bibitem{docker-security}
Docker Inc., ``Docker security: Protecting the Docker daemon socket,''
\url{https://docs.docker.com/engine/security/protect-access/}, 2023.

\bibitem{k8s-auth}
Kubernetes Project, ``Authentication,''
\url{https://kubernetes.io/docs/reference/access-authn-authz/authentication/}, 2024.

\bibitem{nvd}
NIST, ``National Vulnerability Database,''
\url{https://nvd.nist.gov/}, accessed April 2026.

\end{thebibliography}

\balance
\end{document}
