{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "(open-source design and prototyping platform, Kaleidos)",
          "vendor": "Penpot",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Louis Sanchez via Fulldisclosure"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Posting this as an update rather than a first disclosure. The advisory\nwent public on 2026-08-04 with no vendor fix. Penpot has shipped two\nreleases since then, 2.17.1 and 2.17.2 -- the latter 14 days ago, on\n2026-08-27 -- and I re-checked the code this morning: the missing\npermission check is still missing in both, and in every release before\nthem. It was fixed on develop the day after this advisory went public.\nThat fix has never shipped. Anyone running a released version of\nself-hosted Penpot should know that, so here is the whole thing in one\nmessage.\n\n\nSUMMARY\n=======\n\nPenpot\u0027s file-import RPC command takes an optional caller-supplied\nfile-id, meaning \"import into this existing file instead of creating a\nnew one.\" The handler checks that the caller may edit the project they\nnamed -- a project they own, since they supplied it. It never checks\nthat the file-id they supplied belongs to them.\n\nSo any authenticated user can point that parameter at any file on the\ninstance and overwrite it. The same operation also re-parents the file\ninto the attacker\u0027s project, which is the part that matters: the\nattacker does not merely destroy the victim\u0027s design, they end up owning\nit. On a default install with open self-registration, the attacker needs\nno prior relationship to the target at all.\n\n\nAFFECTED\n========\n\nProduct:  Penpot (open-source design and prototyping platform, Kaleidos)\nAffected: 1.20 through 2.17.2, self-hosted Community Edition and\n          Penpot Cloud. The in-place file-id parameter was introduced in\n          1.20 -- the handler\u0027s own ::doc/changes metadata records\n          \"1.20  Add file-id param for in-place import\". The CVE record\n          was updated 2026-08-27 to state the range as 1.20 through\n          2.17.1, the same day 2.17.2 shipped; 2.17.2 is also affected\n          and is not yet reflected in the record.\nFixed in: nothing released. Fixed on develop, unreleased, since\n          2026-08-05, and present in the 2.18.0 release-candidate line.\n          Never backported to a 2.17.x release.\n\nCVE-2026-17613, assigned by CERT/CC as CNA, record state PUBLISHED.\nCWE-639 (Authorization Bypass Through User-Controlled Key), CWE-862\n(Missing Authorization).\n\n\nSTILL UNPATCHED IN EVERY RELEASE -- FIXED ON DEVELOP, NOT SHIPPED\n=================================================================\n\nThe published advisory last verified the flaw at develop HEAD on\n2026-07-27. Penpot has released 2.17.1 and 2.17.2 since then\n(2026-08-17 and 2026-08-27), and 2.17.0 shortly before it (2026-07-22).\nNone of the three fixes it. Verified today, 2026-09-10:\n\n  backend/src/app/rpc/commands/binfile.clj @ tag 2.17.2\n\n    line  78  (files/check-read-permissions! pool profile-id file-id)\n              -- export path, correct check, present\n    line 153  (projects/check-edition-permissions! pool profile-id project-id)\n              -- import path, checks only the caller\u0027s own project\n    line 160  (uuid? file-id)\n    line 161  (assoc ::bfc/file-id file-id)\n              -- import path, the supplied file-id bound unchecked\n\n  same file @ develop 37dab75e (2026-09-10T18:29:44Z)\n\n    line  88  (files/check-read-permissions! cfg profile-id file-id)\n              -- export path, correct check, present\n    line 166  (projects/check-edition-permissions! pool profile-id project-id)\n              -- import path; file-id is no longer a parameter here at\n                 all, so there is nothing left to check\n\nThe fix exists. It just has not shipped. The day after this advisory\nwent public, commit 9242556d landed on develop and removed file-id from\nimport-binfile outright -- gone from the schema, from the handler\u0027s\ndestructuring, and from the audit props. Commit message: \":bug: Close\nimport-binfile schema and remove file-id parameter (#10994)\". The same\nchange is in the current 2.18.0 release-candidate line (2.18.0-RC5). It\nhas never been backported to a 2.17.x release.\n\nThe 2.17.2 release notes list three bug fixes, one of them a different\nsecurity fix (an SVG-exporter command-injection bug, per the vendor\u0027s\nown changelog) -- so the vendor does put security fixes in this line\nwhen it chooses to. This one is not among them. The code above is\nbyte-identical to 2.17.0 (2026-07-22) and 2.17.1 (2026-08-17) -- the\nsame three call sites, the same line numbers, across the last three\nreleases. I am not going to guess why -- I am saying that today, 105\ndays after the report, nobody running a released version of Penpot has\nthe fix that has sat on develop, unreleased, for 36 days.\n\n\nROOT CAUSE\n==========\n\nWhat makes this one worth reading is that the correct check is in the\nsame source file, about seventy lines away, on the other direction of\nthe same feature.\n\nexport-binfile validates read permission on its file-id before handing\nanything back:\n\n  (sv/defmethod ::export-binfile\n    ...\n    [{:keys [::db/pool] :as cfg}\n     {:keys [::rpc/profile-id file-id] :as params}]\n    (files/check-read-permissions! pool profile-id file-id)   ; \u003c-- yes\n    (sse/response (partial export-binfile cfg params)))\n\nimport-binfile validates the caller\u0027s project and then binds the\ncaller\u0027s file-id straight through:\n\n  (sv/defmethod ::import-binfile\n    ...\n    [{:keys [::db/pool] :as cfg}\n     {:keys [::rpc/profile-id project-id version file-id upload-id]\n      :as params}]\n    (projects/check-edition-permissions! pool profile-id project-id)\n    (let [...\n          cfg (cond-\u003e cfg\n                (uuid? file-id)\n                (assoc ::bfc/file-id file-id))]   ; \u003c-- no check\n      ...))\n\nThe permission function exists. It is already imported. It is used\ncorrectly a few dozen lines up. The import path just does not call it.\n\nDownstream, the in-place import fetches the target file by id alone with\nno ownership predicate on the query, enables overwrite mode, writes the\nattacker\u0027s content into the victim\u0027s file row, and sets that row\u0027s\nproject to the attacker\u0027s project. The final update is keyed only on the\nattacker-supplied file id.\n\n\nEXPLOITATION\n============\n\nPrerequisite: any authenticated account with a project of its own. On a\ndefault install, self-register.\n\n  POST /api/rpc/command/import-binfile\n  Cookie: \u003cattacker session\u003e\n  Content-Type: multipart/form-data\n\n    project-id = \u003ca project the attacker owns\u003e   ; checked\n    file-id    = \u003cthe victim\u0027s file\u003e             ; NOT checked\n    file       = \u003ca valid single-file .penpot archive\u003e\n\nThe obvious objection is that file ids are random UUIDs, so how do you\naim it. In practice they leak through entirely normal use, and two of\nthe three routes require no mistake by the victim:\n\n  1. Public share links. Clicking Share produces a URL with the file id\n     in it in plaintext. People send those to clients and contractors\n     all day. Whoever holds the link holds the targeting data.\n\n  2. Shared-library enumeration. Any user who has ever linked a shared\n     design-system library can read that library\u0027s file id from an\n     ordinary library-listing call. No error, no audit trail. This is\n     the route that reaches an entire organisation\u0027s design system\n     rather than one file.\n\n  3. Workspace and viewer URLs embed the file id, so it turns up in\n     screenshots, support tickets, Slack pastes and screen shares.\n\nOn attack complexity, since it came up during coordination: AC:H is\nmeant for conditions the attacker cannot arrange unilaterally. Receiving\na share link and listing shared libraries are ordinary actions any\naccount can take on its own. Complexity stays Low.\n\n\nIMPACT\n======\n\n  - Data destruction. The victim\u0027s file contents are replaced with the\n    attacker\u0027s.\n\n  - Persistent takeover. Penpot resolves file permissions by walking\n    file -\u003e project -\u003e team. Re-parenting rewrites that lineage, so the\n    attacker becomes the legitimate owner in the eyes of every other\n    endpoint, free to open, edit, export, duplicate and re-share the\n    victim\u0027s design. The file vanishes from the victim\u0027s project. They\n    cannot reach it to attempt a restore.\n\n  - Library poisoning. If the hijacked file was a shared design library,\n    every file in every other team that syncs from it starts pulling\n    attacker-controlled components, colours and typography.\n\n  - Cross-team scope. The attacker holds no authorisation on the\n    victim\u0027s team. The operation moves a resource out of that boundary\n    entirely.\n\nDesign files are not low-value data. One file can hold an unreleased\nproduct\u0027s whole interface, pre-launch brand and marketing assets, or\nmockups carrying real customer names in placeholder text. Agencies\nroutinely run one instance with a team per client and rely on team\nseparation to keep those clients confidential from each other. That\nassumption does not currently hold.\n\nThe original report also bundled a lower-severity issue with the same\nroot pattern: the realtime WebSocket channel lets a client subscribe to\na file or team topic using a client-supplied id with no permission\ncheck, allowing live exfiltration of collaborative edits and\nshared-library changes for any file whose id you know. Same mistake --\ntrusting a client-supplied identifier without re-checking it. One\ndisciplined patch closes both.\n\n\nON THE SCORE\n============\n\nThe CVE record carries 7.5 High:\n\n  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H\n\nThat is also the number on my own advisory. I publish the assigned score\nrather than mine, because the CVE record is what the ecosystem actually\nconsumes and a mismatched headline number reads as inflation. It is also\nthe number I disagree with, and I would rather argue that in the open\nthan quietly ship a different one.\n\nC:N/I:N describes the vulnerable endpoint honestly enough if you read\nthe operation as \"the victim\u0027s file is destroyed.\" But the file is not\ndestroyed. It is moved, intact, into the attacker\u0027s project, where they\ncan read and export it. That is a confidentiality loss. Its contents are\nthen attacker-controlled, and if it was a shared library that content\npropagates into other teams\u0027 files. That is an integrity loss with a\nblast radius past the original resource. Scoring it A:H only measures\nwhat the victim stopped having, not what the attacker started having.\n\nS:U has the same problem. The operation carries a resource across a team\nboundary the attacker was never authorised for; calling that scope\nunchanged treats Penpot\u0027s file store as one undifferentiated pool, which\nis precisely the assumption the product\u0027s team model tells customers is\nfalse.\n\nMy pre-assignment score was 9.9. Take that as one researcher\u0027s read, not\nas a correction to the record -- but if you are triaging this from the\n7.5 alone, triage the impact section above instead. Worth more than\neither number for that purpose: the CISA ADP Vulnrichment enrichment on\nthe same record carries an SSVC assessment of exploitation\nproof-of-concept, technical impact partial, automatable yes. I wrote the\ngeneral version of this argument up here, alongside the same pattern in\nCVE-2026-16751:\n\n  https://vokecyber.com/blog/when-cvss-scores-the-endpoint-not-the-loss\n\n\nMITIGATIONS\n===========\n\nNo fixed release to upgrade to, so, in order of value:\n\n  1. Disable open self-registration. Does not fix the bug. Removes the\n     sign-up-and-attack path and takes the score to 6.5, since the\n     attacker then needs an account somebody gave them.\n\n  2. Treat every account on the instance as having write access to every\n     file on it, and plan accordingly. If you rely on team separation\n     for client confidentiality, consider separate instances for\n     genuinely sensitive work until this is fixed.\n\n  3. Audit for prior exploitation. Look for file rows whose owning\n     project changed with no corresponding user action, and for edits\n     written by a profile that is not a member of the file\u0027s team. An\n     in-place import does not leave a normal change row behind, so the\n     signal to chase is a file whose project lineage no longer matches\n     the accounts that historically edited it.\n\n  4. Keep backups outs"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-639",
              "description": "CWE-639",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-862",
              "description": "CWE-862",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-02T04:57:32Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/47"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Sep/47"
        },
        {
          "url": "https://github.com/penpot/penpot"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://penpot.app/"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        },
        {
          "url": "https://vokecyber.com"
        },
        {
          "url": "https://vokecyber.com/blog/cve-2026-17613-penpot-cross-team-file-takeover"
        },
        {
          "url": "https://vokecyber.com/blog/when-cvss-scores-the-endpoint-not-the-loss"
        },
        {
          "url": "https://vokecyber.com/research"
        },
        {
          "url": "https://vokecyber.com/research/cve-2026-17613-penpot-cross-team-file-takeover"
        },
        {
          "url": "https://www.cve.org/CVERecord?id=CVE-2026-17613"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Sep/47"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "CVE-2026-17613: Penpot cross-team file takeover via import-binfile (unpatched in 2.17.2)",
      "x_gcve": [
        {
          "recordType": "analysis",
          "relationships": [
            {
              "destId": "CVE-2026-16751",
              "type": "related"
            },
            {
              "destId": "CVE-2026-17613",
              "type": "related"
            }
          ],
          "vulnId": "GCVE-1988-2026-0413",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/47",
            "automated": true,
            "contentSha256": "dfb7136b474f69e1d616f18aaa2b95b5cb066a235d2de07ebdadf391f9cd9332",
            "evidenceScore": 11,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Sep/47",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-09-11T02:20:54Z"
          }
        },
        {
          "recordType": "advisory",
          "vulnId": "gcve-1988-2026-0413"
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-10-02T04:57:32Z",
    "dateUpdated": "2026-10-02T04:57:32Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0413"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}