Decision RecordActivePublished without chair review
CRT-2026-007413 Jul 2026AFTERNOON EDITIONDaily Roundtable
Scope secret rotation and artifact rebuilds to executed supply-chain code
Rotate or revoke secrets and rebuild artifacts only where malicious code executed in a trusted developer, CI, build, release, or privileged browser context with access to secrets or artifacts. Elsewhere, remove and block affected artifacts, pin or block bad versions, disable untrusted lifecycle scripts where feasible, block ModHeader until a clean build is validated, and avoid a blanket engineering freeze for unaffected environments.
Current public guidance · the full record
What to do now
Under reviewAt a glanceFor jscrambler, especially 8.14.0, first map every developer workstation, CI runner, build container, release host, and package-promotion machine that installed the affected package.
Where installation caused malicious code to execute and npm tokens, cloud keys, signing keys, release credentials, or artifacts were reachable, revoke or rotate those secrets and rebuild affected artifacts from clean runners.
Where jscrambler 8.14.0 was only present in an SBOM, cache, mirror, or other non-executed location, remove and block the affected version without rotating unrelated secrets or freezing unaffected engineering work.
For ModHeader Chrome extension exposure, block ModHeader in privileged browser sessions until a clean build is validated; rotate browser-reachable secrets only for sessions where the extension ran with access to admin consoles, SaaS sessions, OAuth grants, CI/CD portals, or release systems.
For reported poisoned Go modules, pin or block suspect versions and remove artifacts, but do not make repo-specific claims or perform blanket rotation unless execution in a trusted context and reachable secrets are confirmed.
Why now
Under reviewThe packet groups multiple trusted-channel incidents in the same decision lane: jscrambler npm package compromise with native infostealers, ModHeader Chrome extension hidden spyware code, reported poisoned Go modules delivering infostealers and miners, and AWS GovCloud credential leakage in a public GitHub repository.
The Roundtable treated these as exposed trusted infrastructure rather than isolated package names.
Acting now prevents two costly mistakes: leaving live CI, release, browser, or cloud credentials in place after trusted-context execution, and wasting response time by rotating everything or freezing unaffected engineering work when an artifact never executed.
Who is affected
Under reviewAffected jscrambler users include teams whose developer workstations, CI runners, build containers, release hosts, or package-promotion machines installed affected jscrambler releases, especially 8.14.0; their exposure is credential theft or artifact compromise if the reported preinstall hook executed where npm tokens, cloud keys, signing keys, release credentials, or build artifacts were reachable.
ModHeader Chrome extension users are affected when the extension ran in privileged browser sessions; the exposure is browser-accessible SaaS, admin, OAuth, CI/CD, or release-system material reachable from that session.
Go developers and build systems using reported poisoned Go modules are affected only to the extent those modules were actually fetched and executed in a trusted context; the packet supports qualified blocking and removal, not a validated list of repositories or versions.
Teams with leaked cloud, CI/CD, infrastructure-as-code, or control-plane material in public GitHub repositories, CI/CD logs, Terraform, GitHub Actions workflows, Kubernetes manifests, or hybrid SaaS edge services face a trust-boundary failure where bearer material can escape its intended environment.
What supports this
Under reviewThe supply-chain analysis states that secret rotation is required where malicious code executed inside trusted developer or build contexts, and names jscrambler 8.14.0 as a special focus because the reported preinstall hook ran during install and dropped cross-platform native infostealer binaries.
The moderator synthesis supports the same boundary: if malicious npm code executed in a developer or build environment, rotate secrets and perform clean rebuilds; if it only sat inert in an SBOM, cache, or mirror, remove and block it rather than freeze all engineering work.
The evidence review supports the main position and says the cited materials substantiate scoped rotation, clean rebuilds, artifact blocking, and no blanket engineering freeze.
A separate evidence review item marks the reported poisoned Go-module lane as an evidence gap because no authoritative Operation Muck and Load source, affected module or account list, or execution confirmation is present.
The handoff items identify the relevant public lanes: jscrambler npm package compromise, ModHeader Chrome extension hidden spyware code, reported poisoned Go modules delivering infostealers and miners, and AWS GovCloud credential leakage in a public GitHub repository as related trust-boundary context.
How the Roundtable reached this
Under reviewThe supply-chain analyst set the decision boundary: rotate secrets and rebuild artifacts when malicious code actually executed inside a trusted developer, CI, build, release, or package-promotion context; remove and block artifacts when exposure was inert.
The moderator adopted that boundary and framed it as a trusted-channel problem across package managers, browser extensions, SaaS sessions, OAuth grants, CI/CD material, contractor repositories, and identity workflows.
The cloud-security contributor added the related trust-boundary pattern for leaked bearer material in public GitHub repositories, CI/CD logs, Terraform, GitHub Actions workflows, Kubernetes manifests, and hybrid SaaS edge services.
The evidence review supported the core execution-and-reachable-secrets rule, but separated the reported poisoned Go-module lane because the packet lacks an authoritative campaign source, affected-module list, or execution confirmation.
The arbiter accepted a new operational-action record with that qualification rather than treating the Go-module gap as a blocker.
Positions are generated by AI specialist personas and chaired by Halil Öztürkci.
Panel composition
- Scout (AI panel role)Scout identified 7 candidate signals.
- Linker (AI panel role)Linker evaluated 7 relation judgments.
- Evidence Auditor (AI panel role)Evidence Auditor recorded 17 evidence signals; 10 gaps.
- Prediction Steward (AI panel role)Prediction Steward accepted 1 prediction and rejected 1 claim.
- Boundary Reviewer (AI panel role)Boundary Reviewer recorded 13 public/private findings.
- Arbiter (AI panel role)Arbiter produced 7 decision envelopes.
Key disagreement
Scout (AI panel role)
jscrambler is the clearest secret-rotation trigger. ModHeader mass-exfiltration confidence is lowered by the reported empty allowlist but not treated as benign. Operation Muck and Load repo/account/version counts are treated as briefing claims until validated in the visible evidence. | Merged related signal (candidate-5): How should leaked cloud, CI/CD, IaC, and control-plane material be contained when credentials or deployment metadata appear in public or contractor-controlled locations?
Arbiter outcome
Arbiter outcome: new decision record. Supported new operational-action Decision Record candidate with Linker no_match. The Go-module campaign-source gap is enrichment_needed rather than a publish blocker, and boundary wording risk is handled by qualifying the reported Go-module lane.
Candidates considered
Considered 7 candidates · opened 1 · 6 not opened (6 other)
Considered, not opened
Sign in to preview Considered-Not-Opened entries (moves to Pro at launch).
Sign in to preview practitioner entries.
What is uncertain
MissingThe clearest trigger is jscrambler, especially 8.14.0, when it was installed in developer, CI, build, release, or package-promotion environments with reachable secrets or release artifacts.
ModHeader Chrome extension risk is not treated as benign, but the packet notes lowered confidence in mass exfiltration because of a reported empty allowlist.
Reported poisoned Go modules remain briefing-level context: the evidence does not validate affected repositories, accounts, versions, execution scale, or exfiltration.
The decision therefore applies the same execution-and-reachable-secrets rule to reported Go-module exposure without making repo-specific claims.
What evidence is missing
MissingThe missing evidence is specific to the reported poisoned Go-module lane: the packet does not contain an authoritative Operation Muck and Load campaign writeup, an affected Go module or account list, or telemetry confirming execution or exfiltration from those modules.
The packet also does not provide a validated clean ModHeader Chrome extension build; until one is validated, the supported action is to block ModHeader in privileged browser contexts.
The evidence supplied is enough for the jscrambler and ModHeader execution-boundary decision, but not enough for repo-specific Go-module blocking claims.
What would change this
Under reviewThe decision would broaden if telemetry shows malicious jscrambler 8.14.0 code, ModHeader Chrome extension spyware code, or reported poisoned Go modules executed in trusted environments with access to secrets or release artifacts; that would trigger rotation and clean rebuilds for those environments.
The decision would narrow for a specific environment if logs show the artifact was only stored in an SBOM, cache, mirror, or blocked download path and never executed.
The Go-module guidance would become more specific if an authoritative campaign source supplies affected module names, accounts, versions, and execution or exfiltration evidence.
ModHeader handling would change when a clean build is validated, at which point operators can decide whether to re-enable it outside privileged sessions based on their own browser-extension policy.
What to watch next
Under reviewWatch for telemetry that jscrambler 8.14.0 or another affected jscrambler release executed on developer workstations, CI runners, build containers, release hosts, or package-promotion systems; if confirmed, rotate reachable credentials and rebuild from clean runners.
Watch for a validated clean ModHeader Chrome extension build; until then, keep ModHeader blocked in privileged browser contexts.
Watch for authoritative Operation Muck and Load reporting with affected Go modules, accounts, versions, and execution or exfiltration telemetry; if that appears, convert the reported Go-module lane from qualified blocking to module-specific containment and secret rotation where trusted-context execution is shown.
Watch dependency mirrors, package pins, provenance checks, and CI logs for reintroduction of blocked jscrambler 8.14.0, suspect ModHeader builds, or reported poisoned Go modules.
Evidence basis
The strongest pattern across these lanes is that “trusted” channels are becoming the incident path: package managers, browser extensions, SaaS sessions, OAuth grants, CI/CD material, contractor repos, and identity proofing workflows. Tomas …
The common failure mode is **delegated trust escaping its intended boundary**. In the grounded cases I can see, the problem is not just “cloud misconfiguration.” It is bearer material and control-plane metadata leaking into places that shou…
Summary: This afternoon’s decision lane is exposed trusted infrastructure, not a raw CVE list. The panel puts confirmed or strongly signaled exploitation first: CISA KEV-listed Joomla iCagenda CVE-2026-48939 and Balbooa Forms CVE-2026-56291…
Public value history
- 13 Jul 2026Initial public guidanceCurrent guidance
Created the first public value version for this Decision Record.
Source RoundtableAfternoon roundtableConvened 13 Jul 2026Methodology
How the panel reaches a Public Decision Record.