amazon-connect-salesforce-lambda CVE-2026-94384

The affected amazon-connect-salesforce-lambda integration (before v5.26) must be deployed in the AWS account, and the attacker must be an AWS IAM principal that already holds lambda:InvokeFunction permission on the sfExecuteAWSService Lambda function. The core issue is that this Lambda accepts caller-supplied service/API/parameters and dispatches them to privileged AWS APIs using its own execution role without validating the caller's authorization, so any such invoker can perform operations denied to their own IAM identity. Limiting factors: exploitation requires a pre-existing authenticated AWS foothold with invoke rights (PR:L), not anonymous access; it only affects organizations running this specific Salesforce-CTI integration; and v5.26 adds a SalesforceExecuteAWSServiceUser parameter (plus the vendor recommendation to delete/disable sfExecuteAWSService or restrict invocation to the intended IAM user) that closes the gap.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) yields 8.1 (High) and is well-founded: this is a network-reachable confused-deputy privilege escalation requiring only low privileges (PR:L - any AWS IAM principal already holding lambda:InvokeFunction on the affected function), no user interaction, and low attack complexity. The realistic impact is significant - a low-privileged AWS caller can perform privileged AWS API operations their own IAM policy explicitly DENIES, breaking the IAM authorization boundary (hence C:H/I:H). However, several signals temper widespread-risk concern: there is no EPSS score, no CISA KEV listing, and no public POC in the provided data, and the flaw was self-reported by the vendor (AMZN) rather than surfaced through observed exploitation. Exploitation is also gated on the attacker already possessing an AWS identity with invoke permission on the specific sfExecuteAWSService Lambda within a victim's account - i.e., an insider or an already-partially-compromised principal, not an anonymous internet attacker. Net: a genuinely serious privilege-escalation flaw for organizations running this specific integration, but scoped to environments that deploy it and to callers who already have a foothold; prioritize patching where the integration is present, but broad opportunistic exploitation is unlikely. One nuance to verify: the vendor scored S:U, yet the vuln lets the Lambda's execution role act on other AWS services beyond the caller's authority, which is arguably a scope change (S:C) - worth confirming against AWS bulletin 2026-115.

An organization deploys the Amazon Connect-Salesforce Lambda integration, and an IAM principal (e.g., a limited service account or lower-tier user) is granted lambda:InvokeFunction on the sfExecuteAWSService function. That principal invokes the Lambda with attacker-chosen service/API/parameter values; the Lambda executes them under its own broader IAM execution role without validating that the caller is authorized, letting the attacker perform AWS API operations explicitly denied to their own identity. No public exploit code was identified in the provided data, and the attack requires an existing authenticated AWS foothold (PR:L).