The blog post is written in conversational English. It is not meant to be a technical, formal paper about their protocol. If you're going to get hung up on that, that's entirely your problem, not mine.
Yes, their fucking thing is vulnerable, because of how PHP + ext/openssl handles padding errors by default. They can mitigate this behavior by suppressing error reporting, but the underlying behavior will still be observable later in the application when `false` is provided instead of a string.
To trigger the vulnerability, you would need the ability to modify a ciphertext. This requires privileged access to where the encrypted data is stored.
Exploit procedure:
1. Modify ciphertext
2. Access PHP script that processes said ciphertext under-the-hood
3. Did it spit out a PHP error?
* Yes -> Invalid padding
* No -> Valid padding
Am I going to laboriously describe one of the most well-tested padding oracle exploit paths in the web programming ecosystem in an informal blog post whose purpose is to describe coding/design flaws? No, because that's a waste of everyone's time.
I don't generally write articles with the premise that my audience needs every logical conclusion spoon-fed to them.
> I note that you have not explicitly stated that the system is susceptible to a padding oracle attack either. That's because you have read the same article and can not.
I wrote it, actually.