I think Heartbleed is close enough to memory safety to count. It was caused by memory allocator returning uninitialized memory and every memory safe language I know about does not allow this in best-practice code.

(And sure, there are escape hatches - like Python has "recv_into" that could be used to implement heartbleed if you are really inclined to - but this would not be a realistic python program. In python, even with buffer reuse, you'd be using memoryview or similar that can't have a heartbleed problem)

Heartbleed was a buffer overread. Sounds like a memory safety bug... is it not?

The vast majority of web services are not written in memory unsafe languages so this is not surprising.

One of the exceptions (with regards to web facing attack surface in a memory unsafe language) is that people still use OpenSSL, which has a terrible history of memory unsafety, including the cited heartbleed.

Serverside memory corruption is annoying to get working. As a dominant metagame strategy for attackers, it's much more impactful on the clientside.

(I'm not cosigning the analysis in this blog post. I think "I haven't seen a PoC I could get working" is not the evidence this author seems to think it is.)

Huh? Heartbleed is literaly memory safety (buffer over read)