I'm always a bit sceptical about the danger of this type of bug. Sure, it will cause unpredictable errors, but lets look at what could happen.
As they talk about stack overflows, I'm presuming that the URL is being copied into a variable stored on the stack, i.e. a local variable. When this exploit runs, whatever is in the memory locations after this variable will contain some data that is under the control of the exploiter.
So. The memory locations after the variable will be another variable, or possibly a stack frame header including the return address and possibly some saved register contents.
If it's another variable or saved register contents, then the previous contents will be lost, and/or some unpredictable behaviour might happen when the variable is used. It might be a pointer, which may mean that some other data address could be clobbered later in the code. It could be a vector (pointer to some code), but in order to exploit this, you'd have to understand the rest of the code really well. If it's a stack frame (and I've not checked the direction of stack growth so don't know whether it will be the frame for this function or another), then the return address may be damaged, which could be used to control where the code returns to.
The comment from Paul Ducklin from Sophos, re. "The crash, which is a side-effect of a stack overflow, pretty much lets you write to a memory location of your choice," seems an over-reaction, as it is likely that you could overwrite an address following this buffer in the page the stack is in or a contiguously later memory page. Any point after this will probably generate a segmentation or address violation, as soon as it tries to write to an unallocated address. To me, this is not the same as "a memory location of your choice".
You've potentially got some executable code (if that is what the URL contains) stored in a memory location you should not have access to, but it's not in the program text, and I've not yet seen a method described of triggering that code (the return address in a stack frame header is the only one I can see which would affect the execution stream). This does not appear to be a practicle means of injecting code, much more likely some DoS attack against the user running Foxit.
So it is important (all bugs should be regarded as such), and I'm sure there may be some special cases I've not spotted, but on casual inspection it can only be described as a DoS vulnerability with a 'potential' remote execution problem. saying any more would be FUD.
Possibly someone could educate me if I am wrong.