Impact
Any baileys session under the latest version (<7.0.0-rc12, and <6.7.22) can be sent a malicious payload via the placeholderResendMessage and trigger a fake messages.upsert event with a fake message key and payload. This allows anyone to spoof messages. The same exploit also allows an attacker to corrupt the app state sync system by sending fake key shares, and also allows for history sync spoofing which also serves the same problem, injecting fake previous context or "on-demand" sync.
Patches
3beb08e This commit has patched the issue, and we have released a version tag under 7.0.0 (6.7.22) for those still on Baileys v6. We have also released a new Baileys version v7.0.0-rc12 to remediate this.
Workarounds
There are no real workarounds other than dropping messages.upsert events that contain a requestId field, turning off automatic history sync (shouldSyncHistoryMessage: () => false) in socket config. There are no workarounds for the app state sync jamming.
Impact
Any baileys session under the latest version (<7.0.0-rc12, and <6.7.22) can be sent a malicious payload via the placeholderResendMessage and trigger a fake
messages.upsertevent with a fake message key and payload. This allows anyone to spoof messages. The same exploit also allows an attacker to corrupt the app state sync system by sending fake key shares, and also allows for history sync spoofing which also serves the same problem, injecting fake previous context or "on-demand" sync.Patches
3beb08e This commit has patched the issue, and we have released a version tag under 7.0.0 (6.7.22) for those still on Baileys v6. We have also released a new Baileys version v7.0.0-rc12 to remediate this.
Workarounds
There are no real workarounds other than dropping
messages.upsertevents that contain arequestIdfield, turning off automatic history sync (shouldSyncHistoryMessage: () => false) in socket config. There are no workarounds for the app state sync jamming.