Why Message Queues Keep Failing Their Penetration Test

Somehow, in every system that goes through a penetration test and uses message queues, there are security holes. It is as though people never think about security in queues. I do not understand why.

In one system I looked at, every microservice was given credentials to publish and subscribe on the same channel - no ACL restrictions, no topic filtering. An attacker who managed to get onto a single VM, even with very basic privileges, was able to send forged messages and bypass all of the business logic that had been built at the front.

And sometimes it is even accepted from the client side. You see that mostly in IoT systems, where a device connects to a particular channel and sends its messages.

An example. A billing service was listening on a queue called billing_events. The attack:

{
 "event": "issue_refund",
 "userId": "12345",
 "amount": 100000
}

The billing microservice did not check the source of the message, only its structure. The moment I dispatched a message, a refund was carried out - without any authorization.

How do you fix it?

• Separate credentials for every service, with a specific ACL - publish/subscribe on particular channels only.
• Verify the structure and the source of every message. Do not rely on the content alone.
• An audit log for every meaningful message.
• Use message signing and a nonce - double protection.
• Insist on hardening, at the firewall and IAM level as well, not only in the queue itself.

Penetration testers: ask to test internal communication. Try sending messages from servers that are not supposed to send them. Developers: check for yourselves that every message injected into the system goes through a full authentication path, not just basic validation.

I first shared a version of this as a LinkedIn post on 2025-09-01. It is republished here, lightly edited, so it is easier to find and reference. — Erez Metula