[Security] Process crash (DoS) via non-Buffer input to $putCopyData()

[MinhyukHong]

Summary

libpq@1.10.0 is vulnerable to a Denial of Service (DoS) via process crash.
The C++ binding $putCopyData() passes info[0] directly to Buffer::Data()
without type validation. While the public putCopyData() wrapper has an
assert(buffer instanceof Buffer) check, the underlying C++ binding is directly
accessible and can be called without the assertion.

Affected Version

• libpq@1.10.0 (latest on npm)

Root Cause

In connection.cc, PutCopyData() casts info[0] without type validation:

v8::Local<v8::Object> buffer = info[0].As<v8::Object>();
char* data = node::Buffer::Data(buffer);  // no type check

The public JS wrapper putCopyData() has a guard:

assert(buffer instanceof Buffer)

However, the C++ binding $putCopyData() is directly accessible on the instance,
bypassing this assertion entirely.

Proof of Concept

const PQ = require('libpq');
const pq = new PQ();

// Normal call — blocked by JS wrapper
// pq.putCopyData("string")  →  AssertionError

// Direct C++ binding — bypasses JS wrapper
pq.$putCopyData("not a buffer");  // process crashes here

Output:

node: ../src/node_buffer.cc:219:
char* node::Buffer::Data(v8::Localv8::Object):
Assertion `obj->IsArrayBufferView()' failed.
1: node::Abort() [node]
4: [addon.node]
7: v8::internal::Builtin_HandleApiCall [node]
Aborted (core dumped)

Reproduced 3/3 times on Node.js v10.24.1, Ubuntu 22.04.

Impact

Any application where the libpq binding object is accessible allows an attacker
to crash the Node.js process with a single malformed call, causing Denial of Service.

Suggested Fix

Add a type check in the C++ layer before calling Buffer::Data():

if (!node::Buffer::HasInstance(info[0])) {
    return Nan::ThrowTypeError("First argument must be a Buffer");
}

Additional Notes

This vulnerability was identified through static taint analysis using Code Property Graph (CPG).
This issue was identified as part of academic research on Cross-Language vulnerability detection in npm native extensions.
We are reporting this in good faith to help improve the security of the package ecosystems.

[brianc]

Probably would take you the same amount of time to generate the code with AI to fix this and open a PR than submit an AI generated issue. I suppose I'll fix this, since its open. I don't find it particularly troubling but I could throw here on unexpected data so I suppose I should.

[MinhyukHong]

Thank you for the response.

To clarify - I found this through static taint analysis on the cpg as part of research on cross-language vulnerabilities detection on npm native extensions, and confirmed it with dynamic testing. The write-up had some AI help with formatting, sorry if that came across the wrong way.

I'll open a PR with the fix.