GHSA-5P54-WHVP-X327

Vulnerability from github – Published: 2026-09-18 17:16 – Updated: 2026-09-18 17:16
VLAI
Summary
AnyCable: Pusher REST API Does Not Verify Request Body MD5 Enabling Signed-Request Replay with Arbitrary Body
Details

Summary

The Pusher-compatible REST API includes body_md5 in the HMAC signature string but never computes or verifies the MD5 of the received HTTP body, allowing anyone who observes a signed request to replay it with an entirely different body.

Details

In pusher/http.go, the Handler function extracts body_md5 from the URL query string (line 169) and includes it verbatim in stringToSign (line 175). It then verifies HMAC(stringToSign, secret) == auth_signature. After verification succeeds, handleEvents reads and parses r.Body (lines 201-212) without ever computing md5(body) and comparing it against the body_md5 that was signed. The Pusher protocol specification explicitly requires the server to verify this digest to prevent body-substitution attacks. There is also no auth_timestamp staleness check, so replays are valid indefinitely.

PoC

  1. Capture a legitimate signed POST to /apps/<app_id>/events?auth_key=K&auth_timestamp=T&auth_version=1.0&body_md5=LEGIT_MD5&auth_signature=SIG carrying body {"name":"safe-event","channel":"ch","data":"..."} (e.g., from TLS-terminating load-balancer logs).
  2. Send a new request with the same query string parameters but a different body: {"name":"injected-event","channel":"admin","data":"malicious-payload"}
  3. The server accepts the request (HMAC over stringToSign matches the original) and broadcasts the injected event to all subscribers of admin.

Impact

An attacker who can read any single signed Pusher API request (from logs, a shared proxy, or a network tap) can broadcast arbitrary events to any channel indefinitely, potentially forging server-side events, corrupting application state, or delivering phishing messages to WebSocket clients.

Fix

After reading r.Body, compute hex(md5(body)) and compare it to the body_md5 query parameter using a constant-time comparison before proceeding. Additionally, reject requests whose auth_timestamp is more than 600 seconds from the current time.

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.6.14"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/anycable/anycable"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-63405"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-18T17:16:25Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe Pusher-compatible REST API includes `body_md5` in the HMAC signature string but never computes or verifies the MD5 of the received HTTP body, allowing anyone who observes a signed request to replay it with an entirely different body.\n\n### Details\nIn `pusher/http.go`, the `Handler` function extracts `body_md5` from the URL query string (line 169) and includes it verbatim in `stringToSign` (line 175). It then verifies `HMAC(stringToSign, secret) == auth_signature`. After verification succeeds, `handleEvents` reads and parses `r.Body` (lines 201-212) without ever computing `md5(body)` and comparing it against the `body_md5` that was signed. The Pusher protocol specification explicitly requires the server to verify this digest to prevent body-substitution attacks. There is also no `auth_timestamp` staleness check, so replays are valid indefinitely.\n\n### PoC\n1. Capture a legitimate signed POST to `/apps/\u003capp_id\u003e/events?auth_key=K\u0026auth_timestamp=T\u0026auth_version=1.0\u0026body_md5=LEGIT_MD5\u0026auth_signature=SIG` carrying body `{\"name\":\"safe-event\",\"channel\":\"ch\",\"data\":\"...\"}` (e.g., from TLS-terminating load-balancer logs).\n2. Send a new request with the same query string parameters but a different body:\n   `{\"name\":\"injected-event\",\"channel\":\"admin\",\"data\":\"malicious-payload\"}`\n3. The server accepts the request (HMAC over `stringToSign` matches the original) and broadcasts the injected event to all subscribers of `admin`.\n\n### Impact\nAn attacker who can read any single signed Pusher API request (from logs, a shared proxy, or a network tap) can broadcast arbitrary events to any channel indefinitely, potentially forging server-side events, corrupting application state, or delivering phishing messages to WebSocket clients.\n\n### Fix\nAfter reading `r.Body`, compute `hex(md5(body))` and compare it to the `body_md5` query parameter using a constant-time comparison before proceeding. Additionally, reject requests whose `auth_timestamp` is more than 600 seconds from the current time.",
  "id": "GHSA-5p54-whvp-x327",
  "modified": "2026-09-18T17:16:25Z",
  "published": "2026-09-18T17:16:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/anycable/anycable/security/advisories/GHSA-5p54-whvp-x327"
    },
    {
      "type": "WEB",
      "url": "https://github.com/anycable/anycable/commit/d2cbadec792f038f4695c84a65c0d957b0fde72c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/anycable/anycable"
    },
    {
      "type": "WEB",
      "url": "https://github.com/anycable/anycable/releases/tag/v1.6.15"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "AnyCable: Pusher REST API Does Not Verify Request Body MD5 Enabling Signed-Request Replay with Arbitrary Body"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.