We're definitely applying htmlspecialchars to errors in html_errors mode. Can you please double check that it is really enabled (e.g. by printing the html_errors ini setting in the same script you are testing the error message)?

The escaping only happens for E_ERROR and E_PARSE.
https://github.com/php/php-src/blob/php-7.3.0RC4/main/main.c#L1336

Yes, html_errors is enabled.

(Sorry for wrong description, autofilling in browser surprised me ;-)

> The escaping only happens for E_ERROR and E_PARSE

why?

also in cli-mode escape sequences should be filtered, we implemented a lot of sanitze stuff because we don't trust PHP in that context but different behavior depending on the error type is a no-go and explains some headache from the past

> why?
I don't know. I'm not giving an explanation, just stating the current behavior.

The change to give E_ERROR (E_PARSE was added later) special treatment dates back to 5.1.2.
https://github.com/php/php-src/commit/2796160d15463a04acd7088fea379593d2c9caa0

@requinix: The code I was looking at is https://github.com/php/php-src/blob/php-7.3.0RC4/main/main.c#L945, which always escapes -- but now I realize that php_verror is only going to be used for docref type errors, not for "raw" errors.

Possibly this is also why it special cases ERROR and PARSE, to avoid double escaping.

> Possibly this is also why it special cases ERROR and PARSE, to avoid double escaping

wouldn't it be smarter to act like http://php.net/manual/de/function.htmlentities.php  and have bool $double_encode=TRUE in that case using FALSE instead special handeling for the sake of consistency?

It should always encode because then that will always show the original value. If OP's already bizarre situation was even worse, like
  echo ${'<script>alert(123);</script>'};
then I should see those "lt"s and "gt"s in the error message ("&lt/gt;" in the output) because that's what the variable was actually named.

An additional issue here is that docref also inserts markup for the documentation links, and we of course wouldn't want to escape that part.

> An additional issue here is that docref also 
> inserts markup for the documentation links,
> and we of course wouldn't want to escape that part.

is a cry for refactoring - do you tell me you can't distinct between that and escaping happens at the of everything independent from where it came and what it was?