The mentioned commit was a security fix.

@SniperSister So it’s expected behavior, right?

Indeed, that’s expected behavior

instead of a pure escape can we not use htmlenties then we are still secure but dont lose functionality

Here the link to the security issue: https://developer.joomla.org/security-centre/1035-20260503-core-xss-in-com-contenthistory

The underlying issue is:

• the version history output is a generic one; it has an attribute name ("title"), an old and a new value ; everything is handled the same way
• the actual component using the version history knows the context of these attributes and therefore can decide if a raw output (allowing HTML) is safe to use or if escaping is required
• that different handling is the key vector to exploit the vulnerabiliy: a field, that's escaped and therefore safe to use in a component becomes a stored XSS in content history

Closing as expected behaviour

Closing as expected behaviour

The documentation has to be updated : https://guide.joomla.org/user-manual/articles/articles-article-versions
Just to show that users won't be able to understand introtext and full text anymore.

For information, compare versions gives the same kind of result :

For information, compare versions gives the same kind of result :

Is it really what you expected ?