Skip to main content
print this page

Sensitive JDBC datasource connection details could appear in CloudWatch Logs

· 3 min read
Patch Available
Patch Available
This bug has a patch available for affected versions

Sensitive JDBC datasource connection details could appear in CloudWatch Logs​

Affected Versions: 2.7 3.0.3 3.1 3.2 3.3

Fix Version: 3.3

Patch: A fix is available for the affected release lines above. Contact Amorphic support and schedule an upgrade so your environment receives an Amorphic build that includes this fix.

Root cause(s)​

Under certain JDBC datasource workflows, detailed connection settings (including enough information to recover database passwords) could be written to Amazon CloudWatch Logs in plaintext.

What went wrong, in plain terms:

  1. Schema-related operations (for example: testing a JDBC connection, listing databases or tables, running schema conversion or similar previews) could emit full connection details to logs.
  2. Managing JDBC datasources in the product (create, update, test, and related flows) could log the same kind of sensitive material.
  3. Background catalog synchronization for JDBC datasources—used to keep the catalog in sync with your source—could also surface credential-bearing information in logs when it relied on the same schema-discovery path.
  4. Shared connection-handling logic used across APIs could log sensitive values instead of omitting or masking them.

Operational logging existed for troubleshooting, but it was not consistently scrubbed for secrets. Existing redaction mainly covered HTTP-style authorization headers, not full JDBC connection payloads.

Fixes remove or redact those log lines so connection secrets are not written to CloudWatch.

Impact​

  • Who is affected: Customers on the Amorphic versions listed above who use JDBC datasources and have CloudWatch Logs read access available to a wider audience than intended.
  • What was exposed: Source database passwords and related connection attributes could appear in plaintext in CloudWatch when users or automation exercised JDBC datasource features (including catalog sync).
  • Typical database platforms involved include, among others: MySQL, Aurora, MariaDB, PostgreSQL, Redshift, Oracle, SQL Server, Db2, Db2 for i, Snowflake, and JDBC-based external API connectors.
  • What was not affected: Data movement and query execution continued to work as designed; the issue is limited to log visibility, not database availability or correctness of query results.

Mitigation​

Workaround
  1. Tighten who can read Amazon CloudWatch log groups tied to Amorphic until patches are applied—especially groups used when JDBC datasources are created, edited, tested, or when catalog sync runs.
  2. Rotate any source database passwords that may have been used while this issue was present, if log access was broader than your security policy allows.
  3. Optionally shorten log retention and purge older streams if your compliance team requires reducing residual exposure in historical logs.
Patch available

Contact Amorphic support and schedule an upgrade for your Amorphic version (2.7, 3.0.3, 3.1, 3.2, or 3.3) so the fix is applied in your environment. After the upgrade, sensitive JDBC connection details should no longer appear in CloudWatch Logs in plaintext from the affected workflows.

Timeline​

  • 2026-04-14: Bug reported/identified (CLOUD-7329)
  • 2026-04-15: Debug, root cause analysis and fix completed
  • 2026-04-16: Patches made available for all affected release lines; fixes cover JDBC schema operations, datasource management, catalog synchronization, and shared connection handling—not only the originally reported schema path