AWS quietly patched a privilege-escalation bug in one of its own sample serverless applications back in June 2026. Three months later, on September 22, it published the advisory. Then almost nothing happened until October 9 and 10, when security trackers and trade press picked up the story and pushed it into cloud security chatter worldwide. The vulnerability, tracked as CVE-2026-94384, sat in a Lambda function called sfExecuteAWSService that ships inside AWS’s own AmazonConnectSalesforceLambda integration, the glue code that links Amazon Connect contact centers to Salesforce Service Cloud Voice. Any IAM principal that could invoke the function could ride its privileged execution role straight past permissions their own account was explicitly denied.
That gap between a quiet patch and a loud news cycle is itself the story. It shows how little visibility most security teams have into AWS’s Serverless Application Repository, the catalog of pre-built Lambda apps that AWS and third parties publish for common integrations. This piece breaks down what CVE-2026-94384 actually does, why its two CVSS scores disagree, who needs to patch today, and what the incident says about the wider pattern of IAM misconfiguration across AWS, Azure, and Google Cloud serverless platforms.
What CVE-2026-94384 Actually Is
According to AWS’s own security bulletin, the flaw is a missing-authorization bug in the sfExecuteAWSService Lambda function, distributed through the AmazonConnectSalesforceLambda application in the AWS Serverless Application Repository. The function exists to run AWS service calls during the initial setup of an Amazon Connect-to-Salesforce CTI (computer telephony integration) connection. The problem: it accepted caller-supplied parameters describing which AWS operation to run, then executed that operation using its own privileged Lambda execution role, without checking whether the invoking IAM principal was actually allowed to perform that action on its own.
Put plainly, the only permission an attacker needed was lambda:InvokeFunction on that one function. From there, the function’s own execution role did the heavy lifting, running AWS API calls that the caller’s actual IAM policy would have blocked outright. The official description from the NVD/Rapid7 record calls this an IAM identity bypass: a caller performing “AWS API operations that their own IAM identity is explicitly denied.”
This is a textbook confused-deputy problem. The Lambda function is the deputy: trusted, privileged, and willing to act on anyone’s behalf without checking who’s asking. It is also a reminder that AWS Lambda vulnerability research increasingly centers on execution-role design, not just code injection or dependency bugs.
Two CVSS Scores, One Bug: Why 8.1 and 6.4 Both Appear
Anyone cross-referencing vulnerability feeds for CVE-2026-94384 will spot a discrepancy. The National Vulnerability Database lists a CVSS v3.1 base score of 8.1 (High), with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N. The same NVD record also carries a CVSS v4.0 score of 6.4 (Medium), vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:H/SI:H/SA:N. These are not conflicting opinions from different vendors. They’re two different scoring frameworks applied to the same flaw, and the gap illustrates exactly why CVSS 4.0 was built in the first place.
CVSS 3.1 treats confidentiality and integrity impact on the vulnerable component itself as “High,” which drives the score to 8.1. CVSS 4.0 separates the impact on the vulnerable system from impact on a downstream or “subsequent” system, and it rates the direct impact on the Lambda function lower (Low/Low) while shifting the serious damage into the “subsequent system” fields, which are marked High for confidentiality and integrity. The net effect: a more granular score that still flags the real-world severity but through a different lens, landing a full 1.7 points lower on a 10-point scale.
For patch-prioritization purposes, security teams scanning dependency feeds that only ingest one scoring version could file this as either a “fix this week” or “fix eventually” ticket, depending entirely on which CVSS version their tooling defaults to. That’s a real operational risk hiding inside a scoring-methodology footnote.
The Three-Week Gap Between Patch and Disclosure
The timeline here matters almost as much as the bug itself. Checking the project’s GitHub releases page, version 5.26, the first fixed release, shipped on June 29, 2026, nearly three months before AWS published its formal advisory on September 22, 2026. Two more releases, 5.27 and 5.28, followed on September 2, tightening IAM scoping further and adding a dedicated parameter, SalesforceExecuteAWSServiceUser, to lock invocation down to a single named IAM user.
So the code fix predates the public writeup by months, which is standard coordinated-disclosure practice. What’s less standard is the lag between AWS’s September 22 bulletin and the broader security press cycle that picked it up around October 9 and 10. BleepingComputer, Ground News, and AWS’s own community platform, Builder.aws.com, all ran coverage in that window, nearly three weeks after the official bulletin. For any team that doesn’t actively monitor AWS’s security bulletins page, that’s three weeks of a High-severity IAM bypass running in production with nobody watching.
| Date | Event | Detail |
|---|---|---|
| 2020-06-25 | Repository created | amazon-connect-salesforce-lambda first published to GitHub |
| 2026-06-29 | Fix shipped | Version 5.26 released, closing the authorization gap |
| 2026-09-02 | Follow-up hardening | Versions 5.27 and 5.28 released same day, adding SalesforceExecuteAWSServiceUser parameter |
| 2026-09-22 | Public disclosure | AWS Security Bulletin 2026-115-aws and CVE-2026-94384 published, 18:17 UTC |
| 2026-10-09 to 10-10 | Media pickup | Trade press and trackers surface the advisory broadly, 17-18 days after disclosure |
Who Is Actually Exposed
The blast radius is narrower than a platform-wide Lambda vulnerability, but it isn’t trivial. Any organization running Amazon Connect integrated with Salesforce Service Cloud Voice through AWS’s reference AmazonConnectSalesforceLambda application, specifically versions 5.15 through 5.24.16, is affected. That’s roughly four years of released versions, based on the GitHub release history going back to 2024’s v5.22 and v5.23 builds. Contact centers are exactly the kind of workload that tends to accumulate IAM debt: set up once by a systems integrator, left alone for years, revisited only when something breaks.
AWS’s own description of the root cause doubles as an admission that the function was designed for a narrow setup window and never locked down afterward. The bulletin’s guidance is blunt: once initial setup is complete, delete the function or disable it. If you must keep it around for later reconfiguration, restrict lambda:InvokeFunction to one dedicated IAM user and nothing else. That’s not a subtle best practice, it’s an admission that the default state of the function was too permissive for too long. It’s the same category of oversight behind the 9,300 leaked AWS keys found still active earlier this cycle, hundreds of which also granted admin-level rights long after anyone remembered why.
Why a Low-Star GitHub Repo Still Matters
The amazon-connect-salesforce-lambda repository isn’t a flashy project. It carries 55 stars and 44 forks on GitHub, modest numbers next to AWS’s flagship SDKs. But star counts badly undersell exposure for integration glue code like this. Organizations deploy it once through CloudFormation or the Serverless Application Repository console, rarely visit the GitHub page again, and never star or watch the repo at all. Low visibility on GitHub does not mean low deployment count in production AWS accounts, and that mismatch is precisely why Serverless Application Repository apps deserve the same patch-tracking discipline as any third-party dependency.
AWS’s Fix, and the Steps That Still Require Customer Action
AWS’s remediation guidance has four parts, and only the first is a one-click fix:
- Upgrade the deployed AmazonConnectSalesforceLambda application to version 5.26 or later.
- After initial CTI setup finishes, delete or disable the
sfExecuteAWSServicefunction entirely, since it has no ongoing purpose. - If the function must stay deployed for later reconfiguration, restrict its invoke permission to a single, named IAM user rather than any broader role or group.
- Set the new
SalesforceExecuteAWSServiceUserparameter, introduced in versions 5.27 and 5.28, so the function only trusts invocations from that one identity.
Upgrading a Serverless Application Repository application is not always a single click, especially for teams that deployed it years ago through a custom CloudFormation wrapper rather than the console’s native update flow. AWS’s bulletin does not spell out whether a full stack redeploy is required in every case, which means security teams should treat “upgrade to 5.26+” as a verification task, not a checkbox. A quick way to audit exposure is to check the deployed function’s invoke policy directly:
aws lambda get-policy \
--function-name sfExecuteAWSService \
--query 'Policy' --output text | python3 -m json.tool
aws lambda get-function \
--function-name sfExecuteAWSService \
--query 'Configuration.{Role:Role,Version:Version,LastModified:LastModified}'If the resource policy on sfExecuteAWSService grants invoke rights to anything broader than a single IAM user ARN, or if the function’s execution role still carries wildcard permissions inherited from an older release, the account is still exposed regardless of the version number shown in the console.
Market Impact: A Narrow Bug With a Wide Trust Problem
CVE-2026-94384 will not move AWS’s stock price or dominate a quarterly earnings call. Its market impact is reputational and procedural rather than financial. AWS maintains hundreds of sample applications and reference architectures across the Serverless Application Repository and its public GitHub organization, many of which get deployed directly into customer accounts with elevated IAM roles attached by default. Each one is effectively a mini-vendor relationship, and this incident is a reminder that “built by AWS” does not mean “audited like a core service.” It echoes a pattern a cross-tenant Cloudflare Containers flaw surfaced just weeks earlier: platform-provided infrastructure carries its own hidden attack surface, separate from whatever customers build on top of it.
For contact-center operators specifically, the timing lands awkwardly. Salesforce Service Cloud Voice integrations sit squarely in customer-data territory, handling call metadata, customer records, and often screen-pop data pulled from CRM fields. A privilege-escalation bug sitting quietly in that integration layer for years, even one AWS says shows no evidence of exploitation, is the kind of finding that compliance and procurement teams flag in vendor risk reviews for the next several audit cycles.
The bigger market signal is about discovery, not damage. A missing-authorization bug sitting in a reference app since at least its 5.15 release suggests limited external scrutiny of less glamorous AWS sample code, exactly the kind of software supply chain risk that security researchers have been pushing enterprises to inventory more aggressively in recent years.
Historical Context: IAM Debt Is the Serverless Industry’s Oldest Problem
Confused-deputy and overly broad execution-role problems are not new to serverless computing, they’re arguably its original sin. Back in 2021, Contrast Security’s State of Serverless Application Security Report captured how widespread the pattern already was. The survey found that “51% of respondents reported experiencing four or more successful exploits in serverless applications during the preceding 12 months,” according to Contrast Security’s 2021 report.
The same report found that “nearly three-quarters of respondents reported that their serverless applications contained 10 or more vulnerabilities on average,” per Contrast Security. Broken authentication and authorization problems, exactly the category CVE-2026-94384 falls into, ranked near the top of practitioner concerns even then: “61% of respondents ranked broken authentication among their top two concerns for vulnerabilities in serverless applications,” the same survey noted.
Encouragingly, the same 2021 data showed defensive practices were already catching on: “76% of respondents reported using least-privilege configuration analysis to secure their serverless applications,” according to Contrast Security. Five years later, CVE-2026-94384 is a reminder that least-privilege analysis has to extend past an organization’s own Lambda functions and into every pre-built integration it imports from a vendor’s sample-code catalog, AWS’s own included.
Competitive Comparison: How AWS, Azure, and Google Cloud Handle Function Identity
CVE-2026-94384 is specific to AWS Lambda’s execution-role model, but the underlying design question, how much a cloud function should be allowed to do on a caller’s behalf, applies across every major serverless platform. Each of the big three clouds takes a structurally different approach to binding identity to function execution.
AWS Lambda functions run under an IAM execution role attached directly to the function resource, documented in AWS’s Lambda permissions model. The function’s role is entirely separate from the invoking principal’s own permissions, which is exactly the separation CVE-2026-94384 abused: the function trusted its own role far more than it checked the caller’s identity.
Azure Functions, when hosted in Azure App Service, typically rely on managed identities, where Microsoft’s own documentation describes the identity as automatically managed by Azure and tied to Microsoft Entra ID role assignments rather than a standalone credential object. Google Cloud Functions, per Google’s function-identity documentation, run under a specified service account and recommend creating a unique, narrowly scoped service account per function rather than reusing a shared default identity.
| Platform | Identity model for function execution | Default caller-authorization check |
|---|---|---|
| AWS Lambda | Dedicated IAM execution role per function | Not automatic; function code must validate caller identity itself, as CVE-2026-94384 shows |
| Azure Functions (App Service) | System-assigned or user-assigned managed identity tied to Entra ID | Role-based access control via Entra ID role assignments |
| Google Cloud Functions | Attached service account, Google recommends one unique account per function | Cloud IAM policy evaluated per invocation; Google documentation urges least-privilege, single-purpose accounts |
No platform is immune to this failure mode. A function that accepts caller-supplied instructions and executes them with its own elevated identity, without an explicit authorization check in the function’s own code, can reproduce this exact bug on any of the three clouds. The AWS Lambda vulnerability in sfExecuteAWSService is a code-level failure, not an architectural flaw unique to AWS’s IAM model, but AWS’s documentation is explicit that the authorization check is the developer’s responsibility, not something the platform enforces automatically.
What Security and DevOps Teams Should Do This Week
Treat this the same way you’d treat any dependency CVE buried in third-party code, because that’s functionally what a Serverless Application Repository app is.
- Search every AWS account for deployments of AmazonConnectSalesforceLambda and record the installed version.
- Upgrade any instance running 5.24.16 or earlier to version 5.26 or later immediately.
- Audit the resource policy on sfExecuteAWSService in every account where it still exists, even after upgrading, since old overly broad invoke permissions can persist across version bumps.
- Delete the function outright if initial Salesforce CTI setup is already complete and no further reconfiguration is planned.
- Extend the audit beyond this one function: inventory every Serverless Application Repository app deployed across your AWS organization and check each one’s GitHub releases page for unpatched advisories.
- Add AWS’s security bulletins RSS feed to whatever tool your team already uses for dependency and CVE monitoring, rather than relying on trade-press pickup that, in this case, lagged the official advisory by nearly three weeks.
Predictions: Where This Goes From Here
Five things worth watching as this story develops into November and beyond:
- More Serverless Application Repository audits. Expect independent researchers to start systematically reviewing AWS’s own published sample applications for the same confused-deputy pattern, given how directly this one maps to a known, well-documented vulnerability class, not unlike the scrutiny that followed GKE’s Fragnesia container-escape bug earlier this year.
- CVSS version confusion becomes a recurring footnote. As more vulnerability databases populate both v3.1 and v4.0 scores side by side, expect more stories like this one where the severity of a bug depends on which column a scanner reads first.
- AWS tightens its SAR publishing bar. Given the reputational exposure of a missing-authorization bug in AWS’s own reference code, a reasonable bet is tighter internal review requirements, or at minimum a visible security-review badge, for future Serverless Application Repository submissions.
- Contact-center integrations get a second look in vendor risk reviews. Enterprises running Salesforce Service Cloud Voice on Amazon Connect are likely to add this CVE to their next audit cycle’s vendor questionnaire, regardless of whether they’ve already patched.
- No confirmed breach disclosure tied to this CVE. AWS’s bulletin language, consistent with its past disclosures, points toward no confirmed exploitation. Absent new evidence, expect this to remain a patch-and-move-on story rather than a breach-notification story.
The Bigger Lesson Buried in a Small Function
CVE-2026-94384 will not be remembered as a landmark cloud breach. It affected a narrow slice of AWS customers running a specific contact-center integration, and AWS says it has no evidence anyone exploited it. But the mechanics are worth remembering precisely because they’re so ordinary: a setup-only function that never got locked down, a privileged role trusted more than the caller’s own identity, and a three-week gap between a technical advisory and the moment most security teams actually heard about it.
Serverless computing promised to remove infrastructure management from the security conversation. What it actually did was move the hard problem from network perimeters to IAM policies, and from your own code to every piece of sample code you imported from a vendor’s catalog. CVE-2026-94384 is a reminder that the catalog includes AWS’s own name on the label too, and that cloud computing news keeps circling back to the same lesson no matter which vendor ships the next advisory.
Frequently Asked Questions
What is CVE-2026-94384?
It’s a missing-authorization vulnerability in the sfExecuteAWSService Lambda function, part of AWS’s AmazonConnectSalesforceLambda sample application. It let any IAM principal with invoke permission on that one function run privileged AWS operations their own account was explicitly denied.
Is Amazon Connect itself vulnerable, or just this Salesforce integration?
Only the AmazonConnectSalesforceLambda integration package is affected, specifically the sfExecuteAWSService function inside it. Amazon Connect’s core contact-center service is not implicated in this advisory.
Which versions are affected and which version fixes it?
Versions 5.15 through 5.24.16 are affected. AWS’s fix shipped in version 5.26, released June 29, 2026, with further hardening in versions 5.27 and 5.28 released September 2, 2026.
Why does this CVE have two different severity scores?
NVD lists both a CVSS v3.1 score of 8.1 (High) and a CVSS v4.0 score of 6.4 (Medium) for the same flaw. The two scoring versions weigh impact on the vulnerable component versus downstream systems differently, which produces different numbers for an identical vulnerability.
Do I need to redeploy my entire CloudFormation stack to fix this?
AWS’s guidance confirms upgrading to version 5.26 or later resolves the core issue, but does not specify whether every deployment method requires a full stack redeploy versus an in-place function update. Teams should verify their specific deployment method against the project’s release notes rather than assume either path.
Has AWS confirmed any real-world exploitation of this bug?
No. AWS’s advisory does not cite confirmed exploitation. As with most responsibly disclosed vulnerabilities, the absence of a confirmed breach does not guarantee the bug was never exploited, only that none has been publicly reported.
How can I check if my AWS account is still exposed?
Run aws lambda get-policy against the sfExecuteAWSService function to review its resource-based invoke policy, and aws lambda get-function to confirm the deployed version and execution role. If the invoke policy allows anything broader than a single named IAM user, the account remains exposed regardless of version number.
Does this affect only AWS, or could the same bug happen on Azure or Google Cloud?
The specific CVE is AWS-only, but the underlying pattern, a function trusting its own privileged identity over the caller’s, is a generic serverless risk. Azure Functions and Google Cloud Functions use different identity models (managed identities and per-function service accounts, respectively) but any platform’s functions can reproduce this bug if the function code itself skips an explicit caller-authorization check.
