An interesting one. If the CSRF token identifies the user as well, then I can't see it being a vulnerability in itself. Some systems can work without cookies (although you mention this one is designed to work with cookies) and can pass around an auth token in a hidden form field that is used as both a session identifier and an anti-CSRF token.
In your case, as the system does use cookies, it appears to be an authorisation flaw.
You should try some further tests to find out if this is a vulnerability:
- Try issuing the request without the cookie after the "active session" would have normally timed out.
- Try creating two sessions and find out if the CSRF token from one session can be used in the other.
- The creating two sessions under different user accounts and find out if the token from one user can be used in the other. If successful find out which user was associated to the request.
- Try an invalid CSRF token.
- Try a missing CSRF token.
Note for creating two sessions you would need a separate browser or you could create one in private/incognito mode.
By "active session" I am referring to a current short-term session on the website (e.g. one with a sliding expiration of 15-30 minutes or so). For sites that implement "remember me" functionality this should be implemented by a different mechanism that creates a new "active session" whenever the user returns, and a new CSRF token to go with it (rather than just creating a long active session).
If any of the above are still successful then you have discovered a session management flaw.