The Tomcat CorsFilter does not add a Vary header to the response to indicate that the response can vary for different values of the Origin header in the request. This poses problems for caches, as they can yield cached Tomcat responses where they shouldn't because they don't know that a different Origin value may yield a different response. The filter should add the Origin value to the Vary header of the response. Per the CORS standard (https://www.w3.org/TR/cors/#resource-implementation): "Resources that wish to enable themselves to be shared with multiple Origins but do not respond uniformly with "*" must in practice generate the Access-Control-Allow-Origin header dynamically in response to every request they wish to allow. As a consequence, authors of such resources should send a Vary: Origin HTTP header or provide other appropriate control directives to prevent caching of such responses, which may be inaccurate if re-used across-origins." Found this on multiple versions of the Tomcat CorsFilter (7, 8.0 and 8.5). A quick code inspection shows that this isn't present in /trunk either. Found with multiple Java versions, at least including Oracle JDK 8u131 64-bit on Windows 10 64-bit. Seems to be unrelated to the connectors (found on the HTTP NIO and BIO connectors) To reproduce, enable the CorsFilter in Tomcat's web.xml, and send an HTTP request that includes both a Host and an Origin header, where the Origin should be different than the Host, and should be a value that is configured to be allowed by the CorsFilter. Inspect the response headers. A 'Vary: Origin' header should be in the response, but isn't.
This issue will be fixed in 9.0.0.M22, 8.5.16, 8.0.45 and 7.0.79. Thanks.
This is CVE-2017-7674