ruby-advisory-db/gems/decidim-core/CVE-2025-65017.yml at master · rubysec/ruby-advisory-db · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
---
gem: decidim-core
cve: 2025-65017
ghsa: 3cx6-j9j4-54mp
url: https://github.com/decidim/decidim/security/advisories/GHSA-3cx6-j9j4-54mp
title: Decidim's private data exports can lead to data leaks
date: 2026-02-03
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:

  ```bash
  $ 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):

  ```ruby
  # 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:

  ```ruby
  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.
cvss_v4: 8.2
unaffected_versions:
  - "< 0.30.0"
patched_versions:
  - "~> 0.30.4"
  - ">= 0.31.0"
related:
  url:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-65017
    - https://github.com/decidim/decidim/security/advisories/GHSA-3cx6-j9j4-54mp
    - https://github.com/decidim/decidim/releases/tag/v0.31.0
    - https://github.com/decidim/decidim/releases/tag/v0.30.4
    - https://github.com/decidim/decidim/pull/13571
    - https://github.com/advisories/GHSA-3cx6-j9j4-54mp