Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.payloadsend, 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 /notificationssubscriptions. 2. Persistence: params[:endpoint] is stored under user.notificationsettings["subscriptions"]. 3. Retrieval: user.notificationssubscriptions.values returns that stored endpoint later. 4.…
Recommended action: Upgrade to 0.32.0, 0.31.5 or 0.30.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A privileged admin user who can edit an affected landing page can store arbitrary HTML/JavaScript in an HTML block, and the public page renders it with htmlsafe and no output escaping. Technical description This issue lets any admin who can edit an affected landing page store arbitrary HTML and JavaScript in an HTML block. The block is then rendered back through Decidim::ContentBlocks::HtmlCell#htmlcontent without a sanitization boundary, so the script executes later in visitor's browsers. <img width="1541" height="439" alt="decidim-html-xss-01" src="https://github.com/user-attachments/assets/acae1c06-8acb-49be-ab12-aabae33190ce" / <img width="1540" height="752" alt="decidim-html-xss-02" src="https://github.com/user-attachments/assets/a2f1fa7f-03f3-4d17-b58b-f4db865443e9" / Impact - A user with landing-page editing rights for an affected scope can persist JavaScript that executes in visitor's browsers on that page. - Because exploitation already requires privileged…
Recommended action: Upgrade to 0.32.0, 0.31.5 or 0.30.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The normal downloadyourdata flow requires the requester to be logged in as the export owner, but the resulting Active Storage blob redirect URL can be replayed without authentication by anyone who obtains it. Technical description This private export flow turns an authenticated, user-scoped download into a reusable bearer link because the protected Decidim endpoint redirects to the underlying Active Storage blob URL. Decidim::DownloadYourDataController#downloadfile correctly scopes the export record to currentuser, so the wrapper route itself is not directly accessible to another user. However, once the owner performs that authenticated GET request, the response redirects to a signed Active Storage URL that is no longer bound to the user session. Anyone who learns that URL can replay it and retrieve the file without being logged in as the export owner. Because the blob redirect URL is delivered through a GET request and appears in the redirect chain, it is more likely to…
Recommended action: Upgrade to 0.32.0, 0.31.5 or 0.30.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The vulnerability allows any registered and authenticated user to accept or reject any amendments. The impact is on any users who have created proposals where the amendments feature is enabled. This also elevates the user accepting the amendment as the author of the original proposal as people amending proposals are provided coauthorship on the coauthorable resources. The only check done when accepting or rejecting amendments is whether the amendment reactions are enabled for the component: https://github.com/decidim/decidim/blob/9d6c3d2efe5a83bb02e095824ff5998d96a75eb7/decidim-core/app/permissions/decidim/permissions.rb#L107 The permission checks have been changed at 1b99136 which was introduced in released version 0.19.0. I have not investigated whether prior versions are also affected. Patches Not available Workarounds Disable amendment reactions for the amendable component (e.g. proposals).
Recommended action: Upgrade to 0.31.1 or 0.30.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Private data exports can lead to data leaks in cases where the UUID generation causes collisions for the generated UUIDs. The bug was introduced by #13571 and affects Decidim versions 0.30.0 or newer (currently 2025-09-23). This issue was discovered by running the following spec several times in a row, as it can randomly fail due to this bug: Run the spec as many times as needed to hit a UUID that converts to 0 through .toi. The UUID to zero conversion does not cause a security issue but the security issue is demonstrated with the following example. The following code regenerates the issue by assigning a predefined UUID that will generate a collision (example assumes there are already two existing users in the system): Expect to see an error in the situation. Now, login as user with ID 1, go to /downloadyourdata, click "Download file" from the export and expect to see the data that should be attached to user with ID 2. This is an artificially replicated situation with the…
Recommended action: Upgrade to 0.30.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The dynamic file upload feature is subject to potential XSS attach in case the attacker manages to modify the file names of the records being uploaded to the server. This appears in sections where the user controls the file upload dialogs themselves and has the technical knowledge to change the file names through the dynamic upload endpoint. Therefore I believe it would require the attacker to control the whole session of the particular user but in any case, this needs to be fixed. Successful exploit of this vulneratibility would require the user to have successfully uploaded a file blob to the server with a malicious file name and then have the possibility to direct the other user to the edit page of the record where the attachment is attached. The users are able to craft the direct upload requests themselves controlling the file name that gets stored to the database as shown here:…
Recommended action: Upgrade to 0.27.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The external link feature is susceptible to Cross-site scripting. This allows a remote attacker to execute JavaScript code in the context of a currently logged-in user. An attacker could use this vulnerability to make other users endorse or support proposals they have no intention of supporting or endorsing. Patches The problem was patched in v0.27.3 and v0.26.7
Recommended action: Upgrade to 0.27.3 or 0.26.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The processes filter feature is susceptible to Cross-site scripting. This allows a remote attacker to execute JavaScript code in the context of a currently logged-in user. An attacker could use this vulnerability to make other users endorse or support proposals they have no intention of supporting or endorsing. Patches The problem was patched in v0.27.3 and v0.26.7
Recommended action: Upgrade to 0.27.3 or 0.26.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.