Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.
Recommended action: Upgrade to 10.16.1.2, 10.15.2.1 or 10.14.2.1 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 10.4.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
XML external entity (XXE) vulnerability in the SqlXmlUtil code in Apache Derby before 10.12.1.1, when a Java Security Manager is not in place, allows context-dependent attackers to read arbitrary files or cause a denial of service (resource consumption) via vectors involving XmlVTI and the XML datatype.
Recommended action: Upgrade to 10.12.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Apache Derby 10.3.1.4 to 10.14.1.0, a specially-crafted network packet can be used to request the Derby Network Server to boot a database whose location and contents are under the user's control. If the Derby Network Server is not running with a Java Security Manager policy file, the attack is successful. If the server is using a policy file, the policy file must permit the database location to be read for the attack to work. The default Derby Network Server policy file distributed with the affected releases includes a permissive policy as the default Network Server policy, which allows the attack to work.
Recommended action: Upgrade to 10.14.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 10.6.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Derby before 10.2.1.6 does not determine schema privilege requirements during the DropSchemaNode bind phase, which allows remote authenticated users to execute arbitrary drop schema statements in SQL authorization mode.
Recommended action: Upgrade to 10.2.1.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 10.1.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.