mediumCWE-377A02:2021

Shared /tmp State

Serverless functions reuse execution environments between invocations, so sensitive files written to /tmp can be read by later requests from different users.

How It Works

AWS Lambda and similar platforms keep warm execution environments alive to avoid cold starts. If your function writes a user's data to /tmp and doesn't clean it up, the next invocation in the same environment can read it — even if it's a completely different user's request.

Vulnerable Code
// BAD: user data written to /tmp without cleanup
export const handler = async (event) => {
  const userId = event.userId;
  fs.writeFileSync('/tmp/user-data.json', JSON.stringify(event.sensitiveData));
  // no cleanup — next invocation reads this file
};
Secure Code
// GOOD: always clean up /tmp and use user-specific filenames
export const handler = async (event) => {
  const tmpFile = `/tmp/${event.requestId}-data.json`;
  try {
    fs.writeFileSync(tmpFile, JSON.stringify(event.data));
    // process the file...
  } finally {
    if (fs.existsSync(tmpFile)) fs.unlinkSync(tmpFile); // always clean up
  }
};

Real-World Example

Researchers at PureSec (now Palo Alto Prisma Cloud) documented /tmp leakage as a recurring Lambda security issue in their 2019 serverless security report, showing that cached execution environments regularly expose cross-request data.

How to Prevent It

  • Always delete /tmp files in a finally block after use
  • Use unique, request-scoped filenames (include requestId) so concurrent executions don't collide
  • Prefer in-memory processing over /tmp files when the data fits in RAM
  • Treat /tmp as a shared, untrusted filesystem — never write unencrypted sensitive data there

Affected Technologies

aws-lambdaNode.js

Data Hogo detects this vulnerability automatically.

Scan Your Repo Free

Related Vulnerabilities