Here's a real-world example: A captcha service behaves as follows. First, it generates a distorted image of some known text $t$. It sends then image to a web browser, and waits for a response. It compares the response to $t$ to decide whether the captcha is successful.
In a stateful solution, the captcha service itself would have to store $t$ while the web browser would keep some sort of identifier. This leads to all sorts of bookkeeping by the captcha service.
A better approach is to make the captcha service stateless. To do this, you must store the correct solution $t$ to the captcha puzzle in the web browser client! Obviously this solution should be encrypted. The idea is to give the client an image and a ciphertext that encrypts the solution (under a key known only to the captcha service). The client presents the claimed solution along with the ciphertext, and the service just needs to decrypt in order to verify.
But nothing prevents the client from presenting some other ciphertext! This fact (along with poor choice of unauthenticated encryption and error messages leaking padding validity) has led to padding oracle attacks against captcha services. With a standard padding oracle attack you can actually systematically decrypt ciphertexts, hence obtain the captcha solution. Here is a video (loud annoying music) demonstrating a proof-of-concept on a real captcha service.