Lambda Layers - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/products/lambda-layers/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioFri, 03 Jul 2026 16:16:42 +0000AWS Lambda Layer Shared Externallyhttps://feed.craftedsignal.io/briefs/2026-07-aws-lambda-layer-shared-externally/Fri, 03 Jul 2026 16:16:42 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-07-aws-lambda-layer-shared-externally/This brief identifies the critical risk of an AWS Lambda layer's permission policy being modified, typically via the `AddLayerVersionPermission` API, to grant external AWS accounts, AWS Organizations, or the public access, potentially leading to the leakage of proprietary code or secrets and creating a supply-chain vector for attacker-influenced code execution in downstream functions.This threat focuses on the malicious or accidental configuration change of an AWS Lambda layer's permission policy, detected when an entity modifies permissions to grant access to external AWS accounts, entire AWS Organizations, or even the public. The primary mechanism for this action is the AddLayerVersionPermission API call. This configuration allows other entities to utilize the code and dependencies packaged within the Lambda layer. Such external sharing, especially with the public, presents a significant risk of exposing proprietary code, sensitive data, or embedded secrets. Furthermore, it creates a potential supply-chain attack vector, where compromised or malicious layers could inject attacker-influenced code into functions that reference them, impacting their runtime integrity and leading to further compromise. While legitimate cross-account sharing can occur, public or broad external sharing warrants immediate and thorough investigation due to its severe security implications.

Attack Chain

[Omitted - The source describes a specific configuration change and its potential implications, not a multi-stage attack chain.]

Impact

Successful external sharing of an AWS Lambda layer can result in the direct exposure and leakage of an organization's proprietary code and sensitive data, including API keys, database credentials, or other secrets embedded within the layer. If exploited as a supply-chain vector, an attacker could introduce malicious code into functions referencing the compromised layer, leading to various impacts such as unauthorized data exfiltration, remote code execution (RCE) within the function's execution environment, denial of service, or further lateral movement within the cloud environment. The broadness of access granted (e.g., to the public or an entire organization) directly correlates with the potential number of impacted entities and the scope of information exposure.

Recommendation

  • Deploy the provided Sigma rule to detect AddLayerVersionPermission calls in your AWS CloudTrail logs, particularly those granting public or external account access.
  • Investigate all instances of AddLayerVersionPermission where the principal in aws.cloudtrail.request_parameters is * (public) or an external AWS account ID.
  • Validate the layerName and the granted principal against approved sharing practices for your organization, as noted in the false_positives section.
  • If unauthorized sharing is detected, immediately remove the layer permission using the RemoveLayerVersionPermission API call and rotate any secrets that may have been exposed within the layer.
  • Restrict the lambda:AddLayerVersionPermission IAM permission to a limited set of trusted roles and principals to reduce the attack surface.
]]>mediumadvisorycloudawslambdasupply-chainmisconfigurationdata-leakage