@zuke/core EUVD-2026-114136

Three concrete prerequisites must all hold: (1) the build runs under GitHub Actions (runs outside Actions write no job summary and are unaffected); (2) the build calls reportSummary(...) with a note whose value derives from a secret() parameter, e.g. a deploy target reporting an endpoint or image reference that embeds a resolved credential (builds that never place secret-derived text in a summary are unaffected); and (3) the workflow run is viewable by the attacker - on a public repository this is everyone with no account, while a private repository limits exposure to those who can already view the run. GitHub Actions ::add-mask:: directives do NOT limit this because they filter only the runner log stream, not the summary file the build writes. The principal limiting factor is that placing secret-derived text in a summary note is a non-default build-authoring choice, not behavior of a stock configuration.

CVSS 3.1 base score is 7.5 (HIGH) driven entirely by a confidentiality impact (C:H, I:N, A:N) over a network vector with no privileges or user interaction (AV:N/AC:L/PR:N/UI:N), which is consistent with CWE-532 information exposure: on a public repository anyone - including unauthenticated viewers - can read the leaked secret() value from the persisted GITHUB_STEP_SUMMARY artifact. However, the raw CVSS understates an important precondition: this only occurs when a build running under GitHub Actions actually places secret-derived text in a reportSummary(...) note, so the network-unauthenticated profile applies only to that specific, non-default authoring pattern. The vuln.today decision label is 'this_week' (not act_now/emergency). No EPSS score, no CISA KEV listing, and no public exploit code are present in the input - the only references are the GHSA advisory, PR #547, the fix commit, and the release tag, all of which are remediation artifacts rather than exploit code. The signals are therefore internally consistent and point to a real but conditional disclosure issue rather than mass-exploitable RCE: treat it as a credible leak-and-rotate priority for teams that run Zuke in public GitHub Actions workflows, and lower priority for everyone else. Note that absence of EPSS/KEV does not imply safety; it reflects a niche product that automated exploitation telemetry is unlikely to cover.

A public GitHub repository runs a Zuke (@zuke/core < 1.51.0) build under GitHub Actions that reports a summary note whose value embeds a secret() - for example a deploy target reporting the published image reference or endpoint that contains a resolved registry token. writeJobSummary appends that note to GITHUB_STEP_SUMMARY without the redactor, so the credential appears in cleartext in the durable run summary while the console and run record show [redacted]. Any unauthenticated person who opens the workflow run reads the secret, and it stays exposed until the run is deleted. No public exploit identified at time of analysis; reproduction is trivial and requires only viewing the run.