CVE-2026-33143: 
JavaScript vulnerability analysis and mitigation

CVE-2026-33143 is a missing webhook signature verification vulnerability in OneUptime, an open-source monitoring and incident response platform. The WhatsApp POST webhook handler (/notification/whatsapp/webhook) processes incoming status update events without verifying the Meta/WhatsApp X-Hub-Signature-256 HMAC signature, allowing any unauthenticated remote attacker to send forged webhook payloads. Affected versions are all OneUptime releases prior to 10.0.34 (confirmed vulnerable on v10.0.23). The vulnerability was published on March 17, 2026, and assigned a CVSS v3.1 score of 7.5 (High) and a CVSS v4.0 score of 8.7 (High) (GitHub Advisory, OneUptime Advisory).

The root cause is CWE-345 (Insufficient Verification of Data Authenticity): the POST handler in App/FeatureSet/Notification/API/WhatsApp.ts (lines 372–430) accepts and processes any incoming JSON payload that contains "object": "whatsapp_business_account" without checking the X-Hub-Signature-256 HMAC header that Meta/WhatsApp includes on legitimate webhook deliveries. By contrast, the codebase correctly implements HMAC signature verification for Slack webhooks via crypto.timingSafeEqual() in Common/Server/Middleware/SlackAuthorization.ts, and the WhatsApp GET handler validates a verify token — only the POST event handler is unprotected. An attacker requires no credentials, no prior access, and no user interaction; they only need network access to the OneUptime API port (default 8080) to send a crafted HTTP POST request (GitHub Advisory, OneUptime Advisory).

Successful exploitation allows an unauthenticated attacker to forge WhatsApp webhook delivery status events, causing the system to record failed notifications as "delivered" and suppressing escalation retries. This corrupts WhatsApp notification audit logs with false status data, hides delivery failures from administrators, and — critically — can prevent on-call teams from being alerted during active incidents by making failed critical notifications appear successful. There is no confidentiality or availability impact; the primary risk is high-integrity loss to notification and audit systems, with potential operational consequences during incident response (GitHub Advisory, OneUptime Advisory).

A public proof-of-concept exploit is available in the GitHub Security Advisory, consisting of a concrete curl command that demonstrates forging a WhatsApp webhook POST request with a crafted JSON payload — no authentication or signature header required. The server responds with HTTP 200 OK, confirming acceptance of the forged payload. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.025% (3rd percentile), indicating low current exploitation probability. The vulnerability is not listed in the CISA KEV catalog (OneUptime Advisory, GitHub Advisory).

1. Reconnaissance: Identify internet-facing or network-accessible OneUptime instances running versions prior to 10.0.34. Default deployments expose the API on port 8080 (e.g., via docker compose up).
2. Identify the vulnerable endpoint: Target the unauthenticated POST endpoint at /api/notification/whatsapp/webhook on the OneUptime host.
3. Craft a forged webhook payload: Construct a JSON body mimicking a legitimate Meta/WhatsApp Business Account webhook event, including a fake entry array with fabricated WABA ID, phone number ID, message ID (wamid.FAKE), and desired status data.
4. Send the forged request: Submit the payload via HTTP POST without any X-Hub-Signature-256 header:

curl -sv -X POST http://TARGET:8080/api/notification/whatsapp/webhook \
  -H "Content-Type: application/json" \
  -d '{"object": "whatsapp_business_account", "entry": [{"id": "FAKE_WABA_ID", "changes": [{"value": {"messaging_product": "whatsapp", "metadata": {"display_phone_number": "+15550000000", "phone_number_id": "FAKE_PHONE_ID"}, "messages": [{"from": "15551234567", "id": "wamid.FAKE", "timestamp": "1234567890", "text": {"body": "INJECTED_MESSAGE"}, "type": "text"}]}, "field": "messages"}]}]}'

5. Confirm success: The server returns HTTP/1.1 200 OK {}, confirming the forged payload was accepted and processed.
6. Achieve objective: The system updates WhatsApp notification log status records with the forged data, marking failed notifications as delivered and suppressing escalation or retry logic during active incidents (OneUptime Advisory).

• Network: Unexpected HTTP POST requests to /api/notification/whatsapp/webhook originating from IP addresses not associated with Meta/WhatsApp infrastructure (Meta's webhook IPs are documented in their developer documentation); requests lacking the X-Hub-Signature-256 header.
• Logs: OneUptime API access logs showing POST requests to /notification/whatsapp/webhook returning HTTP 200 from unknown or untrusted source IPs; WhatsApp notification log entries showing status changes to "delivered" for messages that were not actually sent or confirmed by Meta.
• Application Data: WhatsApp notification records in the database showing delivery status updates with message IDs matching patterns like wamid.FAKE or other non-standard formats; log entries with phone number IDs or WABA IDs not matching the configured WhatsApp Business Account.
• Behavioral: Absence of expected escalation or retry events for on-call notifications during incidents; discrepancies between WhatsApp Business Manager delivery reports and OneUptime's internal notification logs (OneUptime Advisory).

Upgrade OneUptime to version 10.0.34 or later, which introduces proper X-Hub-Signature-256 HMAC signature verification for the WhatsApp POST webhook handler. As an interim workaround, restrict network access to the /api/notification/whatsapp/webhook endpoint using a reverse proxy, firewall rules, or IP allowlisting to permit only Meta/WhatsApp's known webhook source IP ranges. Additionally, monitor notification logs for anomalous delivery status changes and implement alerting for unexpected status updates. After patching, review historical WhatsApp notification logs to identify any forged statuses that may have suppressed escalations during the exposure window (GitHub Advisory, OneUptime Advisory).

The vulnerability was reported by security researcher n0rv-TvT and published by OneUptime maintainer simlarsen on March 17, 2026. Brief community discussion was noted on Bluesky and Mastodon, with the vulnerability being picked up by automated CVE tracking feeds. No major media coverage or significant vendor statements beyond the GitHub Security Advisory have been identified (OneUptime Advisory).