CVE-2026-42860: Open edX Enterprise SSRF Vulnerability

CVE-2026-42860 Overview

CVE-2026-42860 is a Server-Side Request Forgery (SSRF) vulnerability in the Open edX edx-enterprise Service app. The flaw exists in the sync_provider_data endpoint of SAMLProviderDataViewSet, which fetches SAML metadata from a URL stored in SAMLProviderConfig.metadata_source. Authenticated users with the Enterprise Admin role can set this field to an arbitrary URL through the SAMLProviderConfigViewSet PATCH endpoint, then trigger a server-side HTTP request by calling sync_provider_data. The fetch in fetch_metadata_xml() passes the URL directly to requests.get() without scheme enforcement, IP filtering, or timeout. Affected versions span 7.0.2 through 7.0.4, and the issue is fixed in 7.0.5.

Critical Impact

Authenticated Enterprise Admin users can coerce the Open edX server into making arbitrary outbound HTTP requests, enabling internal network reconnaissance, metadata service abuse, and exposure of sensitive internal services [CWE-918].

Affected Products

• Open edX edx-enterprise 7.0.2
• Open edX edx-enterprise 7.0.3
• Open edX edx-enterprise 7.0.4

Discovery Timeline

• 2026-05-11 - CVE-2026-42860 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-42860

Vulnerability Analysis

The vulnerability resides in the SAML provider configuration workflow of the Open edX Enterprise Service app. An authenticated user with the Enterprise Admin role updates the metadata_source field on a SAMLProviderConfig object via a PATCH request to SAMLProviderConfigViewSet. The field accepts any string, with no validation that the value points to a legitimate SAML identity provider metadata endpoint.

When the user subsequently invokes the sync_provider_data endpoint on SAMLProviderDataViewSet, the backend reads the attacker-controlled URL and passes it to fetch_metadata_xml(). That function calls requests.get() directly on the supplied URL. The request inherits the server's network position, granting access to internal-only services that external clients cannot reach.

Root Cause

The root cause is missing input validation on a user-controlled URL before issuing a server-side HTTP request. The fetch_metadata_xml() helper does not enforce an allowlist of schemes, reject loopback or private IP ranges, or apply a request timeout. This pattern maps to CWE-918: Server-Side Request Forgery.

Attack Vector

An authenticated Enterprise Admin sends a PATCH request to SAMLProviderConfigViewSet, setting metadata_source to a target such as http://169.254.169.254/latest/meta-data/ for cloud instance metadata, http://127.0.0.1:6379/ for a local Redis service, or file:// and gopher:// schemes depending on requests behavior. The attacker then calls sync_provider_data, causing the server to issue the outbound request. Response content or error patterns may leak via API responses or backend logs. The lack of timeout also permits long-hanging connections that consume worker resources.

No verified public exploit code is available. Refer to the GitHub Security Advisory GHSA-64cv-vxpr-j6vc for vendor details.

Detection Methods for CVE-2026-42860

Indicators of Compromise

• Unexpected PATCH requests to SAMLProviderConfigViewSet modifying the metadata_source field to non-IdP URLs, internal IPs, or non-HTTPS schemes.
• Calls to the sync_provider_data endpoint immediately following metadata_source changes by the same user session.
• Outbound HTTP requests from Open edX application servers to RFC1918 ranges, link-local addresses (169.254.169.254), or localhost.
• Application logs from fetch_metadata_xml() showing non-XML responses or connection errors to unusual hosts.

Detection Strategies

• Audit Django application logs for SAMLProviderConfig mutations and correlate with subsequent sync_provider_data invocations from the same actor.
• Inspect egress traffic from Open edX hosts for HTTP calls to internal management interfaces, cloud metadata endpoints, or non-standard ports.
• Alert on Enterprise Admin accounts performing rapid sequential PATCH and sync operations outside normal SAML onboarding windows.

Monitoring Recommendations

• Forward web server and Django audit logs to a centralized SIEM and build queries for metadata_source field changes.
• Enable network flow monitoring on application server egress interfaces and baseline expected destinations for SAML metadata fetches.
• Monitor Enterprise Admin role assignments and review the principle of least privilege for users granted this capability.

How to Mitigate CVE-2026-42860

Immediate Actions Required

• Upgrade edx-enterprise to version 7.0.5 or later, which contains the official fix.
• Audit all existing SAMLProviderConfig.metadata_source values for suspicious URLs targeting internal hosts, loopback addresses, or cloud metadata services.
• Review the list of accounts holding the Enterprise Admin role and revoke access for users who no longer require it.
• Rotate any credentials, tokens, or cloud instance metadata that may have been exposed via SSRF prior to patching.

Patch Information

The maintainers fixed the issue in edx-enterprise version 7.0.5. The patch enforces validation on URLs passed to fetch_metadata_xml(). See the GitHub Security Advisory GHSA-64cv-vxpr-j6vc for the complete advisory and remediation notes.

Workarounds

• Restrict outbound network access from Open edX application servers using egress firewall rules that block traffic to RFC1918 ranges and 169.254.169.254.
• Place the Open edX backend behind an outbound proxy that allowlists only known SAML identity provider hosts.
• Temporarily remove the Enterprise Admin role from non-essential accounts until the upgrade is applied.
• Disable or restrict access to the sync_provider_data endpoint at the reverse proxy layer if patching cannot occur immediately.

# Example egress restriction using iptables to block cloud metadata access
iptables -A OUTPUT -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -d 127.0.0.0/8 ! -o lo -j REJECT
iptables -A OUTPUT -d 10.0.0.0/8 -p tcp -m tcp --dport 80 -j REJECT
iptables -A OUTPUT -d 172.16.0.0/12 -p tcp -m tcp --dport 80 -j REJECT
iptables -A OUTPUT -d 192.168.0.0/16 -p tcp -m tcp --dport 80 -j REJECT