Oh my goodness a anti PHP comment in a Facebook thread. Who would have guessed?

Facebook has some of the best engineers in the world. They also have their own modified version of PHP.

And really it doesn't what they use, they could use Lua and still have this issue. Don't think just because ebay used C++ or cgi or what ever they used doesn't mean ebay didn't ever have issues. Same goes for every other site/language out there.

The PHP hate is getting a little old.

Please don't get confused, there are foolish people utilizing every programming language all the time. PHP may be disproportionately more popular than other programming languages but it hardly deserves the blame.

Blaming technology is the worst. From the nature of the bug I think it was just some if missing somewhere.

I'm sorry, but did you even read the article? The exploit is explicitly stated, it's trusting unauthenticated client state. That's a fundamental design flaw in the intended behaviour, not an accidental coding error. They gave the profile ID to reset to the client when serving the page, and then blindly used whatever profile ID the client sent when submitting the form. The fix was to fetch the profile ID for the authenticated user instead of sending a profile ID on a round-trip through the client.

I certainly agree that the problem wasn't the technology here, but I disagree with your conclusion. "some if missing somewhere" is far easier to avoid technologically than a high-level design flaw like this. It's fairly easy for a type system to notice that not all cases in a conditional are accounted for, but it's much harder for a type system to understand that it's inappropriate to use client-submitted data as a profile ID for a password reset request (as opposed to operations like submitting a friend request, where it's perfectly valid).

what should they use instead?