When the post is saved, the "data:" portion of the src attribute is stripped away by wp_kses_hair() via the line:

if ( in_array(strtolower($attrname), $uris) )

$thisval = wp_kses_bad_protocol($thisval, $allowed_protocols);

"data:" is treated as a protocol prefix, and is not seen as part of the src attribute.

To reproduce this error, try the following in Firefox:

1) Do a Google image search for a rendom image.
2) Right-click -> "Copy Image"
3) Paste into rich text editor
4) Save post
5) View HTML tab of the editor and notice that the "data:" scheme has been removed.

A side effect of this issue is that the image src is treated as a relative image path on the server (in subdirectory "image/png" with long string of characters as the "file name." The server will typically report an error in its log file about the request length of the URI being too long.

In my testing, I encountered an image string that was too large for the regex to handle. I was getting a PREG_BACKTRACK_LIMIT_ERROR from a 26K string. The php documentation states that the ​default value for pcre.backtrack_limit is 100000 (1 million), but the stock installs of php I've tested show it to be 100000 (one-hundred thousand). Raising the backtrack limit via ini_set() allow the code to work on the test string.

I was able to duplicate the original problem. After applying patch 19354.diff​, I was able to embed an image as an unprivileged author that survived saving.