The issue arises during the conversion of JavaScript values to strings within the app.alert() method.
An attacker can craft a PDF such that the following JavaScript is executed automatically upon document open via an OpenAction:
app.alert(app.activeDocs, true);
In this case, app.activeDocs is evaluated as a NULL-equivalent value rather than a valid string object. However, Nitro PDF Pro does not properly validate this value and passes it directly to JS_ValueToString() and subsequently to JS_GetStringChars().
The vulnerable flow can be simplified as follows:
app.alert(value, true)
→ JS_ValueToString()
→ JS_GetStringChars()
→ dereference crash
In the actual vulnerable path, when the argument is not a simple string, JS_ValueToString() is invoked and its return value is passed directly to JS_GetStringChars():
if ( argc != 1 || (v16 = *argv, (*argv & 7) != 0) )
{
v30 = JS_ValueToString(a1, *argv);
StringChars = JS_GetStringChars(v30); // crash
}
The problem is that even though app.activeDocs resolves to a NULL value, the implementation does not sufficiently verify whether the returned value is a valid string object. As a result, JS_GetStringChars() assumes the pointer refers to a valid string object and attempts to access its internal members:
__int64 __fastcall JS_GetStringChars(__int64 *a1)
{
v1 = *a1;
...
}
If a1 is NULL or otherwise invalid, this leads to an access violation, causing Nitro PDF Pro to terminate immediately.