I very much doubt there are many applications at all containing code
like this. It is illogical to be decoding html entities from user
input. Therefore I would not call this a "very serious problem" and
certainly not a critical bug.

Not really. While this is not part of the HTML / HTTP standards, major
browsers
around try to send such characters in the user input as HTML entities
that cannot
all be represented in the encoding of the originating HTML page, it's
quite probable

the function is used to filter the query strings.

Indeed, it probably is, but hopefully the results of that are not then
echoed out to the browser without running htmlspecialchars() etc on
them... If they are (which is the root of this "security problem") then
that is the fault of the idiot who wrote the code, not PHP. You can only
protect users from their own stupidity to a certain degree...

OK, ignore that, forgot what we were talking about for a while there :)

htmlspecialchars() should still be run on the output, otherwise you have
another security hole, but of course that won't protect against sending
memory contents back to the user...