CVE-2026-33143: OneUptime Webhook Signature Verification

CVE-2026-33143 is a missing-signature-verification vulnerability in OneUptime's WhatsApp webhook handler. The issue is specific to affected OneUptime releases; it is not evidence that every webhook implementation is vulnerable.

The practical lesson is broader but still bounded: a webhook endpoint is an unauthenticated internet endpoint until it validates the authentication mechanism defined by its provider. Parsing a plausible JSON body, receiving it over HTTPS, or recognizing an event type does not establish who sent it.

What the advisory establishes

OneUptime's security advisory says the POST /notification/whatsapp/webhook handler processed WhatsApp status events without checking Meta's X-Hub-Signature-256 HMAC signature. An unauthenticated sender could therefore submit forged events that changed notification-delivery status records, suppressed alerts, or corrupted audit trails.

The advisory lists OneUptime 10.0.23 as affected and 10.0.34 as patched. NVD's CVE record describes releases before 10.0.34 as affected. Operators should upgrade to 10.0.34 or a later supported release and confirm the version guidance in the vendor advisory.

GitHub classifies the advisory as High severity and maps it to CWE-345, Insufficient Verification of Data Authenticity. This page does not substitute a different severity label or infer impacts beyond the vendor's published scope.

Why the trust boundary failed

The affected route checked whether the body looked like a WhatsApp event and then processed its entries. Those content checks did not authenticate the sender. An attacker able to reproduce the expected JSON structure could reach the status-update logic because the route did not verify the signature generated with the shared application secret.

The same distinction applies to any webhook integration:

• Schema validation checks whether a payload has the expected shape.
• Signature verification checks whether the raw payload matches a signature created with the configured secret.
• Authorization and business rules decide whether a verified event may perform the requested state change.
• Replay controls decide whether an otherwise valid delivery has already been processed or is too old under that provider's protocol.

Each layer answers a different question. Passing one layer does not imply that the others passed.

Patch first, then verify the deployment

For OneUptime, the primary remediation is to install version 10.0.34 or later. After upgrading:

1. Confirm that every running instance and worker is on the patched release.
2. Confirm that the WhatsApp application secret is present through the deployment's supported secret-management path.
3. Send a provider-generated test delivery and verify that it succeeds.
4. In an isolated environment you control, confirm that a missing or modified signature is rejected before any status record changes.
5. Review notification records created during the exposure window for unexpected status transitions. The advisory establishes the possibility of forged changes, not that a particular deployment was exploited.

Do not compensate for an unpatched handler with an IP allowlist alone. Provider address ranges can change, forwarding layers can obscure the peer address, and network origin is not a replacement for the provider's documented signature protocol.

Verify the exact bytes before parsing

HMAC verification must use the exact request bytes covered by the provider's signature. JSON parsing and serialization can change whitespace, key order, escaping, or encoding. That can cause correct verification code to reject legitimate deliveries—or encourage a dangerous fail-open workaround.

A safe handler order is:

1. read and retain the raw request body within a strict size limit;
2. retrieve the provider's signature header;
3. parse the header according to that provider's current documentation;
4. compute the expected signature with the correct endpoint secret and algorithm;
5. compare the supplied and expected values with a constant-time primitive;
6. reject missing, malformed, or mismatched signatures;
7. only then parse the event and apply schema, authorization, and business-rule checks.

Length and encoding checks must occur before a low-level constant-time comparison. For example, Node.js crypto.timingSafeEqual throws when the buffers have different lengths; an implementation should treat that case as verification failure, not let it become an unhandled error or a reason to continue processing.

Provider protocols are not interchangeable

Do not build a single parser that assumes all providers sign the same message or supply the same replay metadata.

GitHub's webhook documentation specifies an X-Hub-Signature-256 value beginning with sha256= and computed over the payload using the webhook secret. GitHub recommends validating the signature before processing the delivery and using a constant-time comparison. The documentation also provides a public test vector for implementation tests.

Stripe's webhook documentation requires the unmodified raw request body, the Stripe-Signature header, and the endpoint secret. Stripe recommends its official libraries to construct and verify the event. Its signature format can contain a timestamp and multiple versioned signatures; a parser designed only for GitHub's header is not a Stripe verifier.

For Meta/WhatsApp, follow the current Meta application documentation and the OneUptime implementation for the release you deploy. Do not infer Meta's signing string or replay behavior from GitHub or Stripe examples merely because one header name is similar.

HMAC validation is not complete replay protection

A valid HMAC establishes that the signed bytes match a value produced by a holder of the shared secret. It does not, by itself, prove that the delivery is new.

Use the replay controls that the provider actually supplies:

• When the signed protocol includes a timestamp, validate it using the provider's documented tolerance and account for clock synchronization.
• When the provider supplies a stable delivery or event identifier, store a bounded deduplication record and make processing idempotent.
• If neither mechanism exists, design business operations to tolerate duplicate delivery and seek provider-specific guidance rather than inventing an unsigned timestamp header.

Do not apply a universal five-minute rule to every webhook. A timestamp is useful only when it is part of the authenticated protocol; an attacker can freely alter an unsigned timestamp.

Test rejection paths without targeting production

Positive-path tests are insufficient. In an isolated test deployment, verify at least these cases:

| Test case | Expected result | | --- | --- | | Provider-generated event with correct secret | Accepted once and processed according to policy | | Missing signature header | Rejected before parsing or state change | | Signature with one changed hex character | Rejected before state change | | Valid signature over a different body | Rejected | | Malformed or wrong-length signature | Rejected without an unhandled exception | | Correctly signed but invalid event schema | Rejected by schema or business validation | | Repeated delivery identifier | Handled idempotently or rejected according to policy | | Old signed timestamp, when the provider signs time | Rejected under the provider's documented tolerance |

Keep test fixtures synthetic. Do not copy production secrets, customer payloads, or captured authorization headers into local tools, test logs, tickets, or chat.

Operational checklist

• Inventory every public webhook route and its provider.
• Record the provider's signature header, signed bytes, algorithm, and secret source.
• Verify raw bytes before JSON parsing or business processing.
• Reject missing, malformed, and mismatched signatures.
• Use supported provider libraries when available.
• Keep endpoint secrets out of source control and logs; rotate them through the provider's supported workflow.
• Make state changes idempotent and deduplicate stable delivery identifiers.
• Rate-limit and cap request sizes as resilience controls, not as substitutes for authentication.
• Log bounded event metadata and verification outcomes, never secrets or full sensitive bodies.
• Test negative paths after framework, proxy, or middleware changes.

Sources

• OneUptime advisory GHSA-g5ph-f57v-mwjc
• NVD: CVE-2026-33143
• GitHub: Validating webhook deliveries
• Stripe: Resolve webhook signature verification errors