GHSA-6f9w-9hf2-5rg3: SSRF
Summary
Error paths reflect raw upstream response bodies and internal exception messages back to the caller instead of a sanitized, generic message. When the server is pointed at (or redirected/SSRF'd to) a host that returns a non-CKAN response, or when an internal exception occurs, the caller receives verbatim upstream content and internal detail (hostnames, internal IPs, DB errors, stack fragments).
Affected code
src/utils/http.ts — the entire decoded upstream body is embedded in the thrown error, which formatCkanError returns to the tool result:
js } else { throw new CkanApiError( CKAN API returned success=false: ${JSON.stringify(decodedData)}, // full body reflected undefined, action ); }
src/worker.ts — the catch-all handler returns the raw Error.message in the JSON-RPC data field:
js return new Response(JSON.stringify({ jsonrpc: '2.0', error: { code: -32603, message: 'Internal error', data: error instanceof Error ? error.message : String(error) }, // raw internal message id: null }), { status: 500, ... });
Impact
- Reflects arbitrary upstream response content to the caller. Combined with the SSRF vectors (advisories #01/#06), an attacker can use this as the read channel: point the server at an internal endpoint and receive its body inside the success=false error string (turning otherwise-blind SSRF into a semi-blind/return-value SSRF for any host that reaches the guards). - Leaks internal operational detail via exception messages: node error codes and target addresses (e.g. ECONNREFUSED 169.254.169.254:80), which confirm internal reachability and infrastructure, and any stack/path fragments an upstream includes. - Aids reconnaissance and error-oracle attacks against the deployment.
Severity is Low on its own (the server holds no credentials of its own and sends no auth upstream), but it meaningfully amplifies the SSRF findings by providing a response-content channel.
Proof of concept
poc/error-disclosure-poc.mjs reproduces both paths and shows an upstream body (containing a simulated DB error with an internal IP) and an internal ECONNREFUSED 169.254.169.254 message being reflected to the caller.
Remediation
- Return generic, action-scoped error messages to the caller; log the detailed upstream body/exception server-side only. - Do not embed JSON.stringify(decodedData) in caller-visible errors; cap and redact any reflected content. - In the Workers catch-all, omit error.message from the response data (or replace with a correlation id) in production.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/@aborruso/ckan-mcp-serverto a version that resolves this vulnerability.Fixed in 0.4.112 - Configuration
In `src/worker.ts` catch-all handler, do not return the raw `Error.message` to the caller in the JSON-RPC `data` field. Instead omit `error.message` from `data` (or return only a generic error and a correlation id), while keeping detailed error information server-side only.
src/worker.ts (catch-all handler) JSON-RPC error response `data` field = omit `error.message` from `data` (or redact/replace with a correlation id) - Configuration
In `src/utils/http.ts`, remove embedding the entire decoded upstream body (e.g., `JSON.stringify(decodedData)`) in the thrown error that is later surfaced to the caller. Keep upstream body details for server-side logging only.
src/utils/http.ts Thrown error content = do not embed full decoded upstream body / JSON.stringify(decodedData) in caller-visible errors - Configuration
In the CKAN error path (e.g., where the message includes `CKAN API returned success=false: ${JSON.stringify(decodedData)}`), replace the caller-visible message with a generic, action-scoped error and redact any reflected upstream body content.
src/utils/http.ts + formatCkanError CKAN error message construction = generic, action-scoped error message; redact upstream body - Operational
After changing error handling, ensure detailed exception messages/upstream response bodies are logged server-side only (redacted) and not returned to production callers; use correlation IDs for troubleshooting instead of exposing internal node error codes/addresses/DB errors/stack fragments.
Event History
Frequently Asked Questions
Under what conditions can an attacker obtain sensitive information through this issue?
The server must encounter an internal exception or contact an upstream host that returns a non-CKAN response. The impact is greater if an attacker can influence the upstream destination, including through the referenced SSRF vectors, because the full upstream response body can be reflected to the caller.
What information may be exposed to a caller?
Responses can include verbatim upstream content and internal exception details. Examples identified include hostnames, internal IP addresses, database errors, and stack fragments.
How can I identify whether an instance is exhibiting the vulnerable behavior?
Trigger an error path or a non-CKAN upstream response and inspect the JSON-RPC error response. An affected instance returns the raw error message in the error data field rather than only a generic internal-error message.
What should be prioritized if patching cannot happen immediately?
Limit who can invoke the server and prevent untrusted users from influencing or redirecting its upstream destination. This reduces the opportunity to use error handling to retrieve arbitrary upstream response content or internal details.