From examining the p7zip source code, it appears that AES encoding for the 7-zip format operates in CBC mode. This is certainly not necessarily insecure; it’s the mode most popularly used in protocols such as TLS, but it is potentially vulnerable to padding oracle attacks.
While the statement about 7-zip is completely off-topic ;-) I’d still like to correct a misunderstanding here.
You are correct that CBC mode is the foundation for the typical padding oracle attack, it is rarely applicable to file encryption software such as 7-zip or for that matter AxCrypt.
The thing about a padding oracle attack is that you need an oracle. An oracle in this context, is some entity with knowledge that can be questioned. A padding oracle is something we can ask whether or not the padding is correct for a given encrypted message.
For such an oracle to exist, there must be an entity that has knowledge about the decryption key that we can ask whether or not a message is correctly padded.
Such an oracle is typically a server that has the decryption key, and that we can send a message to – and get a response back saying “Invalid padding” or something similar when the padding is incorrect.
For the typical 7-zip or AxCrypt file, no such oracle exists. You just have an encrypted file, and no server or other device you can send a modified file to with the intend of learining whether the padding was correct or not.
So, even if 7-zip and AxCrypt version 1 uses CBC mode, it is a rare situation where a padding oracle attack is possible. You need that oracle.