For a bit of extra context on the follow-up note in the PR body:

While working on this fix, I noticed a few other channel adapters that may be worth checking for similar audioAsVoice consumption gaps in their outbound paths. I deliberately kept this PR scoped to WhatsApp so it stays easy to review and resolves #66053 cleanly.

Happy to prepare a separate follow-up PR for the cross-channel side if maintainers think that would be useful — otherwise I'll leave the observation here for the record.

Greptile Summary

This PR fixes the WhatsApp adapter to correctly route audio replies flagged with audioAsVoice=true to the PTT (push-to-talk) voice-note path instead of the document-attachment path. The fix is applied consistently across send.ts, outbound-base.ts, outbound-adapter.ts, and auto-reply/deliver-reply.ts, with a follow-up commit (566b640) also guarding the media.kind === "audio" branch against being overwritten when forceVoiceDelivery is active — directly addressing the concern raised in the previous review thread.

Confidence Score: 5/5

Safe to merge — all previously flagged P1 issues have been addressed and the remaining changes are well-tested.

The previously flagged bug (audio-kind branch overwriting forceVoiceDelivery) is fixed in the latest commit with the !forceVoiceDelivery guard on line 133 of send.ts. The mimetype normalization logic is consistent across all four touched files. No new logic paths are left unguarded, and no remaining P1 or P0 findings exist.

No files require special attention.

_{Reviews (2): Last reviewed commit: "fix(whatsapp): guard audio-kind branch a..." | Re-trigger Greptile}

Thanks @greptile-apps for the catch. Addressed in the latest commit:

• send.ts — moved the media.kind === "audio" branch into the else if chain guarded by !forceVoiceDelivery, matching the pattern used by the video/image/document branches. The forceVoiceDelivery block now correctly owns the audio-routing decision when the flag is set.
• send.test.ts — added a regression test for the audioAsVoice=true + kind="audio" + contentType=null path, asserting the resulting mimetype is audio/ogg; codecs=opus.

Verification:

• pnpm test extensions/whatsapp/src → 57 files / 484 tests pass
• codex review --base origin/main reports no P1 or P2 findings on the latest state
• The new test fails against the pre-fix code as expected

@codex review

All security findings raised by the analysis bots on this PR have been addressed or scoped to follow-ups as discussed above. The PR is ready for human review when convenient.

Two items intentionally left for separate follow-ups:

• magic-byte verification in isVerifiedAudioSource (needs loadWebMedia refactoring and changes the [[audio_as_voice]] trust model)
• fileName sanitization in inbound/send-api.ts (best fixed alongside the upstream parseContentDispositionFileName sanitizer)

Happy to split either of those into their own PRs if maintainers want them tracked separately.

Codex Review: Didn't find any major issues. Swish!

🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

export function isVerifiedAudioSource(media: {
  kind?: string | null;
  contentType?: string | null;
}): boolean {
  return media.kind === "audio";
}

export function isVerifiedAudioSource(media: {
  kind?: string | null;
  sniffedMime?: string | null;
}): boolean {
  return media.kind === "audio" && Boolean(media.sniffedMime?.startsWith("audio/"));
}

return media.kind === "audio" && media.sniffedMime === "audio/ogg";

Analyzed PR: #68744 at commit 6abf1f4

_{Last updated on: 2026-04-25T00:08:29Z}

Second rebase and security review update (2026-04-24):

Rebase

Rebased onto the latest main after #69813 (canonicalize outbound media
delivery) landed. The media normalization that previously lived inline in
sendMessageWhatsApp / deliverWebReply is now delegated to
normalizeWhatsAppLoadedMedia in outbound-media-contract.ts. This PR's
audioAsVoice routing and security-hardening helpers sit on top of that
canonical layer:

• sendMessageWhatsApp: keeps the audioAsVoice option; forceVoiceDelivery
  is gated on isVerifiedAudioSource({ kind, contentType: media.mimetype })
  after normalization; PTT mimetype uses the opus fallback with
  sanitizeMediaMime(..., { preserveCodecsParam: true }).
• outbound-base.ts (createWhatsAppOutboundBase): propagates audioAsVoice
  through sendMedia. The refactored outbound-adapter.ts consumes this
  factory directly, so the earlier per-adapter wiring is removed.
• deliver-reply.ts: audio and audioAsVoice-verified paths route to PTT with
  sanitized opus mimetype; image/video/document branches apply sanitized
  allowlisted mimetypes; document fileName is sanitized.

Tests: pnpm test extensions/whatsapp → 567 / 0; pnpm tsgo:prod → green.

Aisle response

1. Incomplete Unicode invisible character stripping in sanitizeFileName —
   addressed in the latest commit. sanitizeFileName now strips every
   Unicode General Category Cf character via /\p{Cf}/gu, covering the
   previously-missed ZWSP (U+200B), ZWJ (U+200D), BOM (U+FEFF), and Soft
   Hyphen (U+00AD, itself Cf) as well as the bidi marks already handled.
   Regression tests added in src/media/mime.test.ts.
2. Voice-note sending can be coerced by trusting file extension/headers —
   left as a follow-up, consistent with the earlier comment on this thread.
   Reasoning: this is not WhatsApp-specific. The upstream auto-reply paths
   that land ptt: true based on media.kind === "audio" have the same
   trust boundary (kind is derived from detectMime, which falls back to
   URL/path extension and HTTP Content-Type). Fixing it well means
   plumbing a sniffedContentType/sniffedIsAudio through loadWebMedia
   and having Telegram (resolveTelegramVoiceSend), Discord
   (sendVoiceMessageDiscord), Matrix, and WhatsApp all adopt the verified
   source together. Happy to open a separate PR for that refactor if
   maintainers agree — otherwise flagged here for the record.

Cross-channel note (reiterated)

The shared helpers introduced here — isVerifiedAudioSource,
sanitizeMediaMime, sanitizeFileName in src/media/mime.ts — use a
channel-agnostic signature ({ kind, contentType }) so Telegram, Discord,
and Matrix can adopt them in a follow-up for consistent voice-note
hardening across channels.

Aisle CWE-345 follow-up (2026-04-24):

The Medium finding flagged in the latest scan
("Content-type spoofing allows non-audio payloads to be sent as WhatsApp
voice notes (PTT)") is addressed in the latest commit.

isVerifiedAudioSource now requires a caller-classified kind === "audio".
The contentType parameter is retained on the signature so future work can
extend the helper with a sniffedMime argument once magic-byte sniffing is
plumbed through loadWebMedia / detectMime — but it is no longer consulted
on its own. This closes the header-spoofing path Aisle identified: an
attacker-controlled Content-Type: audio/... response no longer bypasses
the kind classifier.

Tests updated in src/media/mime.test.ts:

• Flip the previously-accepted { kind: "document", contentType: "audio/ogg" }
  case expectation to false.
• Add a dedicated CWE-345 regression test.

Verification:

• pnpm test src/media/mime.test.ts → 107 passed / 0 failed
• pnpm test extensions/whatsapp → 567 passed / 0 failed
• pnpm tsgo:prod → exit 0

The broader "plumb sniffed content type through loadWebMedia and have
Telegram/Discord/Matrix all adopt a verified source" refactor remains a
follow-up PR as discussed earlier in this thread — the current change is the
in-scope defensive tightening Aisle's example implementation suggested.

Thanks @masatohoshino. I landed a narrower mainline fix for the issue in c2a2a481b2

What landed:

• sendTextMediaPayload now preserves payload.audioAsVoice when it fans out media sends.
• The WhatsApp outbound adapter forwards audioAsVoice through sendMedia to sendMessageWhatsApp.
• WhatsApp docs and changelog now document that reply payloads preserve audioAsVoice; WhatsApp audio media continues to go out as Baileys PTT voice notes.

I intentionally did not land the broader MIME/filename helper bundle from this PR in this pass. The current root bug was the dropped shared payload flag, and the existing WhatsApp send path already maps audio MIME payloads to Baileys { audio, ptt: true }. New public SDK helper surface and cross-channel MIME hardening should be split/reviewed separately.

Dependency contract checked locally: installed Baileys types expose AnyMediaMessageContent audio payloads with ptt?: boolean, and createWebSendApi already sends audio as ptt: true.

Verification:

• pnpm test src/plugin-sdk/reply-payload.test.ts extensions/whatsapp/src/outbound-adapter.sendpayload.test.ts extensions/whatsapp/src/outbound-base.test.ts extensions/whatsapp/src/send.test.ts extensions/whatsapp/src/auto-reply/deliver-reply.test.ts extensions/whatsapp/src/inbound/send-api.test.ts
• pnpm format:check -- CHANGELOG.md docs/channels/whatsapp.md src/plugin-sdk/reply-payload.ts src/plugin-sdk/reply-payload.test.ts extensions/whatsapp/src/outbound-base.ts extensions/whatsapp/src/outbound-base.test.ts extensions/whatsapp/src/outbound-adapter.sendpayload.test.ts extensions/whatsapp/src/send.ts
• pnpm docs:list
• git diff --check
• pnpm check:changed passed, including core/extension typecheck, lint, import-cycle guards, changed tests, and full extension test shards.

Closing this PR as superseded by the landed main commit.