VULNERABILITY DETAILS
I find that Chrome doesn't check if the "type" specified on <embed> tag matches the Content-Type specified in the HTTP response header. Especially unlike <object> element, <embed> doesn't have a "typemustmatch" attribute. The spec states: "If both the type attribute and the src attribute are present, then the type attribute must specify the same type as the explicit Content-Type metadata of the resource given by the src attribute."[1] Thus, I think websites do expect browsers to enforce this requirement. It's worth to mention that the <embed> element setup Step 3.2 seems to contradict with the above statement by saying that:
>    2. Determine the type of the content being embedded, as follows (stopping at the first substep that determines the type):
>     1. If the element has a type attribute, and that attribute's value is a type that a plugin supports, then the value of the type attribute is the content's type.

An attack scenario is: An online forum website allows users to upload arbitrary pictures as avatars to the server, and to embed arbitrary Flash media in their posts by providing external URLs. An attacker can create a malicious Flash media, change its filename extension to ".png", and upload it to the website. Provided he also knows the URL on which this "flash-as-a-picture" resides, he then embeds this URL as a Flash media in a post. Whenever a user visits this post, Chrome will run the Flash when he clicks "Allow". If this file is located on the domain as the HTML (not best practice, but common for small websites), and crossdomain.xml allows this domain, this malicious Flash can easily bypass CSRF.

PoC: https://xiaoyinl.github.io/kkp452w/ (not public)

[1] https://html.spec.whatwg.org/multipage/iframe-embed-object.html#attr-embed-type

VERSION
Chrome Version: [63.0.3239.132] + [stable]
Operating System: Windows 10 x64 Version 1709

REPRODUCTION CASE
1. Navigate to https://xiaoyinl.github.io/kkp452w/
2. Click to enable Adobe Flash Player