fix(fleet): bound the token an enrolling server can make us write - #124
Merged
Conversation
Investigating CodeQL's "network data written to file" alerts turned up one thing worth changing. The enrolment response's token is written straight into the user's home directory with no bound on its size, so a hostile or simply broken server can answer with a gigabyte of string and this persists all of it. A real token is `cgm_` plus 32 base64url bytes — under fifty characters. Capped at 1024, which leaves room for a longer token format without leaving room for that. The content feed already bounds its downloads the same way (8MB bundle, 4KB signature); this path had been missed. The other three alerts are examined in the pull request rather than changed.
github-actions Bot
pushed a commit
that referenced
this pull request
Aug 26, 2026
## [1.2.3](v1.2.2...v1.2.3) (2026-08-26) ### Bug Fixes * **fleet:** bound the token an enrolling server can make us write ([#124](#124)) ([9e91067](9e91067))
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Came out of investigating the four CodeQL "network data written to file" alerts. Three are false positives; this one found something real.
What was wrong
enrolMachinewrites the server's token straight into~/.codegate/fleet.jsonwith no bound on its length. A real token iscgm_plus 32 base64url bytes — under fifty characters. A hostile or simply broken server can answer with a gigabyte of string and this persists all of it.Capped at 1024, which leaves room for a longer token format without leaving room for that. The content feed already bounds its downloads the same way (8MB bundle, 4KB signature); this path had been missed.
The other three alerts — analysed, not changed
content-store.ts:120,121— writes the downloaded bundle and its signature. Every leg of the taint path is already guarded:content-updater.ts:114, throws on failure)content_versioncannot express a path — constrained at the parse boundary and again where it becomes a path, with ten traversal shapes under testControlling these bytes requires the publisher's private key, at which point signature verification is meaningless by definition.
enrol-client.ts:101(the write itself) — the destination isfleetConfigPath(), a fixed path, not derived from any response. Content isJSON.stringify'd, so no structural injection. Written0600inside a0700directory. The only party who influences it is the server the operator explicitly chose to enrol with.report-client.ts:48— reads the local inventory and POSTs it to the configured server. This is the product: reporting what AI tooling is on the machine to the operator's console.config.servercomes from the file written at enrolment by the user's own action, and is validated to be http/https.Recommend dismissing those three as "won't fix" with that reasoning rather than contorting the code around them.
880 tests pass; typecheck, lint and build clean.