A high-severity authorization vulnerability in an AWS integration package could allow a user with limited permissions to perform cloud operations through a more powerful Lambda execution role. The flaw, CVE-2026-94384, affects the sfExecuteAWSService function shipped with AmazonConnectSalesforceLambda versions 5.15 through 5.24.16.

The serverless application connects Amazon Connect contact-center features with Salesforce. Its affected function supports initial deployment by invoking AWS services needed during configuration. The problem is that it did not adequately confirm whether the caller was authorized to request the operation supplied in the function parameters.

A privileged function acting as a proxy

Under AWS’s permission model, a principal may be allowed to invoke a Lambda function without receiving direct access to every service that function can reach. The function then runs with its own execution role. That separation is normal, but it becomes a privilege-escalation path when caller-controlled parameters determine which AWS actions the function performs.

For the vulnerable integration, an identity with lambda:InvokeFunction permission could potentially ask sfExecuteAWSService to call APIs that the identity’s own policy would deny. The resulting impact depends on the execution role: a broadly privileged role could expose data, permit resource changes, or enable further movement across the cloud account.

An attacker would first need control of an IAM user or role that can invoke the function. That access might come from a compromised developer account, leaked automation credential, overly broad group policy, third-party integration, or cross-account trust. The flaw then turns a seemingly narrow permission into a channel for stronger actions.

Setup code can outlive its safe purpose

AWS says the function is intended for initial configuration. Leaving it enabled after the Amazon Connect and Salesforce integration is working creates avoidable exposure. This is a recurring cloud-security problem: bootstrap components receive expansive permissions to simplify installation, then remain deployed long after their operational purpose has ended.

Organizations should inventory the affected application in every account and region. Version checks should include serverless deployments created by old templates, not only actively maintained stacks. Teams should also review resource-based Lambda policies because they can grant invocation rights independently of identity policies.

Update, remove, and investigate

AWS released AmazonConnectSalesforceLambda 5.26 to correct the issue. Customers should upgrade and delete or disable sfExecuteAWSService after setup if it is no longer required. Where the function must remain, invocation should be limited to the single IAM identity used by the CTI Adapter.

• Remove broad lambda:InvokeFunction grants for the affected function.
• Use permission boundaries or service control policies to deny unwanted callers.
• Set the SalesforceExecuteAWSServiceUser parameter to the approved adapter identity.
• Inspect the Lambda execution role and eliminate unnecessary service permissions.
• Review CloudTrail, function logs, and cross-account trusts for unexpected invocation or API activity.

Investigators should correlate function invocations with the downstream AWS API calls made by its execution role. Unfamiliar services, unusual regions, configuration changes, and activity outside deployment windows deserve scrutiny. If malicious use is suspected, revoke sessions and rotate credentials associated with affected identities.

Least privilege must cover callable services

CVE-2026-94384 illustrates why reviewing an IAM principal’s attached policies is not sufficient. Callable functions, automation systems, and deployment tools may provide indirect capabilities that do not appear in the principal’s explicit permissions.

Cloud teams should model these transitive paths during access reviews: who can invoke a workload, which role the workload assumes, and which parameters the caller controls. Setup utilities deserve particularly strict lifecycle management. Removing them after installation is often simpler and more reliable than trying to preserve a powerful interface indefinitely.

The same review should cover other installation helpers and custom automation. A narrowly named function may still expose a general-purpose capability when it accepts service names, actions, or request bodies from its caller. Documenting and testing those boundaries makes indirect privilege escalation easier to detect before deployment.