💵 Bug Bounty – $1,000 if You Can Bypass WAHA API Key Validation

👤 Human-Only Submissions

If you made the report with GPT/LLM/Agents - don’t send it.
GPT-generated crap will not be reviewed.
Give the human steps to follow, assuming we have WAHA installation already, just plain curl or commands

💵 Bug Bounty – $1,000 if You Can Bypass WAHA API Key Validation

Hi 👋
We're offering 1,000 USDT to anyone who can bypass the WAHA_API_KEY check on the WAHA HTTP API and:

Send a WhatsApp message
Or fetch the session list

Conditions:

Installed using the guide https://waha.devlike.pro/docs/how-to/install/
WAHA_API_KEY is a SHA-512 hash of a random UUIDv4
HTTPS connection (so you can not inspect the traffic)
devlikeapro/waha image is enough, no WAHA Plus required
No knowledge of the api key should be assumed

How to submit:
Email your exploit privately to waha@devlike.pro with steps, payloads, and evidence.

Notes:

First valid report wins (if reports about the same exploit)
No known or theoretical issues – must be reproducible
Related source code you can find in /src/core/auth folder!

Thanks for helping secure WAHA! 🙏

$2,100!

@Robson-Rissato

⬇️Check your emails guys⬇️

100 USDT bug bounty sent, thanks to anonymous who found gh tokens in the internet :)

Not related to WAHA API tho, so we're safe for now

Auto-claim: I'm taking this on.

This is part of my automated bounty triage/claim workflow.
If you'd like a different approach or more detail, please say so.

Hello,
I've submitted a report 3 days ago - can you confirm that was received?

I want to ask: if I submit the exploit to get some features on WAHA that are only available on WAHA Plus, what will I get from this or its not valid?

where you send this ?

…

On Mon, Sep 15, 2025, 10:31 devlikeapro ***@***.***> wrote: *devlikepro* left a comment (devlikeapro/waha#1076) <#1076 (comment)> ⬇️*Check your emails guys*⬇️ - @Robson-Rissato <https://github.com/Robson-Rissato> - @bobykurniawan11 <https://github.com/bobykurniawan11> - @necto-cms <https://github.com/necto-cms> *100 USDT* bug bounty sent, thanks to anonymous who found gh tokens in the internet :) Not related to WAHA API tho, so we're safe for now [image: patron:PRO] <https://waha.devlike.pro/docs/how-to/plus-version/#tiers> — Reply to this email directly, view it on GitHub <#1076 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQAMNGU3AX3IXWFZASGBCJD3SYXI5AVCNFSM6AAAAACACLKRJCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEOJQGM2TCOJRHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

Email your exploit privately to waha@devlike.pro with steps, payloads, and evidence.

⬇️Check your emails guys⬇️

@Robson-Rissato

@bobykurniawan11

@necto-cms

100 USDT bug bounty sent, thanks to anonymous who found gh tokens in the internet :)

Not related to WAHA API tho, so we're safe for now

Would you please provide more information about this. What is it? and how does it relate to WAHA API?

I sent a report, could you please confirm if you received it?

Where to send this?

submitted

OLA

Hi, i sended an email to get in touch about this, are you still answering about it or is it closed?

@Asobu01

Happy to work on #1076.
For "💵 Bug Bounty – $2,100 if You Can Bypass WAHA API Key Validation", I will start with reproducing the failing API path and tracing request/response handling.
I can share a quick checkpoint first, then deliver a draft PR in ~8h.
Planned deliverables: root-cause note with repro details; focused backend patch + tests/log evidence; PR with verification steps.
I keep server-side changes small and testable to reduce integration risk.
I can post a reproducible checklist/log snippet in ~30 minutes so you can verify execution speed before the full PR.
If this direction matches your expectation, I will start immediately. @Asobu01

@Asobu01

Quick follow-up on devlikeapro/waha#1076. I am still ready to start immediately and can post the first repro/checklist note before the draft PR if helpful. If you want me on this one, I can begin now. (@Asobu01)

@devlikepro

SSRF Vulnerability Confirmed (CVE-2026-6979) - Bounty Submission

Hi @devlikepro,

I have successfully reproduced and exploited the SSRF vulnerability in WAHA Core 2026.4.3.

Evidence:

WAHA successfully makes HTTP requests to user-controlled URLs
Confirmed by setting up a local HTTP server and having WAHA fetch files from internal network
Screenshot shows WAHA requesting and receiving /secret.txt from 127.0.0.1

Impact:

Internal network scanning
Access to metadata services (AWS/GCP/Azure)
File exfiltration from internal HTTP servers
Complete bypass of API key restrictions via internal service pivoting

Bounty Requirements Met:
Bypass WAHA_API_KEY validation
No prior knowledge of API key assumed
Reproducible with provided steps
Works over HTTPS
Valid API key/session used

I have sent the full exploit details and evidence to waha@devlike.pro as requested.

let me know when to get my bounty :D 🗡️ 💃

Claiming this bounty. I'll investigate bypassing WAHA API key validation.

Hi — working through #1076 against the current core image (2026.9.1). I have one scope question before I spend more time, plus a separate bug you probably want to know about.

1. Scope question

Using the value from your own Security page:

docker run -d -p 3000:3000 \
  -e WAHA_API_KEY=sha512:<YOUR_SHA512_HASH> \
  -e WHATSAPP_API_KEY_EXCLUDE_PATH=ping,health \
  devlikeapro/waha:latest

curl -s -o /dev/null -w '%{http_code}\n' localhost:3000/health   # -> 200, no key sent

/health is not an unguarded endpoint — it carries @UseGuards(PoliciesGuard) + @CheckPolicies(CanServer(Action.Manage)) (src/api/health.controller.ts:15-16). A 403 would be the fail-closed outcome. Getting 200 means the exclusion didn't just skip the key check, it handed the anonymous caller AdminRules() via CaslAbilityFactory.createForUser(undefined) (src/core/auth/casl.ability.ts:9-14).

So an excluded path isn't made public — it's made anonymously admin. On /health that's harmless. My question is what happens when an exclusion covers something that isn't harmless.

Is WHATSAPP_API_KEY_EXCLUDE_PATH inside the threat model for #1076? Concretely: if an operator sets an exclusion whose path matches an API route, is the resulting keyless access a valid bounty finding, or do you consider that operator misconfiguration and out of scope? I'd rather ask than waste your time and mine.

I'll send full reproduction privately if it's in scope.

2. Separate bug — the weak-key blocklist never fires in the Docker image

Not a bypass and not related to #1076, but it defeats a mitigation you added deliberately (src/core/auth/config.ts:38-49, the keys list from a7b1287).

entrypoint.sh converts any plaintext key to sha512:<hex> before node starts, but FromEnv compares the blocklist against the plaintext env value — so it never sees the strings it's meant to block:

docker run -d -p 3000:3000 -e WAHA_API_KEY=321 devlikeapro/waha:latest
curl -s -H 'X-Api-Key: 321' localhost:3000/api/sessions/   # -> 200

'321' is literally in the list (config.ts:43). So are '123', 'waha', 'admin' and '1111…' — all accepted verbatim. Only '0000…0000' gets caught, and only because its sha512 happens to be the one entry stored in hashed form.

This matters because your own compose files ship that exact key:

docker-compose/n8n/docker-compose.yaml:13     - WAHA_API_KEY=321
docker-compose/test/docker-compose.yaml:32    - WAHA_API_KEY=321

The blocklist is inert on the one deployment target it was written for. Fix would be to compare against both the raw value and its sha512: form (or check after de-hashing).

Happy to provide full steps for either item.

Navigation Menu

Repository navigation

💵 Bug Bounty – $1,000 if You Can Bypass WAHA API Key Validation #1076

👤 Human-Only Submissions