It doesn't look like that to me. There's a exploit demo here[1]. If the exploit worked in Chrome or Firefox as well as Chromodo, that would clearly indicate th

It doesn't look like that to me. There's a exploit demo here[1]. If the exploit worked in Chrome or Firefox as well as Chromodo, that would clearly indicate the problem is with the website, not with Chromodo. I find it hard to believe that no one at Google or Comodo would test the exploit page in Chrome or Firefox. There's discussion on the original bug and here[2] that Comodo did push out a fix, and it sure sounds like that was a fix to Chromodo. Secondly, looking at the exploit demo, it looks like it does 2 postMessage()s, once in each direction, both using execCode. If it was a vulnerability purely in https://ssl.comodo.com https://ssl.comodo.com the 2nd postMessage() looks like it would fail, because there isn't any code around to receive it. Thirdly, looking at the exploit demo, it has a text box with which you can specify which site you want to attack. So you could change that to https://google.com https://google.com or https://news.ycombinator.com https://news.ycombinator.com . If the exploit only worked against a single site, it wouldn't make sense to provide a text box allowing you to change which site to attack. Taviso's description is a bit misleading. It doesn't sound like the action that Comodo took is to directly disable the same origin policy, but rather to provide an API with which attackers can bypass the same origin policy. From a security perspective that does effectively disable the same origin policy, but from an attack understanding point of view, it's a bit different. Full disclosure, I work at Google, but not on Project Zero. [1] https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=225988 https://bugs.chromium.org/p/project-zero/issues/attachmentTe... [2] https://bugs.chromium.org/p/project-zero/issues/detail?id=713 https://bugs.chromium.org/p/project-zero/issues/detail?id=71...