So when NetCraft's report [0] shows 17% of servers out there appear to be vulnerable, that's just for one direction ... internal servers using HTTP in the other direction might not get patched immediately since they're "not vulnerable". Sheesh.
Can wordpress be coaxed into performing outbound requests? Pingbacks and the like? Next-level malicious spam comments forcing WP into heartbleeding outbound, even if the wordpress install itself never had SSL?
As far as I understand, the sloppy ones are the sysadmin behind those sites, not the WordPress installs. And as far as I know, lazy sysadmins don't discriminate regarding what technology they are lazy with.
Software which is easy to set up initially, but hard to upgrade, tends to be much more likely to be out of date than software which is easier to upgrade.
Things that consist of "a big blob of PHP plus a lot of extensions" tend to fall into this camp. PHP apps are generally very easy to get set up the first time, and popular ones like Wordpress have lots of extensions you can add on; but then once you've been running that for a while, you discover that if you upgrade, these n extensions all break, and rather than bothering to find replacements, you just don't bother upgrading.
How do you fix this? Make upgrading easy, don't rely on extensions, or make sure you have bulletproof, stable APIs so that no one worries "if I upgrade, all these things are going to break."
You give a URL that exists on an HTTPS webserver you control that you've patched to send SSL Heartbeats that have a payload size much greater than the real payload.
If the client code (at whatever site you are targeting) is vulnerable then each heartbeat response you get from the client site may give you up to 64KB of its memory contents.
[1] https://github.com/Lekensteyn/pacemaker