CVE-2026-10274
Server-Side Request Forgery in aem-mcp-server
Publication date: 2026-06-01
Last updated on: 2026-06-01
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| indrasishbanerjee | aem-mcp-server | to b5f833aef9b5dfd17a5991b3b18a8a11edbdc583 (exc) |
| indrasishbanerjee | aem-mcp-server | to b5f833aef9b5dfd17a5991b3b18a8a11edbdc583 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-918 | The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability is a Server-Side Request Forgery (SSRF) that can lead to high confidentiality risks by allowing attackers to probe or access internal network resources. This type of exposure can potentially lead to unauthorized access to sensitive data.
Such unauthorized access or data exposure could impact compliance with data protection regulations like GDPR or HIPAA, which require strict controls over personal and sensitive information to prevent data breaches.
However, the provided context and resources do not explicitly discuss or analyze the direct impact of this vulnerability on compliance with these or other common standards and regulations.
Can you explain this vulnerability to me?
This vulnerability is a Server-Side Request Forgery (SSRF) found in the aem-mcp-server project, specifically in the getAssetMetadata function. The function accepts an assetPath argument that is not properly validated before being used in an HTTP request via the Axios client. An attacker can manipulate this argument to make the server send requests to arbitrary internal or external hosts, potentially accessing unauthorized resources.
The vulnerability allows an attacker to craft absolute or protocol-relative URLs that cause the server to make outbound requests to attacker-controlled or internal network addresses. This flaw arises because the server does not restrict assetPath to valid AEM content roots and does not block requests to sensitive network ranges.
How can this vulnerability impact me? :
The SSRF vulnerability can impact you by allowing an attacker to make the server perform unauthorized requests to internal or external systems. This can lead to several security risks:
- High confidentiality risk: Attackers may probe or access internal network resources that are otherwise inaccessible.
- Low integrity risk: Limited ability to change state unless the targeted endpoints support GET-compatible state changes.
- Low availability risk: Potential for resource exhaustion or scanning attacks through repeated outbound requests.
Overall, the vulnerability can be exploited remotely if the attacker can invoke the vulnerable function and the server has network egress permissions to the target hosts.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for unusual outbound HTTP requests initiated by the vulnerable server, especially those targeting internal or unexpected external hosts. Since the vulnerability involves manipulation of the assetPath parameter to trigger server-side request forgery (SSRF), detection involves identifying requests to the getAssetMetadata function or equivalent HTTP/JSON-RPC methods with suspicious assetPath values.
A practical detection method is to start a local listener on a test machine and send crafted requests with malicious assetPath values (e.g., URLs pointing to the listener) to see if the server makes outbound requests to that listener, confirming SSRF.
Network monitoring commands could include using tools like tcpdump or Wireshark to capture outbound traffic from the server to unexpected destinations. For example:
- tcpdump -i <interface> host <server_ip> and tcp port 80 or 443
- tcpdump -i <interface> src <server_ip> and dst net <internal_network_range>
Additionally, reviewing server logs for calls to getAssetMetadata with assetPath parameters containing absolute URLs or protocol-relative URLs (e.g., starting with http:// or //) can help detect exploitation attempts.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include restricting the getAssetMetadata function to only accept validated AEM DAM paths and rejecting any absolute or protocol-relative URLs in the assetPath parameter.
Specifically, the assetPath should be required to start with an approved AEM asset root path such as /content/dam/, and any outbound requests should be resolved relative to the AEM base URL.
Additional mitigations include blocking requests to loopback, link-local, RFC1918 (private IP ranges), and metadata service destinations after DNS resolution to prevent SSRF to internal resources.
Implement regression tests to detect malicious payloads and ensure that the server does not process unauthorized assetPath values.