Wildcard package.json exports auto-import path does not apply traversal containment checks

[zainnadeem786]

Demo Repo

https://github.com/zainnadeem786/typescript-autoimport-traversal-poc

Which of the following problems are you reporting?

Something else more complicated which I'll explain in more detail

Demonstrate the defect described above with a code sample.

import { LEAKED_SECRET_SYMBOL } from "evil-pkg/secret";

Run tsc --showConfig and paste its output here

{
"compilerOptions": {
"module": "nodenext",
"moduleResolution": "nodenext",
"target": "es2022",
"strict": true
},
"files": [
"./src/app.ts"
]
}

Run tsc --traceResolution and paste its output here

======== Resolving module 'evil-pkg/secret' ========
Module name 'evil-pkg/secret' was not resolved.
======== Module name 'evil-pkg/secret' was not resolved. ========

Paste the package.json of the importing module, if it exists

{
"name": "victim-project",
"private": true,
"type": "module",
"dependencies": {
"evil-pkg": "1.0.0"
}
}

Paste the package.json of the target module, if it exists

{
"name": "evil-pkg",
"version": "1.0.0",
"exports": {
"./": "./../../private/.ts"
}
}

Any other comments can go here

This is not a standard runtime/build-time module resolution mismatch. I selected “Something else more complicated” because the issue is specifically in tsserver package-json auto-import indexing.

Normal module resolution rejects the traversal export target:

resolveModuleName("evil-pkg/secret"): undefined

However, the tsserver auto-import provider still indexes a file outside the package boundary:

D:/TypeScript/msrc-tsserver-autoimport-traversal-poc/victim-project/private/secret.ts

The relevant behavior appears to be in loadEntrypointsFromTargetExports(), where the wildcard export target is expanded and passed to readDirectory() without applying the same traversal/containment validation used by normal export resolution.

The minimal reproduction repository includes a script that demonstrates:

1. normal module resolution rejects the traversal target
2. auto-import indexing still includes the out-of-package file
3. completion details expose the out-of-package symbol metadata

This was originally reviewed by MSRC and treated as defense-in-depth hardening rather than a serviced security vulnerability. MSRC recom
mended opening a GitHub issue so the TypeScript team can consider applying the same ../, ./, and node_modules containment checks to the wildcard branch.

[RyanCavanaugh]

Who exactly is able to read a file they couldn't already read in this setup?

[zainnadeem786]

Good question - I agree this is not a privilege-boundary bypass in the same sense as arbitrary code execution from a malicious dependency.

My concern is mainly that normal export resolution already treats these traversal targets as invalid, while the wildcard auto-import indexing path still expands and indexes them.

So the issue is less about “gaining new filesystem access” and more about inconsistent containment enforcement between:

• normal module resolution
• tsserver package-json auto-import indexing

In the current behavior, wildcard export targets containing traversal segments can still cause out-of-package files to be recursively enumerated and surfaced through auto-import metadata, despite the resolver rejecting the same target.

That inconsistency made it seem worth reporting as a hardening/containment issue even if it does not cross a strong security boundary on its own.

[zainnadeem786]

Hi @RyanCavanaugh ,
I’ve been looking into this further and I think the wildcard branch in "loadEntrypointsFromTargetExports()" may be missing the same traversal/containment validation already applied in the non-wildcard export resolution paths.

I’d be interested in attempting a fix for this if that direction sounds reasonable.

My current understanding is that the fix would likely involve:

• validating wildcard export targets before "readDirectory()"
• rejecting traversal-related segments such as "..", ".", and "node_modules"
• ensuring enumerated paths remain contained under "scope.packageDirectory"

Please let me know if that aligns with the intended direction before I start working on a PR.