How a Circular Import Created a Silent Vulnerability

During a code review engagement for a version control platform, we traced a subtle defect back to a circular dependency between two TypeScript modules. A security-critical constant, MAX_TRAVERSAL_LIMIT = 100, was defined in a module that formed one half of a circular import chain. When the JavaScript runtime resolved these modules, the constant was evaluated before its assignment had executed, causing it to silently resolve to undefined. Downstream arithmetic that depended on this value — specifically MAX_COMMITS_PER_UPDATE = MAX_TRAVERSAL_LIMIT * 1.5 — produced NaN. The resulting git command, git log --pretty='%H %P' <commit> -NaN, executed without error on most code paths, because the specific branch that consumed this parameter was only reached when certain repository metadata was absent.

The defect went undetected for two weeks in production. Existing unit tests passed because the mock objects used in the test suite did not validate the parameters of the outbound request bodies. The mocks confirmed that a function was called, but never inspected whether the limit parameter was a valid number. This is a pattern we encounter frequently during security reviews: test suites that verify happy-path behavior while ignoring the semantic correctness of boundary values. When a constant silently degrades to NaN, JavaScript's type coercion ensures that most comparisons and string interpolations proceed without throwing, making the propagation path nearly invisible.

Why TypeScript Did Not Catch This

TypeScript's module resolution permits circular imports. When module A imports from module B, and module B imports from module A, the runtime provides a partially-initialized module object. Any export that has not yet been assigned at the point of access evaluates to undefined. TypeScript's type system reports the constant as number, because at the type level it is declared as such. The type checker does not model the temporal initialization order of circular dependencies. This means that the type signature is correct in the static analysis but wrong at runtime — a class of error that type systems are generally expected to prevent.

The resolution was mechanically trivial: the constants were moved to a leaf module with no imports, breaking the cycle. The more significant finding was that no tooling in the project's CI pipeline would have caught this class of defect. ESLint's import/no-cycle rule was not enabled. The TypeScript compiler emitted no warning. The application's error monitoring captured no exception because NaN does not throw — it propagates. From a security assessment perspective, this is a silent degradation of a safety limit, precisely the kind of defect that converts a bounded operation into an unbounded one.

Recommendations for Security Reviews

This case illustrates why import graph analysis should be a standard component of application security reviews for TypeScript and JavaScript codebases. Circular dependencies are not merely a code quality concern; they create conditions where security-critical values can silently degrade. We recommend enabling import/no-cycle in ESLint configurations with error-level severity, auditing all constants that serve as security boundaries (rate limits, traversal depths, batch sizes) to ensure they are defined in leaf modules, and adding assertions in test suites that validate the types and ranges of parameters in outbound requests. The cost of these controls is negligible. The cost of a traversal limit silently becoming unbounded is not.

More broadly, this finding reinforces a principle we apply across all code review engagements: any value that enforces a security boundary must be validated at the point of use, not merely at the point of definition. Defensive programming patterns — such as asserting typeof limit === 'number' && !isNaN(limit) before passing a value to a shell command — are inexpensive and provide a fail-closed guarantee that static analysis alone cannot offer.