Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Lifecycle Timeline
7DescriptionGitHub Advisory
Impact
The root level commentable field in the API allows access to all commentable resources within the platform, without any permission checks. All Decidim instances are impacted that have not secured the /api endpoint. The /api endpoint is publicly available with the default configuration.
Patches
Not available
Workarounds
To mitigate the issue, you can limit the scope to only authenticated users by limiting access to the /api endpoint. This would require custom code or installing the 3rd party module Decidim::Apiauth.
With custom code, the /api endpoint can be limited to only authenticated users with the following code (needs to run during application initialization):
# Within your application
# config/initializers/limit_api_access.rb
module LimitApiAccess
extend ActiveSupport::Concern
included do
prepend_before_action do |controller|
unless controller.send(:user_signed_in?)
render plain: I18n.t("actions.login_before_access", scope: "decidim.core"), status: :unauthorized
end
end
end
end
Rails.application.config.to_prepare do
Decidim::Api::ApplicationController.include(LimitApiAccess)
endPlease note that this would only disable public access to the API and all authenticated users would be still able to exploit the vulnerability. This may be sufficient for some installations, but not for all.
Another workaround is to limit the availability of the /api endpoint to only trusted ranges of IPs that need to access the API. The following Nginx configuration would help limiting the API access to only specific IPs:
location /api {
allow 192.168.1.100;
allow 192.168.1.101;
deny all;
}The same configuration can be also used without the allow statements to disable all traffic to the the /api endpoint.
When considering a workaround and the seriousness of the vulnerability, please consider the nature of the platform. If the platform is primarily serving public data, this vulnerability is not serious by its nature. If the platform is protecting some resources, e.g. inside private participation spaces, the vulnerability may expose some data to the attacker that is not meant public.
If you have enabled the organization setting "Force users to authenticate before access organization", the scope of this vulnerability is limited to the users who are allowed to log in to the Decidim platform. This setting was introduced in version 0.19.0 and it was applied to the /api endpoint in version 0.22.0.
AnalysisAI
Decidim GraphQL API exposes all commentable resources platform-wide without permission checks, enabling unauthorized access to comments and associated data across public and private participation spaces. Affects decidim-api and decidim-comments Ruby gems with default configurations exposing the /api endpoint publicly. No vendor patch available - only workarounds via authentication enforcement or IP allowlisting. CVSS 7.5 (High) reflects network-accessible confidentiality breach, though real-world impact depends heavily on whether the Decidim instance hosts non-public participation spaces.
Technical ContextAI
Decidim is an open-source participatory democracy platform built on Ruby on Rails. The vulnerability exists in the GraphQL API implementation (decidim-api gem) where the root-level 'commentable' field resolver lacks authorization checks. GraphQL APIs differ from REST in that they expose a single endpoint (/api) with a schema-driven query language, making fine-grained access control critical at the resolver level. CWE-862 (Missing Authorization) means the code performs operations without verifying the requester has permission. In Decidim's architecture, commentable resources span public assemblies, private consultations, and restricted participatory processes - all accessible through this single unprotected field. The decidim-comments gem provides the comment model and associations that become exposed. Decidim versions from 0.19.0+ support 'Force users to authenticate before access organization' which, when enabled alongside API changes in 0.22.0+, naturally mitigates exposure by requiring authentication platform-wide.
RemediationAI
No vendor-released patch available at time of analysis per GitHub advisory GHSA-ghmh-q25g-gxxx. Primary workaround: Restrict /api endpoint to authenticated users by adding the provided Ruby initializer code (config/initializers/limit_api_access.rb) to prepend authentication checks to Decidim::Api::ApplicationController. Trade-off: all authenticated users retain exploit access - acceptable only if trust boundary aligns with authentication (internal users). Alternative: implement IP allowlisting via web server configuration (Nginx location block for /api with allow/deny directives) to restrict API access to trusted networks or disable entirely. Trade-off: breaks legitimate API integrations from non-allowlisted sources. For high-sensitivity deployments, combine both controls: IP allowlist plus authentication requirement. Third option: enable 'Force users to authenticate before access organization' platform setting if running Decidim 0.22.0+ (Settings > Configuration). Trade-off: disables all anonymous platform access, not just API. Evaluate whether comment data exposure justifies operational impact of each mitigation based on participation space sensitivity outlined in advisory.
The ngx_http_parse_chunked function in http/ngx_http_parse.c in nginx 1.3.9 through 1.4.0 allows remote attackers to cau
A critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
nginx 0.8.41 through 1.4.3 and 1.5.x before 1.5.7 allows remote attackers to bypass intended restrictions via an unescap
An issue was discovered on GL.iNet devices before version 4.5.0. Rated critical severity (CVSS 9.8), this vulnerability
Nginx versions since 0.5.6 up to and including 1.13.2 are vulnerable to integer overflow vulnerability in nginx range fi
The resolver in nginx before 1.8.1 and 1.9.x before 1.9.10 allows remote attackers to cause a denial of service (invalid
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Roxy-WI is a web interface for managing Haproxy, Nginx, Apache and Keepalived servers. Rated critical severity (CVSS 9.8
The STARTTLS implementation in mail/ngx_mail_smtp_handler.c in the SMTP proxy in nginx 1.5.x and 1.6.x before 1.6.1 and
Heap buffer overflow in NGINX Plus and NGINX Open Source ngx_http_rewrite_module allows remote attackers to crash worker
Same weakness CWE-862 – Missing Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-24252
GHSA-ghmh-q25g-gxxx