Edit report at https://bugs.php.net/bug.php?id=71876&edit=1
ID: 71876
Updated by: nikic@php.net
Reported by: the_djmaze at hotmail dot com
Summary: Memory corruption htmlspecialchars(): charset `*'
not supported
-Status: Assigned
+Status: Closed
Type: Bug
Package: Strings related
Operating System: Fedora 22
PHP Version: 7.0.8
Assigned To: nikic
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of nikita.ppv@gmail.com
Revision: http://git.php.net/?p=php-src.git;a=commit;h=1f9e93687c0ceb442ef608b894427ada11ac06fc
Log: Fixed bug #71876
Previous Comments:
------------------------------------------------------------------------
[2020-01-03 10:04:19] nikic@php.net
Fixed in 7.4.2 with https://github.com/php/php-src/commit/fcdc0a6db0ae63fbed9e3828137b899b844623ce.
I didn't notice at the time that this is actually a pre-existing issue, will have to backport
this change.
------------------------------------------------------------------------
[2018-12-07 15:25:58] irasha at yahoo dot com
I just ran into this issue on shared hosting account, and wanted to share the workaround solution,
and a potential security concern with this bug.
Shared hosting account (php version 7.0.32), running WordPress blog with a few plugins. error_log
started to fill up 450mb a day with just these errors.
Modifying php.ini was not an option, as there's one for all accounts on that server. Changes to
the code would be overwritten with WP/plugins updates.
The solution that worked was adding "internal_encoding utf-8" to Apache via include config
(has to be done by hosting support rep).
I parsed gigabytes of these lines to see all the "charset" values I got there, and there
were IPs, regexes, some numeric and text values, table names, paths to files from different
accounts(!), etc.. almost all this was from someone else's accounts. I learned of two other
websites that run on the same server just by skimming through these values, and knew the login names
to their accounts from the paths. Makes me wonder how much as a security risk this bug can be on
shared hosting.
------------------------------------------------------------------------
[2018-03-13 11:37:05] php_net at dlk dot pl
Temporary workaround is to put charset into function call:
html_entity_decode($x, null, 'utf-8');
https://pastebin.com/d1Z6631j
Also doing ini_set before doesn't work (ini_set/get broken?):
ini_set('default_charset', 'UTF-8');
$y = html_entity_decode($x);
https://pastebin.com/Dp5Aqw0Q
------------------------------------------------------------------------
[2018-03-13 11:21:31] php_net at dlk dot pl
Happens the same with our cakephp project.
Sometimes it even show phpcode in place of charset.
While ini_get('default_charset') returning UTF-8
With whole project error rate is around 50%.
Hard to prepare small test-case because it doesn't return error or showing less frequently when
i remove stuff.
Sometimes also generating HTTP 500:
php-cgi[14874]: segfault at 28d5588 ip 000000000078db23 sp 00007fff98b4e0e8 error 4 in
php-cgi[400000+bdd000]
Examples when it doesn't segfault:
https://pastebin.com/AqkC7p8D
http://proxy.sec3.itdesk.eu/phpbug/bugtest.html
< saved example output
------------------------------------------------------------------------
[2016-07-08 23:39:30] the_djmaze at hotmail dot com
Found more using https://www.google.nl/search?q="Warning:+htmlspecialchars():+charset"+"not+supported"
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=71876
--
Edit this bug report at https://bugs.php.net/bug.php?id=71876&edit=1