The 'authenticated attacker' qualifier in this CVE obscures a critical truth: if customer IDs are predictable, authentication provides almost no security boundary. The description explicitly states IDs are 'predictable' — if they're sequential integers or timestamp-based (rather than cryptographically random UUIDs), any user who can register a free account can enumerate every customer's data. That makes this functionally equivalent to an unauthenticated vulnerability, yet CVSS rates it Medium based on the assumption that authentication is a meaningful barrier.
The endpoint name — customer-default-source — is revealing. This is payment infrastructure language. You need to determine exactly what this endpoint returns: does it expose payment method metadata, processor references, billing history, or tokenized payment identifiers? If it does, the severity is misclassified. Enumerating customer IDs combined with payment data is the first domino in a fraud chain — enabling chargeback fraud, targeted phishing of high-value accounts, and social engineering against support staff.
Sequential or timestamp-derived IDs are a developer convenience choice, not an accident. Using uuid4() feels like overhead when integers 'work fine' — but this choice ships an API where the client controls which object to access, with no server-side verification that the requested object belongs to the requesting principal. The real question isn't whether this endpoint was patched; it's whether Flowise's development workflow has any security review that flags 'client sends ID, server returns data' as a red flag. Without that, adjacent endpoints using the same ID format are likely vulnerable.
Assume historical exploitation is possible. If IDs were sequential, anyone who registered an account in 2022 could have silently scraped data for years before disclosure. CVSS scores vulnerabilities as if assessed fresh — it doesn't account for silent historical harvesting. Your severity calculus should include: what data was already compromised?
What to check: confirm the customer ID format in your Flowise deployment (UUID v4 is safe; sequential integers are not), determine whether the patch added proper authorization checks or merely obfuscated the enumeration vector, and audit other endpoints that accept customer ID parameters for the same vulnerability pattern.