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?

So I have done some research and there is an escaping for all docref errors (e.g. usually errors from extensions / functions). This triggers php_verror that creates the message (escaped) and pass it to zend_error_zstr which calls zend_error_zstr_at. However the various compiler and other errors go through zend_error which calls zend_error_va_list and that calls zend_error_zstr_at. This path does not get escaped. It eventually calls zend_error_cb which is by default set to error_function of zend_utility_functions struct which is be default php_error_cb. No other core extension sets it but it is available for external extension so changing anything in it is essentially ABI break.

So I can think of a couple of solutions and none of them is really ideal.

1. Extend all needed definitions and add some flags param that could indicate if escaping has been done. The flag would be then check in php_error_cb instead of that error check. This is obviously an ABI break. We could potentially have _ex functions so the old one would be still available but we would still need to extend utility function so still ABI break.

2. Overload type param as it's an int and there's a space. This would require some masking and unmasking when testing of the type. It would be also problematic if any external extension overload zend_error_cb and quite hard to catch issue. It seems a bit messy as well.

3. Escape the zend_error path too somehow and removing error escaping from php_error_cb. This might require a new utility function as escaping is not available in Zend and we need to somehow bridge it to main...