[devin-ai-integration]

Summary

Fixes Snyk SNYK-JAVA-MYSQL-451464 / CVE-2018-3258 (Connector/J access-control bypass, high, CVSS 8.8). The finding is on mysql:mysql-connector-java@5.1.42 in UserFront/pom.xml. Code-scan finding: sfind-e7a6cbbd249c464ea5500b048cda0070.

 <properties>
   <java.version>1.8</java.version>
+  <mysql.version>8.0.13</mysql.version>
 </properties>

The dependency has no explicit version, so Boot 1.5.4's spring-boot-dependencies resolves it through ${mysql.version}. Overriding that property is the smallest change, and 8.0.13 is the lowest version that fixes the CVE. Java stays on 1.8 and no code changes.

Major bump (5.1 → 8.0). Reviewers please check:

• Boot 1.5 still auto-picks com.mysql.jdbc.Driver. On 8.0.x that class is a deprecated alias for com.mysql.cj.jdbc.Driver, so it still works but logs one deprecation warning at startup.
• Connector/J 8.0.13 (versions before 8.0.23) refuses to connect when the server reports a timezone it doesn't recognise, for example CEST. If that happens, add serverTimezone=<zone> to spring.datasource.url. I didn't add it here, to keep the change minimal and leave timestamp handling as it is.
• 8.0.13 pulls in com.google.protobuf:protobuf-java 3.6.1 at runtime.

Verification

• Not run: snyk test and the real build. The network allowlist blocks api.snyk.io, Maven Central and its Google mirror (SNYK-CLI-0000). The Boot 1.5.4 parent and the 8.0.13 jar aren't in the local cache, so I have no before/after Snyk issue counts and didn't run mvn test on the actual POM. Access has been requested; I'll update this PR if it's granted.
• Property check (offline): I used a POM copy on the cached Boot 1.5.8 parent and ran mvn -o dependency:tree -Dincludes=mysql. Without the override it resolves mysql-connector-java:5.1.44; with -Dmysql.version set it resolves the override. This confirms the property controls the driver version.
• Runtime stand-in (offline): I booted Boot 1.5.8 (Spring 4.3.12, Hibernate 5.0.12, same MySQL5Dialect and default driver class) with the app's domain and dao packages. It ran against Docker mysql:5.7.44 using Connector/J 8.0.33, the closest cached 8.0.x jar. Results:
  • ddl-auto=update created all 9 tables.
  • Saving a User with a PrimaryAccount and a PrimaryTransaction, then reading it back with UserDao.findByUsername, returned the same values (BigDecimal balances and Date intact).

  DRIVER MySQL Connector/J mysql-connector-j-8.0.33 | server 5.7.44
  ROUNDTRIP user=cve3258 acct=11223101 balance=100.00 tx=Deposit 150.00 dateMatch=true
  

Related

These are duplicates; only one should land:

• Branch devin/1790739488-mysql-connector-cve-2018-3258 has the identical one-line change from an earlier run for the same CVE. This new PR exists because of the one-PR-per-ticket rule.
• 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, plus a driver-class change) also clear this CVE.

Devin-Org: engineering

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

---

[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 CEST

When MySQL reports CEST, the upgraded connector rejects spring.datasource.url without a serverTimezone setting. Database initialization fails, leaving the banking frontend unavailable.

Learn more

Connector/J 8.0.13 resolves the MySQL server's timezone when opening a connection. The configured datasource URL has no serverTimezone value. If the server reports an abbreviation such as CEST, this connector does not recognize it and rejects the connection. The application's JPA startup needs that connection, so the frontend cannot start in that deployment.

Example: A MySQL instance reports @@system_time_zone = CEST while the URL remains jdbc:mysql://localhost:3306/onlinebanking. Connector/J 8.0.13 rejects the connection rather than loading the banking accounts.

Recommended fix: Set serverTimezone to the deployment's correct IANA timezone in the datasource URL or ensure MySQL reports a recognized timezone. Verify connection startup against a server configured with an abbreviated timezone before deploying the upgrade.

---

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

[devin-ai-integration]

Confirmed. This is a known Connector/J 8.0.0–8.0.22 behaviour, and the PR description already flags it. I couldn't reproduce it here because the 8.0.13 jar isn't cached and Maven Central is blocked. The local MySQL 5.7 reports @@system_time_zone = UTC, so it isn't affected.

I've left the change as is because the correct fix depends on how this is deployed:

1. Keep 8.0.13 and add ?serverTimezone=<IANA zone> to spring.datasource.url. This needs to be the zone the DB actually runs in. Hardcoding UTC would silently shift stored Dates on a non-UTC server. Under 5.1.x, by default, timestamps were sent without any conversion.
2. Bump to 8.0.23+ instead. The default there is connectionTimeZone=LOCAL, which matches 5.1's no-conversion behaviour and doesn't fail on CEST. It goes past the "smallest fixing version" rule, though.

Maintainers: tell me which option you want and I'll push it.