CVE-2025-14762

What it actually does

This is a cryptographic integrity weakness in AWS SDK for Ruby client-side S3 encryption when encrypted data keys are stored in separate S3 instruction files rather than in object metadata. Because the encrypted data key is not cryptographically bound strongly enough to the encrypted object, a principal that can write to the same S3 bucket may be able to alter or introduce an additional encrypted data key entry so that decryption succeeds but yields attacker-influenced or different plaintext than the application expects. The primary impact is data integrity compromise during decryption; confidentiality and availability are not the main impacts based on the provided assessment. Exploitation requires existing write access to the bucket and use of the affected instruction-file encryption mode.

Why it matters to the business

Applications relying on affected AWS SDK for Ruby client-side encryption may process tampered S3 data as if it were legitimate, which can lead to incorrect business decisions, corrupted records, unsafe automation, or loss of trust in stored encrypted content. The issue is not currently listed in CISA KEV, is not marked as ransomware-associated, has very low EPSS, and requires prior bucket write permission, so broad opportunistic exploitation is less likely; however, the risk is higher for systems where multiple users, services, partners, or automation roles can write to buckets containing encrypted objects. If the listed Debian package context is applicable to an environment, use the vendor fixed version as well, but the described vulnerable component is AWS SDK for Ruby.

How an attack unfolds

An attacker first needs valid credentials or another path that gives write access to an S3 bucket containing objects encrypted by the affected AWS SDK for Ruby client-side encryption workflow. The attacker identifies objects that use separate instruction files for encryption metadata, commonly represented as companion S3 objects associated with the encrypted payload. Instead of needing to break encryption, the attacker manipulates the instruction file content or adds an alternate encrypted data key structure that the vulnerable client may accept during decryption. When an application later retrieves and decrypts the object using the vulnerable SDK, the SDK can accept the modified key material path and produce different plaintext than the legitimate object should yield. If threat activity attributed to Invisible Salamanders is relevant to monitoring, treat unusual S3 write activity against instruction files and encryption metadata as higher priority, especially when performed by identities that do not normally manage encrypted object metadata.

How to fix it

Upgrade AWS SDK for Ruby to version 1.208.0 or later wherever the SDK is used for S3 client-side encryption. Inventory Ruby applications, container images, serverless functions, build artifacts, and dependency lockfiles for aws-sdk-ruby or related AWS SDK gems and rebuild/redeploy after upgrading. If Debian 13 package guidance is relevant in a given distribution context, apply the listed fixed package version linux 6.12.15-1, but prioritize the SDK upgrade because the described flaw is in AWS SDK for Ruby behavior. Where immediate upgrade is not possible, reduce risk by disabling or migrating away from instruction-file-based encryption metadata, preferring fixed SDK behavior and metadata formats with proper key commitment; restrict S3 write permissions to only trusted services; prevent untrusted principals from writing companion instruction files; enable S3 versioning and Object Lock where appropriate; and add bucket policies or application controls that deny unexpected writes to instruction-file objects.

How to confirm the fix worked

Confirm all deployed Ruby applications use AWS SDK for Ruby version 1.208.0 or later by checking Gemfile.lock, gem inventory, container SBOMs, CI dependency reports, and runtime package listings. Search application code and configuration for S3 client-side encryption usage and specifically for instruction-file storage of encryption metadata. Validate S3 bucket policies and IAM policies to ensure only expected principals can write encrypted objects and their companion instruction files. Review representative S3 objects to determine whether instruction files are present and whether version history shows unexpected changes. After remediation, run integration tests that encrypt and decrypt S3 objects with the upgraded SDK and verify tamper attempts against instruction-file metadata are rejected or fail safely.

Typical attack path

1. Obtain or abuse credentials for an IAM user, role, workload identity, or service with write permission to the target S3 bucket.
2. Enumerate bucket contents or observe application behavior to identify objects encrypted with AWS SDK for Ruby client-side encryption using separate instruction files.
3. Locate companion instruction files or encryption metadata associated with encrypted S3 objects.
4. Modify an existing instruction file or introduce a new encrypted data key entry that is accepted by vulnerable SDK versions.
5. Wait for a legitimate application, batch job, or user workflow to retrieve and decrypt the affected object.
6. Cause the application to consume altered plaintext while treating it as valid decrypted content.

How to detect it

Detection should focus on evidence of tampering with S3 instruction files and encryption metadata, because exploitation requires prior write access to the bucket. Review CloudTrail S3 data events, S3 server access logs, object version history, IAM Access Analyzer findings, AWS Config changes, application decryption errors, and application integrity-check failures. Look for PutObject, CopyObject, DeleteObject, DeleteObjectVersion, CompleteMultipartUpload, or RestoreObject events against instruction-file companion objects, especially object keys ending in .instruction or containing JSON encryption metadata fields. Compare object and instruction-file version timestamps: suspicious cases include instruction files modified without a corresponding encrypted object update, modified by a different principal than the application normally uses, written from unusual source IPs or user agents, or changed shortly before downstream data integrity issues. Inspect S3 object versions for changes to encryption fields such as encrypted data key, wrapping algorithm, content encryption algorithm, IV, material description, or tag length. Application logs may show decryption failures, unexpected plaintext validation failures, parsing errors after successful S3 retrieval, or sudden data mismatches. If Invisible Salamanders is a tracked threat actor in the organization’s intelligence sources, correlate suspicious S3 metadata writes with actor-associated credentials, infrastructure, user agents, and time windows. Absence of a public KEV listing and low EPSS reduce likelihood of broad exploitation, but do not rule out targeted abuse by an insider or compromised cloud identity.

• .instruction
• eventName=PutObject
• eventName=CopyObject
• eventName=DeleteObject
• eventName=DeleteObjectVersion
• eventName=CompleteMultipartUpload
• x-amz-key
• x-amz-key-v2
• x-amz-iv
• x-amz-matdesc
• x-amz-wrap-alg
• x-amz-cek-alg
• x-amz-tag-len
• x-amz-unencrypted-content-length
• x-amz-meta-x-amz-key
• x-amz-meta-x-amz-key-v2
• x-amz-meta-x-amz-iv
• x-amz-meta-x-amz-matdesc
• x-amz-meta-x-amz-wrap-alg
• x-amz-meta-x-amz-cek-alg

What your security team should do

• Prioritize upgrading AWS SDK for Ruby to 1.208.0 or later in applications that perform client-side S3 encryption and use instruction files.
• Identify buckets containing instruction-file-based encrypted objects and enable S3 data event logging for read/write operations on those buckets if not already enabled.
• Review IAM and bucket policies to remove broad s3:PutObject, s3:DeleteObject, s3:PutObjectAcl, and copy/write permissions from identities that do not explicitly need them.
• Enable S3 Versioning, and where operationally suitable, Object Lock or retention controls for buckets holding high-integrity encrypted data.
• Create detections for writes, deletes, or copies involving instruction-file objects, especially from new principals, unusual source IPs, automation roles outside their normal schedule, or identities linked to recent credential exposure.
• Hunt historical CloudTrail S3 data events for instruction-file modifications before application data anomalies or decryption discrepancies.
• If threat intelligence for Invisible Salamanders is applicable, enrich S3 write-event investigations with known infrastructure, credential-use patterns, and identity anomalies associated with that activity.
• Document and migrate legacy client-side encryption patterns toward supported SDK versions and encryption modes with key commitment.