GHSA-2G9C-VF8H-PRXX

Vulnerability from github – Published: 2026-07-13 17:19 – Updated: 2026-07-13 17:19
VLAI
Summary
Decidim: Push subscriptions can be abused for server-side requests
Details

Description

The push-subscription endpoint stores an attacker-controlled delivery URL, and the notification send path becomes an outbound-request sink when VAPID delivery is enabled. The practical result is an authenticated, stored, mostly blind SSRF primitive to arbitrary HTTPS endpoints reachable from the app server.

Technical description

When VAPID delivery is enabled, the notification subscription flow stores the client-supplied push endpoint without checking that it belongs to an approved push service. The send path later passes that stored URL to WebPush.payload_send, turning the subscription into an attacker-controlled outbound request destination. This is the source-to-sink chain:

  1. Source: attacker-controlled subscription.endpoint in the JSON body posted to POST /notifications_subscriptions.
  2. Persistence: params[:endpoint] is stored under user.notification_settings["subscriptions"].
  3. Retrieval: user.notifications_subscriptions.values returns that stored endpoint later.
  4. Sink: build_payload sets endpoint: subscription["endpoint"].
  5. Outbound request: WebPush.payload_send(**payload) uses the attacker-supplied endpoint as the destination.

One spec asserts that the endpoint is persisted exactly as supplied:

# decidim-core/spec/services/decidim/notifications_subscriptions_persistor_spec.rb
expect(user.notifications_subscriptions["auth_code_121"]["endpoint"]).to eq(params[:endpoint])

Another spec asserts that SendPushNotification passes the stored endpoint into WebPush.payload_send:

# decidim-core/spec/services/decidim/send_push_notification_spec.rb
first_notification_payload = {
  message:,
  endpoint: subscriptions["auth_key_1"]["endpoint"],
  p256dh: subscriptions["auth_key_1"]["p256dh"],
  auth: subscriptions["auth_key_1"]["auth"],
  vapid: a_hash_including(...)
}
expect(WebPush).to receive(:payload_send).with(first_notification_payload)

Impact

  • In a configured deployment, an authenticated user can register an attacker-controlled or otherwise unauthorized HTTPS URL.
  • The server then sends outbound POST requests there whenever a notification is pushed.
  • This is a stored, mostly blind SSRF primitive: useful for outbound interaction with attacker infrastructure and, where routable, internal HTTPS services.
  • Notification metadata is disclosed to the supplied endpoint through the encrypted web push request path.

Patches

See https://github.com/decidim/decidim/pull/16714.

Workarounds

Disable the push notifications feature by removing the VAPID keys in the server.

Resource

SSRF

Credits

This issue was discovered in a security audit organized by the Decidim Association and made by Radically Open Security against Decidim financed by NGI.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "decidim-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.30.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "decidim-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.31.0.rc1"
            },
            {
              "fixed": "0.31.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "decidim-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.32.0.rc1"
            },
            {
              "fixed": "0.32.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45573"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-13T17:19:17Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Description\n\nThe push-subscription endpoint stores an attacker-controlled delivery URL, and the notification send path becomes an outbound-request sink when VAPID delivery is enabled. The practical result is an authenticated, stored, mostly blind SSRF primitive to arbitrary HTTPS endpoints reachable from the app server.\n\n## Technical description\n \nWhen VAPID delivery is enabled, the notification subscription flow stores the client-supplied push endpoint without checking that it belongs to an approved push service. The send path later passes that stored URL to `WebPush.payload_send`, turning the subscription into an attacker-controlled outbound request destination.\nThis is the source-to-sink chain:\n\n1. Source: attacker-controlled `subscription.endpoint` in the JSON body posted to `POST /notifications_subscriptions`.\n2. Persistence: `params[:endpoint]` is stored under `user.notification_settings[\"subscriptions\"]`.\n3. Retrieval: `user.notifications_subscriptions.values` returns that stored endpoint later.\n4. Sink: `build_payload` sets `endpoint: subscription[\"endpoint\"]`.\n5. Outbound request: `WebPush.payload_send(**payload)` uses the attacker-supplied endpoint as the\ndestination.\n\nOne spec asserts that the endpoint is persisted exactly as supplied:\n\n```ruby\n# decidim-core/spec/services/decidim/notifications_subscriptions_persistor_spec.rb\nexpect(user.notifications_subscriptions[\"auth_code_121\"][\"endpoint\"]).to eq(params[:endpoint])\n```\n\nAnother spec asserts that `SendPushNotification` passes the stored endpoint into `WebPush.payload_send`:\n\n```ruby\n# decidim-core/spec/services/decidim/send_push_notification_spec.rb\nfirst_notification_payload = {\n  message:,\n  endpoint: subscriptions[\"auth_key_1\"][\"endpoint\"],\n  p256dh: subscriptions[\"auth_key_1\"][\"p256dh\"],\n  auth: subscriptions[\"auth_key_1\"][\"auth\"],\n  vapid: a_hash_including(...)\n}\nexpect(WebPush).to receive(:payload_send).with(first_notification_payload)\n```\n\n### Impact\n\n- In a configured deployment, an authenticated user can register an attacker-controlled or otherwise unauthorized HTTPS URL.\n- The server then sends outbound `POST` requests there whenever a notification is pushed.\n- This is a stored, mostly blind SSRF primitive: useful for outbound interaction with attacker infrastructure and, where routable, internal HTTPS services.\n- Notification metadata is disclosed to the supplied endpoint through the encrypted web push request path.\n\n### Patches\n\nSee https://github.com/decidim/decidim/pull/16714.\n\n### Workarounds\n\nDisable the push notifications feature by removing the VAPID keys in the server.\n\n### Resource\n\nSSRF\n\n### Credits\n\nThis issue was discovered in a security audit organized by the [Decidim Association](https://decidim.org) and made by [Radically Open Security](https://www.radicallyopensecurity.com/) against Decidim financed by [NGI](https://ngi.eu/).",
  "id": "GHSA-2g9c-vf8h-prxx",
  "modified": "2026-07-13T17:19:17Z",
  "published": "2026-07-13T17:19:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/decidim/decidim/security/advisories/GHSA-2g9c-vf8h-prxx"
    },
    {
      "type": "WEB",
      "url": "https://github.com/decidim/decidim/pull/16714"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/decidim/decidim"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Decidim: Push subscriptions can be abused for server-side requests"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…