Topic starter
11/11/2026 6:02 pm
TL;DR: Privileged Lambda roles can be reached through configuration changes alone, according to Plerion, even when iam:PassRole is absent. Configuration updates, not just code updates, can expose execution-role credentials and expand blast radius.
Editorial analysis by NHI Mgmt Group, based on content published by Plerion: “"But without PassRole it should be fine", Lambda edition”.
Key questions
Q: What is the difference between PassRole and runtime configuration abuse?
A: PassRole is the permission to let a principal assign an IAM role to a service or resource, while runtime configuration abuse changes the function’s behaviour after deployment without changing role assignment.
Q: How should teams detect malicious Lambda startup changes?
A: Teams should detect malicious Lambda startup changes by monitoring configuration writes, deployment artefacts and runtime settings such as environment variables, layers and handler or wrapper values.
Q: How do Lambda layers change the security model of a function?
A: Lambda layers add shared code and dependencies to a function, so the security model expands from the function package to include every layer it loads at runtime.
Practitioner guidance
- Treat configuration updates as privileged access Review who can call lambda:UpdateFunctionConfiguration on functions that run with sensitive permissions, and place that permission under the same approval standard as handler replacement.
- Restrict attachable layers to approved ARNs Use the lambda:Layer condition key or equivalent guardrails so only vetted layer versions can be attached to production functions.
- Block unapproved runtime wrappers Alert on updates that set AWS_LAMBDA_EXEC_WRAPPER or introduce new environment variables on functions with elevated execution roles.
Bottom line: The central risk is not role creation but role reuse inside an existing Lambda runtime with privileged permissions.
Glossary terms: Lambda extension layer, AWS_LAMBDA_EXEC_WRAPPER, IAM:PassRole, Lambda Layer
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/11/2026 6:06 pm
Lambda configuration is a privileged access path, not a housekeeping surface. The assumption that only iam:PassRole can place a powerful identity on a resource is too narrow for serverless operations. Once a function already carries an execution role, configuration rights can steer execution inside that role without any new assignment step. Practitioners should treat configuration-change authority as part of the privileged perimeter, not as a secondary admin setting.
A question worth separating out:
Q: Can least privilege fail even when no new role is created?
A: Yes. Least privilege can fail when the active function code, environment or attached dependency is changed to exercise capabilities already granted within the runtime boundary. In that case the role may remain unchanged, but the function can still reach data, services or credentials that its legitimate execution path should not need.
👉 Read our full editorial: Lambda config changes can expose privileged Lambda execution roles