GHSA-3cx6-j9j4-54mp
Decidim's private data exports can lead to data leaks
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
decidim-core💎decidimReal-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
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:
$ cd decidim-core
$ for i in {1..10}; do bundle exec rspec spec/jobs/decidim/download_your_data_export_job_spec.rb -e "deletes the" || break ; done
Run the spec as many times as needed to hit a UUID that converts to 0 through .to_i.
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):
# Create the ZIP buffers to be stored
buffer1 = Zip::OutputStream.write_buffer do |out|
out.put_next_entry("admin.txt")
out.write "Hello, admin!"
end
buffer1.rewind
buffer2 = Zip::OutputStream.write_buffer do |out|
out.put_next_entry("user.txt")
out.write "Hello, user!"
end
buffer2.rewind
# Create the private exports with a predefined IDs
user1 = Decidim::User.find(1)
export = user1.private_exports.build
export.id = "0210ae70-482b-4671-b758-35e13e0097a9"
export.export_type = "download_your_data"
export.file.attach(io: buffer1, filename: "foobar.zip", content_type: "application/zip")
export.expires_at = Decidim.download_your_data_expiry_time.from_now
export.metadata = {}
export.save!
user2 = Decidim::User.find(2)
export = user2.private_exports.build
export.id = "0210d2df-a0c7-40aa-ad97-2dae5083e3b8"
export.export_type = "download_your_data"
export.file.attach(io: buffer2, filename: "foobar.zip", content_type: "application/zip")
export.expires_at = Decidim.download_your_data_expiry_time.from_now
export.metadata = {}
export.save!
Expect to see an error in the situation.
Now, login as user with ID 1, go to /download_your_data, 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 .to_s
After attaching that ID, you can test if the file is available for the export:
user.private_exports.last.file.attached?
=> false
user.private_exports.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 .to_s. 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 active_storage_attachments stores the related record_id as bigint which causes the conversion to happen.
Workarounds
Fully disable the private exports feature until a patch is available.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💎RubyGems | decidim-core | ≥ 0.30.0&&< 0.30.4 | 0.30.4 |
| 💎RubyGems | decidim | ≥ 0.30.0&&< 0.30.4 | 0.30.4 |
Detection & mitigation playbook
Open-source dependencyDetect
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.
Fix
Update decidim-core to 0.30.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-3cx6-j9j4-54mp is resolved across your whole dependency graph.
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.
How O3 protects you
O3 pinpoints whether GHSA-3cx6-j9j4-54mp 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-3cx6-j9j4-54mp. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-3cx6-j9j4-54mp in your dependencies?
O3 detects GHSA-3cx6-j9j4-54mp across RubyGems dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.