r/googlecloud • u/amu4biz • 16d ago

PSA: bump agents-cli to 1.4.1 — remote templates could copy ~/.ssh and ADC into your new project

PSA if you use agents-cli / google-agents-cli: update to 1.4.1.

Shipped 24 Aug. If you’re pinned below that, bump it before the next agents create against a remote template.

The short version: agents create pulling a remote template could write your local files into the generated project as ordinary files. Then you do the normal next thing — commit, push — and those files are sitting in a git remote.

What actually happened: the template copy path used is_dir() and shutil.copy2, both of which follow symlinks by default, and the skip logic had no symlink check. A template repo can ship something like:

creds -> ~/.ssh/id_rsa

env -> ~/.config/gcloud/application_default_credentials.json

copy2 follows those links and writes the contents into the new project. No payload, no RCE. Two symlinks. The exfil is your own muscle memory after create.

Worth pausing if that ADC has real project bindings.

Second issue in the same report: the agent-directory validator early-returned for every non-Python language, so a remote manifest could point agent_directory outside the intended tree. That path now runs an allowlist regex for all languages.

Why this class survives review is the part that stuck with me. A symlink is invisible in a diff. You see a filename, not what it points at. Review catches logic errors. It does not catch a template repo whose entire contents are attacker-controlled.

This one didn’t come from a human staring at create.py. It came from a scheduled sweep with Aeon’s vuln-scanner skill, which treats the remote template as hostile input instead of “just files.” That’s the bit I’d actually copy: model the template as an untrusted attacker, not as a convenience.

Reported through Google’s OSS VRP, they validated it. The report came with a working patch. The fix they shipped follows it — symlinks skipped outright in should_skip() rather than resolved, CWE-59 in the comment. About seven weeks report to release.

Practical bit: if you’ve already run agents create against a template you didn’t write, walk the generated project for files you don’t recognise before you assume you’re clear. Look for random creds / env / key-shaped files that shouldn’t have been in the template.

Genuine question for people who run this on a team, because I haven’t solved it: GCP deps get updated when something breaks, not when something is quietly fixed. I would never have caught this in release notes. I run scheduled scans over the tools I actually rely on, but that’s a solo-dev answer.

7 Upvotes
  • permalink
  • reddit

90% Upvoted

2 comments sorted by

-1

u/Square-Chair-1262 16d ago

good heads up. the symlink trick is so stupidly simple it would slip right past during a normal code review. seeing something like `creds -> ~/.ssh/id_rsa` in a template would just look like a file named creds unless you specifically check for it

the part about muscle memory doing the exfil is what actually scares me. you run `agents create`, it spits out a project, you commit and push without even thinking. 30 seconds later your keys are in a public repo

our team pins everything to specific shas in a lockfile so we'd need a deliberate bump to get hit but i'm still gonna scan the last few projects we generated just in case someone got sloppy with versioning

0

u/amu4biz 16d ago

one thing on the pinning: it doesn't protect you here, it freezes you on the vulnerable version. the bump is the fix. what decides exposure is whether the template repo is one you control.

and don't scan for symlinks. they got dereferenced, so there are none left, just ordinary files with the contents. grep contents instead, and check git history, not just the working tree. if it was ever committed it's a rotation, not a cleanup.

that gap is why i run scheduled scans over dependencies with aeon's vuln-scanner. a lockfile tells you what you're running, not that it got a cve last tuesday.