Security Advisories
CVE-2026-105772: The Google ADK TypeScript Path Traversal and Who It Affects
A narrow but serious flaw in Google's Agent Development Kit for TypeScript: which configurations are exposed, how to fix it, and what it teaches about shipping an agent server.
This independent write-up is not affiliated with the vendors named. Patch status reflects public advisories on the date shown, so confirm it against your vendor before acting.
CVE-2026-105772 is a path traversal flaw in FileArtifactService, part of Google's Agent Development Kit for TypeScript, published on npm as @google/adk. Crafted userId or sessionId values can reach outside the artifact storage directory, letting a remote, unauthenticated attacker read certain files and, in some cases, write them. Google scores it 9.1, and it affects versions 0.4.0 up to, but not including, 0.6.0.
Many ADK users are not affected, and that is worth saying first. The flaw requires the ADK API server to be exposed with the non-default FileArtifactService enabled. Applications using the default InMemoryArtifactService are unaffected. CISA's enrichment lists no known exploitation, and we found no public exploit code tracked.
The narrow scope makes this a useful example. It shows how an ordinary configuration choice, made to get a demo working, can turn into a security property of a production system.
/01
How the flaw works
Artifacts are files an agent saves and retrieves during its work. FileArtifactService stores them on local disk, using paths built from values including the user ID and session ID. Those values were not properly constrained, so relative or percent-encoded traversal sequences could point the path outside the intended storage root.
The limits matter. According to the CVE record, reads are limited to files matching the artifact directory layout, and writes occur only when an agent tool invokes saveArtifact. That makes this more constrained than a general arbitrary file read. Even so, a write outside the storage root can be serious, depending on what the process can reach.
/02
Are you affected?
Three conditions must all hold: a version from 0.4.0 before 0.6.0, the FileArtifactService in use, and an ADK API server that an attacker can reach. Search your code for FileArtifactService and run npm ls @google/adk or pnpm why @google/adk to see the installed version. If you are using InMemoryArtifactService, this CVE does not apply to you, though you should still keep the dependency current.
Google's record says to upgrade to 0.6.0 or later. The project's release page now shows a 2.x line, with v2.4.0 dated October 28, so check for breaking changes and move to a current release where you can. We could not confirm the 0.6.0 tag from the first page of releases, so verify the installed version against the advisory.
- Upgrade @google/adk, and confirm the version in every deployed service.
- Do not expose the ADK API server directly to the internet. Put authentication in front of it.
- Derive userId and sessionId on the server from an authenticated session, never from client input.
- Run the process as a low-privilege user, with write access only to its artifact directory.
- Check artifact directories and nearby paths for unexpected files, and review logs for encoded traversal sequences.
/03
Why agent servers keep running into this
Path traversal is one of the oldest web vulnerabilities there is. It keeps appearing in AI tooling because these frameworks are young, are moving quickly, and usually begin as developer tools running on a laptop, where an identifier in a URL is not a security boundary. Move the same code to a public server and every one of those assumptions becomes an attack surface.
The persistence choice is also an easy one to make without thinking about security. In-memory storage disappears on restart, so storing artifacts on disk is an obvious next step when a prototype needs to remember things. A coding assistant asked to make artifacts persistent may well reach for the file-based option. It works, and tests pass. Nothing about the result signals that an internet-facing endpoint now builds file paths from caller-supplied strings.
For production, object storage with scoped credentials is usually a better fit than local disk. ADK's documentation describes a Google Cloud Storage artifact service for this purpose.
/04
The bigger question for AI products in production
Agent frameworks are quickly becoming core dependencies for AI products, and they sit in an unusually sensitive place. They hold model credentials, can call tools with real permissions, and process untrusted content by design. A framework's example server is a starting point for development. It is rarely a complete answer on authentication, tenant separation, or storage.
If your product is earning money on an agent you stood up quickly, take a look at how it is exposed. Who can call the API? Can one customer name another customer's session? What could the process touch if a tool misbehaved? An experienced engineer can usually answer those questions in a short review, and fix what they find. That is the kind of work we do when productionizing AI-built applications, and through retainers as your agents and their frameworks evolve.
Frequently asked
Questions about this topic.
Am I affected by CVE-2026-105772 if I use the default ADK setup?
No. The CVE record says applications using the default InMemoryArtifactService are unaffected. You need to be running @google/adk 0.4.0 to before 0.6.0, using FileArtifactService, with the ADK API server exposed.
Does this affect ADK for Python, Go, or Java?
The CVE covers ADK TypeScript. It does not list other language implementations, but if you use a file-based artifact store in any language, it is sensible to test how it handles untrusted identifiers.
Is CVE-2026-105772 being exploited?
We found no reports of exploitation as of November 4, 2026. It is not in CISA's Known Exploited Vulnerabilities catalog, although CISA's enrichment does rate it as automatable, so patching exposed servers remains important.
Sources