CVE-2023-22102 is a High-severity vulnerability in Oracle's MySQL Connector/J, the official JDBC driver for MySQL, that can result in a full takeover of the connector. It affects supported versions 8.1.0 and prior, carries a CVSS 3.1 base score of 8.3, and was disclosed in Oracle's October 2023 Critical Patch Update. The fix is to upgrade to 8.2.0 or later, with a configuration flag available as an interim mitigation. It matters because Connector/J sits inside almost every Java application that talks to MySQL, usually as a transitive dependency you never think about.
What CVE-2023-22102 actually is
The vulnerability involves an unsafe deserialization path in Connector/J, gated by the autoDeserialize connection property. When autoDeserialize is enabled, the driver will deserialize Java objects it receives from the server side. If an attacker can position themselves in that flow — for example, by getting the client to connect to a malicious or compromised server, or by manipulating traffic on an unencrypted connection — they can feed the driver a crafted serialized object that triggers a gadget chain on deserialization.
The CVSS vector Oracle published is CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H. Reading that vector tells you the practical story:
- AC:H — the attack is difficult; the attacker needs the right conditions to line up.
- PR:N — no privileges required.
- UI:R — a person other than the attacker has to take some action (such as initiating a connection).
- S:C — the scope changes, meaning a successful attack can impact resources beyond the connector itself.
- C:H/I:H/A:H — full confidentiality, integrity, and availability impact.
The scope change and the triple-high impact are what push an otherwise hard-to-exploit bug up to a base score of 8.3. Advisories classify it under CWE-284 (Improper Access Control) and tie the exploitability to SSL/TLS validation weaknesses that make the malicious-server or man-in-the-middle scenario reachable.
Which versions are affected
Connector/J versions 8.1.0 and earlier are vulnerable. The fix is in 8.2.0. In Maven terms the artifact has moved around over the years — older builds use mysql:mysql-connector-java, while newer ones use com.mysql:mysql-connector-j — so check both coordinates:
mvn dependency:tree | grep -Ei "mysql-connector"
A common vulnerable sighting is mysql-connector-j-8.0.33.jar. Anything at 8.1.0 or below is in scope, regardless of which artifact coordinate pulled it in.
How to remediate CVE-2023-22102
Upgrade to MySQL Connector/J 8.2.0 or later. This is the durable fix. If you are still on the legacy mysql:mysql-connector-java coordinate, migrating to the current com.mysql:mysql-connector-j artifact is worthwhile at the same time, since that is where ongoing maintenance happens.
<dependency>
<groupId>com.mysql</groupId>
<artifactId>mysql-connector-j</artifactId>
<version>8.2.0</version>
</dependency>
As an interim mitigation, disable the deserialization path. If you cannot upgrade immediately, set autoDeserialize=false in your JDBC connection string or connection properties. That property defaults to false, so most applications are not exposed by default — but if any of your connection strings turned it on (some ORMs and legacy configs do), turning it back off removes the vulnerable path. Audit your connection URLs explicitly rather than assuming the default holds.
jdbc:mysql://db.internal:3306/app?autoDeserialize=false&useSSL=true&requireSSL=true
Enforce encrypted, verified connections. Because the exploit leans on SSL/TLS validation weaknesses and man-in-the-middle positioning, requiring TLS and verifying the server certificate shrinks the attack surface. Do not establish unencrypted Connector/J connections over any network you do not fully control.
Connector/J is nearly always a transitive dependency dragged in by an ORM, a connection pool, or a framework starter. An SCA tool such as Safeguard can identify which of your services resolve a vulnerable Connector/J and which parent pinned it, so you upgrade the right thing instead of chasing individual POMs.
Why the default helps but does not excuse the upgrade
The fact that autoDeserialize defaults to false is genuinely good news — it means a large share of applications were never in the exploitable configuration. That default is a fair thing to note when you triage the finding and decide urgency. It is not a reason to skip the upgrade. Configuration drifts, someone copies a connection string from an old system that had the flag on, or a future default changes. The clean state is running a patched Connector/J with the flag confirmed off and TLS enforced, all three, so the finding does not resurface every audit cycle.
FAQ
How severe is CVE-2023-22102?
It is High severity, with a CVSS 3.1 base score of 8.3. Successful exploitation can lead to takeover of the MySQL connector and, because of the scope change in the CVSS vector, impact beyond the connector itself. The attack complexity is high, so it is not trivially exploitable.
What version of MySQL Connector/J fixes CVE-2023-22102?
Version 8.2.0 and later. Upgrade from any 8.1.0-or-earlier release to close the vulnerability.
Is CVE-2023-22102 exploitable with default settings?
The vulnerable deserialization path is gated by autoDeserialize, which defaults to false. Applications that never enable it and use verified TLS connections have much lower practical exposure, but the version is still vulnerable and should be upgraded.
How do I know which Connector/J artifact I have?
Run mvn dependency:tree and grep for mysql-connector. Older builds use mysql:mysql-connector-java and newer ones use com.mysql:mysql-connector-j. Check both, since either coordinate can resolve a vulnerable 8.1.0-or-earlier version.