Alright you win. I'm curious to know which one it was after it's fixed!
I really didn't expect this to exist...
That's the part I don't get. Once the code dies it's done. What exactly can you do now, if no code is even running?
1. Parse user.
2. Parse password.
3. Create session object from user and password.
4. Parse JSON. (Crashes here.)
5. Update session and do some other security stuff.
The problem is that they're creating a persistent session object ahead of when the JSON parameters are being decoded, which leaves a (partially initialized, persisting-outside-of-function) session object without having gone through the full authentication flow.
The problem is that they're creating permanent objects ahead of a full validation on the data necessary to actually properly initialize the object.
(I think the OP may have been a little vague because that's probably specific enough to identify the vuln with a scanner and a hunch.)
I don't do PHP. It just sounds incredible to me that so little isolation seems to exist.
I look forward to the disclosure to understand more about this - and check that the frameworks I use don't have this problem.
The scenario is typically username-password-parameters passed as three variables via POST. The offending developer parses all three variables up front for simplicity:
The session user is created from the POST username, the POST password is input sanitized and put in a variable, then the parameters are parsed as JSON. The attacker POSTs a valid user, a valid (but incorrect) password, and malformed JSON.
The login code reads the variables from POST, opens the session, and dies on the JSON decode.
Hint: this bug exists in the wild on a massively deployed framework. I'm working up a responsible disclosure on that one now.