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

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.