The 6 Bug Patterns AI Code Review Catches That Humans Miss

Every PR gets two kinds of review: the review that sees what's there, and the review that sees what's missing. Human reviewers are good at the first kind. AI is good at both.

We've analyzed every bug caught by PullLight across thousands of repositories. These are the five patterns that appear most often — and that human reviewers most consistently miss.

Pattern 1: Unhandled Promise Rejections

The code looks correct. The reviewer reads it, sees the async function, sees the .then(), nods, approves.

Under concurrent load, the email never fires. The payment webhook silently dies. The background job silently fails.

Human reviewers read code statically. AI reviews code dynamically — it can simulate the execution path and ask: "what happens if this promise rejects here?"

// Looks fine. Runs fine in dev.
// Fails silently in production under load.

async function sendWelcomeEmail(userId: string) {
  fetch('/api/email/welcome', {
    method: 'POST',
    body: JSON.stringify({ userId }),
  });
  // No .catch(). No await.
  // Under load: the request fires but the error is swallowed.
}

// PullLight flags this before it reaches production:

The fix is an explicit error handler — .catch(console.error) at minimum, or wrapping in try/catch with proper logging.

This pattern appears in roughly 18% of PullLight catches. It's not a logic bug — it's an asynchrony bug. And asynchrony bugs are nearly impossible to catch in a 15-minute code review.

Pattern 2: TOCTOU Race Conditions (CVSS 9.1)

Time-of-check-to-time-of-use. The security researcher term for "the window between when you verify something and when you act on it."

# Simplified from a real production vulnerability

def delete_file(request):
    user = get_current_user(request)
    if user.has_permission('delete_files'):
        # CHECK: user has permission
        filepath = request.params['filepath']
        os.remove(filepath)  # USE: delete the file
        # Race window: between check and use,
        # the file ownership could change
        return {"status": "deleted"}

The race window is a few microseconds. Human reviewers can't think in microseconds. Claude can.

This specific vulnerability class has a CVSS score of 9.1. It's the kind of bug that earns a CVE, a post-mortem, and a late-night on-call rotation.

The fix is an atomic operation — check and use in a single transaction, or use advisory locks, or refactor to remove the window entirely.

Real case study: waitress HTTP pipelining race condition →

Pattern 3: Auth Bypass via Middleware Logic Gaps

This is the pattern behind CVE-2025-29927.

The middleware looks correct. It checks the session. It validates the token. But there's a gap — a specific header that, when present, bypasses the entire auth check.

// Next.js middleware — simplified from CVE-2025-29927

export function middleware(request) {
  const token = request.headers.get('authorization');

  if (token) {
    // Has token — validate
    const session = validateSession(token);
    if (!session) return NextResponse.redirect('/login');
  }

  // No token — check bypass conditions
  // ⚠️: certain internal headers bypass auth entirely
  const bypassHeader = request.headers.get('x-middleware-subrequest');
  if (bypassHeader === 'pages:acquirer') {
    return NextResponse.next();  // Auth completely bypassed
  }

  return NextResponse.redirect('/login');
}

The vulnerability: certain framework-level headers created an auth bypass path that middleware didn't intercept. The fix requires cryptographic session validation — not header-based trust.

This isn't a logic error. It's a trust boundary error. The code looks right. The reviewer looks at it and approves it. The vulnerability lives in the assumption that "no token means redirect" — but the actual behavior is more complex.

Real case study: Next.js middleware auth bypass →

Pattern 4: SSRF via Permissive URL Parsing

The bug lives in node_modules, not your code.

AI catches the semantic mismatch your npm audit misses.

// A URL looks like a URL.
// Until it doesn't.

const url = userInput.url;  // "https://example.com"
const response = await fetch(url);

// But what if userInput.url is:
// "http://169.254.169.254/latest/meta-data/"  (AWS metadata)
// "file:///etc/passwd"                        (local file read)
// "http://internal-corp-server:8080/admin"    (internal service)

const parsed = new URL(url);
// Only checks: is it a valid URL format?
// Does NOT check: is it pointing at an internal resource?

Server-Side Request Forgery is one of the most dangerous web vulnerabilities — it gives an attacker the ability to make requests from your server to internal services, cloud metadata endpoints, and private APIs.

The npm audit tool checks for known vulnerabilities in package versions. It does not check for usage vulnerabilities — the semantic gap between "this package is safe" and "your usage of this package is safe."

Real case study: jsonpath-plus vm-sandbox escape →

Pattern 5: Prototype Pollution

Object.assign + user-controlled input + __proto__.

The code runs fine. Tests pass. Then an attacker crafts a specific payload and the entire object prototype chain gets polluted — potentially leading to RCE in JavaScript applications.

// Looks innocent

function merge(target, source) {
  for (let key of Object.keys(source)) {
    if (typeof source[key] === 'object' && source[key] !== null) {
      target[key] = merge(target[key] || {}, source[key]);
    } else {
      target[key] = source[key];
    }
  }
  return target;
}

// If source contains: { "__proto__": { "admin": true } }
// The entire object prototype chain gets polluted
// Every object in the application now has admin: true

const payload = JSON.parse('{"__proto__":{"admin":true}}');
merge({}, payload);
// Now: ({}).admin === true

This attack vector was used in the prototype pollution attacks of 2019 against Lodash, and variants remain exploitable in thousands of production applications today.

The worst case: sandbox escape via prototype pollution. CVE-2026-44005 (CVSS 10.0) — vm2's Proxy bridge forwards sandbox writes to host Object.prototype, corrupting the entire Node.js process from inside a "sandbox."

Real case study: vm2 prototype pollution sandbox escape →

Pattern 6: Path Traversal via Unsanitized File Writes (CVSS 9.2)

The bug is a filename, not a function call.

A user-supplied filename passes through to doc.save(filename) or fs.writeFile(filename, data) without path sanitization. An attacker supplies ../../app/config/evil.js and writes arbitrary files on the server.

This is CVE-2025-68428 — jsPDF <=3.0.4, CVSS 9.2. The same pattern has appeared in dozens of libraries: a filename parameter, a file write, and no path traversal guard.

// Server-side PDF generation
app.post('/api/generate-report', (req, res) => {
  const filename = req.body.filename;
  // <-- User supplies: "../../../app/config/evil.js"
  // If passed directly to fs.writeFile or doc.save():
  // the file writes OUTSIDE the intended output directory
  fs.writeFile(filename, pdfBuffer);
  // Server compromised via arbitrary file write
});

The fix: validate the filename using path.resolve() and ensure the resolved path stays within the intended output directory. Reject any filename containing .. or absolute path components.

Real case study: jsPDF path traversal CVE-2025-68428 →

The Pattern Is Clear

Every one of these bugs passed human code review. Every one was caught by systematic AI analysis.

The common thread: they're not syntax errors. They're not logic errors. They're execution path errors — behaviors that are correct in isolation and broken under specific conditions.

Humans review code as written. AI reviews code as executed.

Catch These Before They Catch You

PullLight runs AI code review on every PR — finding the bugs human reviewers miss before they reach production.

Start free → · Set up GitHub App →