https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 13:51:50 +0000 https://cve.radiocsirt.org/vuln/certfr-2017-avi-367 certfr-2017-avi-367 https://cve.radiocsirt.org/vuln/certfr-2017-avi-367 https://cve.radiocsirt.org/vuln/cnvd-2017-11544 cnvd-2017-11544 https://cve.radiocsirt.org/vuln/cnvd-2017-11544 https://cve.radiocsirt.org/vuln/euvd-2026-73522 EUVD-2026-73522 https://cve.radiocsirt.org/vuln/euvd-2026-73522 https://cve.radiocsirt.org/vuln/fkie_cve-2017-5664 <p>The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method. If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTTP method. The Default Servlet in Apache Tomcat 9.0.0.M1 to 9.0.0.M20, 8.5.0 to 8.5.14, 8.0.0.RC1 to 8.0.43 and 7.0.0 to 7.0.77 did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page. Notes for other user provided error pages: (1) Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must must ensure that they handle any error dispatch as a GET request, regardless of the actual method. (2) By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.</p> <p>The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method. If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTTP method. The Default Servlet in Apache Tomcat 9.0.0.M1 to 9.0.0.M20, 8.5.0 to 8.5.14, 8.0.0.RC1 to 8.0.43 and 7.0.0 to 7.0.77 did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page. Notes for other user provided error pages: (1) Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must must ensure that they handle any error dispatch as a GET request, regardless of the actual method. (2) By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2017-5664 https://cve.radiocsirt.org/vuln/ghsa-jmvv-524f-hj5j <p><strong>Affected:</strong> Maven: org.apache.tomcat:tomcat</p> <p>The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method. If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTTP method. The Default Servlet in Apache Tomcat 9.0.0.M1 to 9.0.0.M20, 8.5.0 to 8.5.14, 8.0.0.RC1 to 8.0.43 and 7.0.0 to 7.0.77 did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page. Notes for other user provided error pages: (1) Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must must ensure that they handle any error dispatch as a GET request, regardless of the actual method. (2) By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.</p> <p><strong>Affected:</strong> Maven: org.apache.tomcat:tomcat</p> <p>The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method. If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTTP method. The Default Servlet in Apache Tomcat 9.0.0.M1 to 9.0.0.M20, 8.5.0 to 8.5.14, 8.0.0.RC1 to 8.0.43 and 7.0.0 to 7.0.77 did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page. Notes for other user provided error pages: (1) Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must must ensure that they handle any error dispatch as a GET request, regardless of the actual method. (2) By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.</p> https://cve.radiocsirt.org/vuln/ghsa-jmvv-524f-hj5j https://cve.radiocsirt.org/vuln/gsd-2017-5664 gsd-2017-5664 https://cve.radiocsirt.org/vuln/gsd-2017-5664 https://cve.radiocsirt.org/vuln/opensuse-su-2024:11468-1 <p>tomcat-9.0.36-8.4 on GA media</p> <p>tomcat-9.0.36-8.4 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2024:11468-1 https://cve.radiocsirt.org/vuln/rhsa-2017:1801 <p>openssl: OCSP Status Request extension unbounded memory growth openssl: ECDSA P-256 timing attack key recovery SSL/TLS: Malformed plain-text ALERT packets could cause remote DoS log4j: Socket receiver deserialization vulnerability tomcat: Incorrect handling of pipelined requests when send file was used tomcat: Calls to application listeners did not use the appropriate facade object tomcat: Security constrained bypass in error page mechanism tomcat: Vary header not added by CORS filter leading to cache poisoning log4j: deserialization of untrusted data in SocketServer</p> <p>openssl: OCSP Status Request extension unbounded memory growth openssl: ECDSA P-256 timing attack key recovery SSL/TLS: Malformed plain-text ALERT packets could cause remote DoS log4j: Socket receiver deserialization vulnerability tomcat: Incorrect handling of pipelined requests when send file was used tomcat: Calls to application listeners did not use the appropriate facade object tomcat: Security constrained bypass in error page mechanism tomcat: Vary header not added by CORS filter leading to cache poisoning log4j: deserialization of untrusted data in SocketServer</p> https://cve.radiocsirt.org/vuln/rhsa-2017:1801 https://cve.radiocsirt.org/vuln/suse-su-2017:3039-1 <p>Security update for tomcat</p> <p>Security update for tomcat</p> https://cve.radiocsirt.org/vuln/suse-su-2017:3039-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2017-5664 <p><strong>Affected:</strong> Ubuntu:14.04:LTS: tomcat7, Ubuntu:Pro:14.04:LTS: tomcat6, Ubuntu:16.04:LTS: tomcat8, Ubuntu:Pro:16.04:LTS: tomcat7</p> <p>The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method. If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTTP method. The Default Servlet in Apache Tomcat 9.0.0.M1 to 9.0.0.M20, 8.5.0 to 8.5.14, 8.0.0.RC1 to 8.0.43 and 7.0.0 to 7.0.77 did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page. Notes for other user provided error pages: (1) Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must must ensure that they handle any error dispatch as a GET request, regardless of the actual method. (2) By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.</p> <p><strong>Affected:</strong> Ubuntu:14.04:LTS: tomcat7, Ubuntu:Pro:14.04:LTS: tomcat6, Ubuntu:16.04:LTS: tomcat8, Ubuntu:Pro:16.04:LTS: tomcat7</p> <p>The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method. If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTTP method. The Default Servlet in Apache Tomcat 9.0.0.M1 to 9.0.0.M20, 8.5.0 to 8.5.14, 8.0.0.RC1 to 8.0.43 and 7.0.0 to 7.0.77 did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page. Notes for other user provided error pages: (1) Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must must ensure that they handle any error dispatch as a GET request, regardless of the actual method. (2) By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2017-5664 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0528 <p>Ein Angreifer kann mehrere Schwachstellen in Dell Data Protection Advisor ausnutzen, um beliebigen Code auszuführen, einen Denial-of-Service-Zustand herbeizuführen, Dateien zu manipulieren, vertrauliche Informationen offenzulegen, seine Berechtigungen zu erweitern oder einen nicht spezifizierten Angriff durchzuführen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Dell Data Protection Advisor ausnutzen, um beliebigen Code auszuführen, einen Denial-of-Service-Zustand herbeizuführen, Dateien zu manipulieren, vertrauliche Informationen offenzulegen, seine Berechtigungen zu erweitern oder einen nicht spezifizierten Angriff durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0528