Submit #866026: wongcyrus ExcelLexBot 0.0.3 and earlier Improper Access Controls

ExcelLexBot SAR application creates an over-privileged Lambda execution role enabling account takeover after function compromise
Affected component:ExcelLexBotS3TriggerFunction Lambda execution role
Summary:
The AWS Serverless Application Repository application "ExcelLexBot" defines a Lambda function named ExcelLexBotS3TriggerFunction with an execution role that receives excessive IAM and Lambda permissions by default.

The function is intended to create an Amazon Lex chatbot when an XLSX file is uploaded. However, the SAR template grants the function broad IAM role-management permissions on Resource "*" and attaches high-privilege AWS managed policies, including AWSLambda_FullAccess, AmazonLexFullAccess, AmazonSNSFullAccess, AmazonDynamoDBFullAccess, AWSLambdaExecute, and AWSXrayWriteOnlyAccess.

If an attacker obtains code execution in ExcelLexBotS3TriggerFunction, for example through a bug in the function code, dependency compromise, malicious S3 input, or another runtime compromise, the default permissions allow the attacker to escalate privileges to full account administrator access.

Technical details:
The SAR template defines ExcelLexBotS3TriggerFunction with broad policies. The dangerous permissions include:
- iam:CreateRole on Resource "*"
- iam:DeleteRole on Resource "*"
- iam:AttachRolePolicy on Resource "*"
- iam:DetachRolePolicy on Resource "*"
- iam:PutRolePolicy on Resource "*"
- iam:DeleteRolePolicy on Resource "*"
- iam:PassRole on Resource "*"
- AWSLambda_FullAccess attached to the function role
- Additional broad managed policies for Lex, SNS, DynamoDB, Lambda execution, and X-Ray

This combination allows a compromised function runtime to modify IAM roles, attach administrator-level policies, create or modify Lambda functions, pass roles to new functions, and move laterally into other execution roles.

The issue is not initial access by itself. The risk is that any compromise of the ExcelLexBotS3TriggerFunction runtime becomes a deterministic privilege-escalation path because the execution role is already powerful enough to grant administrator permissions or create backdoor Lambda functions.

Example attack paths:
1. Direct privilege escalation:
An attacker with code execution in ExcelLexBotS3TriggerFunction can use iam:AttachRolePolicy to attach arn:aws:iam::aws:policy/AdministratorAccess to the function's own execution role. Alternatively, iam:PutRolePolicy can be used to add an inline administrator policy. This turns the compromised Lambda execution role into an administrator role.

2. Role and Lambda backdoor creation:
Because the role has IAM role-management permissions and AWSLambda_FullAccess, an attacker can create new IAM roles, attach high-privilege policies, create new Lambda functions, and use iam:PassRole to bind those roles to attacker-controlled functions.

3. Lateral movement through existing Lambda functions:
An attacker can use Lambda management permissions to update function code or configuration of other Lambda functions in the account. If those functions use higher-privileged roles, the attacker may obtain access to those roles' runtime credentials.

4. Lambda layer and configuration abuse:
An attacker can modify Lambda configuration or attach malicious layers to other functions. When those functions execute, attacker-controlled code may run inside the target function environment and access environment variables or temporary credentials associated with the target function role.

Impact:
Successful exploitation can lead to full AWS account takeover after compromise of the ExcelLexBotS3TriggerFunction runtime.

Potential impact includes:
- Escalating the function's own execution role to AdministratorAccess
- Creating new IAM users, roles, policies, or access keys
- Creating persistent backdoor Lambda functions
- Passing privileged IAM roles to attacker-controlled functions
- Modifying existing Lambda function code or configuration
- Accessing temporary credentials from other Lambda execution roles
- Accessing, modifying, or deleting AWS resources reachable by the escalated role
- Disabling or weakening logging, monitoring, or security controls
- Moving laterally across serverless workloads and IAM trust boundaries

The risk is especially significant because the application is distributed through AWS Serverless Application Repository and may be deployed by customers who trust the default IAM policies provided by the SAR template.

Steps to reproduce:
1. Deploy ExcelLexBot from AWS Serverless Application Repository in a controlled AWS test account.
2. Confirm that the deployment creates ExcelLexBotS3TriggerFunction.
3. Open the IAM execution role associated with ExcelLexBotS3TriggerFunction.
4. Confirm that the role has broad AWS managed policies such as AWSLambda_FullAccess, AmazonLexFullAccess, AmazonSNSFullAccess, AmazonDynamoDBFullAccess, AWSLambdaExecute, and AWSXrayWriteOnlyAccess.
5. Confirm that the role has an inline policy allowing IAM role-management actions such as iam:CreateRole, iam:AttachRolePolicy, iam:PutRolePolicy, and iam:PassRole on Resource "*".
6. In the test account only, simulate compromise of the function runtime.
7. Confirm that code running under the function role can attach administrator-level permissions to the role or create privileged Lambda-based backdoors.
8. Confirm that the resulting role permissions allow administrator-level actions in the test account.

Recommended remediation:
- Remove AWSLambda_FullAccess from the Lambda execution role.
- Remove broad IAM role-management permissions from the function role.
- Do not allow iam:AttachRolePolicy, iam:PutRolePolicy, iam:CreateRole, or iam:PassRole on Resource "*".
- Restrict iam:PassRole to specific required role ARNs only.
- Replace broad managed policies with least-privilege inline policies required for the Lex bot workflow.
- Scope Lambda permissions to specific function ARNs and required actions.
- Add conditions such as iam:PassedToService where role passing is required.
- Review existing deployments and manually reduce permissions on deployed roles.
- Add SAR-side warnings or blocking controls for templates that combine broad IAM permissions with AWSLambda_FullAccess.

Disclosure and vendor coordination:
This issue was reported to AWS through HackerOne AWS VDP. AWS initially classified it as customer-side under the Shared Responsibility Model, but later reopened and triaged the report as part of a broader review of overly permissive IAM patterns in AWS Serverless Application Repository applications.

Disclosure timeline:
2025-12-26: Reported to AWS VDP.
2025-12-28: HackerOne triage validated the issue, changed the weakness to Improper Preservation of Permissions, scoped it to AWS Lambda, and assessed severity as Medium.
2025-12-30: AWS initially closed the report as Informative under the Shared Responsibility Model.
2025-12-31: The reporter clarified the SAR platform-level risk and requested publisher coordination and stronger SAR safeguards.
2026-01-20: AWS reopened this report and related SAR IAM permission reports for further investigation.
2026-02-17: AWS marked the report as Triaged and confirmed that the concern was being addressed.
2026-03-25: AWS stated that SAR controls had been implemented to block publication of applications with these permission patterns, including applications that attach AWSLambda_FullAccess to Lambda functions or grant iam:AttachRolePolicy, iam:PutRolePolicy, or iam:* on all resources.
2026-03-27: AWS released SAR-side updates to block publication of applications containing overly broad IAM permission patterns.
2026-05-01: AWS provided an approved public statement for publication.

AWS public statement:
AWS stated that it investigated and resolved the reported concerns. On March 27, 2026, AWS released updates that block publication of AWS Serverless Application Repository applications containing overly broad IAM permission patterns. AWS also notified affected application publishers and customers who deployed these applications with remediation guidance. No customer action is required for new deployments.

References:
https://docs.aws.amazon.com/serverlessrepo/latest/devguide/using-aws-sam.html
https://docs.aws.amazon.com/serverlessrepo/latest/devguide/acknowledging-application-capabilities.html
https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

Notes:
This entry concerns the ExcelLexBot SAR application and the default execution role created for ExcelLexBotS3TriggerFunction. AWS handled the issue as part of a broader SAR platform remediation for third-party applications containing overly broad IAM permission patterns.

• Quelle: ⚠️ https://github.com/wongcyrus/ExcelLexBot
• Benutzer: changli (UID 99220)
• Einreichung: 23.06.2026 08:34 (vor 2 Monaten)
• Moderieren: 08.08.2026 20:59 (2 months later)
• Status: Akzeptiert
• VulDB Eintrag: 387214 [wongcyrus ExcelLexBot bis 0.0.3 Lambda Function ExcelLexBotS3TriggerFunction erweiterte Rechte]
• Punkte: 20