Oracle Siebel Core - Automation vulnerabilities
6 CVEs affecting Oracle Siebel Core - Automation, 0 known to be exploited (CISA KEV), with EPSS scores. Latest: CVE-2021-34428, published 2021-06-22.
More from Oracle.
Highest priority
Known exploited (CISA KEV) first, then by EPSS exploit probability.
- CVE-2021-28164, published 2021-04-01. Medium severity, CVSS 5.3. EPSS: 82.4% chance of exploitation in the next 30 days. In Eclipse Jetty 9.4.37.v20210219 to 9.4.38.v20210224, the default compliance mode allows requests with URIs that contain %2e or %2e%2e segments to access protected resources within the WEB-INF…
- CVE-2021-28165, published 2021-04-01. High severity, CVSS 7.5. EPSS: 53.9% chance of exploitation in the next 30 days. In Eclipse Jetty 7.2.2 to 9.4.38, 10.0.0.alpha0 to 10.0.1, and 11.0.0.alpha0 to 11.0.1, CPU usage can reach 100% upon receiving a large invalid TLS frame.
- CVE-2020-27218, published 2020-11-28. Medium severity, CVSS 4.8. EPSS: 8.3% chance of exploitation in the next 30 days. In Eclipse Jetty version 9.4.0.RC0 to 9.4.34.v20201102, 10.0.0.alpha0 to 10.0.0.beta2, and 11.0.0.alpha0 to 11.0.0.beta2, if GZIP request body inflation is enabled and requests from different clients…
- CVE-2020-27216, published 2020-10-23. High severity, CVSS 7.0. EPSS: 4.4% chance of exploitation in the next 30 days. In Eclipse Jetty versions 1.0 thru 9.4.32.v20200930, 10.0.0.alpha1 thru 10.0.0.beta2, and 11.0.0.alpha1 thru 11.0.0.beta2O, on Unix like systems, the system's temporary directory is shared between…
- CVE-2021-28163, published 2021-04-01. Low severity, CVSS 2.7. EPSS: 4.2% chance of exploitation in the next 30 days. In Eclipse Jetty 9.4.32 to 9.4.38, 10.0.0.beta2 to 10.0.1, and 11.0.0.beta2 to 11.0.1, if a user uses a webapps directory that is a symlink, the contents of the webapps directory is deployed as a…
- CVE-2021-34428, published 2021-06-22. Low severity, CVSS 3.5. EPSS: 1% chance of exploitation in the next 30 days. For Eclipse Jetty versions <= 9.4.40, <= 10.0.2, <= 11.0.2, if an exception is thrown from the SessionListener#sessionDestroyed() method, then the session ID is not invalidated in the session ID…