WaratekVRT Sign in
Reset
More filters (2)
Columns
Published to 2018-05-31✕Product bc-java✕
Overview 2 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
2matches 0protected0.0% 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 0 0.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 2 100.0%
Critical 0 0.0% High 0 0.0% Medium 2 100.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 0 0.0% partly blocked 0 0.0% not blocked 2 100.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 0 0.0% Forecast only 0 0.0% No public exploit 2 100.0%
split by peak 1 / quarter
No exploit published: 2 Medium: 2 not blocked: 2 No public exploit: 2
Q1 131 No exploit published1 Medium1 not blocked1 No public exploit1 Q2 130 Q3 130 Q4 130 Q1 140 Q2 140 Q3 140 Q4 140 Q1 150 Q2 150 Q3 150 Q4 150 Q1 160 Q2 160 Q3 160 Q4 160 Q1 170 Q2 170 Q3 170 Q4 170 Q1 180 Q2 181 No exploit published1 Medium1 not blocked1 No public exploit1
Q2 13Q4 13Q2 14Q4 14Q2 15Q4 15Q2 16Q4 16Q2 17Q4 17Q2 18
2 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2018-5382 Medium 2018-04-16 No exploit published No public exploit The default BKS keystore use an HMAC that is only 16 bits long, which can allow an attacker to compromise the integrity of a BKS keystore. Bouncy Castle release 1.47 changes the BKS format to a format which uses a 160 bit HMAC instead. This applies to any BKS keystore generated prior to BC 1.47. For situations where people need to create the files for legacy reasons a specific keystore type "BKS-V1" was introduced in 1.49. It should be noted that the use of "BKS-V1" is discouraged by the library authors and should only be used where it is otherwise safe to do so, as in where the use of a 16 bit checksum for the file integrity check is not going to cause a security issue in itself.
CVE-2013-1624 Medium 2013-02-08 No exploit published No public exploit The TLS implementation in the Bouncy Castle Java library before 1.48 and C# library before 1.8 does not properly consider timing side-channel attacks on a noncompliant MAC check operation during the processing of malformed CBC padding, which allows remote attackers to conduct distinguishing attacks and plaintext-recovery attacks via statistical analysis of timing data for crafted packets, a related issue to CVE-2013-0169.