Opera, possibly before 9.25, processes a 3xx HTTP CONNECT response before a successful SSL handshake, which allows man-in-the-middle attackers to execute arbitrary web script, in an https site's context, by modifying this CONNECT response to specify a 302 redirect to an arbitrary https web site.
Opera detects http content in https web pages only when the top-level frame uses https, which allows man-in-the-middle attackers to execute arbitrary web script, in an https site's context, by modifying an http page to include an https iframe that references a script file on an http site, related to "HTTP-Intended-but-HTTPS-Loadable (HPIHSL) pages."
Opera executes DOM calls in response to a javascript: URI in the target attribute of a submit element within a form contained in an inline PDF file, which might allow remote attackers to bypass intended Adobe Acrobat JavaScript restrictions on accessing the document object, as demonstrated by a web site that permits PDF uploads by untrusted users, and therefore has a shared document.domain between the web site and this javascript: URI. NOTE: the researcher reports that Adobe's position is "a PDF file is active content."
Multiple buffer overflows in Opera before 9.63 might allow (1) remote attackers to execute arbitrary code via a crafted text area, or allow (2) user-assisted remote attackers to execute arbitrary code via a long host name in a file: URL. NOTE: this might overlap CVE-2008-5178.
Opera before 9.63 does not block unspecified "scripted URLs" during the feed preview, which allows remote attackers to read existing subscriptions and force subscriptions to arbitrary feed URLs.
Cross-site scripting (XSS) vulnerability in Opera before 9.63 allows remote attackers to inject arbitrary web script or HTML via built-in XSLT templates.