2. Bootstrap MITM vulnerability (RFC section 14.6)
3. NTP attacks (RFC section 14.7) [1]
4. Send RSTs on all HTTPS traffic. Eventually the user will get fed up with the website not working and try plain HTTP on a different browser/client which doesn't have the HSTS policy cached.
4.1. After the new client connects, force some kind of error or warning on the connection, but still allow it to continue, and use SSL stripping for any initial plaintext connections. HSTS will not be set if any warnings or errors are found on the connection. (RFC section 14.3)
5. Phishing: Send non-secure URLs to your target with instructions that if the connection fails, try the same non-secure link on a different browser. (It may be easier to just register a fake-but-similar-sounding domain and give it a valid cert, and send links to that)
5.1. Phishing with a non-secure root domain cert (RFC section 14.8)
6. Develop a method to determine when a client's policy will expire - or just wait - and wait to attack the moment of the next request, which will [potentially] be in plain HTTP.
7. Invalid configuration, such as forgetting to include the 'includeSubDomains' flag.
8. Internationalized domain names (RFC section 14.10)
Pre-loaded HSTS lists are affected with some of the above attacks, and public-key lists are affected eventually because eventually you need to rotate a key.
[1] https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-By...
--
These are just the ten identified attacks so far, and they all stem from the design itself, which allows MITM on first connection or policy expiration. If your whole security feature is designed to allow MITM even once, it is guaranteed to happen at least once. This is why it's a well-intentioned bad hack.
The solution was - and still is - to design a protocol which will never allow insecure connections. This could be accomplished by forking SPDY or HTTP2.0 and naming the new protocol "SECURE", and passing out URLs like 'secure://google.com/'. This way it would be totally obvious to both the user and the browser that the connection should only ever be made using at least a valid signed cert, and HSTS would never be needed (but public-key pinning would still be needed). Mandatory DNS-based security would improve this further.
This almost happened with HTTP/2, but nobody proposed the new protocol name. Terrible missed opportunity.