CVE-2022-46337

What it actually does

Bypass of LDAP authentication via crafted username allows unauthenticated creation of Derby databases, execution of visible malware by the server process, and unauthorized data access or modification in databases lacking SQL GRANT/REVOKE controls.

Why it matters to the business

Attackers can exhaust disk space, run malicious code under the Derby server account, or access and alter sensitive data, leading to service disruption, compliance violations, and potential ransomware or data theft scenarios in LDAP-authenticated deployments.

How an attack unfolds

An attacker supplies a specially crafted username during LDAP authentication to Derby; once the bypass succeeds the attacker creates numerous junk databases to fill storage, executes malware visible to the boot account, or directly views and corrupts data and runs privileged procedures in databases without additional SQL authorization.

How to fix it

Upgrade to Java 21 with Derby 10.17.1.0. For older Java LTS versions, build Derby from the backported 10.16, 10.15, or 10.14 families. Disable LDAP authentication or add SQL GRANT/REVOKE protections until patched.

How to confirm the fix worked

Verify Derby version is 10.17.1.0 or later (or the corresponding backport); attempt LDAP login with known bypass usernames and confirm authentication is rejected; review database creation and authorization logs for anomalies.

Typical attack path

1. Craft LDAP username that evades authentication checks
2. Connect to the Derby server and create multiple junk databases
3. Upload and execute malware visible to the Derby process owner
4. Query or modify sensitive tables and invoke procedures if SQL controls are absent

How to detect it

Search Derby server logs for repeated database creation attempts from single LDAP principals, unexpected process executions under the Derby account, and queries against sensitive objects without prior GRANT records; correlate with LDAP authentication logs showing unusual usernames.

What your security team should do

• Immediately upgrade Derby to a fixed release matching the Java version in use
• Audit all LDAP-authenticated Derby instances for missing SQL authorization controls
• Monitor disk usage and unexpected database creation events
• Restrict network access to Derby ports until patches are applied