Common Weakness Enumeration

CWE-359

Allowed

Exposure of Private Personal Information to an Unauthorized Actor

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product does not properly prevent a person's private, personal information from being accessed by actors who either (1) are not explicitly authorized to access the information or (2) do not have the implicit consent of the person about whom the information is collected.

335 vulnerabilities reference this CWE, most recent first.

GHSA-PG4M-3GP6-HW4W

Vulnerability from github – Published: 2024-09-18 14:26 – Updated: 2024-09-18 19:23
VLAI
Summary
org.xwiki.platform:xwiki-platform-notifications-ui leaks data of notification filters of users
Details

Impact

It's possible to get access to notification filters of any user by using a URL such as <hostname>xwiki/bin/get/XWiki/Notifications/Code/NotificationFilterPreferenceLivetableResults?outputSyntax=plain&type=custom&user=<username>. This vulnerability impacts all versions of XWiki since 13.2-rc-1. The filters do not provide much information (they mainly contain references which are public data in XWiki), though some info could be used in combination with other vulnerabilities.

Patches

The vulnerability has been patched in XWiki 14.10.21, 15.5.5, 15.10.1, 16.0RC1. The patch consists in checking the rights of the user when sending the data.

Workarounds

It's possible to workaround the vulnerability by applying manually the patch: it's possible for an administrator to edit directly the document XWiki.Notifications.Code.NotificationFilterPreferenceLivetableResults to apply the same changes as in the patch. See c8c6545f9bde6f5aade994aa5b5903a67b5c2582.

References

  • Jira ticket: https://jira.xwiki.org/browse/XWIKI-20336
  • Commit: c8c6545f9bde6f5aade994aa5b5903a67b5c2582

For more information

If you have any questions or comments about this advisory: * Open an issue in Jira XWiki.org * Email us at Security Mailing List

Attribution

This vulnerability has been reported on Intigriti by Mete.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-notifications-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "13.2-rc-1"
            },
            {
              "fixed": "14.10.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-notifications-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.0-rc-1"
            },
            {
              "fixed": "15.5.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-notifications-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.6-rc-1"
            },
            {
              "fixed": "15.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-46979"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-359"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-18T14:26:20Z",
    "nvd_published_at": "2024-09-18T18:15:07Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nIt\u0027s possible to get access to notification filters of any user by using a URL such as `\u003chostname\u003exwiki/bin/get/XWiki/Notifications/Code/NotificationFilterPreferenceLivetableResults?outputSyntax=plain\u0026type=custom\u0026user=\u003cusername\u003e`. This vulnerability impacts all versions of XWiki since 13.2-rc-1.\nThe filters do not provide much information (they mainly contain references which are public data in XWiki), though some info could be used in combination with other vulnerabilities.\n\n### Patches\n\nThe vulnerability has been patched in XWiki 14.10.21, 15.5.5, 15.10.1, 16.0RC1. \nThe patch consists in checking the rights of the user when sending the data.\n\n### Workarounds\n\nIt\u0027s possible to workaround the vulnerability by applying manually the patch: it\u0027s possible for an administrator to edit directly the document `XWiki.Notifications.Code.NotificationFilterPreferenceLivetableResults` to apply the same changes as in the patch. See c8c6545f9bde6f5aade994aa5b5903a67b5c2582.\n\n### References\n\n  * Jira ticket: https://jira.xwiki.org/browse/XWIKI-20336\n  * Commit: c8c6545f9bde6f5aade994aa5b5903a67b5c2582\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)\n* Email us at [Security Mailing List](mailto:security@xwiki.org)\n\n### Attribution\n\nThis vulnerability has been reported on Intigriti by [Mete](https://www.linkedin.com/in/metehan-kalkan-5a3201199).",
  "id": "GHSA-pg4m-3gp6-hw4w",
  "modified": "2024-09-18T19:23:22Z",
  "published": "2024-09-18T14:26:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-pg4m-3gp6-hw4w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46979"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/29e5edbb2b7068ada17290cea41e0aa8144e1294"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/a0352922a1a61e0e858a9be89d73f0665630a63a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/c8c6545f9bde6f5aade994aa5b5903a67b5c2582"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/ed090d1aa228848d3860968c437b72db3b09119f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xwiki/xwiki-platform"
    },
    {
      "type": "WEB",
      "url": "https://jira.xwiki.org/browse/XWIKI-20336"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "org.xwiki.platform:xwiki-platform-notifications-ui leaks data of notification filters of users"
}

GHSA-PP6W-GFJ2-HQ6C

Vulnerability from github – Published: 2026-07-03 21:31 – Updated: 2026-07-03 21:31
VLAI
Details

Exposure of private personal information to an unauthorized actor in Microsoft Edge for Android allows an unauthorized attacker to disclose information over a network.

Severity
7.1 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-58297"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-359"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-03T21:17:04Z",
    "severity": "HIGH"
  },
  "details": "Exposure of private personal information to an unauthorized actor in Microsoft Edge for Android allows an unauthorized attacker to disclose information over a network.",
  "id": "GHSA-pp6w-gfj2-hq6c",
  "modified": "2026-07-03T21:31:40Z",
  "published": "2026-07-03T21:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58297"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-58297"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PPGF-6V2C-6GGR

Vulnerability from github – Published: 2025-12-18 15:30 – Updated: 2026-06-06 09:31
VLAI
Details

Exposure of Private Personal Information to an Unauthorized Actor vulnerability in Utarit Informatics Services Inc. SoliClub allows Query System for Information.This issue affects SoliClub: from 5.2.4 before 5.3.7.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-1030"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-359"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-18T15:15:53Z",
    "severity": "HIGH"
  },
  "details": "Exposure of Private Personal Information to an Unauthorized Actor vulnerability in Utarit Informatics Services Inc. SoliClub allows Query System for Information.This issue affects SoliClub: from 5.2.4 before 5.3.7.",
  "id": "GHSA-ppgf-6v2c-6ggr",
  "modified": "2026-06-06T09:31:14Z",
  "published": "2025-12-18T15:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1030"
    },
    {
      "type": "WEB",
      "url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-25-0466"
    },
    {
      "type": "WEB",
      "url": "https://www.usom.gov.tr/bildirim/tr-25-0466"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PPHQ-XPJC-VGQX

Vulnerability from github – Published: 2025-04-02 09:30 – Updated: 2025-11-03 21:33
VLAI
Details

Zabbix API user.get returns all users that share common group with the calling user. This includes media and other information, such as login attempts, etc.

Severity
3.5 (Low)
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
2.1 (Low)
CVSS:4.0/AV:A/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-42325"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-359"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-02T07:15:41Z",
    "severity": "LOW"
  },
  "details": "Zabbix API user.get returns all users that share common group with the calling user. This includes media and other information, such as login attempts, etc.",
  "id": "GHSA-pphq-xpjc-vgqx",
  "modified": "2025-11-03T21:33:27Z",
  "published": "2025-04-02T09:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42325"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/04/msg00027.html"
    },
    {
      "type": "WEB",
      "url": "https://support.zabbix.com/browse/ZBX-26258"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-PVMM-55R5-G3MM

Vulnerability from github – Published: 2024-09-10 15:53 – Updated: 2024-09-10 19:01
VLAI
Summary
XWiki Platform document history including authors of any page exposed to unauthorized actors
Details

Impact

The REST API exposes the history of any page in XWiki of which the attacker knows the name. The exposed information includes for each modification of the page the time of the modification, the version number, the author of the modification (both username and displayed name) and the version comment. This information is exposed regardless of the rights setup, and even when the wiki is configured to be fully private.

On a private wiki, this can be tested by accessing /xwiki/rest/wikis/xwiki/spaces/Main/pages/WebHome/history, if this shows the history of the main page then the installation is vulnerable.

Patches

This has been patched in XWiki 15.10.9 and XWiki 16.3.0RC1.

Workarounds

There aren't any known workarounds apart from upgrading to a fixed version.

References

  • https://jira.xwiki.org/browse/XWIKI-22052
  • https://github.com/xwiki/xwiki-platform/commit/9cbca9808300797c67779bb9a665d85cf9e3d4b8
Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-rest-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.8.0"
            },
            {
              "fixed": "15.10.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-rest-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "16.0.0-rc-1"
            },
            {
              "fixed": "16.3.0-rc-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-45591"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-359",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-10T15:53:27Z",
    "nvd_published_at": "2024-09-10T16:15:21Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe REST API exposes the history of any page in XWiki of which the attacker knows the name. The exposed information includes for each modification of the page the time of the modification, the version number, the author of the modification (both username and displayed name) and the version comment. This information is exposed regardless of the rights setup, and even when the wiki is configured to be fully private.\n\nOn a private wiki, this can be tested by accessing `/xwiki/rest/wikis/xwiki/spaces/Main/pages/WebHome/history`, if this shows the history of the main page then the installation is vulnerable.\n\n### Patches\nThis has been patched in XWiki 15.10.9 and XWiki 16.3.0RC1.\n\n### Workarounds\nThere aren\u0027t any known workarounds apart from upgrading to a fixed version.\n\n### References\n* https://jira.xwiki.org/browse/XWIKI-22052\n* https://github.com/xwiki/xwiki-platform/commit/9cbca9808300797c67779bb9a665d85cf9e3d4b8\n",
  "id": "GHSA-pvmm-55r5-g3mm",
  "modified": "2024-09-10T19:01:52Z",
  "published": "2024-09-10T15:53:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-pvmm-55r5-g3mm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45591"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/26482ee5d29fc21f31134d1ee13db48716e89e0f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/9cbca9808300797c67779bb9a665d85cf9e3d4b8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xwiki/xwiki-platform"
    },
    {
      "type": "WEB",
      "url": "https://jira.xwiki.org/browse/XWIKI-22052"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "XWiki Platform document history including authors of any page exposed to unauthorized actors"
}

GHSA-Q423-49RW-G9MH

Vulnerability from github – Published: 2026-07-21 21:51 – Updated: 2026-07-21 21:51
VLAI
Summary
Gitea: GHSA-8fwc-qjw5-rvgp ClearRepoWatches fix not applied to API EditRepo path — sister code path retains stale watches on public->private
Details

Summary

GHSA-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→private. The cleanup was wired into services/repository/repository.go::MakeRepoPrivate only. The sister helper services/repository/repository.go::updateRepository — which is the function used by the API path PATCH /api/v1/repos/{owner}/{repo} — was not patched and still calls ClearRepoStars only.

As a result, when a public repository is flipped to private via the REST API (rather than via the web Settings → Danger Zone UI), the watch records persist. Affected users can:

  • 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.) — even though they have no access to the repository.
  • 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.
  • Inflate the visible NumWatches counter on the repository.

Severity

Medium — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Same 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.

CWE-281 (Improper Preservation of Permissions), CWE-359 (Exposure of Private Personal Information), CWE-200 (Exposure of Sensitive Information).

Affected Versions

Every 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.

Affected Component

  • services/repository/repository.go:240-302 — func updateRepository(ctx, repo, visibilityChanged bool), the sister helper called via the API path. Clears stars on line 273 but never calls ClearRepoWatches.
  • routers/api/v1/repo/repo.go::Edit (line 573) → updateBasicProperties (line 678-697) → repo_service.UpdateRepository(ctx, repo, visibilityChanged) (line 726) — the API path that exercises the sister helper.

Steps to Reproduce

The bug is observable purely from static analysis; the live PoC is straightforward.

  1. Start a Gitea instance at any release from v1.25.4 onwards (verified static at HEAD ef801bb6).

  2. Create users A (org admin) and B (member). Create a public repository A/proj. As B, watch the repo: curl -u B:<token> -X PUT "https://gitea.example.com/api/v1/repos/A/proj/subscription"

  3. As A, flip the repo to private via the REST API (not via the web UI): curl -u A:<token> -X PATCH "https://gitea.example.com/api/v1/repos/A/proj" \ -H 'Content-Type: application/json' \ -d '{"private": true}'

  4. As B, list B's watched repos with private=true: curl -u B:<token> "https://gitea.example.com/api/v1/user/subscriptions"

The now-private repo A/proj is returned in B's subscription list, with the full Repository payload — including description, default_branch, language, topics, license, fork/branch/issue/release counts, etc.

  1. Compare with the web-UI path (which IS patched). As A, flip a different public repo A/proj2 to private via Settings → Danger Zone → "Make this repository private" (which calls repo_service.MakeRepoPrivate). Verify B's subscription list no longer contains A/proj2.

The asymmetry of outcomes between steps 4 and 5 — for the same state transition — is the gap.

Direct Evidence (no PoC needed)

$ gh api repos/go-gitea/gitea/contents/services/repository/repository.go \
    --jq .content | base64 -d | grep -n "ClearRepoWatches\|ClearRepoStars" 

154:                  if err = repo_model.ClearRepoStars(ctx, repo.ID); err != nil {
157:                  if err = repo_model.ClearRepoWatches(ctx, repo.ID); err != nil {  # MakeRepoPrivate
273:                  if err = repo_model.ClearRepoStars(ctx, repo.ID); err != nil {  # updateRepository — ClearRepoWatches missing here

The fix-author's own test file confirms the asymmetry:

$ gh api repos/go-gitea/gitea/contents/services/repository/repository_test.go --jq .content | base64 -d | grep -n "Test.*VisibilityChanged\|Test.*ClearsWatches"

44:func TestUpdateRepositoryVisibilityChanged(t *testing.T) {     # only checks act.IsPrivate
73:func TestMakeRepoPrivateClearsWatches(t *testing.T) {           # checks watches are cleared

TestUpdateRepositoryVisibilityChanged explicitly calls updateRepository(ctx, repo, true) (line 53) and asserts act.IsPrivate (line 61) — but never verifies GetRepoWatchersIDs returns empty, while the parallel TestMakeRepoPrivateClearsWatches does. The test asymmetry mirrors the fix asymmetry.

Impact

  • An organization that uses terraform-gitea or any other REST-API-driven automation to flip repositories private (the canonical IaC pattern) hits updateRepository, not MakeRepoPrivate.
  • 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.
  • Multi-tenant Gitea-as-a-service operators with API-driven repository-lifecycle endpoints are exposed.

Stale watch rows leak through GET /user/subscriptions (with the watcher's 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.

Suggested Fix

Drop-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:

// services/repository/repository.go
func updateRepository(ctx context.Context, repo *repo_model.Repository, visibilityChanged bool) (err error) {
    ...
    if visibilityChanged {
        ...
        // If repo has become private, we need to set its actions to private.
        if repo.IsPrivate {
            _, err = e.Where("repo_id = ?", repo.ID).Cols("is_private").Update(&activities_model.Action{
                IsPrivate: true,
            })
            if err != nil {
                return err
            }

            if err = repo_model.ClearRepoStars(ctx, repo.ID); err != nil {
                return err
            }

            // Match MakeRepoPrivate's behavior — see PR #36319 / GHSA-8fwc-qjw5-rvgp.
            // Stale watch rows on a now-private repo leak repository metadata to ex-watchers
            // via GET /user/subscriptions?private=true and through any future notification
            // path that does not have a send-time access check.
            if err = repo_model.ClearRepoWatches(ctx, repo.ID); err != nil {
                return err
            }
        }
        ...
    }
    ...
}

Regression test (mirror of TestMakeRepoPrivateClearsWatches) to add to services/repository/repository_test.go:

func TestUpdateRepositoryClearsWatchesOnVisibilityChange(t *testing.T) {
    assert.NoError(t, unittest.PrepareTestDatabase())

    repo := unittest.AssertExistsAndLoadBean(t, &repo_model.Repository{ID: 1})
    assert.False(t, repo.IsPrivate)

    watchers, err := repo_model.GetRepoWatchersIDs(t.Context(), repo.ID)
    require.NoError(t, err)
    require.NotEmpty(t, watchers)

    repo.IsPrivate = true
    assert.NoError(t, updateRepository(t.Context(), repo, true))

    watchers, err = repo_model.GetRepoWatchersIDs(t.Context(), repo.ID)
    assert.NoError(t, err)
    assert.Empty(t, watchers)

    updatedRepo := unittest.AssertExistsAndLoadBean(t, &repo_model.Repository{ID: repo.ID})
    assert.Zero(t, updatedRepo.NumWatches)
}

Optional 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.

Discovery Methodology

This 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.

For Gitea:

  1. Enumerate recent advisories via gh api graphql ... securityVulnerabilities(ecosystem: GO, package: code.gitea.io/gitea).
  2. GHSA-8fwc-qjw5-rvgp stood out because the description names a state transition (public→private) — a class of bug where the defense is typically wired into a single helper.
  3. gh api repos/.../commits/8a98ac221 --jq '.files[] | .filename' listed the fix files; ClearRepoWatches was added to one function.
  4. 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).
  5. Walked the call chain from routers/api/v1/repo/repo.go::Edit to confirm the API path uses updateRepository, not MakeRepoPrivate.

Pre-emptive rebuttals

  • "The send-time filter in MailNewRelease already blocks release-content disclosure" — 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.
  • "The web UI is the supported path; the API path is not in scope" — 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' upstream helper — the fix author plainly intended to defend both.
  • "AccessMode is None in the subscription response, so the client should infer no-access" — 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.

References

  • GHSA-8fwc-qjw5-rvgp — the original advisory: https://github.com/go-gitea/gitea/security/advisories/GHSA-8fwc-qjw5-rvgp
  • PR #36319 "clean watches when make a repository private and check permission when send release emails" (commit 8a98ac221)
  • PR #36959 "Require additional user confirmation for making repo private" (commit 943ff7523) — the later refactor that did not propagate the cleanup
  • Patched function: services/repository/repository.go::MakeRepoPrivate (line 125, calls ClearRepoWatches line 157)
  • Unpatched sister: services/repository/repository.go::updateRepository (line 240, calls only ClearRepoStars line 273)
  • API entry: routers/api/v1/repo/repo.go::Edit → updateBasicProperties → repo_service.UpdateRepository → updateRepository
  • Test asymmetry: services/repository/repository_test.go::TestMakeRepoPrivateClearsWatches (covered) vs TestUpdateRepositoryVisibilityChanged (does not assert watches cleared)
Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "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"
}

GHSA-Q494-JHV5-R89F

Vulnerability from github – Published: 2025-03-18 21:32 – Updated: 2025-03-18 21:32
VLAI
Details

Vulnerabilities in the command line interface of AOS-CX could allow an authenticated remote attacker to expose sensitive information. Successful exploitation could allow an attacker to gain unauthorized access to services outside of the impacted switch, potentially leading to lateral movement involving those services.

Severity
6.0 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-27080"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-359"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-18T19:15:50Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerabilities in the command line interface of AOS-CX could allow an authenticated remote attacker to expose sensitive information. Successful exploitation could allow an attacker to gain unauthorized access to services outside of the impacted switch, potentially leading to lateral movement involving those services.",
  "id": "GHSA-q494-jhv5-r89f",
  "modified": "2025-03-18T21:32:01Z",
  "published": "2025-03-18T21:32:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27080"
    },
    {
      "type": "WEB",
      "url": "https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04818en_us\u0026docLocale=en_US"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q4R5-8G97-825Q

Vulnerability from github – Published: 2025-11-04 03:30 – Updated: 2025-12-17 21:30
VLAI
Details

A privacy issue was addressed by removing the vulnerable code. This issue is fixed in iOS 26.1 and iPadOS 26.1, macOS Sequoia 15.7.2, macOS Sonoma 14.8.2, visionOS 26.1. An app may be able to access sensitive user data.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-43389"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-359"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-04T02:15:45Z",
    "severity": "HIGH"
  },
  "details": "A privacy issue was addressed by removing the vulnerable code. This issue is fixed in iOS 26.1 and iPadOS 26.1, macOS Sequoia 15.7.2, macOS Sonoma 14.8.2, visionOS 26.1. An app may be able to access sensitive user data.",
  "id": "GHSA-q4r5-8g97-825q",
  "modified": "2025-12-17T21:30:33Z",
  "published": "2025-11-04T03:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43389"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/125632"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/125633"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/125634"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/125635"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/125636"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/125638"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q56P-C5FR-4842

Vulnerability from github – Published: 2026-08-04 18:31 – Updated: 2026-08-04 18:31
VLAI
Details

Information Disclosure when IPSec negotiation fails or is not established properly during NG-eCall SIP signaling.

Severity
6.5 (Medium)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-24078"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-359"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-04T16:16:23Z",
    "severity": "MODERATE"
  },
  "details": "Information Disclosure when IPSec negotiation fails or is not established properly during NG-eCall SIP signaling.",
  "id": "GHSA-q56p-c5fr-4842",
  "modified": "2026-08-04T18:31:26Z",
  "published": "2026-08-04T18:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24078"
    },
    {
      "type": "WEB",
      "url": "https://docs.qualcomm.com/product/publicresources/securitybulletin/august-2026-bulletin.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q64V-9MH2-3XCQ

Vulnerability from github – Published: 2025-09-30 15:30 – Updated: 2025-09-30 15:30
VLAI
Details

Cookie storage for non-HTML temporary documents was being shared incorrectly with normal browsing content, allowing information from private tabs to escape Incognito mode even after the user closed all tabs This vulnerability affects Firefox for iOS < 143.1.

Severity
4.0 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-10859"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-359"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-30T13:15:48Z",
    "severity": "MODERATE"
  },
  "details": "Cookie storage for non-HTML temporary documents was being shared incorrectly with normal browsing content, allowing information from private tabs to escape Incognito mode even after the user closed all tabs This vulnerability affects Firefox for iOS \u003c 143.1.",
  "id": "GHSA-q64v-9mh2-3xcq",
  "modified": "2025-09-30T15:30:29Z",
  "published": "2025-09-30T15:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10859"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1684624"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2025-79"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Requirements

Identify and consult all relevant regulations for personal privacy. An organization may be required to comply with certain federal and state regulations, depending on its location, the type of business it conducts, and the nature of any private data it handles. Regulations may include Safe Harbor Privacy Framework [REF-340], Gramm-Leach Bliley Act (GLBA) [REF-341], Health Insurance Portability and Accountability Act (HIPAA) [REF-342], General Data Protection Regulation (GDPR) [REF-1047], California Consumer Privacy Act (CCPA) [REF-1048], and others.

Mitigation
Architecture and Design

Carefully evaluate how secure design may interfere with privacy, and vice versa. Security and privacy concerns often seem to compete with each other. From a security perspective, all important operations should be recorded so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk. Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted.

Mitigation MIT-57
Implementation Operation

Strategy: Attack Surface Reduction

  • Some tools can automatically analyze documents to redact, strip, or "sanitize" private information, although some human review might be necessary. Tools may vary in terms of which document formats can be processed.
  • When calling an external program to automatically generate or convert documents, invoke the program with any available options that avoid generating sensitive metadata. Some formats have well-defined fields that could contain private data, such as Exchangeable image file format (Exif), which can contain potentially sensitive metadata such as geolocation, date, and time [REF-1515] [REF-1516].
CAPEC-464: Evercookie

An attacker creates a very persistent cookie that stays present even after the user thinks it has been removed. The cookie is stored on the victim's machine in over ten places. When the victim clears the cookie cache via traditional means inside the browser, that operation removes the cookie from certain places but not others. The malicious code then replicates the cookie from all of the places where it was not deleted to all of the possible storage locations once again. So the victim again has the cookie in all of the original storage locations. In other words, failure to delete the cookie in even one location will result in the cookie's resurrection everywhere. The evercookie will also persist across different browsers because certain stores (e.g., Local Shared Objects) are shared between different browsers.

CAPEC-467: Cross Site Identification

An attacker harvests identifying information about a victim via an active session that the victim's browser has with a social networking site. A victim may have the social networking site open in one tab or perhaps is simply using the "remember me" feature to keep their session with the social networking site active. An attacker induces a payload to execute in the victim's browser that transparently to the victim initiates a request to the social networking site (e.g., via available social network site APIs) to retrieve identifying information about a victim. While some of this information may be public, the attacker is able to harvest this information in context and may use it for further attacks on the user (e.g., spear phishing).

CAPEC-498: Probe iOS Screenshots

An adversary examines screenshot images created by iOS in an attempt to obtain sensitive information. This attack targets temporary screenshots created by the underlying OS while the application remains open in the background.

CAPEC-508: Shoulder Surfing

In a shoulder surfing attack, an adversary observes an unaware individual's keystrokes, screen content, or conversations with the goal of obtaining sensitive information. One motive for this attack is to obtain sensitive information about the target for financial, personal, political, or other gains. From an insider threat perspective, an additional motive could be to obtain system/application credentials or cryptographic keys. Shoulder surfing attacks are accomplished by observing the content "over the victim's shoulder", as implied by the name of this attack.

← Back to the CWE list