mocknest-serverless CVE-2026-86516

Exploitation requires: (1) write or workflow dispatch permission on the affected GitHub repository - this is not a publicly accessible endpoint; (2) the target AWS account must have an IAM role named 'GitHubOIDCAdmin' with an OIDC trust policy that accepts the repository's GitHub Actions identity, using permissive StringLike wildcard conditions (the old template configuration); (3) the vulnerable workflow files (deploy-on-demand.yml, main-aws.yml, sar-publish.yml) must still be present with the hardcoded default role name unpatched. Limiting factors: only repository collaborators or those who have compromised a collaborator's GitHub account can trigger workflow dispatch events; AWS accounts that deployed the updated two-role CloudFormation template are not vulnerable even without patching the workflow files.

The CVSS 4.0 score of 5.1 with PR:H is well-calibrated for this vulnerability: exploitation is gated on possessing repository write or workflow dispatch access, which limits the realistic attacker pool to trusted collaborators or those who have compromised such an account. The VC:L/VI:L/VA:L impact metrics are plausible given that an exploiting party could assume an over-privileged AWS IAM role, but actual blast radius depends on what permissions that role holds in a given deployment. No public exploit code exists and no active exploitation has been reported. EPSS data is absent from the provided intelligence. Even a mid-sized municipal IT team in zabrze running this stack would face a constrained threat surface given the PR:H prerequisite, but the privilege escalation into AWS cloud resources still merits prompt patching. The primary real-world risk is insider threat or supply-chain compromise of a repository collaborator account, not opportunistic scanning.

An attacker with repository write access triggers a manual workflow dispatch on deploy-on-demand.yml or sar-publish.yml, leaving the OIDC role name input blank. Because the old workflow defaults to 'GitHubOIDCAdmin', the job assumes that predictably named IAM role via OIDC exchange, gaining whatever AWS permissions are attached to it - potentially including CloudFormation execution, S3 write, Lambda deployment, and IAM PassRole. No public exploit code is known; the attack path requires existing repository collaborator access.