The issue your vuln reporter is highlighting is the standard weakness of cookie-based CSRF protection. There are ways to plant cookies on a site - in particular, if the site doesn't use HTTP Strict Transport Security, a local network attacker (or anybody else with a man-in-the-middle position) can usually plant a cookie via HTTP that will also be sent in HTTPS (what happens when HTTP-set and HTTPS-set cookies are both set with the same name depends on the browser and sometimes also on the server, but an attacker can usually adjust for that).
However, this isn't actually vulnerable, even to the extent that double-submit cookies are generally a vulnerable method of CSRF prevention. The reason actually has nothing to do with either the cookie or the value. Instead, it's quite simple: a cross-site request from a browser simply can't set any custom header unless you deliberately configure CORS to allow this. If you haven't configured CORS to allow setting that header, then the actual value of the header can be random, constant, or even empty - and doesn't need to be validated beyond ensuring that the header is present at all - and you'll be safe from CSRF.
Note also that it's entirely possible to make CSRF protection stateless without introducing any (new) cookies. Have the server provide the client (either in page content or in an API response) with an HMAC of the session token (whether it be a random token, a JWT, or something else) using a key that is the same across the server cluster but not exposed to the clients. Use that HMAC as your anti-CSRF token, passed in whatever method you want (other than cookies or other automatically-sent content, of course; I recommend a header for the reason above but POST bodies work fine too). Validating an HMAC is extremely fast, the key is the only server-side data required and is both short and constant, it's guaranteed to be unique not only to every user but to every session of that user (at least, as unique as your session tokens themselves are, which is hopefully the case), and it doesn't expose any meaningful data about the session token even if an attacker learns the CSRF token value somehow.
