FYI: I'm the person who fixed the padding oracle attack in ESAPI 2.0-rc# crypto which is why I spotted this.
I did a quick code inspection of encrypt() / decrypt() methods in org.apache.myfaces.shared_impl.util.StateUtils as it relates to the fix for
MYFACES-2749. Most everything is done correct (MAC is over IV+ciphertext and checked before decryption), but I noticed a subtle flaw that, at least in theory (or enough data gathering and statistical analysis), that opens a side-channel timing attack that might be still be used as a oracle in a padded oracle attack such as described by Duong and Rizzo.
The problem is in the 'for' loop at lines 471-478 in StateUtils.java. You need to compare ALWAYS compare ALL the bytes in the MAC to ensure a timing side-channel attack cannot be used to as an oracle in the padding oracle attack.
Contact me at email@example.com if you need more info or want to see how it was fixed in OWASP ESAPI.