CWE-281

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "uu_mkfifo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35341"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281",
      "CWE-732"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-06T21:53:34Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "When `mkfifo()` fails (e.g. target already exists), the code shows an error but is missing a `continue;`, so it falls through to `fs::set_permissions` and changes the permissions of the pre-existing file to the default FIFO mode (`0o666` \u0026 umask -\u003e `0644`).\n\n```\n$ touch secret; chmod 000 secret\n$ coreutils mkfifo secret fifo3 fifo4\nmkfifo: cannot create fifo \u0027secret\u0027: File exists\n$ ll secret      # uutils:\nprw-r--r-- secret   # changed to 644 (GNU leaves it 000)\n```\n\n**Impact:** an attacker (or user error) can relax permissions on sensitive owner-only files such as SSH private keys, exposing them to other users. Recommendation: add `continue;` after the error.\n\n**Remediation:** Acknowledged by Canonical; fixed in PR #10376.\n\n---\n_Reported by Zellic in the *uutils coreutils Program Security Assessment* (prepared for Canonical, Jan 20 2026), audited commit `3a07ffc5a9bd4c283e75afa548ba1f1957bad242`. Finding 3.8. Credit: Zellic._\n\n_Upstream tracking issue: https://github.com/uutils/coreutils/issues/10020 \u00b7 CVE-2026-35341_",
  "id": "GHSA-pmf6-rcx4-v53v",
  "modified": "2026-07-06T21:53:34Z",
  "published": "2026-07-06T21:53:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/uutils/coreutils/security/advisories/GHSA-pmf6-rcx4-v53v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35341"
    },
    {
      "type": "WEB",
      "url": "https://github.com/uutils/coreutils/issues/10020"
    },
    {
      "type": "WEB",
      "url": "https://github.com/uutils/coreutils/pull/10376"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/uutils/coreutils"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "mkfifo: permissions of an existing file are changed after FIFO creation fails"
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-2787"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-27T12:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Schroot before 1.6.13 had too permissive rules on chroot or session names, allowing a denial of service on the schroot service for all users that may start a schroot session.",
  "id": "GHSA-pmr6-f78j-pq2c",
  "modified": "2022-09-02T00:01:06Z",
  "published": "2022-08-28T00:00:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2787"
    },
    {
      "type": "WEB",
      "url": "https://codeberg.org/shelter/reschroot/commit/6f7166a285e1e97aea390be633591f9791b29a6d"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/08/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-security-announce/2022/msg00182.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202210-11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-32465"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-04T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "An incorrect permission preservation vulnerability in Trend Micro Apex One, Apex One as a Service and OfficeScan XG SP1 could allow a remote user to perform an attack and bypass authentication on affected installations. Please note: an attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.",
  "id": "GHSA-pmr9-53h4-q7gr",
  "modified": "2022-05-24T19:09:54Z",
  "published": "2022-05-24T19:09:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32465"
    },
    {
      "type": "WEB",
      "url": "https://success.trendmicro.com/jp/solution/000287796"
    },
    {
      "type": "WEB",
      "url": "https://success.trendmicro.com/solution/000287819"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-21-911"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-1386"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-24T16:15:11Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in the 9p passthrough filesystem (9pfs) implementation in QEMU. When a local user in the guest writes an executable file with SUID or SGID, none of these privileged bits are correctly dropped. As a result, in rare circumstances, this flaw could be used by malicious users in the guest to elevate their privileges within the guest and help a host local user to elevate privileges on the host.",
  "id": "GHSA-ppj8-867g-rgjr",
  "modified": "2024-04-17T18:31:30Z",
  "published": "2023-07-24T18:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1386"
    },
    {
      "type": "WEB",
      "url": "https://github.com/v9fs/linux/issues/29"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-1386"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2223985"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-ppj8-867g-rgjr"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20230831-0005"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2020-13230"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-05-20T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In Cacti before 1.2.11, disabling a user account does not immediately invalidate any permissions granted to that account (e.g., permission to view logs).",
  "id": "GHSA-pqfc-vh74-fmv2",
  "modified": "2022-05-24T17:18:12Z",
  "published": "2022-05-24T17:18:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13230"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Cacti/cacti/issues/3343"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Cacti/cacti/releases/tag/release%2F1.2.11"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/03/msg00038.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ICJMWSY77IIGZYR6FE6NAQZFBO42VECO"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/Q3PCDGNELH7HEBIXRNT5J5EWQEXQAU6B"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-41644"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-06T22:15:20Z",
    "severity": "CRITICAL"
  },
  "details": "Insecure Permissions vulnerability in Open Robotics Robotic Operating System 2 ROS2 navigation2 v.humble allows an attacker to execute arbitrary code via the dyn_param_handler_ component.",
  "id": "GHSA-pxqf-jg9m-j88f",
  "modified": "2024-12-12T03:32:59Z",
  "published": "2024-12-07T00:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41644"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ros-navigation/navigation2/issues/4496"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ros-navigation/navigation2/pull/4521"
    },
    {
      "type": "WEB",
      "url": "https://github.com/GoesM/ROS-CVE-CNVDs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-27858"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-17T00:15:47Z",
    "severity": "MODERATE"
  },
  "details": "A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15. An app may be able to access protected user data.",
  "id": "GHSA-q27x-q82p-47rv",
  "modified": "2025-11-04T18:31:19Z",
  "published": "2024-09-17T00:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27858"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/121238"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Sep/33"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-31923"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-22T15:15:09Z",
    "severity": "HIGH"
  },
  "details": "Suprema BioStar 2 before 2022 Q4, v2.9.1 has Insecure Permissions. A vulnerability in the web application allows an authenticated attacker with \"User Operator\" privileges to create a highly privileged user account. The vulnerability is caused by missing server-side validation, which can be exploited to gain full administrator privileges on the system.",
  "id": "GHSA-q32m-5wqx-f57m",
  "modified": "2024-04-04T04:16:23Z",
  "published": "2023-05-22T15:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31923"
    },
    {
      "type": "WEB",
      "url": "https://nobugescapes.com/blog/creating-a-new-user-with-admin-privilege"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2017-5033"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-04-24T23:59:00Z",
    "severity": "MODERATE"
  },
  "details": "Blink in Google Chrome prior to 57.0.2987.98 for Mac, Windows, and Linux and 57.0.2987.108 for Android failed to correctly propagate CSP restrictions to local scheme pages, which allowed a remote attacker to bypass content security policy via a crafted HTML page, related to the unsafe-inline keyword.",
  "id": "GHSA-q3xm-785w-f7gp",
  "modified": "2022-04-30T00:02:22Z",
  "published": "2022-04-30T00:02:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5033"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2017/03/stable-channel-update-for-desktop.html"
    },
    {
      "type": "WEB",
      "url": "https://crbug.com/669086"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201704-02"
    },
    {
      "type": "WEB",
      "url": "https://twitter.com/Ma7h1as/status/907641276434063361"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2017-0499.html"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2017/dsa-3810"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/96767"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-58510"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-281",
      "CWE-359"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T21:51:41Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nGHSA-8fwc-qjw5-rvgp (\"Gitea may send release notification emails for private repositories to users whose access has been revoked\", fix in PR #36319 / commit 8a98ac22) added `repo_model.ClearRepoWatches` as a defense for the state transition public\u2192private. The cleanup was wired into `services/repository/repository.go::MakeRepoPrivate` only. The sister helper `services/repository/repository.go::updateRepository` \u2014 which is the function used by the API path `PATCH /api/v1/repos/{owner}/{repo}` \u2014 was not patched and still calls `ClearRepoStars` only.\n\nAs a result, when a public repository is flipped to private via the REST API (rather than via the web Settings \u2192 Danger Zone UI), the watch records persist. Affected users can:\n\n- See the now-private repository in `GET /api/v1/user/subscriptions?private=true` along with its full `Repository` JSON (description, default branch, language, fork status, counts, mirror metadata, license list, etc.) \u2014 even though they have no access to the repository.\n- Have their stale watch records re-leak content through any future notification path that does not include the send-time `CheckRepoUnitUser` check that was added to `services/mailer/mail_release.go`.\n- Inflate the visible `NumWatches` counter on the repository.\n\n## Severity\n\nMedium \u2014 `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N`\n\nSame impact class as the original GHSA-8fwc-qjw5-rvgp (which was classified Medium). The send-time mail filter added in the same PR mitigates the release-content disclosure vector. The residual leak is repo metadata via the subscriptions endpoint and stale watcher counts.\n\nCWE-281 (Improper Preservation of Permissions), CWE-359 (Exposure of Private Personal Information), CWE-200 (Exposure of Sensitive Information).\n\n## Affected Versions\n\nEvery release starting from v1.25.4 (the release shipping the original GHSA-8fwc-qjw5-rvgp fix) through HEAD (master @ `ef801bb6`, 2026-05-16). The follow-up refactor in commit `943ff752` (PR #36959, 2026-03-24) which merged `MakeRepoPublic`+`MakeRepoPrivate` did not propagate the `ClearRepoWatches` call to `updateRepository`.\n\n## Affected Component\n\n- `services/repository/repository.go:240-302` \u2014 `func updateRepository(ctx, repo, visibilityChanged bool)`, the sister helper called via the API path. Clears stars on line 273 but never calls `ClearRepoWatches`.\n- `routers/api/v1/repo/repo.go::Edit` (line 573) \u2192 `updateBasicProperties` (line 678-697) \u2192 `repo_service.UpdateRepository(ctx, repo, visibilityChanged)` (line 726) \u2014 the API path that exercises the sister helper.\n\n## Steps to Reproduce\n\nThe bug is observable purely from static analysis; the live PoC is straightforward.\n\n1. Start a Gitea instance at any release from v1.25.4 onwards (verified static at HEAD `ef801bb6`).\n\n2. Create users `A` (org admin) and `B` (member). Create a public repository `A/proj`. As `B`, watch the repo:\n   ```\n   curl -u B:\u003ctoken\u003e -X PUT \"https://gitea.example.com/api/v1/repos/A/proj/subscription\"\n   ```\n\n3. As `A`, flip the repo to private via the REST API (not via the web UI):\n   ```\n   curl -u A:\u003ctoken\u003e -X PATCH \"https://gitea.example.com/api/v1/repos/A/proj\" \\\n        -H \u0027Content-Type: application/json\u0027 \\\n        -d \u0027{\"private\": true}\u0027\n   ```\n\n4. As `B`, list `B`\u0027s watched repos with `private=true`:\n   ```\n   curl -u B:\u003ctoken\u003e \"https://gitea.example.com/api/v1/user/subscriptions\"\n   ```\n\n   The now-private repo `A/proj` is returned in `B`\u0027s subscription list, with the full `Repository` payload \u2014 including `description`, `default_branch`, `language`, `topics`, `license`, fork/branch/issue/release counts, etc.\n\n5. Compare with the web-UI path (which IS patched). As `A`, flip a different public repo `A/proj2` to private via Settings \u2192 Danger Zone \u2192 \"Make this repository private\" (which calls `repo_service.MakeRepoPrivate`). Verify `B`\u0027s subscription list no longer contains `A/proj2`.\n\nThe asymmetry of outcomes between steps 4 and 5 \u2014 for the same state transition \u2014 is the gap.\n\n## Direct Evidence (no PoC needed)\n\n```\n$ gh api repos/go-gitea/gitea/contents/services/repository/repository.go \\\n    --jq .content | base64 -d | grep -n \"ClearRepoWatches\\|ClearRepoStars\" \n\n154:                  if err = repo_model.ClearRepoStars(ctx, repo.ID); err != nil {\n157:                  if err = repo_model.ClearRepoWatches(ctx, repo.ID); err != nil {  # MakeRepoPrivate\n273:                  if err = repo_model.ClearRepoStars(ctx, repo.ID); err != nil {  # updateRepository \u2014 ClearRepoWatches missing here\n```\n\nThe fix-author\u0027s own test file confirms the asymmetry:\n\n```\n$ gh api repos/go-gitea/gitea/contents/services/repository/repository_test.go --jq .content | base64 -d | grep -n \"Test.*VisibilityChanged\\|Test.*ClearsWatches\"\n\n44:func TestUpdateRepositoryVisibilityChanged(t *testing.T) {     # only checks act.IsPrivate\n73:func TestMakeRepoPrivateClearsWatches(t *testing.T) {           # checks watches are cleared\n```\n\n`TestUpdateRepositoryVisibilityChanged` explicitly calls `updateRepository(ctx, repo, true)` (line 53) and asserts `act.IsPrivate` (line 61) \u2014 but never verifies `GetRepoWatchersIDs` returns empty, while the parallel `TestMakeRepoPrivateClearsWatches` does. The test asymmetry mirrors the fix asymmetry.\n\n## Impact\n\n- An organization that uses [terraform-gitea](https://github.com/go-gitea/terraform-provider-gitea) or any other REST-API-driven automation to flip repositories private (the canonical IaC pattern) hits `updateRepository`, not `MakeRepoPrivate`.\n- An organization using the official Gitea SDK (`go-sdk`, `py-gitea`, etc.) or `curl` scripts to make repos private after an internal policy change hits the same path.\n- Multi-tenant Gitea-as-a-service operators with API-driven repository-lifecycle endpoints are exposed.\n\nStale watch rows leak through `GET /user/subscriptions` (with the watcher\u0027s own credentials), `GET /repos/{owner}/{repo}/subscribers` (stale `NumWatches` total), and become a re-leak surface for any future notification path that forgets the send-time access check.\n\n## Suggested Fix\n\nDrop-in mirror of the call already present in `MakeRepoPrivate`. In `services/repository/repository.go::updateRepository`, inside the existing `if repo.IsPrivate { ... }` branch (around line 265-276), add the `ClearRepoWatches` call directly after `ClearRepoStars`:\n\n```go\n// services/repository/repository.go\nfunc updateRepository(ctx context.Context, repo *repo_model.Repository, visibilityChanged bool) (err error) {\n    ...\n    if visibilityChanged {\n        ...\n        // If repo has become private, we need to set its actions to private.\n        if repo.IsPrivate {\n            _, err = e.Where(\"repo_id = ?\", repo.ID).Cols(\"is_private\").Update(\u0026activities_model.Action{\n                IsPrivate: true,\n            })\n            if err != nil {\n                return err\n            }\n\n            if err = repo_model.ClearRepoStars(ctx, repo.ID); err != nil {\n                return err\n            }\n\n            // Match MakeRepoPrivate\u0027s behavior \u2014 see PR #36319 / GHSA-8fwc-qjw5-rvgp.\n            // Stale watch rows on a now-private repo leak repository metadata to ex-watchers\n            // via GET /user/subscriptions?private=true and through any future notification\n            // path that does not have a send-time access check.\n            if err = repo_model.ClearRepoWatches(ctx, repo.ID); err != nil {\n                return err\n            }\n        }\n        ...\n    }\n    ...\n}\n```\n\nRegression test (mirror of `TestMakeRepoPrivateClearsWatches`) to add to `services/repository/repository_test.go`:\n\n```go\nfunc TestUpdateRepositoryClearsWatchesOnVisibilityChange(t *testing.T) {\n    assert.NoError(t, unittest.PrepareTestDatabase())\n\n    repo := unittest.AssertExistsAndLoadBean(t, \u0026repo_model.Repository{ID: 1})\n    assert.False(t, repo.IsPrivate)\n\n    watchers, err := repo_model.GetRepoWatchersIDs(t.Context(), repo.ID)\n    require.NoError(t, err)\n    require.NotEmpty(t, watchers)\n\n    repo.IsPrivate = true\n    assert.NoError(t, updateRepository(t.Context(), repo, true))\n\n    watchers, err = repo_model.GetRepoWatchersIDs(t.Context(), repo.ID)\n    assert.NoError(t, err)\n    assert.Empty(t, watchers)\n\n    updatedRepo := unittest.AssertExistsAndLoadBean(t, \u0026repo_model.Repository{ID: repo.ID})\n    assert.Zero(t, updatedRepo.NumWatches)\n}\n```\n\nOptional belt-and-suspenders: an integration test against `PATCH /api/v1/repos/{owner}/{repo}` with body `{\"private\": true}` that exercises the entire API path through `routers/api/v1/repo/repo.go::Edit`.\n\n## Discovery Methodology\n\nThis finding follows the \"sister-fix-incomplete\" lens that has been productive across several recent reports: pick a recent advisory where the fix lands as a single PR touching one function, then grep the codebase for parallel call sites that should have received the same defense.\n\nFor Gitea:\n\n1. Enumerate recent advisories via `gh api graphql ... securityVulnerabilities(ecosystem: GO, package: code.gitea.io/gitea)`.\n2. GHSA-8fwc-qjw5-rvgp stood out because the description names a state transition (public\u2192private) \u2014 a class of bug where the defense is typically wired into a single helper.\n3. `gh api repos/.../commits/8a98ac221 --jq \u0027.files[] | .filename\u0027` listed the fix files; `ClearRepoWatches` was added to one function.\n4. `grep -rn \"ClearRepoWatches\\|MakeRepoPrivate\"` revealed two functions in `services/repository/repository.go` that handle the state transition: `MakeRepoPrivate` (patched) and the lowercase sister `updateRepository` (unpatched).\n5. Walked the call chain from `routers/api/v1/repo/repo.go::Edit` to confirm the API path uses `updateRepository`, not `MakeRepoPrivate`.\n\n## Pre-emptive rebuttals\n\n- \"The send-time filter in `MailNewRelease` already blocks release-content disclosure\" \u2014 Correct, and acknowledged. The residual leak this report concerns is metadata via the `GET /user/subscriptions` endpoint and stale `NumWatches`. The send-time filter is a necessary but not sufficient defense; the `ClearRepoWatches` call is the persistence-side belt-and-suspenders that the original PR author explicitly added.\n- \"The web UI is the supported path; the API path is not in scope\" \u2014 The API is documented public surface (swagger spec in `templates/swagger/v1_json.tmpl`), Gitea ships official SDKs (`go-sdk`, `py-gitea`) that use exactly this path, and there is an official Terraform provider that exercises it. The existing fix is in a sister helper used by both paths\u0027 upstream helper \u2014 the fix author plainly intended to defend both.\n- \"AccessMode is `None` in the subscription response, so the client should infer no-access\" \u2014 The response still returns the full `Repository` payload including description, default branch, language, fork status, counts, mirror metadata, OriginalURL, license, etc. (see `services/convert/repository.go::innerToRepo` line 189-259). `AccessMode: 0` does not gate the metadata fields, only the `Permissions{Admin,Push,Pull}` triple.\n\n## References\n\n- GHSA-8fwc-qjw5-rvgp \u2014 the original advisory: https://github.com/go-gitea/gitea/security/advisories/GHSA-8fwc-qjw5-rvgp\n- PR #36319 \"clean watches when make a repository private and check permission when send release emails\" (commit `8a98ac221`)\n- PR #36959 \"Require additional user confirmation for making repo private\" (commit `943ff7523`) \u2014 the later refactor that did not propagate the cleanup\n- Patched function: `services/repository/repository.go::MakeRepoPrivate` (line 125, calls `ClearRepoWatches` line 157)\n- Unpatched sister: `services/repository/repository.go::updateRepository` (line 240, calls only `ClearRepoStars` line 273)\n- API entry: `routers/api/v1/repo/repo.go::Edit` \u2192 `updateBasicProperties` \u2192 `repo_service.UpdateRepository` \u2192 `updateRepository`\n- Test asymmetry: `services/repository/repository_test.go::TestMakeRepoPrivateClearsWatches` (covered) vs `TestUpdateRepositoryVisibilityChanged` (does not assert watches cleared)",
  "id": "GHSA-q423-49rw-g9mh",
  "modified": "2026-07-21T21:51:41Z",
  "published": "2026-07-21T21:51:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-q423-49rw-g9mh"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: GHSA-8fwc-qjw5-rvgp ClearRepoWatches fix not applied to API EditRepo path \u2014 sister code path retains stale watches on public-\u003eprivate"
}