Is a padding oracle attack possible if data is only encrypted internally on a server (e.g. for storage)? I read something about the padding oracle attack when analysing the use of an AES-encryption of data in a database and was "scared" it could be a serious issue.
But after investigating a bit further, I now came to the conclusion that in our specific scenario it should be no matter at all. I would like to validate this, because I have the feeling to not fully understand the attack method.

I have got the following scenario:

Clients send plain text messages to an application server (Java). This messages shall be stored in a database, but not as plain text; they have to be encrypted (synchronous encryption with a static encryption key). We use AES-128/CBC/PKCS5Padding, while the encryption is done by the application server, which is the only instance that knows the encryption key.
This means, the server does not offer an external interface, which could be used to send (modified) encrypted data packages. So there should be no chance for an end user / external hacker to do an padding oracle attack.
Or, in other words, there is no instance / server acting as "oracle".

The only attack scenario would be an internal attempt to hack the encryption, let's say a person who has access to the database (e.g. a database administrator with a criminal attitude) and by that to the encrypted messages. But due to the fact the application server does not offer any interface and the attacker does not have access to the encryption key, he should have no opportunity to make an padding oracle attack (?).

Also, an attacker would not discover the encryption key by being successful with an padding oracle attack, he only would decrypt specific messages. So even if the database administrator with access to the database and with an account for the application would change the encrypted data directly in the database to check if decryption still works (the data is displayed in the client / web site = no padding exception), he only could decrypt his own data by doing that, which actually wouldn't be of any use for him.

My question: Do I understand this right or do I miss anything important?
As far as I can tell, you just have encrypted data in a DB and are worrying that it can be hacked. In short, encryption works so you're good.

In more detail, your analysis of a padding oracle attack is correct. As you don't have any services or APIs or network protocols that partake in the encryption, a padding oracle attack can't occur. 

Understanding that I don't fully understand your architecture, I can tell you about the attacks I'd worry about:


There are potential client-side attacks. Perhaps via OS or browser malware. Not your app's fault but can still lead to an exposure of your data.
If you have a malicious admin, they could attack your application directly. They could potentially modify your class files to extract your data while it's in motion. Worse, they can call your decryption functions to bulk decrypt the DB.
Examination of your app's memory to look for secure data or the encryption key.
Examination of your app's configuration to get your decryption key. 
An application vulnerability that allows a remote attacker to extract data from your app or cause it to perform malicious actions. This may be the biggest threat as it allows for remote attacks.


I'm sure there's more but that's my quick evaluation. I think that the breaking the DB encryption is far down the list of things to worry about. Secure your key (preferably in a password-sealed keystore) and secure your app against a remote attack.