WaratekVRT Sign in
Reset
More filters (1)
Columns
Product derby✕
Overview 5 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
5matches 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 5 100.0%
Critical 1 20.0% High 1 20.0% Medium 2 40.0% Low 1 20.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 0 0.0% partly blocked 0 0.0% not blocked 5 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 5 100.0%
split by peak 1 / year
No exploit published: 5 Low: 1Medium: 2High: 1Critical: 1 not blocked: 5 No public exploit: 5
20051 No exploit published1 Medium1 not blocked1 No public exploit1 20060 20071 No exploit published1 Medium1 not blocked1 No public exploit1 20080 20090 20101 No exploit published1 Low1 not blocked1 No public exploit1 20110 20120 20130 20140 20150 20160 20171 No exploit published1 High1 not blocked1 No public exploit1 20180 20190 20200 20210 20220 20231 No exploit published1 Critical1 not blocked1 No public exploit1
2005200720092011201320152017201920212023
5 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-2022-46337 Critical 2023-11-20 No exploit published No public exploit A cleverly devised username might bypass LDAP authentication checks. In LDAP-authenticated Derby installations, this could let an attacker fill up the disk by creating junk Derby databases. In LDAP-authenticated Derby installations, this could also allow the attacker to execute malware which was visible to and executable by the account which booted the Derby server. In LDAP-protected databases which weren't also protected by SQL GRANT/REVOKE authorization, this vulnerability could also let an attacker view and corrupt sensitive data and run sensitive database functions and procedures. Mitigation: Users should upgrade to Java 21 and Derby 10.17.1.0. Alternatively, users who wish to remain on older Java versions should build their own Derby distribution from one of the release families to which the fix was backported: 10.16, 10.15, and 10.14. Those are the releases which correspond, respectively, with Java LTS versions 17, 11, and 8.
CVE-2010-2232 High 2017-10-23 No exploit published No public exploit In Apache Derby 10.1.2.1, 10.2.2.0, 10.3.1.4, and 10.4.1.3, Export processing may allow an attacker to overwrite an existing file.
CVE-2009-4269 Low 2010-08-16 No exploit published No public exploit The password hash generation algorithm in the BUILTIN authentication functionality for Apache Derby before 10.6.1.0 performs a transformation that reduces the size of the set of inputs to SHA-1, which produces a small search space that makes it easier for local and possibly remote attackers to crack passwords by generating hash collisions, related to password substitution.
CVE-2006-7216 Medium 2007-07-05 No exploit published No public exploit Apache Derby before 10.2.1.6 does not determine privilege requirements for lock table statements at compilation time, and consequently does not enforce privilege requirements at execution time, which allows remote authenticated users to lock arbitrary tables.
CVE-2005-4849 Medium 2005-12-31 No exploit published No public exploit Apache Derby before 10.1.2.1 exposes the (1) user and (2) password attributes in cleartext via (a) the RDBNAM parameter of the ACCSEC command and (b) the output of the DatabaseMetaData.getURL function, which allows context-dependent attackers to obtain sensitive information.