As a practical example, imagine using encrypted cookies for a session store (like Rails can do), but imagine that they're not authenticated. It's possible that with clever manipulation of the encrypted cookie, I can alter the cookie such that it still decrypts into the structure ecorcyed, but with different data. For example, maybe I change the initialization vector a bit in a clever way and that makes the userId stored in the cookie change.
For a more detailed explanation and hypotherical, I thought [1] was a great article. It uses PHP for the examples, but it's mostly the theory that's of interest.
Of note, things are actually worse in Magento's case than this hypotherical since you can, as an attacker, get Magneto to use some pretty bad crypto when decrypting your message even if they used something decent when encrypting their payload (remember: since it's unauthenticated, what they give you and what you give back are not necessarily the same).
[1] https://paragonie.com/blog/2015/05/using-encryption-and-auth...
When I encrypt something and give it to you, I should take a signature (hash of the encrypted msg) and append it to the encrypted message. Then if you twiddle bits before asking me to decrypt it, I'll see that your provided signature is incorrect.
I know there's more in it, and I've briefly read through the article you provided, which I may look at it in more detail later, but I think that's the gist of it.
[1] https://en.wikipedia.org/wiki/Message_authentication_code [2] https://en.wikipedia.org/wiki/Hash-based_message_authenticat...
I think I'm in a bit over my head looking at the code, but does the author mean that somehow the data should be verified to come from a trusted source first? But doesn't the attacker have to have some of the encrypted data first for that to be meaningful?