VRT 391,192 CVEs tracked · 15,442 in RASP scope · data as of 19 hours ago
Reset
More filters (3)
Columns
Published from 2020-07-01Published to 2020-09-30Advisory: Oracle Critical Patch Update October 2020
Overview 2 matches, all in RASP scope, all public PoC · 0 protected · 0 KEV · 0 CISA SSVC · 1 EPSS ≥ 0.5 · 0 disputed
2matches, all in RASP scope, all public PoC 0protected0.0% 0KEV0.0% 0CISA SSVC0.0% 1EPSS ≥ 0.550.0% 0disputed0.0%
Critical 1 50.0% High 1 50.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
Protected by RASP 0 0.0% Rule in development 0 0.0% Mitigation candidate 1 50.0% No exploit published 1 50.0% No fix identified 0 0.0% Mitigated by environment configuration 0 0.0% Queued for review 0 0.0% Not applicable 0 0.0% Out of RASP scope 0 0.0% Rejected 0 0.0%
blocked by ARMR today 0 0.0% not blocked 2 100.0% not established 0 0.0% unrecorded 0 0.0%
Exploited in the wild 0 0.0% Working exploit published 1 50.0% Proof of concept only 0 0.0% Forecast only 0 0.0% No public exploit 1 50.0%
split by peak 2 / month
Unknown: 0None: 0Low: 0Medium: 0High: 1Critical: 1 Rejected: 0Out of RASP scope: 0Not applicable: 0Queued for review: 0Mitigated by environment configuration: 0No fix identified: 0No exploit published: 1Mitigation candidate: 1Rule in development: 0Protected by RASP: 0 unrecorded: 0not established: 0not blocked: 2blocked by ARMR today: 0 No public exploit: 1Forecast only: 0Proof of concept only: 0Working exploit published: 1Exploited in the wild: 0 July 2020: 2 CVEs
Jul 20
2 matches CSV JSON
CVE Severity Published Status Exploitation Description
CVE-2020-13935 High 2020-07-14 Mitigation candidate Working exploit published The payload length in a WebSocket frame was not correctly validated in Apache Tomcat 10.0.0-M1 to 10.0.0-M6, 9.0.0.M1 to 9.0.36, 8.5.0 to 8.5.56 and 7.0.27 to 7.0.104. Invalid payload lengths could trigger an infinite loop. Multiple requests with invalid payload lengths could lead to a denial of service.
CVE-2019-17638 Critical 2020-07-09 No exploit published No public exploit In Eclipse Jetty, versions 9.4.27.v20200227 to 9.4.29.v20200521, in case of too large response headers, Jetty throws an exception to produce an HTTP 431 error. When this happens, the ByteBuffer containing the HTTP response headers is released back to the ByteBufferPool twice. Because of this double release, two threads can acquire the same ByteBuffer from the pool and while thread1 is about to use the ByteBuffer to write response1 data, thread2 fills the ByteBuffer with other data. Thread1 then proceeds to write the buffer that now contains different data. This results in client1, which issued request1 seeing data from another request or response which could contain sensitive data belonging to client2 (HTTP session ids, authentication credentials, etc.). If the Jetty version cannot be upgraded, the vulnerability can be significantly reduced by configuring a responseHeaderSize significantly larger than the requestHeaderSize (12KB responseHeaderSize and 8KB requestHeaderSize).