CVE-2025-14761: 
PHP vulnerability analysis and mitigation

CVE-2025-14761 is a missing cryptographic key commitment vulnerability in the S3 Encryption Client component of the AWS SDK for PHP, classified as a "Key Commitment Issue." It affects all versions of aws/aws-sdk-php up to and including 3.367.0, and was disclosed on December 17, 2025 (AWS Security Bulletin, Github Advisory). The vulnerability is part of a broader set of related CVEs (CVE-2025-14759 through CVE-2025-14764) affecting S3 Encryption Clients across multiple AWS SDKs. It carries a CVSS v3.1 base score of 5.3 (Medium) and a CVSS v4.0 base score of 6.0 (Medium) (Github Advisory).

The root cause is the absence of cryptographic key commitment in the S3 Encryption Client (S3EC) for PHP when the Encrypted Data Key (EDK) is stored in an "Instruction File" rather than in S3's object metadata record (CWE-327: Use of a Broken or Risky Cryptographic Algorithm) (Github Advisory). This exposes the EDK to an "Invisible Salamanders" attack (described in https://eprint.iacr.org/2019/016), a known cryptographic weakness where a single ciphertext can be decrypted to two different plaintexts using different keys. An attacker must: (i) craft a rogue EDK that also decrypts the underlying S3 object to attacker-controlled plaintext, and (ii) have write access to the S3 bucket to replace the legitimate instruction file with one containing the rogue EDK. Subsequent decryption by legitimate users will silently use the rogue EDK, producing tampered plaintext without any error or warning (AWS Security Bulletin).

Successful exploitation allows an attacker with low-privilege write access to an S3 bucket to silently substitute encrypted data keys, causing legitimate decryption operations to produce attacker-controlled plaintext without detection. The primary impact is a high integrity violation — encrypted data can be tampered with in a way that is cryptographically valid and undetectable by the S3EC library. There is no direct confidentiality or availability impact, but the ability to covertly alter decrypted data could enable downstream data corruption, fraud, or unauthorized data manipulation in applications relying on S3-stored encrypted content (Github Advisory, AWS Security Bulletin).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Github Advisory). The EPSS score is approximately 0.017% (4th percentile), indicating a very low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an attacker to already possess write access to the target S3 bucket and the cryptographic capability to craft a valid rogue EDK, making opportunistic exploitation unlikely but targeted abuse by a malicious insider or compromised credential holder feasible.

1. Identify target: Locate an S3 bucket where the AWS SDK for PHP S3 Encryption Client (version ≤ 3.367.0) is used with the "Instruction File" storage mode for EDKs, rather than S3 object metadata.
2. Obtain write access: Acquire low-privilege AWS credentials with s3:PutObject permission on the target bucket (e.g., via compromised IAM credentials, insider access, or overly permissive bucket policies).
3. Retrieve the existing instruction file: Download the instruction file associated with the target encrypted S3 object. This file contains the EDK used to decrypt the object.
4. Craft a rogue EDK: Using knowledge of the "Invisible Salamanders" attack technique (https://eprint.iacr.org/2019/016), construct a new EDK that, when used to decrypt the same ciphertext, produces attacker-controlled plaintext instead of the original plaintext.
5. Replace the instruction file: Upload a new instruction file to the S3 bucket containing the rogue EDK, overwriting the legitimate one.
6. Trigger decryption: Wait for a legitimate application using the vulnerable S3EC PHP library to decrypt the object. The library will use the rogue EDK and silently return the attacker-controlled plaintext, completing the integrity compromise without any error (Github Advisory, AWS Security Bulletin).

• S3 Access Logs: Unexpected PutObject requests targeting instruction files (objects with the .instruction suffix or similar naming convention) from unfamiliar IAM principals or IP addresses.
• S3 Access Logs: GetObject requests for instruction files followed shortly by PutObject requests to the same key from the same or a different principal, indicating a read-then-replace pattern.
• AWS CloudTrail: IAM events showing low-privilege users or roles performing s3:PutObject on instruction file keys in buckets containing encrypted data.
• Application Behavior: Decryption operations returning unexpected or altered plaintext content without raising exceptions, which may surface as data integrity errors in downstream application logic.
• S3 Object Versioning: If versioning is enabled, review version history of instruction files for unauthorized replacements or unexpected version creation events.

The fix is to upgrade aws/aws-sdk-php to version 3.368.0 or later, which introduces S3EncryptionClientV3 and KmsMaterialProviderV3 with full key commitment support — cryptographically binding the EDK to the ciphertext (AWS SDK PHP Release). AWS notes that version 3.368.0 is released in two compatibility tiers: a minor version that can read key-commitment messages but not write them, and a new major version that supports both reading and writing with key commitment; customers are advised to upgrade to the latest major version for maximum protection (AWS Security Bulletin). There are no known workarounds — upgrading is the only remediation. As a defense-in-depth measure, organizations should also review and restrict S3 bucket write permissions, enable S3 object versioning, and audit CloudTrail logs for unauthorized instruction file modifications.

AWS published a formal security bulletin (AWS-2025-032) on December 17, 2025, covering the full family of related key commitment CVEs across six SDK languages, indicating coordinated disclosure and proactive vendor response (AWS Security Bulletin). The vulnerability was noted in security community feeds and aggregators including Vulners, VulDB, and CIRCL shortly after disclosure, reflecting standard industry tracking. No notable independent researcher commentary or significant social media discussion beyond routine CVE tracking has been identified for this specific CVE.