← Back to Feed CACHED · 2026-09-24 02:07:11 · CACHE_KEY CVE-2026-94384
CVE-2026-94384 · CWE-862 · Disclosed 2026-09-22

Missing authorization in Amazon amazon-connect-salesforce-lambda before 5.26

ASSESSED — NOISGATE
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

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.

"Cloud priv-esc in a niche setup-only Lambda most orgs already deleted."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Obtain AWS IAM credentials with lambda:InvokeFunction

The attacker must already possess valid AWS IAM credentials that include 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.
Conditions required:
  • Valid AWS IAM credentials in the target account
  • lambda:InvokeFunction permission on the sfExecuteAWSService function ARN
Where this breaks in practice:
  • 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
Detection/coverage: CloudTrail logs every lambda:Invoke call. AWS GuardDuty anomaly detectors flag unusual Lambda invocations from new principals or IP ranges.
STEP 02

Identify the sfExecuteAWSService function is still active

The attacker confirms the function exists and is not disabled. Because AWS recommends deleting this function post-setup, well-managed deployments will have already removed it. The attacker can call lambda:GetFunction or attempt an invocation to confirm.
Conditions required:
  • The target organization deployed AmazonConnectSalesforceLambda v5.15–5.24.16
  • The sfExecuteAWSService function was NOT deleted or disabled after initial setup
Where this breaks in practice:
  • 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
Detection/coverage: CloudTrail will log GetFunction and Invoke API calls against the Lambda function. CSPM tools (Prisma Cloud, Wiz, Orca) can inventory Lambda functions and flag residual setup utilities.
STEP 03

Craft privileged API payload and invoke the function

The attacker constructs a payload containing the target AWS service, action, and parameters — e.g., requesting an S3 ListBuckets, an IAM CreateUser, or an STS AssumeRole call. They invoke 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.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: CloudTrail logs the downstream API calls made by the Lambda execution role. Anomalous actions (IAM mutations, S3 access from a Connect integration role) should trigger SIEM alerts.
STEP 04

Exfiltrate data or establish persistence

If the Lambda execution role grants access to sensitive services (S3 buckets, DynamoDB tables, Secrets Manager), the attacker uses the proxy to read data or create persistence mechanisms (new IAM users, access keys, role trust modifications). The scope of damage is strictly bounded by the Lambda role's attached policies.
Conditions required:
  • The Lambda execution role has permissions beyond what the attacker's own identity allows
  • Target data or persistence surfaces are accessible to the role
Where this breaks in practice:
  • 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
Detection/coverage: GuardDuty detects credential exfiltration, unusual API patterns, and new IAM entity creation. CloudTrail + SIEM correlation on the Lambda role's activity catches anomalous downstream calls.
03 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNot observed. Not listed in CISA KEV. No known campaigns or ransomware associations reported as of 2026-09-24.
Proof-of-conceptAvailable — 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.
EPSS0.00413 (0.41%) — 35th percentile. Reflects the niche deployment footprint and authenticated-access prerequisite.
KEV statusNot listed. No CISA KEV entry as of 2026-09-24.
CVSS v3.1 vectorCVSS: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 score6.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 versionsAmazonConnectSalesforceLambda v5.15 through v5.24.16. Introduced in v5.15. Versions prior to 5.15 are not affected.
Fixed versionv5.26 — released 2026-09-22. Git fix commit: 96579b79b6f89fa4bcf9cf9ce231b29636762719. GHSA: GHSA-c9j2-qjfv-mm4p.
Exposure surfaceNot 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 date2026-09-22 — coordinated disclosure. Patch released same day.
04 · The Call

Final Verdict
DOWNGRADED to MEDIUM (6.0/10)

Why this verdict

  • Authenticated prerequisite narrows the population: Exploitation requires valid AWS IAM credentials with lambda:InvokeFunction on 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 sfExecuteAWSService after 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:* or s3:*. 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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. Enable CloudTrail alerting on the Lambda function ARN — Create a CloudWatch Events rule or SIEM correlation that alerts on any lambda:Invoke call targeting the sfExecuteAWSService function. This provides detection coverage while remediation is in progress.
What doesn't work
  • 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:Invoke calls.
  • 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.
06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
fi
07 · Sources

Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.