Decidim is a participatory democracy framework, written in Ruby on Rails, originally developed for the Barcelona City government online and offline participation website. Decidim uses a third-party library named Ransack for filtering certain database collections (e.g., public meetings). By default, this library allows filtering on all data attributes and associations. This allows an unauthenticated remote attacker to exfiltrate non-public data from the underlying database of a Decidim instance (e.g., exfiltrating data from the user table). This issue may lead to Sensitive Data Disclosure. The problem was patched in version 0.27.3.

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

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).

Impact A stored code execution vulnerability in the user name field allows a low-privileged attacker to execute arbitrary code in the context of any user who passively visits a comment page, resulting in high confidentiality and integrity impact across security boundaries.

Patches N/A

Workarounds Not available

References OWASP ASVS v4.0.3-5.1.3

Credits This issue was discovered in a security audit organized by octree and made by Secu Labs against Decidim financed by the city of Lausanne (Switzerland).

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:

bash $ cd decidim-core $ for i in {1..10}; do bundle exec rspec spec/jobs/decidim/downloadyourdataexportjobspec.rb -e "deletes the" || break ; done

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):

ruby Create the ZIP buffers to be stored buffer1 = Zip::OutputStream.writebuffer do |out| out.putnextentry("admin.txt") out.write "Hello, admin!" end buffer1.rewind buffer2 = Zip::OutputStream.writebuffer do |out| out.putnextentry("user.txt") out.write "Hello, user!" end buffer2.rewind

Create the private exports with a predefined IDs user1 = Decidim::User.find(1) export = user1.privateexports.build export.id = "0210ae70-482b-4671-b758-35e13e0097a9" export.exporttype = "downloadyourdata" export.file.attach(io: buffer1, filename: "foobar.zip", contenttype: "application/zip") export.expiresat = Decidim.downloadyourdataexpirytime.fromnow export.metadata = {} export.save!

user2 = Decidim::User.find(2) export = user2.privateexports.build export.id = "0210d2df-a0c7-40aa-ad97-2dae5083e3b8" export.exporttype = "downloadyourdata" export.file.attach(io: buffer2, filename: "foobar.zip", contenttype: "application/zip") export.expiresat = Decidim.downloadyourdataexpirytime.fromnow export.metadata = {} export.save!

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 predefined UUIDs but it can easily happen in real situations.

The reason for the test case failure can be replicated in case you change the export ID to export.id = "e9540f96-9e3d-4abe-8c2a-6c338d85a684". This would return 0 through .tos

After attaching that ID, you can test if the file is available for the export:

ruby user.privateexports.last.file.attached? => false user.privateexports.last.file.blob => nil

Note that this fails with such UUID as shown in the example and could easily lead to collisions in case the UUID starts with a number. E.g. UUID "0210ae70-482b-4671-b758-35e13e0097a9" would convert to 210 through .tos. Therefore, if someone else has a "private" export with the prefixes "00000210", "0000210", "000210", "00210", "0210" or "210", that would cause a collision and the file could be attached to the wrong private export.

Theoretical chance of collision (the reality depends on the UUID generation algorithm):

- Potential combinations of the UUID first part (8 characters hex): 16^8 - Potentially colliding character combinations (8 numbers characters in the range of 0-9): 10^8 - 10^8 / 16^8 ≈ 2.3% (23 / 1000 users)

The root cause is that the class Decidim::PrivateExport defines an ActiveStorage relation to file and the table activestorageattachments stores the related recordid as bigint which causes the conversion to happen.

Workarounds Fully disable the private exports feature until a patch is available.

Impact The invites feature allows users to accept the invitation for an unlimited amount of time through the password reset functionality.

When using the password reset functionality, the deviseinvitable gem always accepts the pending invitation if the user has been invited as shown in this piece of code within the deviseinvitable gem: https://github.com/scambra/deviseinvitable/blob/41f58970ff76fb64382a9b9ea1bd530f7c3adab2/lib/deviseinvitable/models.rb#L198

The only check done here is if the user has been invited but the code does not ensure that the pending invitation is still valid as defined by the invitefor expiry period as explained in the gem's documentation: https://github.com/scambra/deviseinvitable#model-configuration-

invitefor: The period the generated invitation token is valid. After this period, the invited resource won’t be able to accept the invitation. When invitefor is 0 (the default), the invitation won’t expire.

Decidim sets this configuration to 2.weeks so this configuration should be respected: https://github.com/decidim/decidim/blob/d2d390578050772d1bdb6d731395f1afc39dcbfc/decidim-core/config/initializers/devise.rb#L134

The bug is in the deviseinvitable gem and should be fixed there and the dependency should be upgraded in Decidim once the fix becomes available.

Patches Update deviseinvitable to version 2.0.9 or above by running the following command:

$ bundle update deviseinvitable

Workarounds The invitations can be cancelled directly from the database by running the following command from the Rails console:

Decidim::User.invitationnotaccepted.updateall(invitationtoken: nil)

References OWASP ASVS V4.0.3-2.3.1

This bug has existed in the deviseinvitable gem since this commit which was first included in the v0.4.rc3 release of this gem: https://github.com/scambra/deviseinvitable/commit/94d859c7de0829bf63f679ae5dd3cab2b866a098

All versions since then are affected.

This gem was first introduced at its version ~> 1.7.0 to the decidim-admin gem in this commit which was first included in the v0.0.1.alpha3 release of Decidim: https://github.com/decidim/decidim/commit/073e60e2e4224dd81815a784002ebba30f2ebb34

It was first introduced at its version ~> 1.7.0 to the decidim-system gem in this commit which was also first included in the v0.0.1.alpha3 release of Decidim: https://github.com/decidim/decidim/commit/b12800717a689c295a9ea680a38ca9f823d2c454

Credits This issue was discovered in City of Helsinki's security audit against Decidim 0.27 done during September 2023. The security audit was implemented by Deloitte Finland.

Impact

The meeting embeds feature used in the online or hybrid meetings is subject to potential XSS attack through a malformed URL.

Patches

Not available

Workarounds

Disable the creation of meetings by participants in the meeting component.

References

OWASP ASVS v4.0.3-5.1.3

Credits

This issue was discovered in a security audit organized by mitgestalten Partizipationsbüro against Decidim. The security audit was implemented by the Austrian Institute of Technology.

Impact

A race condition in the endorsement of resources (for instance, a proposal) allows a user to make more than once endorsement.

To exploit this vulnerability, the request to set an endorsement must be sent several times in parallel. Workarounds

Disable the Endorsement feature in the components.

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: https://github.com/rails/rails/blob/a967d355c6fee9ad9b8bd115d43bc8b0fc207e7e/activestorage/app/controllers/activestorage/directuploadscontroller.rb#L14

The attacker is able to change the filename e.g. to <svg onload=alert('XSS')> if they know how to craft these requests themselves. And then enter the returned blob ID to the form inputs manually by modifying the edit page source.

Therefore, anywhere we display these strings, we should properly escape them.

Patches PR #11612 fixes this problem both for 0.28.dev and 0.27.x.

Workarounds Disable dynamic uploads for the instance, e.g. from proposals.

References OWASP ASVS v4.0.3-5.1.3

Credits This issue was discovered in City of Helsinki's security audit against Decidim 0.27 done during September 2023. The security audit was implemented by Deloitte Finland.

Impact The CSRF authenticity token check is currently disabled for the questionnaire templates preview as per: https://github.com/decidim/decidim/blob/3187bdfd40ea1c57c2c12512b09a7fec0b2bed08/decidim-templates/app/controllers/decidim/templates/admin/questionnairetemplatescontroller.rb#L11

This was introduced by this commit in the PR that introduced this feature (#6247): https://github.com/decidim/decidim/pull/6247/commits/5542227be66e3b6d7530f5b536069bce09376660

The issue does not imply a serious security thread as you need to have access also to the session cookie in order to see this resource. This URL does not allow modifying the resource but it may allow attackers to gain access to information which was not meant to be public.

Patches #11743

Workarounds Disable the templates functionality or remove all available templates.

References #11743

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

Impact

The WYSWYG editor QuillJS is subject to potential XSS attach in case the attacker manages to modify the HTML before being uploaded to the server.

The attacker is able to change e.g. to <svg onload=alert('XSS')> if they know how to craft these requests themselves.

Patches

N/A

Workarounds

Review the user accounts that have access to the admin panel (i.e. general Administrators, and participatory space's Administrators) and remove access to them if they don't need it.

Disable the "Enable rich text editor for participants" setting in the admin dashboard

References

OWASP ASVS v4.0.3-5.1.3

Impact The admin panel is subject to potential XSS attach in case an admin assigns a valuator to a proposal, or does any other action that generates an admin activity log where one of the resources has an XSS crafted.

Patches

N/A

Workarounds

Redirect the pages /admin and /admin/logs to other admin pages to prevent this access (i.e. /admin/organization/edit)

References

OWASP ASVS v4.0.3-5.1.3

Impact

The templates module doesn't enforce the correct permissions, allowing any logged-in user to access to this functionality in the administration panel. An attacker could use this vulnerability to change, create or delete templates of surveys.

Impact

The admin panel is subject to potential XSS attach in case the attacker manages to modify some records being uploaded to the server.

The attacker is able to change e.g. to <svg onload=alert('XSS')> if they know how to craft these requests themselves. And then enter the returned blob ID to the form inputs manually by modifying the edit page source.

Patches

Available in versions 0.27.6 and 0.28.1.

Workarounds

Review the user accounts that have access to the admin panel (i.e. general Administrators, and participatory space's Administrators) and remove access to them if they don't need it.

References

OWASP ASVS v4.0.3-5.1.3