Insecure Deserialization: When AI Code Lets Attackers Execute Commands

What is Insecure Deserialization?

Insecure deserialization is a vulnerability where attackers inject malicious code through serialized data that your application converts back into objects. When you deserialize untrusted input without validation, that data can execute arbitrary commands on your server.

Think of it like opening a package from an unknown sender - it could contain anything, including something dangerous. Serialization converts objects to strings (safe). Deserialization converts strings back to objects - and if an attacker controls that string, they control what gets created and executed.

According to CWE-502: Deserialization of Untrusted Data, this vulnerability appears in the 2024 CWE Top 25 Most Dangerous Software Weaknesses. The impact is severe: Remote Code Execution (RCE) means attackers can run any command on your server, steal data, install backdoors, or delete everything.

How Do Deserialization Attacks Work?

Deserialization attacks follow a predictable pattern. The attacker finds an endpoint that accepts serialized data from users. They craft a malicious payload that executes code when deserialized. Your server processes the payload, running the attacker's code with your application's privileges.

The attack chain looks like this:

1. Attacker identifies an endpoint accepting serialized input
2. Attacker crafts a payload containing executable code
3. Attacker sends the payload to your server
4. Your server deserializes the payload, executing the malicious code with full server privileges

Unlike SQL injection that targets databases or XSS that targets browsers, deserialization attacks target your server directly. Success typically means complete server compromise.

Why Do AI Tools Generate Vulnerable Deserialization Code?

AI coding assistants like Cursor, Claude Code, and GitHub Copilot generate insecure deserialization patterns because they optimize for "working code" rather than secure code. When you ask for dynamic execution or flexible data handling, AI reaches for powerful but dangerous tools.

AI generates eval() because it handles any expression. AI uses yaml.load() because older tutorials do. AI suggests node-serialize because it appears in training data from before the vulnerability was understood. The models don't distinguish between trusted internal data and untrusted user input.

This is especially dangerous for vibe coders building quickly with AI tools. The generated code works perfectly during development - the vulnerability only becomes apparent when attackers exploit it in production.

What Are the Dangerous JavaScript and Node.js Patterns?

JavaScript and Node.js have several patterns that lead to deserialization vulnerabilities. The most common is eval() with user input - AI generates this for "dynamic calculation" or "flexible execution" requests.

Pattern 1: eval() with User Input

// AI generates this for "dynamic calculator" requests
app.post('/calculate', (req, res) => {
  const formula = req.body.formula
  const result = eval(formula) // RCE!
  res.json({ result })
})

// Attack payload:
// formula = "require('child_process').execSync('cat /etc/passwd')"

import { evaluate } from 'mathjs'

app.post('/calculate', (req, res) => {
  const formula = req.body.formula
  try {
    const result = evaluate(formula) // Safe math only
    res.json({ result })
  } catch (e) {
    res.status(400).json({ error: 'Invalid expression' })
  }
})

Pattern 2: node-serialize Package

The node-serialize package has a known RCE vulnerability (CVSS 9.8). AI tools suggest it because it appears in older tutorials and training data.

const serialize = require('node-serialize')

app.post('/save-state', (req, res) => {
  // Deserializing untrusted input - RCE!
  const state = serialize.unserialize(req.body.state)
  // Attack payload can include functions that execute on unserialize
})

import { z } from 'zod'

const StateSchema = z.object({
  userId: z.string(),
  preferences: z.record(z.string())
})

app.post('/save-state', (req, res) => {
  try {
    const parsed = JSON.parse(req.body.state) // Safe
    const state = StateSchema.parse(parsed) // Validated
    res.json({ success: true })
  } catch (e) {
    res.status(400).json({ error: 'Invalid state' })
  }
})

Pattern 3: Function() Constructor

// AI generates this for "dynamic function execution"
app.post('/run', (req, res) => {
  const fn = new Function('return ' + req.body.code) // RCE!
  const result = fn()
  res.json({ result })
})

const ALLOWED_OPERATIONS = {
  sum: (a, b) => a + b,
  multiply: (a, b) => a * b,
  average: (arr) => arr.reduce((a, b) => a + b, 0) / arr.length
}

app.post('/run', (req, res) => {
  const { operation, args } = req.body
  const fn = ALLOWED_OPERATIONS[operation]
  if (!fn) return res.status(400).json({ error: 'Unknown operation' })
  const result = fn(...args)
  res.json({ result })
})

What Are the Dangerous Python Patterns?

Python's flexibility makes it particularly susceptible to deserialization attacks. Two patterns dominate AI-generated vulnerable code: pickle.loads() and yaml.load().

Pattern 1: pickle.loads() with User Input

Python's pickle module can serialize and deserialize arbitrary Python objects - including objects that execute code when created. There is no "safe pickle" for untrusted data.

import pickle
import base64

@app.route('/load', methods=['POST'])
def load_data():
    data = request.json['data']
    # Deserializing untrusted pickle data - RCE!
    obj = pickle.loads(base64.b64decode(data))
    return jsonify(obj)

# Attack: Craft pickle payload that executes os.system()

import json
from pydantic import BaseModel

class UserData(BaseModel):
    name: str
    preferences: dict

@app.route('/load', methods=['POST'])
def load_data():
    data = request.json['data']
    parsed = json.loads(data)  # Safe - JSON can't execute code
    validated = UserData(**parsed)  # Validated
    return jsonify(validated.dict())

Pattern 2: yaml.load() Without SafeLoader

Before PyYAML 5.4, yaml.load() executed arbitrary Python code embedded in YAML files. This was fixed in CVE-2020-14343, but AI tools still generate the vulnerable pattern.

import yaml

@app.route('/config', methods=['POST'])
def load_config():
    # yaml.load() without SafeLoader - RCE in PyYAML < 5.4!
    config = yaml.load(request.data)
    return jsonify(config)

# Attack payload:
# !!python/object/apply:os.system ["rm -rf /"]

import yaml

@app.route('/config', methods=['POST'])
def load_config():
    # safe_load() has always been safe - use it!
    config = yaml.safe_load(request.data)
    return jsonify(config)

What is Prototype Pollution and How Does it Relate?

Prototype pollution is a related JavaScript vulnerability where attackers modify Object.prototype through unsafe object merging. While JSON.parse() itself is safe, merging parsed data without sanitization can pollute prototypes.

According to PortSwigger's research, prototype pollution has affected major libraries including lodash (CVE-2019-10744) and jQuery (CVE-2019-11358). The attack works by injecting __proto__ keys that modify all JavaScript objects.

function merge(target, source) {
  for (let key in source) {
    if (typeof source[key] === 'object') {
      target[key] = merge(target[key] || {}, source[key])
    } else {
      target[key] = source[key] // __proto__ pollutes prototype!
    }
  }
  return target
}

// Attack: { "__proto__": { "isAdmin": true } }
// Now EVERY object has isAdmin = true

import sjson from 'secure-json-parse'

// Rejects __proto__, constructor, and prototype keys
const data = sjson.parse(userInput)

// Or validate keys manually
function safeMerge(target, source) {
  const FORBIDDEN = ['__proto__', 'constructor', 'prototype']
  for (let key in source) {
    if (FORBIDDEN.includes(key)) continue
    if (typeof source[key] === 'object' && source[key] !== null) {
      target[key] = safeMerge(target[key] || {}, source[key])
    } else {
      target[key] = source[key]
    }
  }
  return target
}

The secure-json-parse library from the Fastify team is a drop-in replacement for JSON.parse() that prevents prototype pollution. Use it for any user-supplied JSON.

What Framework-Specific Guidance Applies?

Next.js and React Server Components

CVE-2025-55182 affected React Server Components in React 19.0.0-19.2.0, allowing unauthenticated RCE via crafted requests to Server Function endpoints. This also impacted Next.js (CVE-2025-66478), React Router, Waku, and Expo.

• Update to React 19.2.1+ and Next.js 15.0.5+
• Validate all inputs to Server Actions with Zod
• Check your Next.js + Supabase stack for additional patterns

Express.js

• Never use eval() or new Function() with user input
• Use JSON.parse() with schema validation for deserialization
• Validate request bodies with Zod or Yup before processing
• See OWASP Deserialization Cheat Sheet for complete guidance

FastAPI and Flask

• Always use yaml.safe_load() - never yaml.load()
• Never use pickle with untrusted data - there is no safe way
• Use Pydantic models for request validation
• Prefer JSON for all data serialization

How Do I Detect Deserialization Vulnerabilities?

Search your codebase for these dangerous patterns. Each one requires immediate attention if it processes user input.

# Search for eval() usage
grep -rn "eval(" --include="*.js" --include="*.ts"

# Search for Function constructor
grep -rn "new Function(" --include="*.js" --include="*.ts"

# Search for node-serialize
grep -rn "node-serialize\|unserialize(" --include="*.js" --include="*.ts"

# Search for prototype pollution vectors
grep -rn "__proto__\|constructor\[" --include="*.js" --include="*.ts"

# Search for pickle usage
grep -rn "pickle.load\|pickle.loads" --include="*.py"

# Search for unsafe yaml
grep -rn "yaml.load(" --include="*.py"

# Check if SafeLoader is used
grep -rn "yaml.load" --include="*.py" | grep -v "SafeLoader\|safe_load"

AI Fix Prompt: Secure Deserialization Patterns

Copy this prompt into Cursor, Claude Code, or GitHub Copilot to fix deserialization vulnerabilities:

Review my codebase for insecure deserialization vulnerabilities (CWE-502):

## JavaScript/Node.js Checks

1. **Search for eval()**: Find any use of eval() with user input
   - Pattern: `eval(`, `new Function(`
   - Replace with: Safe expression parsers (mathjs) or predefined operations
   - If dynamic execution is truly needed, use a sandboxed VM

2. **Search for unsafe deserializers**:
   - Pattern: `serialize.unserialize`, `node-serialize`
   - Replace with: `JSON.parse()` + schema validation with Zod
   - REMOVE the node-serialize package entirely

3. **Check for prototype pollution**:
   - Pattern: Recursive merge functions, `__proto__` in object keys
   - Replace with: `secure-json-parse` from npm
   - Add key validation: reject __proto__, constructor, prototype

## Python Checks

1. **Search for pickle.loads()**:
   - Pattern: `pickle.loads(`, `pickle.load(`
   - Replace with: JSON - there is NO safe pickle for untrusted data
   - Only use pickle for trusted internal data

2. **Search for yaml.load()**:
   - Pattern: `yaml.load(` without `Loader=yaml.SafeLoader`
   - Replace with: `yaml.safe_load()`
   - Note: safe_load() has always been safe

## Framework Version Checks

1. **React/Next.js**: Verify React >= 19.2.1, Next.js >= 15.0.5 (CVE-2025-55182)
2. **PyYAML**: Verify version >= 5.4 (CVE-2020-14343)
3. **lodash**: Check for prototype pollution patches

## For Each Vulnerability Found

1. Show the dangerous code with line number
2. Explain why it's vulnerable (what an attacker could do)
3. Show the secure replacement using:
   - JSON.parse() + Zod for JavaScript
   - yaml.safe_load() or json.loads() + Pydantic for Python
4. Add schema validation if missing
5. Verify no user input reaches deserialization without validation

Frequently Asked Questions

Related Security Topics

External References

• CWE-502: Deserialization of Untrusted Data - MITRE definition
• OWASP A08:2021 - Software and Data Integrity Failures
• OWASP Deserialization Cheat Sheet - Prevention guidance
• PortSwigger Prototype Pollution - Detailed technical guide
• secure-json-parse - Safe JSON parsing library
• Snyk: node-serialize Vulnerability - Known RCE vulnerability