Security News
Latest Updates

The Hacker News

Cybersecurity news and insights

New Zapscape KVM Flaw Could Let Privileged L1 Guest Code Escape to Linux Hosts - August 06, 2026

Zapscape, a new Linux kernel vulnerability, could allow an attacker with kernel privileges inside an L1 guest virtual machine (VM) to escape KVM isolation and execute code on the host. The risk applies when nested virtualization is exposed to untrusted guests.

The flaw is tracked as CVE-2026-64561 and affects KVM/x86’s shadow memory management unit (MMU), which manages shadow page

Cisco Patches 12 SD-WAN and IOS XE Flaws, Including Three 9.8 CVSS Score Bugs - August 06, 2026

Cisco has rolled out updates to address multiple critical security vulnerabilities impacting Catalyst SD-WAN and IOS XE Software as part of a comprehensive internal security review.

The security issues affect Cisco Catalyst SD-WAN Software, regardless of device configuration, and Cisco IOS XE Software when it is running in autonomous or controller mode.

“These vulnerabilities were found

New Interrupt Injection Attack Can Bypass Spectre v2 Defenses on Intel and AMD CPUs - August 06, 2026

An unprivileged Linux program can time a hardware interrupt to land in the gap between a processor sanitizing its branch predictor and the kernel using it, re-poisoning the predictor after the defense has run.

MIT CSAIL researchers Daniël Trujillo and Mengjia Yan named the technique INTERRUPT INJECTION. On an AMD Zen 2 machine running Linux 6.14 with every default Spectre v2 mitigation on,

ThreatsDay: Odysseus RCE, Samsung One-Click Takeover, iCloud Backdoor Fight + 27 More Stories - August 06, 2026

Apparently, opening the thing is now enough. A repo can run before the first prompt, a package can hide among hundreds, and a harmless-looking PDF can finish the job.

This week runs on cheap leverage: exposed servers, recycled bugs, poisoned agent instructions, remote-access tools dressed as support software, and trusted defaults doing attackers a favor.

Nothing here is especially mystical.

SecurityWeek

Latest cybersecurity news

Zero-Click AI Browser Hacking: Claude and ChatGPT Atlas Hijacked via Emails, X Posts - August 06, 2026

Zenity researchers reported the findings to Anthropic and OpenAI in late 2025 and early 2026, but they remain unpatched.

The post Zero-Click AI Browser Hacking: Claude and ChatGPT Atlas Hijacked via Emails, X Posts appeared first on SecurityWeek.

The Hacker News

Cybersecurity news and insights

Over 4,400 Rockwell PLCs Exposed Online, 22 Found in Water Attack Cities - August 06, 2026

Forescout found 22 internet-facing Rockwell Automation programmable logic controllers (PLCs) in cities hit by recent cyberattacks on US water utilities. Nineteen used the same mobile carrier network.

Its August 3 scan counted 4,407 exposed Rockwell controllers worldwide, including 2,844 in the United States, but Forescout could not confirm any were compromised. That figure counts exposed

SecurityWeek

Latest cybersecurity news

Podcast: Compliance Won’t Save You: The Future of Cyber Risk with Edna Conway - August 06, 2026

(Video) In this podcast, we share insights from Edna Conway, a recognized leader in cybersecurity and supply chain resilience with over 40 years of experience in the field.

The post Podcast: Compliance Won’t Save You: The Future of Cyber Risk with Edna Conway appeared first on SecurityWeek.

The Hacker News

Cybersecurity news and insights

CryptoJS Weak RNG Behind $5.7 Million in Drains Affects Five Crypto Wallet Apps - August 06, 2026

Coinspect has identified CryptoJS.lib.WordArray.random() as the weak random number generator behind the Ill Bloom wallet drains.

Introduced in the JavaScript cryptography library 12 years ago, the function supplied weak entropy that affected wallet apps used to generate recovery phrases. Coinspect’s on-chain analysis puts the measured theft across two sweeps since late May at a lower bound of

Apple iCloud Private Relay Can Expose Real IPs Through WebKit Proxy Bypasses - August 06, 2026

Cybersecurity researchers have disclosed a security issue with Apple’s iCloud Private Relay tool that can expose a user’s real IP address.

Introduced with iOS 15, iCloud Private Relay employs a dual-hop architecture to ensure users’ privacy by routing their Safari web traffic through two relays so that no single third-party, including Apple, can determine where the request is originating from

AI Recommendation Poisoning: How “Ask AI” Buttons Silently Alter LLM Memory - August 06, 2026

A new class of prompt injection is spreading across commercial websites. It requires no malware, no stolen credentials, and no zero-day exploit. It abuses a standard feature built into almost every major AI assistant: pre-filled deep links.

We observed production websites embedding hidden prompt injection payloads inside “Ask AI” buttons on marketing and competitor comparison pages. When a user

SecurityWeek

Latest cybersecurity news

Critical Paperclip Flaw Allowed Admin Access, Code Execution - August 06, 2026

An attacker could self-register, sign in for board-level API access, and import a new company for code execution.

The post Critical Paperclip Flaw Allowed Admin Access, Code Execution appeared first on SecurityWeek.

Schneier on Security

Security news and analysis by Bruce Schneier

Adversarial Clothing Designed to Fool Facial Recognition Systems - August 06, 2026

There are many companies manufacturing adversarial clothing designed to confuse facial recognition systems.

It’s a cool idea, but I worry that it’s mostly security theater:

“Our patterns play with that chaos, confuse algorithms and make it way harder to pin you down,” he said.

Bell, however, said “none of these products are tried and tested, and a lot of these surveillance technologies can deal with a little resistance … [but] even if the designs don’t necessarily work perfectly, fashion is also a visible sign of resistance.

“This is consumers collectively coming together to make a visible statement.”...

SecurityWeek

Latest cybersecurity news

Meta AI Hacked External Systems During Cybersecurity Testing - August 06, 2026

The incident involved a testing environment set up by Irregular, similar to what Anthropic reported last week.

The post Meta AI Hacked External Systems During Cybersecurity Testing appeared first on SecurityWeek.

The Hacker News

Cybersecurity news and insights

Attackers Compile khunt Inside Oracle to Turn SQL Injection Into Windows SYSTEM Access - August 06, 2026

Attackers broke into an organization’s Oracle database through a SQL injection flaw in a public-facing web application, then installed a post-exploitation toolkit without writing an executable to disk. They fed Java source code to the database, let Oracle compile it into stored schema objects, and ran commands from inside the database engine.

Huntress, which tracks the toolkit as khunt,

AWS, Google, and Vercel Agent Flaws Let Attackers Trigger Tools Without Running the Model - August 06, 2026

Security flaws in agent infrastructure from Amazon Web Services (AWS), Google, and Vercel let untrusted or forged instructions reach an agent’s tools with no check that a model turn had authorized them.

In several of the attack paths, the model never ran at all, so system prompts, content filters, and model-level guardrails never got a chance to intervene.

The affected products include Amazon

SecurityWeek

Latest cybersecurity news

Cisco Patches Critical SD-WAN, IOS XE, FMC Vulnerabilities - August 06, 2026

Patches were rolled out for two dozen vulnerabilities, including one with public proof-of-concept (PoC) code.

The post Cisco Patches Critical SD-WAN, IOS XE, FMC Vulnerabilities appeared first on SecurityWeek.

Hackers Start Exploiting Recent JetBrains TeamCity Vulnerability - August 06, 2026

Tracked as CVE-2026-63077, the critical bug can be exploited without authentication for remote code execution.

The post Hackers Start Exploiting Recent JetBrains TeamCity Vulnerability appeared first on SecurityWeek.

How a $50,000 Exploit Chain Turned Bixby Against Samsung Phones - August 05, 2026

The chain involved the exploitation of several vulnerabilities in the Samsung Members and Samsung Account applications.

The post How a $50,000 Exploit Chain Turned Bixby Against Samsung Phones  appeared first on SecurityWeek.

Trail of Bits Blog

Security research and insights from Trail of Bits

A few notes on AWS Nitro Enclaves: KMS integration - August 05, 2026

Nitro Enclaves and Key Management Service (KMS) feel like a natural fit: since the KMS can verify attestation documents generated by the enclaves, developers can offload key management tasks from their applications to the AWS-managed service. But integrating an external service with your trusted enclaves comes with new threats, even if that service comes from the same provider.

In this blog post—the third in our series on Nitro Enclaves, following our posts on attack surface and images and attestation—we catalog passive and active attack classes against the enclave-KMS communication channel, and cover the operational risks that persist even when the cryptography is correct.

Intro to KMS

The KMS is an AWS service that provides a unified public API for creating and managing keys backed by HSMs to the broader AWS ecosystem. There are three main key types supported by KMS that devs need to care about:

• Customer-managed keys (CMK)
• Data keys (DK, symmetric)
• Data key pairs (asymmetric)

CMKs never leave KMS. You request KMS to perform cryptographic operations (like encryption or signing) for you.

Data keys and key pairs are generated in KMS, are not stored in KMS, and are intended for programmatic uses.

For symmetric keys, the KMS gives you a plaintext key and the same key encrypted to CMK. Your application performs encryptions, removes the plaintext key, and stores the key encrypted to a CMK along the ciphertexts; this pattern is called envelope encryption.

For asymmetric keys, the KMS gives you a plaintext key pair and the private key encrypted to CMK. Your application creates signatures or encrypts data, deletes the private key, and keeps the public key and encrypted private key (along with signatures/ciphertexts).

Both types of data keys can be used with Decrypt operation to get plaintext keys again.

Access to keys is subject to authorization policies, including key policies, IAM policies, and grants. Cross-account access for keys can be enabled.

Keys can be identified in multiple ways: ARN, Id, Alias ARN, and Alias name. Keys are usually per-region (single-region), but multi-region keys can be created too.

Enclave-KMS communication

There are two mechanisms that are in play when integrating KMS with Nitro Enclaves:

• KMS policies restricting access to CMKs to specific enclaves (by PCR values)
• KMS encrypting responses to enclave’s public keys

In the first mechanism, the key policy may authorize access to only requests that contain fresh and correctly signed attestation documents with the expected PCR values. Enclaves have to generate attestations and include them in requests to KMS. Note that the enclave still needs IAM credentials to access KMS in the first place.

The second mechanism is about enclaves sending asymmetric public keys (inside the attestation documents) to KMS, and KMS encrypting part of the responses to the key. This mechanism is supposed to ensure that only the requesting enclave can see output from KMS.

Only a few KMS operations support these two mechanisms. The operations are:

• GenerateDataKey, GenerateDataKeyPair
• Decrypt
• DeriveSharedSecret
• GenerateRandom

Note the absence of the Encrypt operation: enclaves can request this operation, but without the attestation-based security mechanisms. CMKs cannot be used directly by enclaves for encryption without missing on the attestation checks. This means cryptography operations are supposed to be implemented via data keys, and not directly via CMKs.

Use cases

KMS can be integrated with Nitro Enclaves for various reasons: for application-specific needs, to sign enclave image files (EIFs), or to increase the entropy available in the enclave.

The application-specific use cases are based on KMS’ ability to verify attestation documents, which in turn enables developers to write KMS authorization policies based on PCR measurements from the attestation. A common use case is implementation of authenticated external storage for the enclaves. When access to KMS keys is restricted by PCRs 0-2, only a specific enclave version has access to the keys.

Enclave image files can be signed. Any signing certificate (private key) can be used for the task, but the officially supported ways include signing with a key stored in a local file, and via KMS. The signing certificate used for the EIF is then exposed as PCR8. This PCR can be used in KMS policies. This feature lets one to restrict access to KMS keys to enclaves created by the same developer, while developer identity is protected by the KMS too.

Finally, the GenerateRandom method of KMS can be used to add more entropy to the enclave. While not critically important – enclaves already have access to high quality entropy from the hypervisor – additional randomness may increase trust in the system. On the other hand, one may argue that the added complexity exceeds the benefits. No strong opinions here.

Passive attack prevention

Threats to the enclave-KMS communication can be divided into two categories: passive and active. Passive attackers can observe traffic and modify data that is stored outside of the enclave and is not attested (data at rest). Active attackers can additionally modify all traffic coming in and out of the enclave (traffic on the network).

The exact landscape of passive attacks depends on specific system design, but KMS operations allow us to reason about them fairly well, as an attacker can control any and all of the inputs to these operations. This tl;dr checklist helps avoid passive attacks:

• Requests to KMS always contain the Recipient parameter.
• Encryption context is used for supported operations.
  • Context is decided by enclaves, and is not fully attacker-controlled.
  • Encrypt and GenDataKey operations are authorized properly.
• Data encrypted with data keys has context.
  • Key commitment is considered.
• Correct CMK is used.
  • CMK ARN is hardcoded.
  • keyId from response is checked.
  • Decrypt requests always specify key ID.
  • IAM role is attested.
  • Full ARNs are used, key aliases are not used.
• Freshness/replay attacks are mitigated.
• Side-channel attacks are considered.
• Key types and cryptographic algorithms are validated.

The Recipient parameter includes attestation, which allows KMS to validate PCRs. If key policies are correctly configured, requests without this param fail, so it is rather hard to miss.

A single CMK key can be used to generate multiple data keys and shared secrets. Since the encrypted data keys are stored outside of the enclave, an attacker can swap them. It is therefore important to cryptographically distinguish the ciphertexts, and the encryption context is one of the ways to achieve that. Importantly, this solution works only if the attacker does not have full control over the encryption context; if they do, they can swap the ciphertext blob while also making the enclave use the wrong context.

Below are diagrams for simple “data swap” attacks that encryption contexts can prevent.

Passive attackers that can call Encrypt (or ReEncrypt) on a CMK can perform an even more severe version of the attack above and swap the DK-ciphertext pair with a custom one, effectively providing arbitrary plaintext to the enclave. The same issue applies if an attacker can call GenerateDataKey. Note that some cases may require authorization to these operations for non-enclave entities, but this authorization should be revoked after the initial setup.

The attacks we’ve discussed so far have been on the “envelope” level. Similar issues exist on the DK level if a DK is used multiple times (though this rarely happens). These issues should be solvable with correct encryption context implemented via AAD.

Some funky attacks are possible if an algorithm without key commitment property is used with data keys: an attacker can generate a single ciphertext that correctly decrypts under different keys. Though this is unlikely, the key commitment should be considered as part of a security audit.

The next class of attacks is when the host can select CMK that enclave uses. The exact nature of the attack depends on specific degrees of freedom, but in the worst case, the host can force the use of a completely unprotected CMK.

To protect against these attacks, the enclave must ensure the expected CMK is used; this can be done by hardcoding full ARN, so it is attested. Then the attested ARN must be provided as the optional keyId parameter in Decrypt requests, and validated against keyId from KMS responses. Note that the keyId param is optional, because CiphertextBlob includes a reference to the CMK as metadata (HBKID in Appendix A): the metadata is not cryptographically protected, and the attacker may be able to manipulate it.

Using key aliases instead of ARNs is possible but risky, as the aliases are more ambiguous. Specifically, an attacker can manipulate the enclave’s IAM credentials to trick the enclave into using the wrong AWS account or AWS Region and therefore a wrong CMK. That’s why we recommend attesting the IAM role that the enclave must use and validating that role against IAM credentials provided at runtime. The enclave can do this by calling sts:GetCallerIdentity.

Replay attacks are an interesting attack vector. Attestations include timestamps that KMS validates to be at most five minutes old. While this means old documents cannot be replayed, there is still a time window when a malicious host can observe a document and use it multiple times. As attestations are not cryptographically bound to the requests, the attacker can use the attestation with any supported operation with arbitrary params. Although the responses are encrypted with the attestation’s public key and cannot be decrypted by the attacker, this gives the attacker some abilities that must be considered during an audit. For example, an attacker can request multiple decryption with different CMK keys and later use the KMS responses to confuse the state machine of the enclave. Note that the user_data and nonce fields from attestation documents are not used by KMS at all.

Even when an attacker cannot observe exact traffic exchanged with KMS, the attacker can note times, orders, and sizes of communication. This may be used to deduce some information, depending on the specific protocol your enclaves implement.

Finally, requests and responses to KMS include many key specifications and algorithm identifiers (CMK KeySpec, attestation’s KeyEncryptionAlgorithm, Decryption operation’s EncryptionAlgorithm, for example). Ideally these must not be attacker-controlled in requests (e.g. are bundled in EIF) and the identifiers from responses are checked against the expected ones by the enclave.

Active attack prevention

As a reminder, active attackers can additionally modify all traffic coming in and out of the enclave. This tl;dr checklist helps avoid active attacks:

• Active attacks are prevented with enclave-initiated TLS.
• TLS CA is bundled inside the enclave (attested).
• VPC is used.

Many problems may arise when active attacks are in scope. Most importantly, the attestation and its pubkey are not bound to other parts of the request. This allows the attacker to change the CMK ID in requests and responses (even if the ID is bundled in EIF); to encrypt any data key under the attestation pubkey and use it for replays; or to attack not-authenticated AES-CBC encryption in CiphertextForRecipient responses.

These vulnerabilities are basically unsolvable without a secure communication channel. Therefore, TLS initiated inside the enclave is required if active attacks are in scope. For the enclave-initiated TLS solution to be secure, the enclave’s CA set must be limited; ideally, the KMS’ CA certificate (Amazon’s) is attested and pinned.

With this setup, the active attacker threat may be considered prevented. Note that having a secure communication channel implicitly prevents some of the possible vulnerabilities described in the “passive attacks” section.

KMS terminates TLS outside of HSM (most likely), and the attestation’s pubkey encryption is probably done outside of HSM. This makes it impossible to have an end-to-end TLS channel between enclave and HSM, and AWS insiders may theoretically constitute an active attacker threat. Your threat model should account for this possibility.

To further protect the communication channel, VPC can be used. This ensures that traffic never leaves AWS infrastructure and generally isolates the parent EC2 at the network level. Moreover, key policy can authorize requests based on the VPC. This makes attacks easier to detect in case of stolen IAM credentials; this is valuable even if key access is authorized via PCRs, as demonstrated in the previous sections.

KMS policies

Correctly authorizing access to CMK keys is critical. The list below includes basic checks for your KMS key policy. AWS’ recommendations for IAM policies provides more generic advice.

• Configured KMS policy authorizes enclaves in a reasonable way.
  • No unexpected IAM roles have or can get access.
  • PCR0 is used for authorization. PCRs 1-2 are used for defense in depth. Alternatively, PCR8 is used.
  • Principal for RecipientAttestation is not a wildcard.
  • PCR3 is used to restrict by EC2 IAM role.
  • kms:EncryptionContext condition is used when relevant.
• For critical key operations (e.g., deletion) the policy requires MFA.
• TLS and VPC restrictions are considered.
• For end-to-end security, the clients can verify that the enclave uses correct and properly secured KMS keys.
  • Immutable key policies are likely not possible, and clients must be aware of this.

Of course, the exact CMK policy setup is business-dependent. Generally, you should ensure that the key can be managed only by the expected IAM principal, and the principal doesn’t have access to Decrypt operation (and possibly others like GenDataKeys and Encrypt).

The figure below shows an interesting example of a vulnerable key policy that violates the “only expected IAM principal” check. One may assume that only the root user and the enclave can operate on the key, but this is incorrect: the first policy entry grants full access to any IAM role that has access to the key configured in the role’s policy. The fix is to use a specific IAM user or role instead of root or to add an explicit deny statement for non-root users.

[
 {
 "Sid": "Enable IAM User Permissions",
 "Effect": "Allow",
 "Principal": { "AWS": "arn:aws:iam::599412696120:root" },
 "Action": "kms:*",
 "Resource": "*"
 },
 {
 "Sid": "Allow Nitro Enclave KMS operations with PCR0 lock",
 "Effect": "Allow",
 "Principal": {
 "AWS": "arn:aws:iam::599412696120:role/NitroEnclaveKMSRole"
 },
 "Action": ["kms:Decrypt", "kms:GenerateDataKey", "kms:GenerateDataKeyPair"],
 "Resource": "*",
 "Condition": {
 "StringEqualsIgnoreCase": {
 "kms:RecipientAttestation:PCR0": "00a119d1...0ed55"
 }
 }
 }
]

For the PCRs, you want to use PCR0, as it binds the policy to specific enclave code. Additionally, using PCRs 1-2 is recommended for the reasons stated in our blog post on the Nitro Enclaves attack surface. Alternatively, you can use PCR8, which allows updating the enclave code without needing to update key policy. This allows more restricted access to key policy modification permission at the cost of managing the signing key.

The Principal field and PCR3 measurement provide further restrictions. Principal is used to authorize the IAM role used to access KMS, while PCR3 is measured by hypervisor at the time of enclave launch based on EC2 role. The EC2 role can be dynamically changed and should be considered untrusted from the enclave’s perspective. Yet both Principal and PCR3 can be used to prevent attackers from running (signed) enclaves on their own EC2 instance (which could make side-channel attacks easier) and accessing the KMS key.

Access to the key can be further improved with TLS and VPC restrictions. VPC can be enforced with aws:SourceVpc and similar condition keys. TLS can be enforced with the aws:SecureTransport condition (although this condition is redundant, as it’s not possible to access the KMS API with plain HTTP).

As the key has to be manageable by some IAM role (at least to allow key deletion), the aws:MultiFactorAuthPresent and aws:MultiFactorAuthAge conditions can be used to strengthen the authorization.

KMS policy end-to-end verification

So far, our discussion has focused on how to secure the KMS keys. A much more difficult problem arises when you want your system to provide end-to-end verifiability to end-users. If enclaves can be reproducibly built and remotely attested by users, then users likely have to validate that the KMS keys are properly protected, too. Otherwise, a malicious insider can pass remote attestation (not modify enclave code), yet use KMS directly with IAM permissions to get full access to the keys.

One solution is to hardcode the hash of the key policy in the enclave, provide full policy along with enclave’s code to clients, and make the enclave validate the hash against the dynamically obtained policy before sending attestation-protected requests to the KMS. This requires the enclave to have kms:GetKeyPolicy and kms:DescribeKey permissions.

This alone doesn’t prevent attacks. A malicious IAM user can dynamically change the policy after the enclave’s verification. To prevent this, the policy has to be made immutable, which can be achieved by blocking kms:PutKeyPolicy permission for all users. Note that --bypass-policy-lockout-safety-check flag is required to insert such a statement via CLI.

{
 "Sid": "DenyPutKeyPolicyForAll",
 "Effect": "Deny",
 "Principal": {
 "AWS": "*"
 },
 "Action": "kms:PutKeyPolicy",
 "Resource": "*"
}

Locking access by PCR0 and denying all kms:PutKeyPolicy operations makes the system quite immutable. This has the obvious downside of making updates and bug fixes difficult. As mentioned earlier, the specific setup must be adjusted based on business requirements.

Note that key owners can always contact AWS support to restore default key policies. How AWS authenticates such requests I do not know, but AWS likely won’t check if the key is used in an enclave-enabled setup. This makes a system with full end-to-end trust hard to implement.

Finally, consider implementing publicly observable and verifiable monitoring and alerting for key policies. Such a system would alert end users when a policy changes, mitigating the impact of policy restoration by AWS support. However, we are not aware of any “Certificate Transparency”-style public, append-only log for KMS key policies that an external party can independently verify.

Operational concerns

Even if the system is secure point-in-time, there are operations that must be periodically performed. These introduce new risks into the system. This checklist covers these concerns:

• Key rotation and revocation is implemented for CMK.
  • ReEncrypt operation is not used for data keys.
• Backups:
  • Risks from CMK destruction are mitigated.
  • Regional outages are considered.
  • Data keys are backed up as needed.
• Users cannot cause a denial of service or balloon the bill.
  • The number of user-triggered KMS operations is limited.
  • Request quotas are considered.
  • Limits on data lengths are respected.
  • KMS’s clients take into account delays in KMS updates.

AWS provides mechanisms to easily rotate CMK keys. The only item to note here is that rotating a compromised CMK does not make data keys protected by it non-decryptable. For a CMK revocation, a more involved approach than just rotating CMK and destroying data keys must be implemented.

Rotating data keys is hard to implement securely, as the KMS ReEncrypt operation does not support attestations. The system should be designed so that such rotations are not needed.

A malicious actor deleting CMK keys permanently creates a risk of non-recoverable system state. The system’s design can sometimes be made so that destruction of a single key is recoverable (e.g., by setting up key hierarchy and using secret sharing). Nevertheless, there should be security controls in place mitigating the risk. First, configure a scheduled deletion period for keys to a time in which your team can act on an incident. Set up CloudWatch alarms for KMS keys for deletion events, and tighten IAM policies with Service Control Policies that prevent KMS key deletion.

Single-machine disasters in AWS infrastructure are not a concern, as single-region KMS keys are replicated within the region in multiple Availability Zones in multiple HSMs. However, if the system must be resilient to a regional outage, multi-region keys should be used instead of single-region keys.

Encrypted data keys backups are a responsibility of the system, not AWS. Note that the CMK key may become unusable in a few scenarios, and the data key backup system must account for this.

Yet another set of risks relates to billing. AWS charges dollars per KMS operations and CMK key maintenance, so the system must not let end-users make the enclaves send arbitrary many requests to KMS. When implementing rate-limits, KMS quotas must be taken into account.

Inputs to KMS have various size limits. For example, plaintexts can be up to 4096 bytes long, ciphertexts can be up to 6144 bytes long, and key IDs can be up to 2048 bytes long. These limits are unlikely to be reached with attestation-supported operations, but still should be considered.

Finally, changes to KMS resources need some time to propagate and synchronize inside AWS infrastructure. Your system must expect delays and possible temporary inconsistencies when requesting KMS.

Software and SDKs

Amazon ships a lot of SDKs for various tasks. Among them is aws-nitro-enclaves-sdk-c that provides tools and a library for enclaves-KMS communication. Avoid it: this particular SDK is written in C, and we found it contains vulnerabilities that can be used to exploit enclaves from the parent host.

Rather than using the aws-nitro-enclaves-sdk-c, we recommend a combination of other libraries, such as the following:

• aws-nitro-enclaves-nsm-api (in Rust) to get attestation documents
• KMS.Client from Boto3 (in Python) to communicate with KMS
• Any cryptographic library to parse and decrypt responses

Final notes

Many issues can arise from misusing the KMS within enclave-secured systems. This blog post does not even cover all supported operations (GenerateDataKeyPair, DeriveSharedSecret), possible vulnerabilities (key reuse, key wearout, forward secrecy, nonce management, …) and system features (custom key stores, multi-region keys, …). Make sure to document your system’s protocol, have a cryptographer review it, and check the actual implementation against it.

Appendix A

Data formats of the CiphertextBlob and CiphertextForRecipient structures are presented below.

Schneier on Security

Security news and analysis by Bruce Schneier

Vulnerabilities in Car Anti-Theft Device - August 05, 2026

This is disturbing:

…a team of security researchers at UC San Diego, who found that a model of aftermarket car alarm known as the KARR Security System, installed in more than 2 million vehicles across the US by their estimate, can let any hacker within Bluetooth range send radio commands to silently unlock the car at will, turn off its alarm, honk the car’s horn or flash its lights, or even disable its ignition and leave a driver stranded.

Iran Cyberattacks Against Minnesota Water Systems - August 04, 2026

Attribution is preliminary, and so far it seems no real damage.

And it seems like this is a campaign that has targeted at least seven states. And, because this is where the US is right now, Trump doesn’t believe it’s Iran and that Minnesota…I guess…hacked itself.

“I think I blame it on Minnesota because they’re grossly incompetent,” Trump said. “I would blame it on Minnesota and the governor, the corrupt governor of Minnesota. They like to say, ‘Oh, it’s Iran.’ Iran should be so lucky. Iran’s got bigger problems than worrying about Minnesota.”...

Some Claude Chats Are Searchable on Google - August 04, 2026

And it’s personal information (alternate link):

The exposed data includes an AI-powered therapy app that someone appears to have vibe-coded, notes on meetings, and a dashboard someone made apparently to analyze medical billing data. Exposed chats reportedly include private cryptocurrency wallet keys and personal information like peoples’ addresses.

What seems to be the issue is a user setting about data sharing. Anthropic’s position is that it’s not their problem:

“We give people control over sharing their Claude conversations publicly, and in keeping with our privacy principles, we do not share chat directories or sitemaps with search engines like Google,” the company said in a statement. “These shareable links are not guessable or discoverable unless people choose to share them themselves. When someone shares a conversation, they are making that content publicly accessible, and like other public web content, it may be archived by third-party services.”...