Here's how, normally:

1) You take the commit referenced, like this: https://github.com/rails/rails/commit/f980289fd2c1b9073a94b5...

2) Right below the title, GitHub shows you which branches the commit is in. As you can see with that commit (the one that caused the problem), it's only in 3-2-stable. Therefore, not being in master, it wasn't ever in Rails 4, only in Rails 3.2.

Since this was a security issue, it's possible that the commit was different for Rails 4. So we load up the page for the referenced CVE (cve-2013-1854): http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1854

That page links to the announcement email: https://groups.google.com/group/ruby-security-ann/msg/34e0d7...

The announcement email discusses which versions were affected:

> Versions Affected: 3.2.x, 3.1.x, 2.3.x

But, since Rails 4 wasn't yet released, it wouldn't be there.

To be 100% sure, you can grab a copy of the source, and grep the git log for the CVE number. That brings up this commit: https://github.com/rails/rails/commit/2392535f4085d88186097e...

This commit is in master and v4.0.0rc1, as GitHub shows.

I am not mega super updated on the status of this issue, as I'm not on the security team, but given that it's still open and marked as 'regression,' I would not be sure that this was fixed.

That said, this particular bug is a complex interaction between components, and people haven't mentioned if it affects master or not. Therefore it's possible that even though the fix didn't make it into 3-2-stable yet, it may not have affected master.

So, at the end of all that, I guess the answer is "I'm not 100% sure, I'd ping tenderlove," but I hope that helps you identify which commits have made it into which releases in the future.

Thanks Steven! I'll look into it. And thanks for all the great work you've been putting on Rails.

<3