CVE-2026-10274: Server-Side Request Forgery in aem-mcp-server

Technical summary

The vulnerability resides in src/mcp-server.ts within the Axios Request Flow component's getAssetMetadata function. Improper validation of the assetPath argument allows an attacker with authenticated access to inject arbitrary URLs or paths, causing the server to issue requests on their behalf. This is a classic SSRF vulnerability (CWE-918) where attacker-controlled input flows directly into an HTTP client request without sanitization or allowlisting. The project does not follow semantic versioning, making version tracking impossible; the affected code is present up to commit b5f833aef9b5dfd17a5991b3b18a8a11edbdc583.

Business impact

If deployed in production, this vulnerability allows authenticated users to probe internal network resources, access metadata APIs, or redirect traffic to external attacker-controlled servers. In environments where the aem-mcp-server has network access to sensitive backend systems—such as asset repositories, configuration servers, or administrative interfaces—an attacker could exfiltrate data or execute unauthorized operations. The requirement for authentication reduces the risk surface, but any insider or compromised account holder becomes a potential attacker.

Affected systems

Any deployment of the indrasishbanerjee aem-mcp-server project up to commit b5f833aef9b5dfd17a5991b3b18a8a11edbdc583 is vulnerable. Because the project does not use semantic versioning, affected versions cannot be enumerated using traditional release tags. Organizations must audit their codebase to identify if they are running this project and, if so, check whether their local copy is at or prior to the vulnerable commit hash. Determine whether the getAssetMetadata function is exposed to authenticated users in your deployment context.

Exploitability

Exploitation requires valid authentication credentials to the aem-mcp-server, which raises the bar somewhat. However, the attack is straightforward: an authenticated user or internal application integrating with this service can call getAssetMetadata with a crafted assetPath parameter pointing to an internal IP, localhost service, or external URL. The Axios HTTP client will follow the instruction without restriction, making this a low-complexity attack once access is obtained. Public disclosure has occurred, and exploit code may be available, increasing real-world risk.

Remediation

The primary remediation is to update to a patched version once the maintainers release one. Until then, monitor the GitHub repository for security updates. If immediate remediation is needed, apply input validation to the assetPath parameter by enforcing an allowlist of permitted paths or domains, or by using a URL parsing library to reject suspicious schemes (file://, gopher://, etc.). Consider network segmentation to limit the server's ability to reach internal systems. Require strong authentication and monitor usage of the getAssetMetadata endpoint for anomalous requests to non-production hosts.

Patch guidance

Check the aem-mcp-server GitHub repository for security advisories and commits addressing this issue. Because the project lacks versioning, patches will be identified by commit hash or a security announcement from the maintainer. After the maintainer publishes a fix, pull the latest code and verify the vulnerable function has been hardened with input validation. Test thoroughly in a staging environment before deploying to production. If no patch is available after a reasonable grace period, implement compensating controls (see remediation_summary) or consider alternative solutions.

Detection guidance

Monitor access logs for the getAssetMetadata endpoint, especially requests with unusual assetPath values containing IP addresses, localhost references, or non-asset domain names. Look for failed connection attempts to internal systems originating from the aem-mcp-server process. Implement Web Application Firewall (WAF) rules to reject requests with suspicious URL schemes or internal IP patterns in the assetPath parameter. Use static analysis tooling to scan your codebase and identify if getAssetMetadata is called with user-supplied input that has not been validated.

Why prioritize this

Although the CVSS score of 6.3 is medium, the combination of public disclosure, available exploit code, and the ease of exploitation for authenticated users warrants prompt attention. The vulnerability is not currently in the CISA KEV catalog, suggesting limited active exploitation—but this may change quickly given public knowledge of the flaw. Prioritize based on whether your organization deploys aem-mcp-server and whether it has network access to sensitive backend systems; if yes, treat as high-priority for remediation planning.

Risk score, explained

The CVSS:3.1 score of 6.3 (MEDIUM) reflects authenticated access requirement (PR:L), network-based exploitability (AV:N), low attack complexity (AC:L), and impact on confidentiality, integrity, and availability (C:L/I:L/A:L). The score appropriately discounts the severity because authentication is mandatory. However, this score should not be misread as low-risk in environments where the attacker pool includes trusted insiders or where the server has privileged network position. Adjust your internal risk rating upward if the aem-mcp-server has access to high-value internal systems.

Frequently asked questions