CVE-2026-33060: CKAN MCP Server SSRF Vulnerability

CVE-2026-33060 Overview

CVE-2026-33060 is a Server-Side Request Forgery (SSRF) vulnerability affecting CKAN MCP Server, a tool for querying CKAN open data portals. The vulnerability exists in multiple tools including ckan_package_search and sparql_query that accept a base_url parameter, enabling HTTP requests to arbitrary endpoints without proper validation or restriction.

The flaw allows attackers to abuse the server's ability to make outbound requests, potentially targeting internal network services, cloud metadata endpoints, and other sensitive resources that should not be accessible from external sources.

Critical Impact

Attackers can leverage this SSRF vulnerability to perform internal network scanning, steal cloud metadata including IAM credentials via IMDS at 169.254.169.254, and potentially execute SQL/SPARQL injection through unsanitized query parameters.

Affected Products

• CKAN MCP Server versions prior to 0.4.85

Discovery Timeline

• 2026-03-20 - CVE-2026-33060 published to NVD
• 2026-03-20 - Last updated in NVD database

Technical Details for CVE-2026-33060

Vulnerability Analysis

This SSRF vulnerability (CWE-918) stems from insufficient input validation on the base_url parameter across multiple CKAN MCP Server tools. The affected components include ckan_package_search, sparql_query, and ckan_datastore_search_sql, all of which accept arbitrary base URLs and make HTTP requests without proper restrictions.

The vulnerability is particularly dangerous in cloud environments where instance metadata services (IMDS) can be reached at link-local addresses. A CKAN portal client has no legitimate reason to contact cloud metadata or internal network services, yet the application performs no URL validation to prevent such access.

Exploitation requires the attacker to control the base_url parameter, typically achieved through prompt injection techniques. Once an attacker gains control of this parameter, they can direct the server to make requests to arbitrary internal or external endpoints.

Root Cause

The root cause is a complete lack of URL validation on the base_url parameter. The vulnerable code fails to implement:

• Private IP blocking for RFC 1918 address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
• Link-local address blocking (169.254.x.x)
• Cloud metadata endpoint blocking (specifically 169.254.169.254)
• Protocol restrictions to prevent file:// or other dangerous schemes

Additionally, the sparql_query and ckan_datastore_search_sql tools expose injection surfaces through unsanitized query parameters, compounding the risk beyond simple SSRF.

Attack Vector

The attack leverages the network-accessible base_url parameter to redirect server-side HTTP requests. An attacker who can influence the base_url value through prompt injection can:

1. Internal Network Reconnaissance: Scan internal network services by observing response times and error messages
2. Cloud Metadata Theft: Access AWS/GCP/Azure instance metadata services to steal IAM credentials and other sensitive configuration data
3. Query Injection: Combine SSRF with SQL or SPARQL injection through the unsanitized query parameters in sparql_query and ckan_datastore_search_sql tools

The vulnerability manifests when the server processes requests with malicious base_url values pointing to internal resources. For example, an attacker could specify http://169.254.169.254/latest/meta-data/iam/security-credentials/ as the base URL to extract cloud IAM credentials. See the GitHub Security Advisory for additional technical details.

Detection Methods for CVE-2026-33060

Indicators of Compromise

• Outbound HTTP requests from CKAN MCP Server to link-local addresses (169.254.x.x), particularly the cloud metadata endpoint at 169.254.169.254
• Unexpected requests to private IP ranges (RFC 1918) from the application server
• SPARQL or SQL queries containing suspicious URL parameters or injection patterns
• Anomalous network traffic patterns indicating internal port scanning activity

Detection Strategies

• Monitor network traffic for outbound connections from CKAN MCP Server to internal IP ranges or cloud metadata endpoints
• Implement alerting on DNS queries for internal hostnames originating from the application
• Review application logs for base_url parameter values containing private IPs, localhost, or metadata service addresses
• Deploy web application firewall (WAF) rules to detect and block SSRF patterns in request parameters

Monitoring Recommendations

• Enable detailed logging for all HTTP requests made by CKAN MCP Server, including the destination URL
• Set up real-time alerts for any attempted access to 169.254.169.254 or other metadata endpoints
• Monitor for unusual response patterns that may indicate successful internal service enumeration
• Track prompt injection attempts that may be used to control the base_url parameter

How to Mitigate CVE-2026-33060

Immediate Actions Required

• Upgrade CKAN MCP Server to version 0.4.85 or later immediately
• If immediate upgrade is not possible, restrict network egress from the application server to only necessary external endpoints
• Implement network-level controls to block outbound access to RFC 1918 addresses and cloud metadata endpoints
• Review logs for any evidence of prior exploitation attempts

Patch Information

The vulnerability has been addressed in CKAN MCP Server version 0.4.85. The fix implements proper URL validation on the base_url parameter to prevent requests to internal networks and cloud metadata services. For additional details, refer to the GitHub Security Advisory.

Workarounds

• Deploy a network egress firewall to block outbound connections to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and link-local addresses (169.254.0.0/16)
• Configure cloud provider security groups to deny access to the instance metadata service from application workloads
• Implement an allowlist of permitted base_url domains at the application or proxy level
• Use IMDSv2 (token-based) on AWS instances to add an additional layer of protection against metadata theft

# Example: Block metadata endpoint access using iptables
iptables -A OUTPUT -d 169.254.169.254 -j DROP

# Example: AWS - Require IMDSv2 for instance metadata
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens required \
    --http-endpoint enabled