Hi Michael, I think I know how to solve the problem. I tested out using HTML::Entities::encode_entities in a very simple Perl program and found I got the same type of entity encoding as in the WUI CGI pages. However, if I treated the string of characters as utf8 then the HTML::Entities::encode_entities gave the results expected. So I need to figure out how to treat the remark strings as utf8 and hopefully that should fix the problem. At least I have a view of a path forward on this issue now, that will keep the protection of the cleanhtml command while also allowing characters with diacritical marks, plus special characters such as the Cyrillic alphabet and also things like the german eszet that currently all get mangled. Will let you know how I get on. Additionally I will also later on create patches for the WUI CGI pages for the Firewall Groups and for WIO as they do not use the cleanhtml command at all yet they also have many Remark entries. I will also check out the other WUI pages that don't use the cleanhtml command to see if they have remarks etc that should use it. Regards, Adolf. On 06/03/2024 23:23, Adolf Belka wrote: > Hi Michael, > > On 06/03/2024 22:28, Michael Tremer wrote: >> Hello Adolf, >> >> I believe that I cannot merge these patches. > Then you need to also look back at the dns.cgi patch for the bug fix > due to german umlauts being changed. The acceptance of that patch is > what made me create these patches as they all had the same problem > with remarks as well. If this can't be accepted as is then that patch > needs to be reverted. > > https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=7c6ff5ff12331a53f416080a44c8d6145e78bfac > >> >> The reason simply is that it would create a store cross-site >> scripting attack vector because someone could store some