[devin-ai-integration]

Summary

Fixes Snyk SNYK-JAVA-MYSQL-174574 / CVE-2019-2692 (Privilege Escalation, medium, CVSS 6.3) in mysql:mysql-connector-java@5.1.42, a direct dependency in UserFront/pom.xml. Code-scan finding sfind-69305faa28ee4e96a2c8e5e35944a14f.

 <properties>
   <java.version>1.8</java.version>
+  <mysql.version>8.0.16</mysql.version>   <!-- Boot 1.5.4 BOM property; 5.1.42 -> 8.0.16 -->
 </properties>
 ...
 <artifactId>mysql-connector-java</artifactId>
+<exclusions><exclusion>com.google.protobuf:protobuf-java</exclusion></exclusions>

• 8.0.16 is the smallest version that fixes it (vulnerable range is [,8.0.16)). This is a major bump (5.1 → 8.0). Java stays at 1.8 and nothing else in the Boot 1.5.4 parent changes.
• Why protobuf-java is excluded: 8.0.16 pulls in protobuf-java 3.6.1, which only the X DevAPI (com.mysql.cj.xdevapi) uses. Excluding it keeps the bump from adding new protobuf findings. The app connects over plain JDBC.
• No config changes needed:
  • Boot 1.5 still picks com.mysql.jdbc.Driver for jdbc:mysql: URLs. In 8.x that class is a deprecated alias of com.mysql.cj.jdbc.Driver, so startup logs a deprecation warning but the connection works.
  • Review note: Connector/J 8.0.16–8.0.22 fails to connect if the MySQL server reports a time-zone abbreviation the JVM doesn't recognise (e.g. CEST). A UTC server is fine. If a deployed server uses such a zone, add ?serverTimezone=... to spring.datasource.url.

Verification

• Not verified with the real build: the Boot 1.5.4 parent and Connector/J 8.0.16 aren't in the local Maven cache. Maven Central and api.snyk.io are blocked by this session's network policy (access was requested and not yet granted). So I couldn't run mvn compile, the real app, or a Snyk re-scan.
• Snyk before/after issue count: not available. I couldn't re-scan; the only change I expect is that SNYK-JAVA-MYSQL-174574 no longer appears.
• Tests: UserFront/src/test has no tests and the repo has no CI.
• Offline stand-in that did run (closest cached versions):
  • Setup: Boot 1.5.8 spring-boot-starter-data-jpa, Hibernate 5.0.12, tomcat-jdbc, Connector/J 8.x (8.0.33 cached jar, same protobuf exclusion), the repo's domain/dao packages and application.properties, against MySQL 5.7.44.
  • Boot picked the legacy com.mysql.jdbc.Driver (deprecation warning only).
  • Hibernate ddl-auto=update created all 9 tables, and saving and reading back Role and User through RoleDao and UserDao.findByUsername worked.

Duplicates

• Branch devin/1790739541-mysql-connector-8.0.16 has the same property bump, but no protobuf exclusion.
• Open PRs bug: bump mysql-connector-java 5.1.42 -> 8.0.27 (CVE-2021-2471 XXE) #209 (8.0.27) and bug: upgrade mysql-connector-java 5.1.42 -> 8.0.28 (CVE-2022-21363) #294 (8.0.28) also clear this CVE.
• Upgrade mysql-connector-java 5.1.42 -> 8.0.13 (CVE-2018-3258) #268 (8.0.13) does not clear it.
• Only one connector bump should land.

Devin-Org: engineering

Link to Devin session: https://devin-gtm.devinenterprise.com/sessions/c8b153dd109341e4981af4e90113b002
Open in Devin Desktop: https://devin-gtm.devinenterprise.com/desktop/session/c8b153dd109341e4981af4e90113b002?variant=devin

---

Devin Review

Status	Commit
⚪ Not started	—

Run Devin Review

---

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

Devin Review found 1 potential issue.

[devin-ai-integration]

🔴 Database startup fails in some time zones

When MySQL reports CEST, mysql.version 8.0.16 rejects the connection without an explicit time zone. The configured JDBC URL supplies none, so the application fails to start.

Learn more

Connector/J 8.0.16 cannot map some server-reported time-zone abbreviations to Java time zones. The application's JDBC URL has no serverTimezone parameter, so a MySQL server reporting an abbreviation such as CEST can prevent datasource initialization during startup. This affects deployments using those server settings; UTC servers do not trigger this failure.

Example: A deployment connects to MySQL reporting CEST. Connector/J rejects that abbreviation during connection setup, and the banking application never finishes starting. With a recognized time zone specified in the JDBC URL, the connection can initialize.

Recommended fix: Provide a recognized serverTimezone value through the JDBC URL in application properties, selecting the actual database time zone rather than hard-coding UTC for servers in another zone. Verify startup against a server configured to report CEST.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Agreed that this can happen: Connector/J 8.0.16–8.0.22 rejects time-zone abbreviations it can't map (e.g. CEST). The PR description already calls this out as a review note.

I left serverTimezone out of this PR on purpose:

• The right value depends on how the target MySQL server is configured, and the repo doesn't record that. The local MySQL 5.7 I tested against reports SYSTEM/UTC, which works.
• Hard-coding serverTimezone=UTC would convert timestamps wrongly on a server that actually runs in another zone.
• The remediation guidance asks for the minimal bump.

If you know the deployed server's zone, I'll add ?serverTimezone=<zone> to spring.datasource.url. Moving up to 8.0.23+ would also avoid the hard failure, but that's no longer the smallest fixing version.