Weekly builders roundup, 12 November 2026: a CI secret stealer, a GPUStack patch and two deadlines

Eight changes from the past week of our coverage that affect what you build or run, most urgent first. Each item links to our full post and to the original source. This is a checklist, not new reporting: every fact below comes from those posts.

Hijacked GitHub accounts are pushing a CI secret stealer

What changed: Since about 12:45 UTC on 10 November, stolen GitHub credentials have been used to push a secret stealer, which calls itself wfx, into repositories those accounts can write. Aikido counts 4,837 accounts and probe pull requests in 61,764 repositories, and at least 1,835 repositories where the payload ran and credentials were taken. Aikido says that count likely understates the run, because the logs were deleted. 10,431 probes went in through collaborator or organisation access, and 92 percent of those were still open when Aikido checked. StepSecurity, as of 07:40 UTC on 12 November, saw more than 63,000 probe pull requests, about 90 percent still open, with new ones every few minutes. SafeDep, as reported by The Hacker News, counts 8,093 public repositories with malicious commits on default branches up to 04:36 UTC on 12 November, 771 of them through an npm postinstall hook. Nobody has said how the credentials were taken. See our post.

Suggestion: Search your organisations, from 10 November onward, for a wfx-docs branch, a pull request titled docs: dependency audit notes, and commits titled ci: refresh build cache, chore: add ci helper, chore: add dependency audit workflow, or ci: restore. Look for missing Actions run numbers around those commits. If the stealer ran, rotate every secret and cloud role the workflow could reach, revoke that account’s tokens, OAuth grants, SSH keys and sessions, and look for wfx-ci-* Entra ID credentials and AWS trust policies opened to any account. Aikido lists Packagist package digitalelvis/neuronai-studio 3.14.3 and Go module onuragtas/docker-env v1.0.278 and v1.0.280 as affected. If you consume a package published from an affected repository, pin a version you have checked. Aikido says any account that opened a probe pull request should be treated as compromised.

Check first: The three counts use different methods, so quote them with the firm that published them. StepSecurity says that since about 05:30 UTC on 12 November, new copies send stolen data only to a Telegram chat, so blocking the published IP addresses no longer stops the theft. In cases StepSecurity describes, the token belonged to an automation account, and one of those bots could bypass branch protection. How the accounts were stolen is not known.

GPUStack’s auth bypass is on CISA’s exploited list

What changed: Before 2.2.0, GPUStack treated a request from loopback as the built-in admin when force_auth_localhost was off, which is the default. The advisory describes two paths with no credentials: a same-host reverse proxy that sends every request from 127.0.0.1, and a forged X-GPUStack-Real-IP: 127.0.0.1 header. Either path yields admin, including admin API keys with scope * that keep working from any IP, worker and cloud secrets, and code execution on workers through POST /v2/inference-backends/from-yaml. The advisory says exploitation was observed on a v2.1.1 deployment, where attackers created custom backends that ran reverse shells. CISA added CVE-2026-102895 to the Known Exploited Vulnerabilities catalog on 9 November, with a federal due date of 12 November 2026, and flagged it for forensic triage. The advisory rates it critical, CVSS 3.1 score 9.8. The fix shipped in GPUStack 2.2.0 on 18 June, and the current line is 2.3.x. See our post.

Suggestion: If you run GPUStack below 2.2.0, upgrade to 2.2.0 or later. If you cannot upgrade yet, set force_auth_localhost to true, strip a client-supplied X-GPUStack-Real-IP header at the proxy, and keep the API off untrusted networks. After upgrading, list admin API keys and revoke any you did not create. Check for custom inference backends you did not add, and rotate the worker and cloud credentials GPUStack held.

Check first: The in-the-wild report is the advisory’s account of one v2.1.1 deployment. How widely it has been used is not public. The advisory says minted keys stay valid from any source. Our post found no statement that the upgrade revokes them, so review keys yourself.

Actions: the 9 November brownout has passed, and 2 December is the default block

What changed: GitHub said on 2 November that from 2 December 2026, Actions will block pull_request_target by default in public repositories unless an event policy allows it. Enforcement had previously been scheduled for 2 November. Private and internal repositories are not affected. The change applies to GitHub Free, Team and Enterprise Cloud, not Enterprise Server. Two brownouts were scheduled, each 16:00 to 18:00 UTC (18:00 to 20:00 IST): 9 November, which has passed, and 16 November, which has not. During a brownout, blocked runs fail with an error annotation and do not execute. Workflow lockfiles reached general availability on 28 October on Enterprise Cloud, including data residency, and on Team and Free. gh actions-lock writes .github/workflows/actions.lock, which pins direct and transitive actions to commits. Onboarded workflows keep readable tags and run the locked commit even if the tag moves. See our post.

Suggestion: Use Insights to see which pull_request_target runs the rule would block, then either keep the block or allow that event for specific workflow files, before the 16 November window and the 2 December default. If you adopt lockfiles, review the commits before you lock them. Dependabot regenerates the matching lockfile entry in its version-update pull requests. Our post’s advice is to avoid auto-merging those, because that pull request is where the trust decision sits.

Check first: The lockfile docs say the locked commit must be reachable from the recorded branch or tag, fork-only commits are rejected, and the file records numeric owner and repository IDs. Reusable workflow calls are not pinned and still need a full SHA. GitHub’s own caveat: a lockfile means you run the commits you locked. It does not make those commits safe. Outside those two windows, our post says the rule stays in evaluate mode. The default block starts on 2 December.

Val Town: signups have ended, read-only starts 10 December

What changed: Val Town, which hosts small JavaScript and TypeScript programs called vals, is winding down. Founder Steve Krouse announced it on 10 November, saying the company “couldn’t compete in the cloud computing space”. Signups and plan upgrades ended on 10 November. Billing is paused, existing subscriptions keep running for free, and annual prepaid plans get a partial refund. Read-only mode starts on 10 December and does not include SQLite and blob storage. All other services stop on 10 January 2027. Val Town is open-sourced on 1 February 2027. Migration guides cover Cloudflare, Vercel, Netlify and Render. Support is at [email protected] and on Discord. See our post.

Suggestion: List every val you own, note which ones store data in SQLite or blob storage, and export that data before 10 January. The guides are linked from Krouse’s post. He says “today’s LLMs are great at these types of migrations”. Our post’s advice is to hand an agent the code and the target docs, then test each endpoint by hand.

Check first: The announcement does not say whether vals keep executing during the read-only month. Do not assume they do. Our post’s advice is to plan as if they might not. SQLite and blob storage stay as they are until 10 January, which is the date to treat as the data deadline.

Claude Code’s “don’t ask again” rules have put secrets in public git files

What changed: When you pick “Yes, and don’t ask again”, Claude Code saves an allow rule in .claude/settings.local.json, its settings docs say. The first time it writes that file in a git repository, it adds **/.claude/settings.local.json to your global git excludes. It does not add the path to the project’s .gitignore. The Hacker News and iTWire report Apiiro’s Shmulik Cohen and Matan Giladi, who published on 5 November from public data collected 1 to 3 November: 104,185 copies of the file in 103,617 repositories, 1,122 of them (about 1.1 percent) holding at least one secret, 1,379 distinct values. Counting git history, the shared .claude/settings.json and saved transcripts, Apiiro counts 2,539 secrets across 1,994 repositories. The Hacker News report says more than a third opened a database, including 379 database passwords, 43 SSH logins, 42 GitHub, GitLab and npm tokens, and 23 AWS keys. Gitleaks and TruffleHog together missed 215 of the files. See our post.

Suggestion: Apiiro’s steps, as reported: search the organisation for .claude/settings.local.json and .claude/settings.json, including history. Rotate every password, token and key those files ever held before you delete them. Run git rm --cached .claude/settings.local.json and add the path to the repository’s own .gitignore. Delete any local rule that contains a secret. Keep secrets in variables such as $DB_URL, and approve patterns such as Bash(npm run:*) rather than one literal command.

Check first: The counts are Apiiro’s, as reported by those two outlets. Apiiro did not try the credentials, so this is an exposure risk. It says it notified organisations on 2 and 3 November and that one confirmed its key had been live. Our post could not open Apiiro’s own write-up. The global git exclude lives on one machine. It does not cover a file that is already tracked. Names of affected organisations are not in our post.

AWS Emulator runs AWS APIs on your laptop, telemetry on by default

What changed: AWS Emulator is generally available as of 11 November 2026. It answers AWS API calls on your machine over local HTTPS, with no AWS account and no service fee. The source is CC0 1.0 and written in Rust. Install an RPM or Debian package on Linux, or Docker on macOS and Windows. On start it writes credentials, config and a self-signed certificate under ~/.aws/emulator/9297/ and serves HTTPS on 127.0.0.1:9297. State stays in memory. What’s New says each copy gets its own port, keys and state. Services come from published Smithy models. An operation that is not implemented returns HTTP 501. A skill installs with aws agent-toolkit add-skill --skill-name aws-emulator on AWS CLI 2.35.0 or later. Building from source needs at least 100 GB free for target/. In a making-of post, Matthew Goldberg says the emulator “was written entirely by autonomous agents” and that the team has not written or reviewed any of the code. Release v1.0.322 was tagged at 00:32 UTC on 11 November. See our post.

Suggestion: Point a test suite or a coding agent at one service you actually call, and read that service’s published fidelity score, given as “k of n” on each release, before you trust the result. Turn telemetry off with --telemetry off, EMULATOR_TELEMETRY=off, or enabled = false under [telemetry] in ~/.aws/emulator/config.toml. Keep permission tests on real AWS.

Check first: The “no human review” line is Goldberg’s account, and our post did not run the emulator. AWS says the emulator does not evaluate IAM and resource-based policies the way AWS does, so a request AWS would deny might succeed locally. The record we used does not name which services have high fidelity scores. The repository takes issues and does not take pull requests.

HashiCorp’s Terraform policy agent is generally available

What changed: On 5 November, HashiCorp announced general availability of the Terraform policy agent, a container that converts Sentinel and Open Policy Agent policies into Terraform policy, with a policy file, tests and a conversion report. For each source policy it restates the intent in plain language, writes .policy.hcl and a test file, then runs the tests. It uses the Terraform MCP server to look up provider schemas, and it can read Sentinel mock files to add cases. HashiCorp says it tested AWS, Azure and Google Cloud policies. Other registry providers work through schema lookups and are less tested. You bring the model: GitHub Copilot, Amazon Bedrock or LiteLLM. The README says policy content goes only to the provider you configure, validation needs TFPolicy 0.3.0 or later, and nothing is published to HCP Terraform. See our post.

Suggestion: Point it at one policy, read the plain-language requirements before you accept generated code, run tfpolicy test, and start in advisory enforcement. Move to mandatory only after you have checked the behavior.

Check first: HashiCorp says the output is produced by a model and can vary between runs. A passing generated test shows the policy meets the generated scenarios. It does not show that the policy matches the original. Constructs with no Terraform policy equivalent are written down as limitations in the report.

Gemini Decision 1 returns probabilities, and you pay for input only

What changed: Google has added gemini-decision-1 to the Gemini API. It does not write text. You send shared input and up to 1,000 typed questions, and it returns calibrated probabilities. Input can be text, images, video, audio or PDFs, up to 262,144 tokens. A noul question returns a probability from 0.01 to 0.99 plus a confidence. A choice question takes 2 to 255 options. A score question rates 2 to 255 rubric levels. The model page, the Decisions guide and the pricing page are live. Google AI Studio announced it on X on the evening of 11 November. Paid use is $0.10 per million input tokens for every modality. Output tokens are not billed. The shared input is billed once, and each question adds the tokens of its own instructions. The call is client.decisions.create and needs the Google Gen AI SDK 3.2 or later. See our post.

Suggestion: If an agent spends output tokens producing a yes or no so your code can parse it, try one Decisions call for a routing check or a set of policy rules. Google’s guide says each question runs on the shared input in one forward pass, questions cannot see each other, and latency stays nearly flat as you add questions. The guide’s pattern for a low confidence score is to send that case to a person.

Check first: This is the Gemini Developer API on v1beta only. Question instructions are text only. YouTube URLs and gs:// URIs are not accepted. Conversation history, thought blocks and tool-call blocks are not accepted as input. There is no context caching, Batch API, or Flex or Priority inference, so repeated input is billed in full every time. A safety filter returns HTTP 400, with a code such as safety or prohibited_content, and no answers. The free tier costs nothing, and the pricing table marks free-tier data as used to improve Google’s products. Paid-tier data is marked as not used that way. Google staff have called the model state of the art on many benchmarks. The docs our post read publish no benchmark table, so that line stays Google’s claim.