Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
💎 RubyGems

GHSA-2g9c-vf8h-prxx

MEDIUMFix: decidim/decidim#16714

GHSA-2g9c-vf8h-prxx is a medium-severity (CVSS 6.4) Server-Side Request Forgery (SSRF) vulnerability in decidim-core. O3 Security confirms whether GHSA-2g9c-vf8h-prxx is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Decidim: Push subscriptions can be abused for server-side requests

Also known asCVE-2026-45573
Published
Jul 13, 2026
Updated
Jul 13, 2026
Affected
3 pkgs
Patched
3 / 3
Exploits
None indexed

Real-World Exposure

3 pkgs affected
💎decidim-core💎decidim-core💎decidim-core

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects RubyGems packages — download data is not available via public APIs for these ecosystems.

Description

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.

Affected Packages

3 total 3 fixed
EcosystemPackageVulnerable rangeFix
💎RubyGemsdecidim-coreall versions0.30.9
💎RubyGemsdecidim-core0.31.0.rc1&&< 0.31.50.31.5
💎RubyGemsdecidim-core0.32.0.rc1&&< 0.32.00.32.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for decidim-core. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update decidim-core to 0.30.9 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2g9c-vf8h-prxx is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-2g9c-vf8h-prxx is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-2g9c-vf8h-prxx. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## 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
O3 Security · Impact-Aware SCA

Is GHSA-2g9c-vf8h-prxx in your dependencies?

O3 detects GHSA-2g9c-vf8h-prxx across RubyGems dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.