Upgrading to 2.4.1 results in &#13; in HTML code

I noticed that after upgrading to 2.4.1 and editing an article suddenly every linebreak has a &#13; so that the code is not XHTML Strict nor Transitional anymore:

Line 109, Column 37: character data is not allowed here
<ul><li>Runs on your phone!</li>&#13;?
You have used character data somewhere it is not permitted to appear. Mistakes that can cause this error include:

•putting text directly in the body of the document without wrapping it in a container element (such as a <p>aragraph</p>), or
•forgetting to quote an attribute value (where characters such as "%" and "/" are common, but cannot appear without surrounding quotes), or
•using XHTML-style self-closing tags (such as <meta ... />) in HTML 4.01 or earlier. To fix, remove the extra slash ('/') character. For more information about the reasons for this, see Empty elements in SGML, HTML, XML, and XHTML.

yep, i've got the same problem mate, updating doesnt have nothing to do with it as i used the new 2.4.1 version. what worse it doesnt validate the website as that character is not allowed there http://validator.w3.org.
interestingly when you edit HTML code as admin in SS CMS, the &#13 character doesnt appear there!

So I've just spent a couple of hours tracking down why this happens (google's not much help because it just interprets &#13; as a carriage return... smart google). I've found what causes it, but not why it happens. In short, when you save any content that is of type HTMLText, it gets examined for link integrity. To help with the messy XML work needed, SilverStripe passes the content into a DOMDocument, does the DOM manipulations needed, then gets the content back out. What's happening though is that carriage return characters (\r) are being converted into their unicode equivalents at some point of the process, coming back as the dreaded &#13;

So why does this happen? As you might know, *nix systems represent their newlines as "\n", whereas windows systems use "\r\n". So DOMDocument processing on your Linux server expects newlines to be "\n" delimited, and converts the trailing "\r" to its entity equivalent. Why it happens on some content areas and not others though is a complete mystery to me at the moment. Content fields in the backend work without a problem, because for whatever reason they return "\n" newline characters, but switching to frontend content fields (eg in the blog module) start sending back "\r\n" characters when posting/editing via the frontend.

Even stranger, I'm actually on a linux system, so in theory I should be always sending "\n" as my newlines; however, in both Firefox and Chrome, it's sending "\r\n". I'm stumped at the moment as to what's introducing the "\r" in there.

Anyway - for the quick fix I've put in place as I continue trying to track down the real problem, you can try adding something like

In sapphire/integration/HTMLValue.php at ~line 48 (the setContent method)