Like leaving the master key inside the locksmith's toolbox after the locks were installed
CVE-2026-94384 is a missing-authorization flaw in the sfExecuteAWSService Lambda function shipped with Amazon's Connect–Salesforce integration package (AmazonConnectSalesforceLambda). Versions 5.15 through 5.24.16 are affected. The function accepts caller-controlled parameters and dispatches them to AWS service APIs using the Lambda's own privileged execution role — without checking whether the invoking IAM principal is authorized for those operations. Any principal with lambda:InvokeFunction on this specific function can escalate to perform actions their own IAM policy explicitly denies. The fix is version 5.26, released 2026-09-22. Researcher Chang Li of Xidian University discovered and reported the issue through coordinated disclosure.
The vendor rates this HIGH / 8.1 on CVSS v3.1, but the v4.0 re-score from the GHSA advisory drops it to 6.4 MEDIUM — and reality supports the lower number. The function is a *setup utility*: AWS's own documentation tells customers to delete or disable sfExecuteAWSService the moment initial configuration finishes. The product itself is a niche contact-center integration used by the subset of AWS customers running both Amazon Connect *and* Salesforce. Exploitation requires pre-existing AWS IAM credentials, and the blast radius is capped by whatever permissions the Lambda execution role was granted — typically scoped to Connect/Salesforce integration tasks, not account-wide admin. The 8.1 treats this as a generic network-accessible escalation and ignores every one of those narrowing factors.
4 steps from start to impact.
Obtain AWS IAM credentials with lambda:InvokeFunction
lambda:InvokeFunction permission on the target sfExecuteAWSService function ARN. This could come from a compromised developer workstation, leaked CI/CD secrets, or a phished SSO session federating into the AWS account. Without this existing access, the chain cannot begin.- Valid AWS IAM credentials in the target account
- lambda:InvokeFunction permission on the sfExecuteAWSService function ARN
- Requires pre-existing authenticated access to the specific AWS account — this is not an unauthenticated attack
- The function ARN must be known or discoverable, which typically requires ListFunctions or prior knowledge of the deployment
lambda:Invoke call. AWS GuardDuty anomaly detectors flag unusual Lambda invocations from new principals or IP ranges.Identify the sfExecuteAWSService function is still active
lambda:GetFunction or attempt an invocation to confirm.- The target organization deployed AmazonConnectSalesforceLambda v5.15–5.24.16
- The sfExecuteAWSService function was NOT deleted or disabled after initial setup
- AWS documentation explicitly tells customers to delete this function after setup — compliant deployments are immune
- Amazon Connect + Salesforce CTI is a niche integration; most AWS accounts will not have this package deployed at all
GetFunction and Invoke API calls against the Lambda function. CSPM tools (Prisma Cloud, Wiz, Orca) can inventory Lambda functions and flag residual setup utilities.Craft privileged API payload and invoke the function
sfExecuteAWSService with this payload. The function dispatches the request using its own execution role without validating that the caller is authorized for the requested operation. Public PoC code demonstrates the invocation pattern.- Knowledge of the sfExecuteAWSService input schema (publicly documented and in PoC code)
- The Lambda execution role must have permissions for the targeted AWS API call
- The Lambda execution role is typically scoped to Amazon Connect and Salesforce integration actions — not broad IAM or S3 admin
- Well-configured permission boundaries on the Lambda role further limit what can be escalated to
Exfiltrate data or establish persistence
- The Lambda execution role has permissions beyond what the attacker's own identity allows
- Target data or persistence surfaces are accessible to the role
- Least-privilege Lambda roles — which AWS best practices demand — sharply limit what the attacker can reach
- AWS SCPs at the organization level can block sensitive actions regardless of the Lambda role's policy
The supporting signals.
| In-the-wild exploitation | Not observed. Not listed in CISA KEV. No known campaigns or ransomware associations reported as of 2026-09-24. |
|---|---|
| Proof-of-concept | Available — 2 public PoC references cataloged (per TheHackerWire). Invocation pattern is straightforward: craft a JSON payload with target AWS service/action and pass it to lambda:Invoke. Researcher: Chang Li, Xidian University. |
| EPSS | 0.00413 (0.41%) — 35th percentile. Reflects the niche deployment footprint and authenticated-access prerequisite. |
| KEV status | Not listed. No CISA KEV entry as of 2026-09-24. |
| CVSS v3.1 vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N — Network-accessible, low complexity, low privilege required, high confidentiality+integrity impact, no availability impact. Scope is Unchanged (stays within the Lambda account boundary). |
| CVSS v4.0 score | 6.4 MEDIUM per GHSA advisory — AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:H/SI:H/SA:N. The v4.0 methodology acknowledges the subsequent-system impact distinction. |
| Affected versions | AmazonConnectSalesforceLambda v5.15 through v5.24.16. Introduced in v5.15. Versions prior to 5.15 are not affected. |
| Fixed version | v5.26 — released 2026-09-22. Git fix commit: 96579b79b6f89fa4bcf9cf9ce231b29636762719. GHSA: GHSA-c9j2-qjfv-mm4p. |
| Exposure surface | Not scannable externally — this is an AWS Lambda function invocable only by IAM principals within the account (or cross-account if explicitly configured). No Shodan/Censys/GreyNoise/FOFA exposure footprint applies. |
| Disclosure date | 2026-09-22 — coordinated disclosure. Patch released same day. |
Why this verdict
- Authenticated prerequisite narrows the population: Exploitation requires valid AWS IAM credentials with
lambda:InvokeFunctionon the specific function ARN. This is a post-authentication, post-access privilege escalation — not an internet-facing RCE. The attacker is already inside the AWS account. - Niche deployment footprint: AmazonConnectSalesforceLambda is a Serverless Application Repository package for organizations running *both* Amazon Connect contact centers *and* Salesforce CRM. This is a small fraction of AWS accounts — estimated low single-digit thousands of deployments globally.
- Setup-only function with vendor delete guidance: AWS documentation explicitly instructs customers to delete or disable
sfExecuteAWSServiceafter initial configuration. Compliant deployments are immune. This materially reduces the vulnerable population even among those who deployed the package. - Blast radius bounded by Lambda execution role: The escalation ceiling is whatever the Lambda's IAM role can do. The vendor-provided SAM template scopes this role to Connect and Salesforce integration APIs, not broad
iam:*ors3:*. Over-privileged roles widen the blast, but that's a customer misconfiguration layered on top. - Role multiplier: (a) *Low-value role*: dev/sandbox Connect+SF integration — minimal data, chain succeeds but blast radius is negligible. (b) *Typical role*: production contact-center integration — chain succeeds if function is retained; blast radius is host-level (Lambda role scope), not domain/fleet/supply-chain. (c) *High-value role*: this component is NOT canonically a high-value-role component. It is a SaaS integration utility, not an identity provider, hypervisor, CI/CD system, backup, PAM, or network edge. Even in the worst case (over-privileged Lambda role in a production account), the outcome is bounded to single-account API abuse, not domain takeover or fleet compromise. The high-value floor does not apply.
- PoC availability is an upward pressure but is offset by the authenticated prerequisite and niche footprint. EPSS at 0.41% (35th percentile) corroborates low real-world exploitation likelihood.
Why not higher?
The vendor's 8.1 HIGH treats this as a generic network-accessible privilege escalation. In reality, it requires pre-existing AWS IAM access, targets a niche contact-center integration, affects a setup-only function that vendors tell you to delete, and has blast radius capped by the Lambda execution role. The component is not a canonical high-value target (not IdP, hypervisor, PAM, backup, or edge). No active exploitation or KEV listing further undermines urgency.
Why not lower?
PoC code is public and the exploitation is trivial once prerequisites are met — a single aws lambda invoke call. The function *does* run with elevated permissions by design, and organizations that failed to delete it post-setup are silently carrying this risk. The CVSS v4.0 advisory score of 6.4 MEDIUM from the GHSA itself validates that this is more than noise. Dropping below MEDIUM would undercount the real escalation potential for the (admittedly small) population of affected deployments.
What to do — in priority order.
- Delete or disable the sfExecuteAWSService Lambda function immediately — AWS recommends this as standard post-setup hygiene. If the function does not exist, the vulnerability is fully neutralized regardless of version. This is the fastest and most complete mitigation. As a MEDIUM-severity finding under the noisgate mitigation SLA, there is no formal mitigation deadline — go straight to the 365-day remediation window. However, deleting the function takes minutes and costs nothing; do it now.
- Restrict lambda:InvokeFunction via resource-based policy — If the function must remain active, update its resource-based policy to allow invocation *only* from the specific IAM role or user used by the Salesforce CTI Adapter. Deny all other principals. This prevents any other identity from reaching the vulnerable code path.
- Apply permission boundaries to the Lambda execution role — Attach an IAM permission boundary to the Lambda's execution role that restricts it to only the AWS APIs required for the Connect–Salesforce integration. This caps the blast radius even if the authorization bypass is exploited.
- Upgrade to AmazonConnectSalesforceLambda v5.26 — The patched version adds proper authorization validation to sfExecuteAWSService. Deploy via the AWS Serverless Application Repository update mechanism. Under the noisgate remediation SLA for MEDIUM, complete within 365 days — but given the trivial effort, prioritize within your next change window.
- Enable CloudTrail alerting on the Lambda function ARN — Create a CloudWatch Events rule or SIEM correlation that alerts on any
lambda:Invokecall targeting the sfExecuteAWSService function. This provides detection coverage while remediation is in progress.
- WAF / network firewalls — The vulnerable function is an AWS Lambda invoked via the AWS API, not through an HTTP endpoint behind a load balancer. Network-layer controls have no visibility into
lambda:Invokecalls. - AWS Shield / DDoS protection — This is an authorization bypass, not a volumetric or protocol attack. Shield provides no coverage.
- Disabling the Amazon Connect instance — The vulnerable Lambda function is deployed independently via SAR and remains invocable even if the Connect instance is deactivated. You must delete the function itself.
Crowdsourced verification payload.
Run this script from any workstation with the AWS CLI configured and IAM permissions for lambda:ListFunctions and lambda:GetFunction in the target account. Invoke with: bash check_cve_2026_94384.sh [--region us-east-1]. Requires read-only IAM access; does not invoke the vulnerable function.
#!/usr/bin/env bash
# check_cve_2026_94384.sh — Detect CVE-2026-94384 exposure
# Checks whether sfExecuteAWSService Lambda exists and is on a vulnerable version.
# Exit codes: 0=PATCHED/not-present, 1=VULNERABLE, 2=UNKNOWN
set -euo pipefail
REGION="${1:---region us-east-1}"
if [[ "$REGION" == --region ]]; then
REGION_FLAG=""
else
REGION_FLAG="--region ${REGION#--region }"
fi
echo "[*] Scanning for sfExecuteAWSService Lambda function..."
# Find functions matching the name pattern
MATCHES=$(aws lambda list-functions $REGION_FLAG \
--query "Functions[?contains(FunctionName, 'sfExecuteAWSService')].FunctionName" \
--output text 2>/dev/null || true)
if [[ -z "$MATCHES" || "$MATCHES" == "None" ]]; then
echo "PATCHED — sfExecuteAWSService function not found in this account/region."
echo "The function was either never deployed or has been deleted (best practice)."
exit 0
fi
VULN_FOUND=0
for FUNC_NAME in $MATCHES; do
echo "[*] Found function: $FUNC_NAME"
# Check if function is active
STATE=$(aws lambda get-function $REGION_FLAG \
--function-name "$FUNC_NAME" \
--query "Configuration.State" --output text 2>/dev/null || echo "UNKNOWN")
if [[ "$STATE" == "Inactive" ]]; then
echo " State: Inactive (disabled) — not currently exploitable."
continue
fi
# Try to extract version from environment variables or description
DESC=$(aws lambda get-function $REGION_FLAG \
--function-name "$FUNC_NAME" \
--query "Configuration.Description" --output text 2>/dev/null || echo "")
ENV_VERSION=$(aws lambda get-function-configuration $REGION_FLAG \
--function-name "$FUNC_NAME" \
--query "Environment.Variables.SF_ADAPTER_VERSION" --output text 2>/dev/null || echo "None")
echo " State: $STATE"
echo " Description: $DESC"
echo " Adapter version (env): $ENV_VERSION"
# Check for the fix commit or version indicator in the code
if [[ "$ENV_VERSION" != "None" && "$ENV_VERSION" != "" ]]; then
# Compare version — vulnerable: 5.15 through 5.24.16, fixed: 5.26+
MAJOR=$(echo "$ENV_VERSION" | cut -d. -f1)
MINOR=$(echo "$ENV_VERSION" | cut -d. -f2)
if [[ "$MAJOR" -eq 5 && "$MINOR" -ge 15 && "$MINOR" -le 25 ]]; then
echo "VULNERABLE — $FUNC_NAME is on version $ENV_VERSION (affected range: 5.15–5.24.16)."
echo " Action: Delete this function or upgrade to v5.26+."
VULN_FOUND=1
elif [[ "$MAJOR" -ge 6 || ("$MAJOR" -eq 5 && "$MINOR" -ge 26) ]]; then
echo "PATCHED — $FUNC_NAME is on version $ENV_VERSION (fixed in 5.26)."
else
echo "PATCHED — $FUNC_NAME is on version $ENV_VERSION (pre-5.15, not affected)."
fi
else
echo "UNKNOWN — Could not determine version for $FUNC_NAME."
echo " Recommend: verify manually or delete the function if no longer needed."
VULN_FOUND=2
fi
done
if [[ $VULN_FOUND -eq 1 ]]; then
echo ""
echo "VULNERABLE — One or more sfExecuteAWSService functions are on affected versions."
exit 1
elif [[ $VULN_FOUND -eq 2 ]]; then
echo ""
echo "UNKNOWN — Function found but version could not be confirmed."
exit 2
else
echo ""
echo "PATCHED — All detected functions are on patched or unaffected versions."
exit 0
fiWhat defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.