DerbyApplication · Apache
CVE-2022-46337
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedA 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.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceA username validation flaw in Apache Derby's LDAP authentication implementation allows specially crafted usernames to bypass authentication checks. An attacker exploiting this could create arbitrary Derby databases (disk exhaustion), execute malware under the Derby server's service account, and in configurations lacking SQL GRANT/REVOKE protections, read/modify sensitive data or execute privileged database functions.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data
DerbyApplication
>= 10.1.1.0, < 10.14.3.0>= 10.15.1.3, < 10.15.2.1= 10.16.1.1CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify if Apache Derby is in useCheck for derby.jar, derbycore.jar, or derby.war files in the application directory; also check for derby.log files or derby.system.home directoryAffected if Derby is not present on the system - not vulnerable because Derby is not used
-
Determine the installed Derby versionRun 'java org.apache.derby.tools.sysinfo' from the Derby lib directory, or inspect the derby.properties file for derby.version property, or check the JAR file metadataAffected if The version falls within: >= 10.1.1.0 and < 10.14.3.0; OR >= 10.15.1.3 and < 10.15.2.1; OR equals 10.16.1.1
-
Verify LDAP authentication is configuredInspect derby.properties for the property 'derby.authentication.provider' - valid values include LDAP, LDAP_AUTHENTICATOR, or a LDAP server URL patternAffected if The property is set to LDAP or LDAP_AUTHENTICATOR, or contains an LDAP server host/port configuration (e.g., java.naming.provider.url=ldap://...)
-
Confirm the LDAP authentication module is actively loadedCheck Derby startup logs (derby.log) for LDAP authentication initialization messages, or verify the LDAP authentication provider is listed in the Derby server connection attributesAffected if LDAP authentication is listed as the active authentication provider in runtime configuration
You are affected if you are running a vulnerable Derby version (10.1.1.0 to 10.14.2.x, 10.15.1.3 to 10.15.2.0, or exactly 10.16.1.1) AND LDAP authentication is enabled in your configuration.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped10.14.3.010.15.2.1
Upgrade to Derby 10.17.1.0 with Java 21, or for older Java LTS versions, rebuild Derby from backported branches 10.16 (Java 17), 10.15 (Java 11), or 10.14 (Java 8).
Derby 10.17.1.0 with Java 21
- 1. Backup all existing Derby databases before making any changes.
- 2. Ensure Java 21 is installed on the system (run 'java -version' to verify).
- 3. Download Apache Derby 10.17.1.0 from a trusted Apache mirror (https://db.apache.org/derby/derby_downloads.html).
- 4. Stop the Derby server if it is currently running.
- 5. Replace the existing Derby installation files with version 10.17.1.0, or install to a new directory.
- 6. Update any classpath or environment variables (DERBY_HOME, CLASSPATH) to point to the new Derby 10.17.1.0 installation.
- 7. Restart the Derby server with the new installation.
- 8. Test that LDAP authentication is working correctly with the new version.
Generated from the published advisory — verify against the referenced sources before acting.
Fix this in Derby
Scoped from the published advisory
- Consultation8.0 h
- Implementation16.0 h
- Testing12.0 h
- Review / QA4.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $11,200.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2022-46337 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2022-46337 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data