{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "decidim-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.30.0"
            },
            {
              "fixed": "0.30.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "decidim"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.30.0"
            },
            {
              "fixed": "0.30.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-65017"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-703"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-03T17:21:17Z",
    "nvd_published_at": "2026-02-03T15:16:12Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nPrivate data exports can lead to data leaks in cases where the UUID generation causes collisions for the generated UUIDs.\n\nThe bug was introduced by #13571 and affects Decidim versions 0.30.0 or newer (currently 2025-09-23).\n\nThis issue  was discovered by running the following spec several times in a row, as it can randomly fail due to this bug:\n\n```bash\n$ cd decidim-core\n$ for i in {1..10}; do bundle exec rspec spec/jobs/decidim/download_your_data_export_job_spec.rb -e \"deletes the\" || break ; done\n```\n\nRun the spec as many times as needed to hit a UUID that converts to `0` through `.to_i`.\n\nThe UUID to zero conversion does not cause a security issue but the security issue is demonstrated with the following example.\n\nThe 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):\n\n```ruby\n# Create the ZIP buffers to be stored\nbuffer1 = Zip::OutputStream.write_buffer do |out|\n  out.put_next_entry(\"admin.txt\")\n  out.write \"Hello, admin!\"\nend\nbuffer1.rewind\nbuffer2 = Zip::OutputStream.write_buffer do |out|\n  out.put_next_entry(\"user.txt\")\n  out.write \"Hello, user!\"\nend\nbuffer2.rewind\n\n# Create the private exports with a predefined IDs\nuser1 = Decidim::User.find(1)\nexport = user1.private_exports.build\nexport.id = \"0210ae70-482b-4671-b758-35e13e0097a9\"\nexport.export_type = \"download_your_data\"\nexport.file.attach(io: buffer1, filename: \"foobar.zip\", content_type: \"application/zip\")\nexport.expires_at = Decidim.download_your_data_expiry_time.from_now\nexport.metadata = {}\nexport.save!\n\n\nuser2 = Decidim::User.find(2)\nexport = user2.private_exports.build\nexport.id = \"0210d2df-a0c7-40aa-ad97-2dae5083e3b8\"\nexport.export_type = \"download_your_data\"\nexport.file.attach(io: buffer2, filename: \"foobar.zip\", content_type: \"application/zip\")\nexport.expires_at = Decidim.download_your_data_expiry_time.from_now\nexport.metadata = {}\nexport.save!\n```\n\nExpect to see an error in the situation.\n\nNow, 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.\n\nThe 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`\n\nAfter attaching that ID, you can test if the file is available for the export:\n\n```ruby\nuser.private_exports.last.file.attached?\n=\u003e false\nuser.private_exports.last.file.blob\n=\u003e nil\n```\n\nNote 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.\n\nTheoretical chance of collision (the reality depends on the UUID generation algorithm):\n\n- Potential combinations of the UUID first part (8 characters hex): 16^8\n- Potentially colliding character combinations (8 numbers characters in the range of 0-9): 10^8\n- 10^8 / 16^8 \u2248 2.3% (23 / 1000 users)\n\nThe 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.\n\n### Workarounds\nFully disable the private exports feature until a patch is available.",
  "id": "GHSA-3cx6-j9j4-54mp",
  "modified": "2026-02-03T17:21:17Z",
  "published": "2026-02-03T17:21:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/decidim/decidim/security/advisories/GHSA-3cx6-j9j4-54mp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65017"
    },
    {
      "type": "WEB",
      "url": "https://github.com/decidim/decidim/pull/13571"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/decidim/decidim"
    },
    {
      "type": "WEB",
      "url": "https://github.com/decidim/decidim/releases/tag/v0.30.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/decidim/decidim/releases/tag/v0.31.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Decidim\u0027s private data exports can lead to data leaks"
}