Take a look at BIP0016.

This new transaction type is redeemed by a standard scriptSig:

...signatures... {serialized script}

And...

{serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey.

In this case, {serialized script} is {m [pubkey1] [pubkey2] ... [pubkeyn] n OP_CHECKMULTISIG} for a m-of-n transaction. When Bitcoin detects one of these special transactions, the serialized script is popped of the stack as soon as its hash is validated (you're validating the script hash! not an actual public key!) and then executed with the remaining stack intact.

Your payment script looks like this:

0 /* null element because a bug pops one-too-many items */
304402205fdee0b00f5e2fa07324458fe06b47a41bb2ef4e73892343796e9f6456e378940220630b423ce14b0d5ed487da751c368d7fc0122efa21cac1a4afce7c3c017bf29f01 
304502205edb6ce77a772346b21d60a775c81f52bec9e8957f795fce7ea4fab862bc656c022100fc1376399134348fae516d6e627b1f72c094affd3ba2f458685bdbe9b6a51f5e01 
5221020678adff50855b6748e93ab03667968817363fff84306d7ffc13276191fd7f542102bff39dce7ae4c6a06104ac4e49948eb7bac9d4a82e9e16df41b1436d31b76f0052ae

The last part (5221020678...52ae) is actually your serialized script. If you decode it you get:

2 020678adff50855b6748e93ab03667968817363fff84306d7ffc13276191fd7f54 02bff39dce7ae4c6a06104ac4e49948eb7bac9d4a82e9e16df41b1436d31b76f00 2 OP_CHECKMULTISIG

Which is a 2-of-2 transaction!

The first two parts not including the null element (the ones that look like 304...01) are just your provided signatures which are going to validate against the serialized public keys when OP_CHECKMULTISIG is executed.