This seems to have been mostly fixed with the recent global re-rendering of most posts to CommonMark. All posts that were re-rendered as a result of the migration no longer exhibit this bug.
In the case of the one example I linked in the comments, the non-HTTPS image was previously showing in the revision history, but now it's only showing up as a link. Also, the query linked by Ilmari Karonen returns no results for most sites (as that checks the rendered HTML for a non-HTTPS image embed).
However, as the CommonMark migration post says, a small percentage of posts were not re-rendered, as they used potentially unsupported markup that could not be automatically edited out. This subset of posts is still affected by this bug. After some searching, I found an example.
In summary, this bug has been fixed in the rendering engine, as it no longer renders insecure images when it was updated to the CommonMark specification. However, the posts that weren't re-rendered with the updated renderer can still serve non-HTTPS images.
Update: After querying this across all network sites (except Stack Overflow due to its size), it seems the scope of this bug is a bit bigger than what I had thought before. It looks like the re-bake of non-HTTPS images into plain links never took place on per-site metas, and so there are a lot of per-site meta posts that serve non-HTTPS images. Those posts all use standard Markdown markup for images, so it's not the same (rare) issue encountered on main Q&A sites where there was a capital <IMG
tag.
(Note: if you run the query above, only search for one year at a time - longer periods may make it time out.)
<IMG
and the replace wasn't case-insensitive or something.<IMG>
tags.<IMG
tags.