No it's not possible to circumvent this CSRF-protection in a classical CSRF attack. Using the user-agent- header to submit the anti-CSRF-token is just like using any custom header, which is one of the currently preferred methods of CSRF-protection.

An attacker could only 'fake' the user agent via a XSS, or a malign browser extension (or browser). But in such a case the attacker wouldn't have to use a CSRF-attack to do what he wants, because XSS > CSRF.

No it's not possible to circumvent this CSRF-protection in a classical CSRF attack. Using the user-agent- header to submit the anti-CSRF-token is just like using any custom header, which is one of the currently preferred methods of CSRF-protection.

An attacker could only 'fake' the user agent via a XSS, or a malign browser extension (or browser). But in such a case the attacker wouldn't have to use a CSRF-attack to do what he wants, because XSS > CSRF.

I also found a related answer from 2016: How do defend CSRF against requests that pretend not to be browsers? Which concluded:

"The attacker can not succesfully modify the User-Agent header unless you allow her to do so."