CVE-2025-14763: 
Java vulnerability analysis and mitigation

CVE-2025-14763 is a missing cryptographic key commitment vulnerability in the Amazon S3 Encryption Client for Java (S3EC), enabling an "Invisible Salamanders" attack against encrypted data stored in S3. It affects all versions of the library up to and including v3.5.0, and was disclosed on December 17, 2025. The vulnerability is part of a broader set of key commitment issues across multiple AWS S3 Encryption Client SDKs (CVE-2025-14759 through CVE-2025-14764). It carries a CVSS v3.1 score of 5.3 (Medium) and a CVSS v4.0 score of 6.0 (Medium) (AWS Security Bulletin, GitHub Advisory).

The root cause is classified as CWE-327 (Use of a Broken or Risky Cryptographic Algorithm): older versions of S3EC do not implement cryptographic key commitment, meaning a single ciphertext can potentially be decrypted to two different plaintexts using different encryption keys. This flaw is specifically triggered when the Encrypted Data Key (EDK) is stored in an "Instruction File" rather than in S3's object metadata record — a supported but less common configuration. An attacker exploiting this weakness (known academically as the "Invisible Salamanders" attack, described in https://eprint.iacr.org/2019/016) must: (i) craft a rogue EDK that decrypts the same ciphertext to attacker-controlled plaintext, and (ii) replace the legitimate instruction file in the S3 bucket with the rogue one. Subsequent decryption operations by legitimate clients will silently use the rogue EDK and produce the attacker-chosen plaintext (AWS Security Bulletin, GitHub Advisory).

Successful exploitation allows an attacker with write access to an S3 bucket to manipulate decryption outcomes, causing legitimate clients to receive attacker-controlled plaintext instead of the original encrypted data. This represents a high-integrity impact — data trustworthiness is fundamentally undermined — while confidentiality and availability are not directly affected. The attack is limited to deployments using the "Instruction File" EDK storage mode and requires the attacker to already possess write permissions to the target S3 bucket, constraining the blast radius to environments where bucket access controls are insufficiently restrictive (GitHub Advisory, AWS Security Bulletin).

1. Identify target: Determine that the target application uses the Amazon S3 Encryption Client for Java version ≤ 3.5.0 with the "Instruction File" EDK storage mode (i.e., EDKs are stored as separate S3 objects rather than in S3 object metadata).
2. Obtain write access: Acquire write permissions to the target S3 bucket — this could be through compromised IAM credentials, overly permissive bucket policies, or insider access.
3. Locate the instruction file: Identify the instruction file object in the S3 bucket associated with the target encrypted object (typically named with a .instruction suffix alongside the encrypted object).
4. Craft a rogue EDK: Leveraging the lack of key commitment, construct a rogue Encrypted Data Key that, when used to decrypt the same ciphertext, produces attacker-chosen plaintext (exploiting the "Invisible Salamanders" cryptographic property).
5. Replace the instruction file: Upload the rogue instruction file to the S3 bucket, overwriting the legitimate one.
6. Trigger decryption: Wait for or induce a legitimate client using S3EC to decrypt the target object; the client will silently use the rogue EDK and receive the attacker-controlled plaintext, achieving data integrity compromise (AWS Security Bulletin, GitHub Advisory).

• S3 Access Logs: Unexpected PUT or PutObject API calls targeting .instruction suffix objects in S3 buckets, especially from unfamiliar IAM principals or source IPs.
• S3 Access Logs: GetObject calls on instruction files followed shortly by PutObject calls on the same key from a different principal, indicating potential file replacement.
• CloudTrail: IAM activity showing unusual cross-account or external access to S3 buckets containing encrypted objects with instruction files.
• Application Logs: Decryption operations returning unexpected or malformed plaintext that does not match application expectations, potentially surfacing as data validation errors.
• S3 Object Versioning: If versioning is enabled, review version history of .instruction files for unauthorized modifications or unexpected version additions.

The primary remediation is to upgrade the Amazon S3 Encryption Client for Java to version 4.0.0 or later, which introduces mandatory key commitment using the ALG_AES_256_GCM_HKDF_SHA512_COMMIT_KEY algorithm suite and requires the REQUIRE_ENCRYPT_REQUIRE_DECRYPT commitment policy by default. AWS also released a code-compatible minor version that can read messages with key commitment but not write them, for organizations needing a transitional step. There are no known configuration-based workarounds — upgrading is the only remediation. Additionally, organizations should review and restrict write access to S3 buckets containing encrypted objects as a defense-in-depth measure (AWS Security Bulletin, GitHub Release v4.0.0).

AWS published a formal security bulletin (AWS-2025-032) on December 17, 2025, covering the key commitment issue across six S3 Encryption Client SDKs simultaneously, indicating a coordinated disclosure effort. The advisory was noted by security community members on Mastodon (infosec.exchange) shortly after publication. Red Hat also tracked the CVE, suggesting downstream impact awareness in enterprise Linux ecosystems. Overall community reaction has been measured, consistent with the moderate severity rating and the specific deployment conditions required for exploitation (AWS Security Bulletin).