Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-10274

CVE-2026-10274: AEM MCP Server SSRF Vulnerability

CVE-2026-10274 is a server-side request forgery flaw in aem-mcp-server affecting the getAssetMetadata function. Attackers can exploit the assetPath parameter remotely. This article covers technical details, impact, and mitigation.

Published:

CVE-2026-10274 Overview

CVE-2026-10274 is a Server-Side Request Forgery (SSRF) vulnerability in the indrasishbanerjee/aem-mcp-server project, affecting the codebase up to commit b5f833aef9b5dfd17a5991b3b18a8a11edbdc583. The flaw resides in the getAssetMetadata function within src/mcp-server.ts, part of the Axios Request Flow component. An attacker who can supply the assetPath argument can manipulate it to coerce the server into issuing arbitrary HTTP requests. The exploit has been publicly disclosed. The project does not use versioning, so affected and unaffected releases cannot be enumerated. The maintainer was notified through a GitHub issue but has not responded.

Critical Impact

Remote attackers with low privileges can abuse getAssetMetadata to issue server-side requests to internal resources, enabling reconnaissance of internal services and potential access to metadata endpoints.

Affected Products

  • indrasishbanerjee/aem-mcp-server up to commit b5f833aef9b5dfd17a5991b3b18a8a11edbdc583
  • File src/mcp-server.ts containing the getAssetMetadata function
  • Axios Request Flow component used for outbound HTTP requests

Discovery Timeline

  • 2026-06-01 - CVE-2026-10274 published to NVD
  • 2026-06-01 - Last updated in NVD database

Technical Details for CVE-2026-10274

Vulnerability Analysis

The vulnerability is classified as Server-Side Request Forgery [CWE-918]. The getAssetMetadata function in src/mcp-server.ts accepts an assetPath argument and passes it to an Axios HTTP client without sufficient validation of the destination. An authenticated attacker with low privileges can supply a crafted assetPath that redirects the outbound request to an arbitrary host or internal network resource. Because the request originates from the server, it bypasses network controls that restrict direct client access to internal services. The attack can be launched remotely over the network and does not require user interaction.

Root Cause

The root cause is missing validation and allowlisting of the assetPath argument before it is consumed by the Axios client. The function trusts caller-supplied input to construct or select the request target, allowing attackers to override the intended Adobe Experience Manager (AEM) destination. No URL parsing, scheme restriction, or host allowlist is enforced in the vulnerable code path.

Attack Vector

An attacker with valid low-privilege access to the MCP server endpoint invokes the getAssetMetadata tool and supplies an assetPath that resolves to an attacker-controlled or internal URL. The server then issues an HTTP request to that destination using the privileges and network position of the server process. Targets typically include cloud metadata services such as 169.254.169.254, internal admin interfaces, and localhost-bound services. Confidentiality, integrity, and availability impacts are each rated low because the response handling primarily exposes metadata content rather than executing returned payloads.

No verified public exploit code is included here. Technical details are available in the GitHub Issue Discussion and the VulDB CVE-2026-10274 Details entry.

Detection Methods for CVE-2026-10274

Indicators of Compromise

  • Outbound HTTP requests from the aem-mcp-server process to non-AEM hosts, RFC1918 ranges, or 127.0.0.1
  • Requests to cloud metadata endpoints such as http://169.254.169.254/ originating from the server
  • Unusual assetPath values in MCP server request logs containing full URLs, IP literals, or non-standard schemes

Detection Strategies

  • Inspect application logs for getAssetMetadata invocations whose assetPath parameter is a fully qualified URL or contains an IP address rather than a relative AEM path
  • Correlate MCP server process telemetry with egress network connections to flag deviations from the expected AEM backend host
  • Apply a Server-Side Request Forgery [CWE-918] detection rule that alerts on internal IP ranges appearing in outbound URL fields

Monitoring Recommendations

  • Forward Node.js runtime and reverse proxy logs to a centralized analytics platform and alert on anomalous destination hosts
  • Monitor egress traffic from hosts running aem-mcp-server for connections to cloud metadata services and link-local addresses
  • Track GitHub repository activity on indrasishbanerjee/aem-mcp-server for any maintainer response or patch commit

How to Mitigate CVE-2026-10274

Immediate Actions Required

  • Restrict access to the aem-mcp-server endpoint to trusted users and networks until a fix is available
  • Place the server behind an egress proxy that allowlists only the intended AEM backend host and port
  • Block outbound access from the server host to RFC1918 ranges, link-local 169.254.0.0/16, and 127.0.0.0/8 where not required
  • Audit recent getAssetMetadata calls for suspicious assetPath values pointing to non-AEM destinations

Patch Information

No official patch is available at the time of publication. According to the VulDB CVE-2026-10274 Details, the maintainer was notified through GitHub Issue #3 but has not responded. The project does not use semantic versioning, so consumers must track the upstream commit history in the GitHub Repository for AEM MCP and apply any future fix commit manually.

Workarounds

  • Wrap the getAssetMetadata function with an input validator that rejects any assetPath containing a URL scheme, hostname, or IP literal
  • Configure the underlying Axios client with a fixed baseURL and disable following redirects to prevent host override
  • Enforce an allowlist of permitted AEM hosts at the network layer using firewall rules or a forward proxy
  • Run the MCP server in a network segment with no route to internal management interfaces or cloud metadata services
bash
# Example egress restriction using iptables to block cloud metadata access
iptables -A OUTPUT -m owner --uid-owner aem-mcp -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner aem-mcp -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner aem-mcp -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner aem-mcp -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner aem-mcp -d 192.168.0.0/16 -j REJECT

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.