The custom HTTP header works as a defense in and of itself. Actually, one rudimentary form of CSRF protection is to simply set a custom header to a constant non secret value and then check for it server side. This protection is sometimes applied unknowingly by simply requireing certain content-type headers.
OWASP describes this technique:
The limitation to this is, as you say yourself, Flash vulnerabilities:
[B]ypasses of this defense using Flash were documented as early as 2008 and again as recently as 2015 by Mathias Karlsson to exploit a CSRF flaw in Vimeo. Riyaz Walikar from Appsecco Labs was able to exploit this even in early 2019 using older versions of Firefox and also in some recent versions of Chrome (with a bit of user involvement). Since we cannot the control the versions of browser end user uses nor depend on it for their security, this technique is not recommended as a primary defense in measure.
The last sentence is key here. If the victim uses a vulnerable combination of browser and Flash plugin, you can exploit this. If not, you are probably out of luck (unless a permissive CORS policy lets you set the header).