There appears to be a denial of components of this from senior AWS figures, not a blanket denial but I think some of the statements could be a potential overreach.
Wholeheartedly endorse. I just wish AWS would every once in a while get ahead of the messaging on stuff like this. They knew it was coming, there's a principal engineer quote in the blog post, but right now there isn't any official statement past "tweets."
It's just speculation as to how this went down, but having been in this position before it's usually not an easy thing to handle. If there's a dispute about impact a responsible researcher will usually say "I still plan on publishing this information on X date". This gives the company time to both convince the researcher the impact isn't as severe as they think and also to prepare a public response for that date.
An irresponsible researcher will either say "I'm gonna publish because I think it's high impact" and not give a date (and then often publishing with no notice on a Friday afternoon) or won't even provide notice.
It's often impossible to know which type of actor you're dealing with until it's too late. I've even had people claim they won't publish until X date and then publish early. You can't just provide public notice or you'll both piss off the researcher and run the risk of accidentally giving the impression a low impact bug is actually high impact.
Wait, so they managed to make AWS trigger a request on their own bucket using AWS internal credentials, and they extrapolate that this means they now have access to $everything ?
That definitely sounds plausible. AWS services undergo mandatory security reviews and threat modelling that usually cover these scenarios exhaustively. A lot of work and complexity goes into scoping down credentials for defense-in-depth protection, to protect against exactly these kinds of issues.